What Makes a Good Programmer Good?

I’ve worked with a lot of programmers over the years — some of them super
amazing, and some distinctly lackluster. As I’ve had the pleasure of working
with some very skilled individuals recently, I spent some time thinking about
what I admire in them. What makes a good programmer so good, and a bad
programmer so bad? Or, to mangle English a little bit, what makes a good
programmer good?

Based on my experiences, being a great programmer has nothing to do with age,
education, or how much money you make. It’s all in how you act and, more deeply,
how you think. I’ve noticed a consistent set of habits in the programmers I
admire. More than knowledge of their chosen language, deep understanding of data
structures and algorithms, or even more than years of on-the-job experience —
the way they communicate, the way they conduct themselves, and the way they
approach programming speak volumes as to their amazing level of skill.

Certainly there’s more to being a good programmer than anyone can enumerate,
and I wouldn’t judge any programmer solely based on the presence (or lack) of
these practices. But I do know wisdom when I see it, and when I see a programmer
expressing these traits, I think, “This person really knows what they’re
doing.”

They do their research

Or “measure twice, cut once.” Or “Google it.”

Whatever you call it, most programming problems you’re likely to encounter
have been solved in some form already — Ecclesiastes had it right in observing
there was nothing new under the sun. In the form of libraries on GitHub, blog
posts on the Internet, or just getting in touch with experienced individuals,
good programmers know to do the research before they try to solve a problem.

I’ve seen even great programmers rush to solutions: but the worst programmers
I’ve worked with never consult others, and as a result do huge amounts of
duplicate work or tackle issues in precisely the wrong way. And unfortunately,
they end up paying for their mistakes later.

They read error messages (and act on them)

This includes desymbolicating stack traces. Yes, it’s ugly and unfortunate —
but if you’re not willing to do it how are you going to know what’s wrong? The
most effective programmers I know aren’t afraid to dig deep into problems. The
least effective see there was an error but don’t even bother reading the error
message. (This sounds ridiculous but you’d be surprised how frequently I run
into it.)

To take this a step further, great programmers see a problem and hunger to
solve it. Reading error messages are for them just the beginning: they’re
anxious to dive deep into the issue that it represents and figure out what’s
going wrong. They’re not interested in passing responsibility, they’re
interested in finding a solution. The buck really does stop with them.

They go to the source

Documentation, tests, people: these things lie. Not intentionally, but if you
want to know exactly how something works, then you must view the source
yourself.

Don’t be afraid if it’s not a language you’re super familiar with — if you’re
primarily a Ruby programmer and you suspect there’s an error in one of Ruby’s C
libraries, go crack it open and have a look. Yes, you might not get it. But who
knows? You just might, and you stand a way better chance than if you didn’t try
at all!

If you’re in a closed-source environment then this becomes a lot harder,
unfortunately, but the principle still applies. Poor programmers have little
interest in viewing source, and as a result problems flummox them much longer
than those who are willing to do some research.

They just do it

Good programmers are driven to act. There’s a compulsion in them that can be
difficult to control: they’re implementing a solution as soon as they identify a
problem or see a new feature request, sometimes too early and sometimes too
aggressively. But their instinctive response to a problem is to tackle it
head-on.

This can be troublesome at times — but their enthusiasm is a crucial part of
being good at what they do. While some might stonewall or wait for the problem
to go away on its own, good programmers start solving.

To put it more simply (and, perhaps, too obviously): if you see someone
excitedly grabbing problems and acting on them, chances are you have a good
programmer on your hands.

They avoid crises

This is mostly a bad programmer trait: they tend to bounce from artificial
crisis to artificial crisis, never really understanding one before they move to
the next. They’ll assign blame to the wrong parts of their program and then
spend hours debugging something that works perfectly well. They let their
emotions get the better of them, trusting gut feelings rather than careful,
explicit analysis.

If you hurry through a problem — or even view each problem as a
world-shattering catastrophe — you’re more likely to make errors or not address
the underlying issues. Great programmers take the time to understand what’s
going wrong, even when there really is a catastrophe: but more than that, they
treat regular problems as issues to be solved. Thus they solve more of them more
accurately, and do so without raising the tension level of your
organization.

They communicate well

Ultimately, programming is a form of communication. Being able to succinctly
and eloquently express your thoughts is as crucial in writing code as it is in
writing prose — and I’ve always found that those who can write a pithy email,
elegant status report, or even just an effective memo will also be better
programmers than those who cannot.

This applies to code in addition to English. It’s certainly possible to make
a one-liner filled with parenthesis, brackets, and single-letter functions: but
if no one understands it, what’s the point? Good programmers take the time to
communicate their ideas properly in whatever medium they’re using.

They are passionate

I think this might be the most important aspect of a good programmer (and
perhaps the part of this list most generally applicable to fields other than
computer science).

If you truly care about what you’re doing — if it’s not just a job, but a
hobby, an interest, even a fascination — then you have a major advantage over
anyone else in your field. Great programmers are always programming. Their peers
will clock out at eight hours a day: not out their job, but of their field in
general. They don’t have programming side projects or much interest in
contributing back to the community. They’re not constantly trying neat new
methods and crazy programming languages just to see how they work.

When I see a programmer who’s doing their own hobby projects on the weekends,
who’s involved in the creation of the tools that they use every day, who’s
fascinated by the new and the interesting: that’s when I really know I’m looking
at an amazing person. Ultimately great programmers view their profession not
just as a means to make money, but as a means to make a difference. I think
that’s what makes the best programmers who they are. Coding, to them, is a way
of shaping the world. And that’s what I truly respect and admire.

Josh Symonds performs devops and server wrangling on cloud-scale
infrastructures, deploys amazing web applications with Ruby on Rails, and
creates awesome iOS apps with Objective-C and RubyMotion. He is founder and CTO
of Symonds & Son, a development shop
focused on quality and excellence.