Making the Good Programmer ... Better
One of the hardest questions to answer in our industry surrounds the issue of what qualities differentiate a 'good' programmer from the rest? I just read Eran Galperin's "What makes a good programmer?" post on the subject today, and thought that I would share my list of those essential skills and traits that I would look for in anyone on my team.
Adaptable and Flexible
It's always been the case that you need flexible developers on your team, but at no other time in the short history of software development has it been so important. If you're usually the person that does the UI coding, we'll want you to dig into the persistence layer. We might even want you to go do some testing, which you'd usually run a mile from. You may have been hired as a Java programmer, but we want you to write our next application in .NET, and maybe it's best to accept that. It's the world we live in, and you'll be all the better for it. Multi-tasking is as important as being an expert in one narrow field. At the time it might not be pleasant, but your CV will impress as your next employer sees what you're willing to do.
Maybe you went to university and studied computer science because you heard that was where the money is. A few years in, maybe it was not as rewarding as you expected, and you start getting disillusioned. A great programmer will love coding - maybe not the code their working on right now - but in general you should be someone who enjoys building something to solve a problem for someone. When you get a chance to have a cup of coffee at the desk you'll be going to sites like JavaLobby, and finding how to improve. When you hear about Google's latest move, or the newest web framework that everyone's talking about you're interested. After all, why wouldn't you be - any ripples in the software development and IT landscape are going to reach you eventually.
A Pragmatic Thinker With a Scientific Mind
The Pragmatic Programmer is one of the most important books in the software industry. Not only is it timeless in the way that it doesn't tie itself down to one language, but it provides a great set of guidelines. Thinking about the consequences of your actions is essential when working in a team, and my favourite metaphor is "No Broken Windows". Maintain a consistently high standard in all your work - testing, coding and documentation alike - and others are likely to follow your lead. Let that slip however, and things can take a turn for the worse.
The best way to stay fresh, despite what programming language is currently in fashion, is to keep thinking scientifically. Any problem can be broken down and all languages have a similar set of a characteristics. While this may be natural to some and not to others, the main thing to do is to keep questioning yourself. Can you write this piece of code better? Could I present this information in a more structured way? Mind you, the answer is almost always yes, so use pragmatism to find a reasonable end to this questioning!
When I started programming I would just dive right into my latest task. And that was fine back then, as I was just beginning to get assigned tasks. A few months later, I went to a talk on time-keeping, and learnt a lot that I still utilise today. A good programmer will be well organised, perhaps sitting down at the end of every day to list out the tasks for tomorrow. If someone needs something else done, at least I can refer to this list and see where I can fit it in, or what else will get affected. A useful tool for this is Mylyn, a task based Eclipse plugin.
It pays to be organised on the code and documentation side of things too. An organised approach to packaging, class and variable naming and design, makes everything much easier to follow for others on your team, and for you when you look back at something after a few months.
Reasonable and Approachable
The majority of us work in team environments, so we have to possess people skills. All the great programmers who have respect are those who are approachable. You need to make time for those who feel they need your help, whether that's a developer with a code problem or a project manager wondering about your estimates. Along with these skills, you should endeavour to be clear in all your communications - the worst thing that can happen after any meeting is that all parties walk out more confused than before.
Being reasonable can't be underestimated. No matter what your position in the organisation, some negotiation will always be required. Maybe something can't be done that way you know is right, but in the interests of moving forward, it's good to be able to find some half-way point, rather than being too head strong.
You can't assume that someone else will tell you what the right thing to do is, and when. Maybe you need to move to the latest version of a framework even if you're close to a release -especially if you feel there's some benefit there. If you're enthusiastic about your job, then you've probably been keeping up to date with what's available. And if you're flexible, you won't mind sacrificing part of your lunchtime, or your spare time at home, to prototype and see if it works. Every chance has it's costs, but all need some investigation rather than charging in blindly - be prepared to take that time.
Taking chances applies to your career too. Maybe this new startup is worth joining? Maybe you're just comfortable in your job right now and you need to challenge yourself. You'll notice there's a common theme in any success story - the chance was worth taking, and the chances that were wrong calls help you learn.
Takes Pride In Their Profession
If there's one point that you can take away and implement from this article it's this one. Take pride in what you do. Everything else falls into place, and you will become a great programmer if you take this advice. It's a lesson learned from all professions - the people we regard as great are those who feel that their industry is the most important, the ones that want to believe that the world needs great programmers.
It's difficult to do if you don't love programming, but it's still possible. You've to ask why you don't like your job right now and find ways to address it. If you're writing tedious code in the day job, maybe joining an open source project will kick off the spark for you again? You can spot developers who take pride in their profession a mile off, from the quality of the code they write, to their enjoyment at being given a difficult task.
This is just my opinion, and it doesn't hit any of the real technical aspects of a developers job. Are there any other points here that I've missed that help produce the Über-programmer? From the great developers that you have known, what would you describe as their outstanding traits?