What makes a good programmer?

This subject was being debated on a newsgroup that I subscribe to. I have been the matter some thought. While I am not personally a good programmer, I know quite a lot of people who are.

Here are some suggested rules that I would offer.

1. Except for video games programming, starting with the UI is the wrong place. Marketing like a UI. For many people in Marketing, if you have the UI then you have the application. After all if it looks right then what is there left to do? We all love Marketing folk. They see the world in such a different way.

2. Think in terms of data flow. This is obviously appropriate in applications programming but it is true of systems programming as well. A resultset is clearly data but then, so is a device context or a security descriptor.

3. Simple is better. Go for an efficient algorithm but don't micro-optimise. It is rare that you will need to do so and it will generally only be for a critical path.

4. Consider carefully if your application needs to be performant or scalable. Some things need to be both and that is hard to do. Having a scalable app when you need a performant one is not good. Having a performant app when you need a scalable one is terrible.

4. When implementing a module, consider how to test it. Most people do not like creating test harnesses. I can understand that. It is very dull. It also takes time that could otherwise be spent on developing code that you can sell. However, this fundamentally ignores real world economics. Most applications spend a lot longer in their maintenance phase than their development phase. Very often, this costs more than the initial development. Profit = income - cost. Reducing the cost a lot can be better than increasing the income a little. Unless your time costs nothing, this makes many accepted practices of debatable value.

5. Do not confuse activity with progress. I had one manager in a previous company who used to get worried if he couldn't hear keystrokes because that meant that we were not working. I am a big fan of thinking about any non-trivial problem for at least an hour. Some big problems need a couple of days. Thinking seems to bear a lot of resemblance to doing nothing but is much harder work.

6. Record at least the bare minimum of information. You don't have to write War and Peace but the design decisions and the reasons behind them should never be lost. Self documenting code is a nice idea but assume that the person reading the code is stupider than you. That person could well be you, dragged out of bed to fix a bug 3 years later after a really good party. Ok, most programmers don't get to go to really good parties but we can dream.

7. There are two sayings: "Never test for an error condition that you don't know how to handle" and "It was hard to write so it should be hard to understand". Neither has any validity.

8. Do not rely on undocumented anything.

9. When reviewing code, leave it a couple of days after writing it otherwise you will read what you thought that you wrote. If you can't do this, best to get someone else to review it.

10. Remember Dykstra's advice. If you can not clearly explain to someone what your program is going to do then you are not ready to start writing it.

Signing off

Mark