A Comment on Comments In my first programming class in college, my teacher handed out two BASIC coding sheets. On the board, the assignment read “Write a program to input and average 10 bowling scores.” Then the teacher left the room. How hard could this be? I don’t remember my final solution but I’m sure it had a FOR/NEXT loop in it and couldn’t have been more than 15 lines long in total.

A Message to the Future Maybe it’s because most of them are smart people, but in all the years I’ve taught and worked side-by-side with programmers, it seems that most of them thought that since the problems they were struggling with were difficult that the solutions should be just as difficult for everyone (maybe even for themselves a few months after the code was written) to understand and maintain. I remember one incident with Joe, a student in my data structures class, who had to come in to show me what he’d written.

Act with Prudence “Whatever you undertake, act with prudence and consider the consequences” Anon No matter how comfortable a schedule looks at the beginning of an iteration, you can’t avoid being under pressure some of the time. If you find yourself having to choose between “doing it right” and “doing it quick” it is often appealing to “do it quick” on the understanding that you’ll come back and fix it later.

Apply Functional Programming Principles Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because emergent properties of the functional paradigm are well positioned to address the challenges posed by our industry’s shift toward multi-core. However, while that is certainly an important application, it is not the reason this piece admonishes you to know thy functional programming. Mastery of the functional programming paradigm can greatly improve the quality of the code you write in other contexts.

Ask “What Would the User Do?” (You Are not the User) We all tend to assume that other people think like us. But they don’t. Psychologists call this the false consensus bias. When people think or act differently to us, we’re quite likely to label them (subconsciously) as defective in some way. This bias explains why programmers have such a hard time putting themselves in the users' position. Users don’t think like programmers.

You’ve probably been there too. At the beginning of a project, everybody has lots of good intentions — call them “new project’s resolutions.” Quite often, many of these resolutions are written down in documents. The ones about code end up in the project’s coding standard. During the kick-off meeting, the lead developer goes through the document and, in the best case, everybody agrees that they will try to follow them. Once the project gets underway, though, these good intentions are abandoned, one at a time.

Beauty Is in Simplicity There is one quote that I think is particularly good for all software developers to know and keep close to their hearts: Beauty of style and harmony and grace and good rhythm depends on simplicity. — Plato In one sentence I think this sums up the values that we as software developers should aspire to. There are a number of things we strive for in our code:

Before You Refactor At some point every programmer will need to refactor existing code. But before you do so please think about the following, as this could save you and others a great deal of time (and pain): The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code. This will help you understand the strengths and weaknesses of the code as it currently stands, so you can ensure that you retain the strong points while avoiding the mistakes.

Beware the Share It was my first project at the company. I’d just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned — commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt so ready for came as a rude awakening — reuse was frowned upon!

Check Your Code First before Looking to Blame Others Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that’s broken. Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software.