Why write yet another blog about making computer programs?

I am not a natural born programmer. I think I wrote three programs before I went to university, all in BASIC. The first was the classic one anyone who’s spent time with a C-64 has done:

10 PRINT “JOE IS COOL”
20 GOTO 10

RUN

The author as a teenager, playing golf rather than coding.

The second asked your name and if you entered anything other than “JOE” it would call you a dick. The third was an ambitious attempt at a text adventure written. I got stuck as soon as the story called for the user to pick one of three choices.

Even at university I wasn’t really a programmer. My degree was in Information Science and it wasn’t really based around writing software. The coding we did do was weird in the context of today. A lot of it was in MS Access or bespoke AI tools and a sprinkling of C++. An odd mix, right? The big project in the final year was written in a 4GL and hooked up to a Digital RDBMS.

I’m a fan of saying that university teaches you to learn and think. I think it’s fair to say that university taught me how to learn to code on the job. And it was on the job that I discovered the joy of programming.

Over the years I was lucky to be in jobs that gave me many opportunities to work on dozens of different applications, tools, and languages. I’ve written apps in Delphi, Java, ColdFusion, PHP, FoxPro, C#, and, my favourite, Ruby. I’ve built them on top of half a dozen databases. For a while I was a Unix sysadmin, sorting out the email for some “world famous in New Zealand” bands. I’ve been made things for fun, things for bands, things for government, things for big corporations.

A lot of the time I was on my own, inheriting existing stuff, and flailing about until I understood how they worked. My self-taught techniques got things going, but, man, I don’t think you’d call them good.

As my career progressed, I became a member of some great teams and learned from people who really understood how to code.  I think I got good at debugging, at finding why a problem is happening and marking it with an X. I’m still not that great at fixing the bugs, or not causing them in the first place.

As an engineering manager I don’t code unless it’s really, positively, absolutely, necessary. I’ll be a rubber duck for anyone who asks. I’ll explain business rules and give excuses for why something “works that way”, but I don’t generally put shit into production.

I do still read a lot about programming and the process of making software. And I go through bursts of writing stuff for myself. This blog is a double-down on that, and there’s a reason for it.

One of the best articles on engineering management is  Bored People Quit by Michael Lopp. It has some wonderful advice but the bit that has stuck with me is the coda:

Part of your credibility as a leader is your public and repeated declaration that it’s your job to help your team succeed, but you have another task: you need to keep building stuff.
I’ve gone back and forth on whether managers should code and my opinion is: don’t stop coding. Each week that passes where you don’t share the joy, despair, and discovery of software development is a week when you slowly forget what it means to be a software developer. Over time it means you’ll have a harder time talking to engineers because you’ll forget how they think and how they become bored.

Michael Lopp – Bored People Quit

And that’s why I spend several hours this weekend practicing coding. It’s why the post after this one will (probably) be all about that practice. I have always loved the joy and discovery of programming and it’s important for me to keep finding the joy. This blog is here to make sure I keep doing it and to celebrate the joy.