The hacker, the architect and the superhero: three completely different ways to be an excellent programmer

Like most programmers, I suppose, I’m arrogant enough to think I’m pretty good (although see The Dunning-Kruger effect).  But through the last thirty years’ programming, I’ve worked with plenty who I know are better than me.  Today I want to talk about three of them, and about how very different their skills are; and I’ll finish up by thinking about what the rest of us can learn from them, and what we can do to maximize our own abilities.

I agonized about whether to name them, but eventually concluded that I can say more about their work if I am specific; and what the heck, they might enjoy being held up as examples.  They certainly deserve it!  So step forward (in chronological order) Steve Sykes, Mike Selway and Adam Dickmeiss!

The hacker: Stephen Sykes

I met Steve back at Warwick University in, I think, 1986, and we’ve been in touch on and off ever since.  Our first interaction was him introducing me to GNU Emacs, which has been my editor of choice pretty much ever since, and he is one of the very few people I know who’s contributed patches to the Emacs kernel (and had them accepted).  I’ve seen him track down bugs in the Emacs event loop for fun; I seem to remember him also fixing bugs in GDB, although that might be my memory playing tricks on me.

I’ve sometimes joked of Steve that when he needs to write a program, he starts with any other randomly chosen chunk of code, and debugs it until it does what he wants.  As far as I know, that’s not literally true … but I can imagine how it might be.

I’d say that Steve’s greatest asset, aside for his sheer appetite for detail, is his knack of looking at other people’s code and very quickly understanding its intent.  I don’t know how it feels from behind his eyes (I might interview him here one day if he’s up for it), but to me it seems little short of magical: it’s almost as though he just looks at the tarball and somehow zens it.  I don’t know, but I’m guessing he doesn’t suffer from Framework Fear: probably he can zen the stacks of massive documentation that go with these things, intuitively finding the half-dozen pages out of thousands that tell him what he actually needs to know.

Maybe the best evidence of Steve’s knack for seeing order in the midst of chaos is his run of winning entries in the IOCCC (International Obfuscated C Code Competition): he won the prestigious Best Abuse of Indentation category in 2004, followed it up with the 2005 award for Best Emulator, and completed the hat-trick in 2006 with not one but two awards: Best Assembler and Best One-Liner.  His winning entries are available on his own web-site.

The 2005 entry is my favourite, and I think it’s frankly a disgrace that it didn’t win Best of Show: in 3.5 Kb of source code which forms an ASCII-art picture of a Commodore Pet, he wrote a PET emulator, which provides enough hardware to load and run programs from virtual tape in both 6502 machine code and BASIC (the latter using an image of Commodore’s ROM, of course).

Of the programmers I discuss here, Steve is the one who most resembles the prototypical “hacker” (in the original, positive sense).  If I were NASA, and realised thirty minutes before a probe was due to enter the Martian atmosphere that there was a bug in the machine code controlling the landing sequence, Steve would be person I’d want tracking it down and fixing it.  (Admittedly, by the time the fix was transmitted to Mars, it would be too late to help, but you have to make the effort.)

The architect: Michael Selway

After I left Warwick, I spent nine years working for System Simulation, a small but long-lived software house based in Covent Garden, London.  (I am told that the building where we had our office, above the Rock Garden cafe, was previously a banana warehouse.)

System Sim have been going for well over thirty years, and in that time they’ve grown and shrunk and repurposed more times that it would be easy to track, but when I joined I became the fifth member of the team — and the third called Mike.  We were referred to informally as Mike 1, Mike 2, and Mike 3; or sometimes as Mike 40, Mike 30 and Mike 20, since that’s how old we were at the time.  Since then, the company’s gone from strength to strength, and now employs lots more people.

Mike 2 was Mike Selway, who’s still with System Sim after what must be the best part of 30 years now.  I hesitated about calling him an “architect” above because that word seems in recent years to have come to mean someone who toys with UML diagrams all day and never writes any code, which could not be further from Mike; but the word divested of this connotation fits, so I used it.

Mike was and is The Main Guy behind Index+, a proprietary non-relational database optimised for structured and textual data and widely used in museums and art galleries — the system that much of System Sim’s work is based on.  I wish I could show you the code (they’ve been talking on and off about open-sourcing it for about ten years, but nothing seems to have come of it yet) because it is the most beautifully structured C you could ever wish to see.  It’s a significant chunk of software that covers everything from low-level details like the forms of compression used for the bit-patterns that represent the indexes on disk, up through a network/RPC layer to an application-level API and a set of application libraries — yet the whole thing makes perfect sense.  The code was a joy to work on, and gives the lie to the idea that C can’t be used for big, complex systems.  (That’s not to say that other languages wouldn’t be a better bet these days, but remember that the core of the code dates back to the days before C++ was a realistic option, let alone Java or Ruby.)

Putting a body of code like that together, and keeping it coherent across decades as multiple other people work on it, is no simple task.  I was going to write that Mike has the talent of holding the whole of a complex system in his head, but actually that’s not it.  His skill lies in designing that system in such a way that you don’t have to hold it all in your head at once.  In a sense, that’s “only” encapsulation; but doing it right is an art-form.

Mike also cares more about the beauty of his code than anyone else I know.  He was talking about code-quality metrics long before the idea caught on; he talked about, and practiced, refactoring decades before the word was coined.  It’s not enough for him that code merely works; it has to be right in a deep sense.

When I am installed as NASA Supremor, I’m going to get Mike to design the probe-landing code; that way, I won’t need to get Steve in to debug it at the last moment.

The superhero: Adam Dickmeiss

Since 2002, I’ve worked more or less full-time for Index Data, another small software house, based in Denmark and the USA, with offices also in England (that’s me!), Germany and Canada.  (Yes, that is a lot of offices for eleven of us — we’re a very distributed company.)  We started sixteen years ago as the joint project of Sebastian Hammer and Adam Dickmeiss, releasing open source software such as the YAZ Toolkit and the Zebra database from day one.  In fact, I used some of this software in my work with System Sim, and it was the quality of their code that drew me to Index Data a couple of years later.

Most people at Index Data are pretty hardcore coders, but I think most of us would admit that Adam is on a different plane again.  To be frank, he frightens me a little bit.  All the tricky stuff that the rest of us have to sit and think about — events, concurrency, asynchronicity — he seems to just chew up and spit out without having to think about it.  I think he has the widest mind I’ve ever encountered.

An anecdote might illustrate it.  In the world of libraries, which is where we do a lot of our work, the most important standard protocol is the seductively named ANSI/NISO Z39.50, an old-school binary-on-the-wire protocol in which the packets are defined in an ancient IDL called ASN.1 and encoded using BER.  If you’ve never heard of these technologies, that’s forgiveable: although they are robust, efficient and battle-proven, they are profoundly unfashionable, and so near the turn of the millennium, the Z39.50 implementors’ group decided to recast the Z39.50 semantics in more web-friendly terms, as a protocol implemented over HTTP and using XML for the encoding.  (In an easy-to-avert disaster, the resulting family of protocols was given, if possible, an even less memorable name: SRW/SRU.  But that’s not my point right now.  Another time, I might rant about the importance of names, but not today.)

So we had a problem: one of the most important tools in the kit was what we call the Generic Frontend Server, or GFS for short: a Z39.50 server framework that calls out to application-specified handler functions to fulfill searches and other requests.  But some customers were going to want to send SRW/SRU requests instead of classic Z39.50.  And to make it worse, that ugly SRW/SRU designation hides two distinct though related protocols: SRW uses SOAP, and SRU uses HTTP GET requests and raw XML responses.  We could make two new GFSs or — I discussed this possibility with Seb — might we possibly find a way to extend the existing GFS so that it could handle all three protocols?  We started to email back and forth, discussing whether such a thing might be feasible, scoping out the possible approaches, starting to think about how much time we’d need to allocate.  And (as you no doubt saw coming), in the middle of this flood of emails came a CVS commit notification: not knowing about our discussion, Adam had gone right ahead and implemented the two new protocols into the GFS — seemingly not even realising that it was a big deal.

Not only that, he’d made it so that a single listener on a single port could accept all kinds of connections, and would sniff the first incoming packet to decide which set of handlers to use.  And while he was at it, he’d upgraded the GFS so that it could act as a generic HTTP server in its spare time (so it could provide, for example, XSLT stylesheets to be used in rendering SRU responses as human-readable HTML).

Well, I mean to say.  It’s embarrassing.

Adam would be a lot scarier if he wasn’t such a nice bloke.  I just hope his brain has an industrial-sized heatsink, because it’s obvious that he’s overclocking that baby.

If I don’t become NASA supremor until one week before the Mars probe is launched, then Adam is the person I’ll get in to write the control software in a real hurry.

And the winner is …

Haha, as if I’m going to pick one!  Not gonna happen.  The interesting thing about these three programmers, to me, is that each of them surpasses me along a different dimension.  Of the three, Steve would likely be the best at immediately grokking someone else’s code; Adam would probably produce a given program more quickly than Mike, but Mike’s version would likely be easier for mortals to maintain.  (Sometimes Adam’s very wizardliness can be an impediment: he thinks nothing of dashing off a 300-line C++ function that fits comfortably into his skull but not so easily into our mortal minds.)

I do know that it’s been a privilege to know and work with all three.

But what can I learn from them?

I‘d like to wrap up this article with a nice, neat bow.  You know the kind of thing: “from Steve, I learned the importance of understanding state transition; from Mike I learned that every human being is beautiful and unique; from Adam I learned to trust in myself and follow my dream”.  But it doesn’t actually work that way.  Although there are surely plenty of micro-techniques I could learn from Steve and Adam (and hopefully have done), the bottom line is that both of them have intrinsic skills and abilities — maybe the best word is capacities — that I just don’t have.  In a way, trying to learn programming by reading their code is like trying to improve your football by watching a superhuman genius like Matthew Le Tissier — the only lesson is “be incredibly skillful”.

But maybe I can do better at learning from Mike.  I don’t know whether it’s because design and organisation are more transferrable skills than debugging and wizardry, or because Mike is so intentional about software quality, or just because his quality of Goodness happens to be a better match for where my own natural aptitudes lie, but I think I’ve benefitted most from working with him.

Like me, Mike is a disciple of those old Bell Labs Guys With Beards (hereafter OBLGWBs) — Thompson, Ritchie, Kernighan and their buddies, who gave us Unix and C, but also a legacy of outstanding books that embody important principles of software design.  In my earlier review of The Elements of Programming Style, I drew attention to the second rule in the book — “Say what you mean, simply and directly”.  Mike’s programming is a lesson in how applying that principle absolutely does not mean dumbing down — there is Deep Magic in the low levels of Index+ — but does mean making the magic as comprehensible as possible.  That is high and lofty goal.

And in my own best code, I think or hope that I approach that ideal — at least, much more closely than I do Steve’s and Adam’s qualities.  If you’ll forgive me a moment of immodesty, there are times when I re-read some of my own code, and my mental reaction is just “yes, of course”.  The code looks obvious; in retrospect, it seems impossible that it could have been written any other way.  But of course getting it into that state is not so trivial as it looks.  A great ski racer makes skiing look easy, but that impression of ease is gained only with years of learning, experience and practice; ease is attained only by great effort.  And as we strive to write simple code, we need to recognise that simplicity is attained by the same means.

Update (22 March 2010)

Some good discussion at Reddit.

Also at Hacker News.  The interesting thing here for me is that (based admittedly on a very small sample), programmers seem to self-classify more or less evenly into these three buckets.