Bad, good and great programmers

A recent tweet by Cory House started my brain a-twitching:

One of my new favourite interview questions: What is the difference between a bad, good and great programmer? Which are you and why?

I’ve worked with all three kinds, and thinking about the question of what the differences are I realised (not for the first time) that pure coding skill is nowhere near all the story. This blog post explores what else may put you in one category or another. First some assumptions:

As this is an interview question I took “programmer” to mean “one who works in a software development team”
The basics of being a decent employee – turning up on time, dressed appropriately and at least partially sober – are a given
The programmer can actually code to a decent level, “decent” being whatever is appropriate to fulfil the job requirements
The employer doesn’t just want a code monkey. I hope and trust that there are very few companies who want programmers to just “shut up and write the code”, and if you find yourself working for one of those then get out as soon as you can.
I’m talking to traditional programmers (C#, PHP, Python, Ruby, JavaScript etc) rather than front-end (HTML, CSS) but many of the points are applicable for any type of developer

Bad programmers

Generally, bad programmers are easy to spot. They write code that generally works (if they didn’t they’d be out of a job), but suffer from many or all of these issues:

They have a bad attitude towards non-geeks, whether non-technical colleagues or users
They have a bad attitude towards other programmers whose views don’t closely match their own
They know it all, or at least everything that matters
They are opinionated about tech; either wanting to use cutting edge stuff because it’s cool (whether or not it gets the job done) or they only trust very established things and refuse to look at new tech
Their communication skills are poor, and they have little desire to improve
They may fulfil specification requirements but don’t go any further than coding for exactly what is written
Their sense of humour is non-existent, or is harsh and rude
They don’t ask questions, and don’t make suggestions

It’s important to take all these points on balance. Some people may be shy, which could mean they don’t ask questions or make suggestions. But a good manager or lead developer will help staff to fulfil their potential, for example by encouraging the quieter members of the team to contribute.

The code from a bad programmer may also have these hallmarks:

Lack of comments, or comments that state the obvious and don’t tell you *why* they coded something a particular way
Obtuse, gnarly, over-abstracted, over-complicated architecture (at any level: method, class, subsystem or app)
Inconsistent or otherwise poorly-considered naming of variables, methods and classes
Lack of attention to detail, such as proper sanitisation of inputs for security
Copy-and-paste-itis. Bonus points if it’s clear they didn’t understand how the copied code works.

You get the picture. We’ve all written code like this at some point and we should be careful not to think of a programmer with less experience, or one who is struggling with a complex task, as a bad programmer. Bad programmers have a bad attitude, and even if they can mask that attitude for a while, eventually the mask will slip.

Good programmers

Good programmers, like bad, are known by their attitude as well as their technical skill. Note that a good programmer may not have as powerful code-fu as a bad programmer, but their attitude and “soft” skills more than make up for any technical shortcoming. (This is not to say that someone who doesn’t know XML from XTC can be classed as a good programmer; the basics mentioned above still apply.)

You’ll know a good programmer because:

They have a good, helpful and professional attitude towards colleagues and customers/users
They have respect for other programmers and are willing to listen – and when necessary respectfully disagree – to other points of view
They have a good sense of humour and contribute to a good atmosphere in the team
They exhibit attention to detail, and can spot the holes and inconsistencies in a specification
They are respected and liked by other members of the team
They don’t make rash decisions and have learned to weigh the pros and cons of different technologies
They can put themselves into the users’ shoes and make good decisions about how their code affects the user interface and experience
They have good communication skills, and avoid jargon wherever possible when communicating non-technical people

These kind of people make a team better, and so help an organisation to be better. But it’s not just soft skills, they also have a good grasp of technology:

Their code is readable and well-formatted, adhering to any coding standards adopted by the team
They choose sensible, descriptive and unambiguous names for classes, methods, properties etc
Their comments are actually useful: not just telling you what a method does, but why it is used – and any non-obvious things you may need to watch out for
Their architecture choices (at method, class, subsystem or any other app level) are clear, well-abstracted and only as complicated as it needs to be. My rule of thumb for “good” architecture: either you would have written it the same way, or you see why they did it their way and don’t need to change it much.

No doubt anyone with a bit of experience working in a development team can think of several more hallmarks of good and bad programmers. But what about great programmers?

Great programmers

While many people would roughly agree what makes a programmer good or bad, deciding what criteria to use to distinguish the greats ones is much more subjective. Here are a few points I can think of that, in addition to everything I noted for a good programmer, would class a programmer as great:

They are aware not just of the users’ needs and the specification, but the organisational environment. They can guide the development of an application so that it serves wider organisational purposes: in the case of a business to serve users and be commercially successful.
Their communication and “people” skills are highly developed; for example they can explain complex technical concepts to non-geeks in an understandable, even entertaining, way
They are known in the team as the person who will help you out with a problem: partly because they have the experience and knowledge, but also because they make themselves available to help others
They keep themselves up to date with technology – not just their own area of expertise but the wider world of development, UI, UX, project management and business
Their thinking in terms of abstracting code takes into consideration not just the next 3 months but the next 3 years (that *almost* means they can tell the future)

In short a great programmer has an expansive view of technology, of people, of the future of the organisation and applications they work on. They are part psychologist, part entrepreneur, part designer, part storyteller.

A couple of years or so experience and taking pride in what you do will take you from being a bad programmer to being a good one. But to be a great programmer takes a special kind of person. The kind that, eventually, will do something really special. Like write a great book, start a great company, write an amazing Open Source project.

There’s lots I haven’t mentioned here (such as writing testable code).For more on this subject check out these links: some are articles and essays, some are great programmers.