Rob Cook

Home | Donate

Role of a programmer


A common mistake people make - even those who work as programmers - is to see the purpose of the job as making things work. This is only partly true. Making things work is the purpose of learning to program. Once you grasp that skill, the principle goal is one of communication. It is not enough merely to make things work, instead it must be done in such a way that others can readily understand how they work. A programmer must package the code so that it's workings are clear to other programmers, can easily be modified or extended, and introduces a minimum of cognitive load on the reader.

Many techniques, along with many, many books exist on the subject. Sadly it seems the current state of the profession is such that a programmer must be seen to pile one technique atop the other in pursuit of "best practice", and the approval of other programmers. I think this is a mistake. I think if programming continues in this vein it will eventually eat itself.

I make no secret of my disappointment with object oriented programming. Studied, practised, and applied over many years, I feel it leads to bloated abstraction and difficult to understand programs. It is easily misapplied even by skilled developers. I'm of the increasing opinion that a handful of well recognised data structures are better than a plethora of custom defined classes.

There are I think only two key skills a programmer need learn to write code that communicates it's working clearly to other programmers. They are naming things, and organising things. If you can do that well, you can pretty much forget the other stuff. Give me a simple procedural codebase with precise names for things and a logical layout, and I'll be a happy man.

This is not merely old age complaining. In most cases I find clever techniques are simply not needed. Indeed they often get in the way of conveying how a program works. Everything you add to a program increases the cognitive load on other programmers who have to work with it. Adding classes, introducing an abstraction, these things should be done sparingly instead of without thought. Frameworks and third party packages should be carefully considered before being introduced.

To write good code focus on the basics. Get good at naming things, find a home for each piece of code, and every time you make a change review if the naming and organisation still makes sense.