August 16, 2010

Rules of Programming


Coder, programmer, software developer, IT engineer. Whatever it is called, my profession has changed the way I think. I started learning to program 23 years ago as a hobby, started studying it seriously 17 years ago and have been doing it as a job for 13 years. Now I seem to think a great deal straighter than I did before – straighter than when I was in my early twenties and studying postgrad logic. By thinking straight, I mean following a chain of logical rules to their conclusion – determining what they imply and where any gaps in the rules or strange corner cases exist. Straighter in that I can quickly work out the logical chain, identify problems, and ignore unimportant avenues of thought. I don’t tend to take the scenic route anymore; I go straight to the destination.

This makes sense to me, most of my job as a programmer is thinking straight. Writing the code is very easy once the language is mastered. Instead, the job comes down to solving problems with code. At the start of a project this is done by precisely specifying the steps of the solution in code. No ambiguity is allowed and all the possible situations must be covered. Edge and corner cases will cause bugs, so must be considered. As the project progresses, any changes or additions must take into account interactions with the body of rules already encoded in the existing codebase. As the complexity of the system increases, so do the possible interactions and it gets harder to run through them. This is one of the reasons big systems tend to have so many problems and why experienced coders try to keep things as simple as they can.

It seems reasonable that I have trained myself this way. I have far more than the suggested 10,000 hours of practice. A back of the envelope calculation suggests I’m close to 50,000 hours. That much practice is bound to etch a groove in my thought process. Sometimes that groove is too easy to follow and I get lost in thought, monomaniacally thinking about a system. In software development this state is often sought out and is no bad thing, except in your interactions with other people. Sometimes I wonder if a similar process is at work in other professions, perhaps with less than ethical results.

I studied a Business degree mid career (so far). It hasn’t been of huge career advantage to me, as I have learnt I am happiest just coding away. However, I did learn the basics of some other professions. There was a semester of accounting and another of contract law. In both courses the lecturers spent some time detailing how case law or accounting rules were applied – explaining that it wasn’t intuitive and you just had to follow the general rules. What!? I found it quite simple to apply the rules and I achieved good marks with little effort. I just did the same thing I did every day, simply swapping lines of code for case law.

My impression is that both law and accounting use similar thought processes to programming – applying rules to reach a desired end state. While programming uses exact statements of software logic; law and accounting use the written language in laws, cases or standards. This natural language is more malleable and open to interpretation. I sometimes wonder if people in other professions get similarly lost in their rules. Focussing on just beating the problem as presented to the exclusion of other concerns. This could offer a generous excuse for the motivation behind results like tax evasion, or dodgy financial products.

comments powered by Disqus