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.