It’s very tempting to start this entry with a nostalgic description of all the old hardware and software I’ve ever worked with, but I’ll skip that part. When talking to other programmers, I’m more often than not astonished by all the different paths people follow on their way to this profession. Despite being immersed in a very similar spirit of time, even most programmers of similar age to me arrived where they are via their own unique way. So I thought it could be an interesting exercise to list the milestones on my own path that seem important in retrospect. Who knows whether skipping any of these would have had a profound effect on my career, but here they are.

8-bit assembly and the discovery of abstraction

During the school years, before I first started fiddling with programming in Z80 assembly, my view of computers was very romantic. When you encounter assembly, it totally sobers you up. This is partially due to the fact that it reveals the computer completely in front of you, down to the hardware rock bottom, so that no more mystery remains about it.

At that time I had a go at the demoscene, which forced me to think hard about the programs I was writing. Here’s why: to the high school version of me, the assembly program was just a sequence of elementary steps, nothing other than a straight flow of instructions. I don’t remember using any sophisticated data structures, or organizing code in any way, except minimal split into procedures. It obviously led to a code that was never up to the serious performance standards of the demoscene. Nevertheless it was inconceivable for me at first that some alternative way of writing programs may exist. Over time, different ways of looking at the same small operations slowly started revealing themselves to me. For example, if you need a series, you don’t necessary need the loop. A blob of data generated at right in front of your program counter becomes code. Stack is just a memory, and so on. I entered university suspecting that there was more than one way to describe what you want the computer to do — by abstracting yourself away from the sequence of instructions — and that this is actually important.

Pascal and the discovery of void

During the first university year, the teaching language of choice was Pascal and the teaching style of choice was asking students to implement many standard data structures in it. This wasn’t difficult in itself, and my main memory of that time was struggling to deal with the “absence” of something, like a search tree that has no nodes. Adding a node to a tree is simple, you just hook to a node’s parent, but how do you add a node to an empty tree? On one occasion, an algorithm required several nested loops with the innermost loop’s both lower and upper bound controlled by the outer ones and both starting from zero, which eliminated the inner loop for the at least one iteration. At 18, I found it so difficult to reason about the collapsed loop, that I instead chose to perform whatever the first iteration required outside of loops — by hand. My dorm roommates who were less clueless about writing programs gave me some hard time laughing about that. That was the beginning of my learning to juggle “absent” code or data in my head.

This is continued in part two.