Coders at Work – Jamie Zawinski

I’ll be perfectly honest and admit that until Joel Spolsky’s “Duct Tape Programmer” blog, I’d never heard of Jamie Zawinski. Whilst reading Ayende Rahien’s blog the other day I find that he was also attributed with that memorable quote about Regular Expressions:-

Some people, when confronted with a problem, think "I know, I’ll use regular expressions." Now they have two problems.

Luckily my mum, ever in search of something to buy me for my birthday, checked my Amazon wish list and pulled an item from it - the book Coders at Work by Peter Seibel. The blurb states that this is a collection of interviews with some of the top programmers of our time. Now I consider myself to be pretty well read and yet I could only tell you who 4 of the 15 interviewees were, and one of those was only because his name came up at the Stack Overflow Dev Day last October. For the record Donald Knuth, Joe Armstrong & Simon Peyton Jones are the names I immediately recognised and Peter Norvig was the one name-checked during the Dev Day. Anyway I’m sure looking forward to finding out who these other “prominent” programmers are and maybe I’ll be able to work out why their names didn’t register.

My impression of Jamie from the blog posts by Joel Spolsky and Uncle Bob wasn’t at all favourable. I felt he was portrayed as a reckless hacker who paid little attention to the maintenance aspects of software development. I had a vision of a loner coder sat in an Ivory Tower churning out Netscape. Ok, maybe I’m exaggerating now :-) Of course soon into the book I realised this picture was far from the truth, in fact the more I read the more I noticed how much I have in common with him…

I started out working on shrink-wrap software and have since spent more time working in the enterprise arena. As Jamie points out these two worlds are very different and that can have a significant knock-on effect on the way that software is developed. In the dog-eat-dog shrink-wrap world your customer likely has a number of choices and if you don’t deliver someone else will. In stark contrast is the closed world of in-house software where your customer has only one choice – you - they can’t reasonably go anywhere else. In Jamie’s words:-

I know it’s kind of a cliché but it comes back to worse is better. If you spend the time to build the perfect framework…release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you’re out of the game. You never shipped your 1.0 because someone else ate your lunch. Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore.

These statements put his later comments about unit testing (at Netscape) into a whole different light. I’m sure Uncle Bob would cite Yoda and use the quote “No! No different! Only different in your mind”, and in theory he is probably right. After my recent post “My [Unit] Testing Epiphany” it would be churlish of me to disagree entirely with Bob, but I can also see where Jamie is coming from.

I also agree with his sentiments about education. It’s extremely rare these days to come across a programmer that didn’t go to University and get a degree in Computer Science or some form of Engineering (I have a degree in Electronic System Engineering - but I sucked big time on the analogue side!). In the couple of cases I have come across where a decent candidate lacked a degree they fitted the mould of the classic 80’s bedroom coder and have themselves described how hard it is to be noticed when you don’t have a degree on your CV. I rated both these candidates highly for the type of work I do because they come from a time where resource management needed careful consideration. In the interview (pp 47) Siebel questions whether we can leave those days behind in favour of a more abstract view of resource management. Given the current attitude to Scaling-Out (more hardware) instead of Scaling-Up (optimised code) it seems that way, but as the need to reduce power consumption within the data centres (and therefore the cloud) becomes more important we may see greater importance placed on those skills.

The one part of the interview that did surprise me was his attitude towards Design Patterns. He said:-

Then there was another book that everybody thought was the greatest thing ever in that same period – Design Patterns - which I just thought was crap. It was just like, programming via cut and paste…Then in meetings they’d be tossing around all this terminology they got out of that book.

I honestly think that he has completely missed the point (or maybe I’m misunderstanding his answer). I’m sure that some developers do try and design software in a cookie cutter fashion and attempt to use every one of the GoF patterns, but by-and-large the single biggest contribution they have made is the introduction of a common vocabulary. They have also been instrumental in promoting the notion of “Program to an interface, not an implementation”. Maybe he uses common terms like Composite, Factory, Mediator, Proxy etc but doesn’t attribute their wide acceptance or visual connotations to the GoF. Fair enough, it doesn’t take a rocket scientist to guess what each of those terms mean, but there are a number of others that are less obvious and yet are also incredibly common, such as Double-Checked Lock, Scoped Guard, Monitor, Context Object and Data Mapper. I’d sure be interested to know how he avoids this aspect of Patterns.

I’ve only read one this one chapter so far but it has achieved it’s job of painting a far richer picture of the man that ended up becoming the centre of a row about software quality. It has also reminded me that there are different forces driving the software development process, like shrink-wrap vs enterprise and application vs framework, which pretty much guarantees that one size never fits all.