Rys Sommefeldt

The perils of not programming enough

I’ve been programming since I’ve had access to a computer, from the Acorn Electron in 1986 and the reason I started programming in the first place, to modern day hardware where I’m mostly on the GPU. Most of my professional life has been spent writing code, and while it’s still part of my job at PowerVR it’s something I do less and less. In fact, I’ve just hired a guy to be my group’s dedicated software engineer, so I should only really be involved in the design from now on, at least as much as possible lest I waste new guy’s time.

So that means I try and program at home when I can, at least just to keep my hand in so I’m not designing software I know is going to be a nightmare to write. I also still find it really fun, and I still believe heavily in open source as a means to learn.

Recently I decided to fix some bugs in an open source program that I use, written in a language I’ve never used for anything but experimentation (Perl). I did it to improve the software, but also because it was fun and the language was one I’m not comfortable with so I’d learn.

After reading the spec for the thing the Perl was trying to drive (SMTP), I figured out where the bug was and engineered a fix, adding one new line of logic wrapped in a few lines of runtime configuration, based on options passed on the command line. The code already had an options parsing framework, and it already included IO::Socket::SSL for doing TLS (I was adding a specific SSL connection to the SMTP server before the initial SMTP handshake), so I was really doing very little in terms of work or new code.

It was a deeply trivial fix to make in the end, and reading IO::Socket::SSL showed I was (hopefully) doing the right thing with the socket since it was used elsewhere. Despite that, it took me four commits to actually prepare the patch properly: after getting the options logic wrong and setting a flag on the wrong side of a branch, I made a typo when handling the SSL socket init errors, and I left a stray character in the file causing it to not even parse, after Poppy trod on the keyboard saying hi while I was coding. I wasn’t even on the ball enough to run the damn code through Perl’s built-in linter before commiting and pushing to the repo, a commit the maintainer could see. Embarassing.

This is what happens when you don’t code seriously for a while, and especially not where someone can see it and constructively criticise; you get rusty. While I’ve been programming at home, it’s been on toy programs I’m not publishing out in the open, so I don’t really care if my commit history is riddled with mistakes. Four commits to get a simple piece of logic added to someone’s public source is bad though. Here’s hoping he rejects the commits entirely and applies the patch by hand!

So if you’re a programmer, or especially someone in my kind of position where you’re a lead engineer involved in design but not necessarily a lot of actual coding, make sure to keep your hand in and still code, and do it in public where everyone can see. Fixing or developing open source is great for that; coding in isolation will rarely do you any favours.