When I was 8 years old, I remember having a friend over to dinner one fateful night. Sometime during the course of the meal, someone told a funny joke, and I burst out with an explosive laugh – which wouldn’t have been a big deal, except that my mouth was full of milk. My parents sent me to my room, which I honestly thought was unfair – it’s not like I meant to do it! Fast forward to a week ago, when my four-and-a-half year-old sprayed milk across the table with a bark of a laugh. Of course I wasn’t happy, but a part of me marveled at the deep and karmic nature of the cosmos.
I share this because, as all coders, I’ve made a lot of mistakes over the years. Most were caught soon after coding, some went on to wreak a particularly destructive kind of havoc, and some of those made enough of an impact that I still think about them today. These weren’t your standard segfaults or “overwrote the framebuffer” type of bugs – each was truly egregious, for one reason or another. I’m a little embarrassed to even bring them up, but they frequently come to mind when I see an especially creative disaster. Been there, done worse.
It can be easy, especially as a non-coding manager whose success is predicated on his team’s ability to write performant, secure, scalable, flexible code – quickly – to get upset when things break badly. The following blunders are my personal touchstone, my way of remembering that everyone sprays milk across the table sometimes, and that I’ve screwed up as well as or worse. So, without further ado, here are some of the mistakes that still stick with me.
Finger muscle memory is a good thing. It’s what helps us touch-type, punch in command keys without thinking, and go from impulse to completed command line instruction without conscious thought. It’s what makes emacs and vi possible. When I was a senior in high school, I took CS classes at my local college, and was up late at the computer lab the night before a big assignment was due. I was mostly done, just cleaning up some loose ends, and I decided to get rid of some old backup files. And accidentally erased everything. vi giveth, and rm -rf taketh away. I didn’t have another backup, and ended up having a long night ahead of me.
When I was working in Japan, I was frustrated that the new version of one of the products I was supporting wasn’t going to be translated into Japanese. So I did it by myself on nights and weekends, using Visual Basic, sockets, and an API the company made available. It was eventually productized. Happy ending, right?
Unfortunately, I fundamentally misunderstood how Visual Basic variables worked, and ended up storing values in off-screen UI elements. Yeah. Instead of allocating memory dynamically, using – you know – data structures – when I needed a list I just created a select box, put it below the bottom border of the dialog box, and managed my variables in there. This worked fine, of course, until the lists started getting too big – which didn’t happen during development, of course. Pesky users.
Giant Fighting Robots
When I was at Activision, I worked on a giant fighting robot game called Heavy Gear. It was my entrée into the game industry, and I was tasked with writing the “shell” – i.e., the part of the game the user sees before actually getting into the game. It was a pretty diverse project, with some challenging aspects – I had to integrate the 3D engine, implement chat using bare metal UDP, write tools to manipulate images, etc. etc.
The thing is, I needed to use a debug version of one of the C++ DLLs during development (I can’t remember why, but it seemed important at the time). I gave QA instructions on installing the DLL during testing, and all was fine.
Except that when it came time to ship, the code still had a dependency on the debug DLL. Fortunately, this is the kind of thing that gets caught in regression testing. Unfortunately, QA had wiped their machines, installed the finished game, then installed the debug DLL (as per my instructions) before verifying that everything worked. We ended up sending a glass master to the CD pressing facilities that would only work on machines with Visual C++ installed. We had to yank it out of production, send a new master, and pay a couple hundred thousand dollars to get our place back in line. Shrink wrap is a harsh mistress.
I didn’t stop coding after Activision, and it’s not as though my code since then has been perfect… But somehow, nothing since then sticks out as much. These are the mistakes I still think about, the lessons I had to learn first hand. If you’ve programmed enough, I’m sure you have your own war stories (like the famous select isn’t broken). Comments are open – I’d love to hear about them, if you’re willing to share!