Recently, I heard a quote that has stuck with me. I can’t remember word-for-word how it was used, but the paraphrase is:

If you’re the smartest person in the room, then you need to find another room.

It sounds a little weird (and potentially even a little offensive) without knowing the context.

In short, it was said during a conversation about leadership and the importance of surrounding yourself with other smart people (well, smarter people), knowing that just because you may be the first person at a place doesn’t make you the smartest, and not being afraid to ask for insight, criticism, and advice in a variety of areas.

The topic had nothing to do with programming, development, or anything remotely close to that; however, I’ve been thinking about not only how it relates to this particular industry, but how it relates directly to me and my career.

The Smartest Person in the Room

To be honest, I think very few people would actually admit to thinking that they are the smartest person in the room (or one of the smartest people in the room), but I’m sure that many of us have experienced someone else doing that at some point during a conference, a meeting, or some other event.

It’s really lame to feel to come across someone like that, isn’t it? It can even be worse to be accused of something like that, but if are to look at it from the other perspective, what’s the option? To admit that we’re not the smartest person in the room?

Exactly – but what’s wrong with that?

If there’s one thing that open source software development – let alone past generations of computer science – can teach you, it’s that there is always someone smarter and better than you at something (and more often than not, some things).

When you embrace that and understand that, it’s kind of liberating, isn’t it? More specifically, it gives you the freedom to ask why, to contact other people, and to ask questions without feeling embarrassed.

As much as I love writing on this site, trying to help others, and generally working with other contributors to build things, there are so many areas in which I need to mature.

Here’s a bit of a scattered list of three things that came to mind when thinking about this.

1. Coding Conventions

When it comes to writing code in a specific environment, I’ve been pretty clear about my opinions on how I think we – as programmers – should adhere to said environments coding standards.

But none of this is written in stone.


In fact, just this weekend, I contacted a fellow developer to ask about his opinion on coding techniques, opinions, and even documentation in an effort to try to work to make the code I’m writing better.

He’s more experienced and better at it than I am, and he’s willing to help. Why would I shy away from that?

2. Development Tools

One of the toughest parts of our job is keeping up with all of the technologies that exist today.

In fact, it say that it’s a little uncomfortable as to how quickly new tools are being released and shared in an effort to make things easier. But the catch-22 is that they often end up being yet-another-thing-to-learn that may actually get in the way of making things easier.

After all, how can we make things easier before we learn the tools that are supposed to make things easier?

Years ago, I used to feel this compulsive need to make sure that I was familiar with each library, framework, or tool that was available in my scope of work so that I’d be able to pick it up and keep moving with work, if needed.

But that’s unsustainable.

In fact, I think that’s true now more so than ever because more things are being released more quickly than they once were. That makes it difficult not only to keep up, but also to actually focus on building important things.

Then, at some point a few years ago, it became clear that I didn’t have to keep up. And the same can be said for my peers, as well. Sure, it’s important to read about the new things that are released so that we have awareness of them, but this is different in having a deep knowledge of how to use this.

For example, this is why I still use CodeKit more than Grunt – it suits my needs just fine, it gets the job done, and I’ve yet to find a compelling reason to switch.

This isn’t to say I haven’t used Grunt as anyone who contributes to WordPress core likely will, but this is to say that I don’t use it daily, nor do I feel a reason to do so.

And when people claim “oh, but you can do so much with it,” that is not a reason to begin using it any more than “oh, but the car drives so well” is a reason to buy a new car. What if the set of tools I’m currently using are allowing me to do exactly what I need at an efficient rate?

All of that to say, other people are going to have other tools that they use rather than the ones that you have and that you use, and that’s fine – I’m always interested in hearing what other people opt to use to get their stuff done, but that doesn’t mean I’m always looking to be convinced as to why my own toolbox is primitive.

Sometimes, I just want to know what’s out there should I hit a wall in my own work.

3. Old Blog Posts

One of the conundrums of blogging about your experience in writing code or thinking through problems is that, at some point, you’re going to become better at what you do.

Your approach to problem solving is going to change, the way you write code is going to change, and the conventions that you use will not always be the same.

This means that things that you wrote two years, one year, or even six months ago may not represent the type of developer that you are today, yet someone stumbles across your content in Google and begins using your material, and it’s not the material you’d want them to use.


So what are we supposed to do?

Honestly, this is one of those things that bothers me a little bit. I try hard to keep older posts updated with notes at the top of the content indicating when I have a more updated post, but I’m not great at it.

At this point, I also try to make sure that a lot of the code that I share on the blog is done so using gists so that I can update the gist and the post, in a sense, updates itself.

But this is why dates matter, right? We can’t expect to keep all of our content updated especially as it shows somewhat of a journal as to what we’ve experienced, discussed, thought, and worked on over time.

It’s not unreasonable to expect our readers to check the date on the post, to search the blog, or to look at related posts and see if there isn’t something more relevant than something that was written in January 2012.

Regardless, this doesn’t mean that I think that we – as bloggers – shouldn’t take proactive steps to keep our content somewhat updated.

I just think that it means we can relax a bit as it relates to keeping however many articles we have published up-to-date.

There’s Always More

I don’t think anyone can possibly share all of the things they’re working on or working with that has room to improve, but that’s not the point of what’s above.

The point I’m trying to share – admittedly, through a relatively scattered list – is that there is always room to better yourself, that we shouldn’t be afraid to ask for it, but that there’s also a time and a place to do so.

In the areas that you know someone else is better, don’t be afraid to ask for advice. In the areas in which you’re proficient, be aware of what’s available, but don’t feel the demand to have to learn it immediately, and in the places in which you have some control over how something is perceived, don’t forget that other people have responsibilities to act on the content (such as checking dates, other posts, and so on) other than just you.