Thirty Years of Experience - A Perspective, part 3

I think it's time to finish off this set of posts before the title has to change to 'Thirty-One Years of Experience'.

I started off trying to work out how much use thirty years of programming experience was really worth, given that so much of it was in technologies that are no longer extant. I've come, sadly, to the conclusion that much of the first fifteen years or so can be safely skimmed through by anyone reading my CV. In the field of Software, specific knowledge of languages, libraries and operating systems dates all too quickly. If you're not constantly learning new technologies, you can end up fit only for maintaining legacy code.

And yet I still hold that I've gained something from having programmed since 1980 that I wouldn't have now if I'd only started in 2000. Thirty years of debugging have given me an intuition for tracking down bugs, to the extent that sometimes I can't even explain to myself afterwards how I got to the solution. I believe this is because debugging is quite often a logic problem, and practice makes you better at it irrespective of what language or platform you're using.

Over thirty years I've seen trends come and go, supposedly 'killer' languages have their day and then fall away (Ada, you promised so much!). It would be nice to say that my experience lets me spot which upcoming technologies are the ones to follow, and which are going to fail, but that would be untrue. I write as someone who once learned Forth.

In the end, it's not so important how much my experience is worth. The bottom line is that, after nearly three decades in the field, I still feel as I did when I received my first pay packet back in 1980: that it's a nice life when you get paid to do something you'd willingly do for a hobby.

Thirty Years of Experience - A Perspective, part 2

Even if the languages I wrote in are dead, the knowledge of how to write good software is timeless.

There are some problems with this, though. Many of the techniques for good coding that I was taught, I no longer agree with. Sometimes I completely disagree with them. At university I was taught that there should be as many lines of comment as there are of code, which led to absurdities like:

C    Increment counter
     I = I + 1

In my code nowadays, comments are the technique of last resort for explaining what's going on. I much prefer to use plentiful, sensibly named functions to express my intent.

Nor do I any longer believe that every function should have only one return statement. Maybe that made sense once, but modern compilers are quite capable of coping with multiple return points. The emphasis on speed of execution and compactness that I learned at University also looks quaint. For most of my work, the most important quality that software can have, after correctness of course, is readability, so that the poor git who has to debug it three months later (quite often me) has a sporting chance of understanding it. Speed and size optimisation almost always reduce comprehensibility.

Another point that occurs to me is that I'd been programming for 16 years before I came upon Object-Oriented Design, and 25 before I had a chance to try Test Driven Development. I don't have any of my code from 16 years ago (what with it being the intellectual property of my former employers and all), but I rather suspect that most of the good practices I was using then haven't proved portable to the current day.

This isn't looking too good for the usefulness of my 30 years of experience. Let's look at my second argument instead.

I have acquired a sense of perspective, useful in a field like software engineering where the landscape changes at exponential rates.

As many others have already noted, IT is a field that undergoes exponential change. Processor speeds, memory size, disc capacity, etc. are all doubling every year or two. We all experience this; however, you have to be a certain age for the full magnitude of what's going on to sink in.

From this side of 50, I have a sense of perspective that younger (more energetic, faster learning, possibly more talented, not that I feel in any way threatened) programmers still lack. A good example of this involves the prefixes we use for size and speed. G for Giga is typical nowadays. When I started my professional career in 1980 though, memory size was typically measured in Kilobytes, and disc space in Megabytes. The HP1000 I worked on in 1980 had just 128K of RAM (and you could only address 32K of that at once). Three or four years later when my department was buying a Comart Communicator, my boss had to weigh up the pros and cons of getting one with a 10 or 20 Megabyte hard drive (in those days referred to as a Winchester drive).

My favourite example: in the mid-eighties Cambridge University was upgrading its mainframe system. I forget what computer exactly they were buying (though I remember it was replacing an IBM 3081), but I listened in stunned silence when a friend told me that it would have 50 Gigabytes of online hard drive. 'Giga' was new then, so I had to take a second to work out that that meant an astounding fifty thousand Megabytes! And that was to service a whole University. I have three times that much space in my Western Digital Passport external hard drive now, and I've nearly filled it up. Also, I've just noticed that, for the price I paid for it less than two years ago, Amazon are now selling the 500Gb version. And there's also a 1 terabyte version! Tera is coming to personal computing. That's a million-fold increase in disc space in a couple of decades. Also, what used to need its own air-conditioned room now fits comfortably in your pocket.

All this is starting to make me sound like some boring old f**t, going on and on about what things were like when he was your age. I will therefore stop now, and try to salvage my argument in part 3.

Thirty Years of Experience - A Perspective, part 1

Having recently felt the need to update my CV, which now lists nearly thirty years of computing experience, I couldn't help noticing that quite a few of the skills I list are somewhat out of date. Fortran IV, Algol68, DEC VMS--who uses these any more? (More to the point, would I want a job using them anyway?) In fact, for most of my first decade in employment I was working on computers, operating systems, and languages that have all but vanished. Much of my second decade has already gone the same way. (Now that I think about it, most of the companies I've worked for no longer exist either. I'm pretty sure that's not my fault, though there does seems to be a pattern there.) So what use then, is thirty years of experience?

Does our field change so fast that there's a maximum amount of useful experience that you can acquire? After which, your total experience is being rendered redundant at one end as fast as you can add to it at the other?

Not liking the way this argument was going, I came up with two counter-arguments that show why it is still useful to have a many years of experience in computing.

Firstly, even if the languages I wrote in are dead, the knowledge of how to write good software is timeless. I've spent thirty years learning how to program.

Secondly, I have acquired a sense of perspective, useful in a field like software engineering where the landscape changes at exponential rates.

It's been three days since I started writing this entry (work, chores and childcare not being conducive to creativity), so I'll get back to these points in my next blog.