When I first started programming for a living, I worked at a small start-up in Malvern, Worcs in the UK, called The Weather Company (or, at least, I think it was called that, it was a long time ago. In fact I should caveat all of these memories by saying that my memory, like nostalgia, is not what it used to be). There I coded in C. This was in the summer before I went to university. I had had jobs before that involving computers. I had a gig for an art business typing up up form letters, and hundreds of addresses, mail merging them and printing off the letters, stickers for the envelopes and putting letters in addressed envelopes altogether. That wasn’t programming, but it had a similar focus on getting stuff done with computers, end-to-end. I was given a computer system that was pretty much blanco when I started and my job was to take all the inputs and produce letters we could send out which would offer the right paintings to the right customers. Anyway, this was the first job in which I was really getting paid to program.

It was also the first job in which I had a mentor to help me. The company had a handful of programmers and I remember Andy as being the main programmer who wasn’t one of the founders. Mostly Andy came in to help when I called him over because of a bug in my program. He was a big fan of Zen and the Art of Motorcycle Maintenance, that well-known programming tome, and that was the first time I read that book. He explained that successful debugging of programs mostly came down to resolving a misunderstanding. A programmer starts off thinking that the program is wrong in some way and feel that it’s his or her job to find out what’s wrong with the program. By the time the bug has been found, something miraculous has occurred because the programmer has realised the program was correct all along but there was something incorrect in his understanding of how the program worked. Once how the program worked and programmer’s understanding of how the program worked were better aligned, it became very simple to correct it.

Andy’s first rule of order was for me to read my program out loud to him and explain what it did line-by-line. In C programming, the most common error is a missing semi-colon at the end of a line, and inevitably, at some point during the reading out of my program, I would cry out “Oh, I know what’s wrong!” having spotted the miscreant punctuation, or a more fundamental problem in the logic. Sometimes, although rarely, I’d get through a whole read out of the program without identifying the problem. That often clarified things enough that upon starting over I’d see the problem.

Andy involved himself very little and used to joke, semi-seriously, that he wasn’t actually needed in the process. He threatened to make a life-size cardboard cut-out photo of himself, or maybe he actually made one; I admit to my memory being rather hazy here. He said that I would get 99% of the benefit of his wisdom by reading out the program to the cardboard cut-out and in the 1% of the cases when that didn’t work, I could call him over. By removing himself from the equation it became clearer where the wisdom was really coming from.