50bookchallenge #23/50: The Best Software Writing I Joel Spolsky, editor

Joel Spol­sky is the Joel of joelonsoftware.com, who writes that his com­pa­ny has a pol­i­cy that any pro­gram­mer work­ing for him must be able to write Eng­lish well. How­ev­er, he notes that there are pre­cious few good writ­ers writ­ing about soft­ware and a good many ter­ri­ble ones. So he decid­ed to col­lect the best soft­ware writ­ing he could find to show­case it and encour­age the writ­ing of bet­ter arti­cles and books about soft­ware in general.

I’m inter­est­ed, of course, because I pro­gram for a liv­ing and I also val­ue clear writ­ing in Eng­lish (though you may not be able to tell based only on what you read here). It seemed like a nat­ur­al for me, and I was right. This book was filled with good arti­cles, some of which were very rel­e­vant to the work I do and oth­ers served only as an exam­ple of clear and engag­ing prose about sub­jects periph­er­al to my realm of experience.

Many, if not all, of the arti­cles fea­tured in The Best Soft­ware Writ­ing I are avail­able online, so the val­ue of a col­lec­tion like this is in hav­ing an easy, ran­dom-access copy of them to hold and read on the train or in a cof­feeshop or the park, and also the job of edit­ing or choos­ing the arti­cles that Joel Spol­sky has done. Google still does­n’t have a “show me the best-writ­ten pages” button.

On a per­son­al lev­el, I’ve been read­ing books about pro­gram­ming and soft­ware devel­op­ment because I’d like to be a bet­ter pro­gram­mer, which is a nice way of say­ing that I have short­com­ings as a pro­gram­mer that I would like to have addressed. That’s not to say that I’m par­tic­u­lar­ly gung-ho about doing the work to address them; real­ly I’d like to just mag­i­cal­ly be a bet­ter pro­gram­mer. Or maybe if I just read the right books about software…

Late­ly, in fact, it’s seemed almost impos­si­ble for me to write even small snip­pets of code. I’ve found that I can talk about pro­gram­ming, I can talk about soft­ware devel­op­ment, I can sit in aroom with my man­ag­er and talk about the best way to address a prob­lem, and then sit at my desk look­ing at the screen real­iz­ing that the gran­u­lar lev­el of actu­al­ly writ­ing the code is just too much for my brain to handle.

So read­ing Eric Sink’s excel­lent “Haz­ards of Hir­ing” hit me in a par­tic­u­lar­ly deep way. In Spol­sky’s intro­duc­tion he writes of the impor­tance of keep­ing away from hir­ing the “90%” per­son, who isn’t ter­ri­ble but who will even­tu­al­ly slip your dates because they just aren’t up to speed the way they should be.

One of Sink’s admo­ni­tions is not to hire any­one with even the slight­est hes­i­tance. Only hire the very best, and not some­one who is sim­ply as good as every­one else on the team, hire some­one who is bet­ter at at least one thing than any­one else on your team.

I look around the room at the team I work with and I’m hard-pressed to find that one thing that I do bet­ter than any of them. In fair­ness, there are a cou­ple of things, but none are relat­ed to the work that I do. So look­ing at my own desk, I won­der why I got hired, and my esti­ma­tion of my man­agers decreas­es. Well, maybe anoth­er thing that I do bet­ter than them is to deter­mine if I’m a good fit for the team.

One thing he nails that does­n’t hurt too much is his sug­ges­tion to hire devel­op­ers, not pro­gram­mers. He says a pro­gram­mer is some­one who does noth­ing but code new fea­tures and fix bugs. A devel­op­er sees code as one aspect of a project and will con­tribute to the project in mul­ti­ple ways. So maybe my skills are suit­ed to oth­ers of those ways. I wish I could put my fin­ger on what those oth­er skills are, because I’m not inter­est­ed in putting in the work nec­es­sary to become a bet­ter coder. Again, I’d rather read a book that put in actu­al work to devel­op­ing prob­lem­solv­ing tech­niques in code.

Then he writes a sec­tion titled “Look at the Code.” Of course, the very best devel­op­ers ought to be darn good pro­gram­mers. He gives exam­ples of what to look for, and in par­tic­u­lar this jumps out as an indict­ment of my suit­abil­i­ty to the job I’m paid to do. Open Source projects, he says, are a great indi­ca­tor that the poten­tial hire is a good choice. If the can­di­date enjoys writ­ing code enough to do it with­out pay, like­ly the pas­sion and skills will be there.

Well, that’s enough to scare me right out of the indus­try. If I were to nev­er write anoth­er line of code in my life, I think that would be a good life. So one depress­ing piece of self-aware­ness that comes along with hav­ing read this book is that I don’t even vague­ly enjoy what I get paid to do.

So thanks, Joel. Your book has inspired me to real­ize that I’m no good at what I do and that I should quit my job. Too bad I’m get­ting paid enough to sac­ri­fice my own integri­ty and not fol­low through with this insight.

On a part­ing note, here, this (from the book) is great: A Quick (and Hope­ful­ly Pain­less) Ride Through Ruby (with Car­toon Fox­es). And it’s a lit­tle inspir­ing that maybe, just maybe, hav­ing visu­al skills and some com­put­er knowl­edge is not such a bad thing.