Review:
Coders at Work, by Peter Seibel
| Publisher: |
Apress |
| Copyright: |
2009 |
| ISBN: |
1-4302-1948-3 |
| Format: |
Trade paperback |
| Pages: |
601 |
Coders at Work is a collection of edited interviews by Peter Seibel
(probably best known previously for his book
Practical Common Lisp)
of an eclectic and excellent collection of fifteen programmers. It opens
with an interview with Jamie Zawinski (one of the original Netscape
developers) and closes with Donald Knuth. In between, the interview
subjects range in programmer generations from Fran Allen (who started at
IBM in 1957) and Bernie Cosell (one of the original ARPANET developers) to
Brad Fitzpatrick (LiveJournal founder and original developer). Techniques
and preferences also range widely, including two people involved in
JavaScript development and standardization (Brendan Eich and Douglas
Crockford), a functional programming language designer and developer
(Simon Peyton Jones), language designers and standardizers such as Guy
Steele, and people like Dan Ingalls who have a different experimental
approach to programming than the normal application development focus.
All of the interviewees are asked roughly the same basic questions, but
each discussion goes in different directions. Seibel does an excellent
job letting the interview subjects shape the discussion.
Two things immediately stood out for me about this book. First, it's
huge, and that's not padding. There are just over 600 pages of content
here, much of it fascinating. The discussions Seibel has are
broad-ranging, covering topics from the best way to learn programming to
history and anecdotes of the field. There's some discussion of technique,
but primarily at the level of basic approaches and mindset. One typical
question is how each programmer organizes their approach to reading code
that isn't familiar with them. Each interviewee is also asked for book
recommendations, for their debugging techniques, for their opinions on
proving code correct, and how they design code. The participants are so
different in their backgrounds and approaches that these conversations go
in fifteen different directions. This is one of the most compelling and
engrossing non-fiction books I've read.
Second, the selection of interview subjects, while full of well-known
names in the field, is not the usual suspects. While I'm interested in
the opinions of people like Larry Wall and Guido van Rossum, I've already
heard quite a lot about how they think about programming. That's material
that
Coders at Work doesn't need to cover, and it doesn't. Many of
the interview subjects here are people I'd heard of only vaguely or not at
all prior to this book, often because they work in an area of programming
that I'm not yet personally familiar with. Those who I had heard of, such
as L. Peter Deutsch, I often knew in only one context (Ghostscript in that
case) and was unfamiliar with the rest of their work. This gives the book
a great exploratory feel and a lot of originality.
There is so much good material here that it's hard to give a capsule
review. This is a book I'm highly likely to re-read, taking more detailed
notes. There's entertaining snarking from Jamie Zawinski and Brendan
Eich, fascinating history of the field (including in gender balance) from
Fran Allen, and an intriguing interview with Joe Armstrong (creator of
Erlang), who seems to have a far different attitude towards languages and
libraries than the other interviewees. Every interview is full of gems,
bits of insight that I now want to research or play with.
A couple of examples come to mind, just to provide a feel of the sort of
insights I took out of the book. In the interview with Joshua Bloch, who
does a lot of work on library APIs, he mentions that empathy is one of the
most important skills for designing an API. You have to be able to put
yourself in the shoes of the programmer who's going to use the API and
understand how it will feel to them. This came up in the context of a
discussion about different types of programmers, and how programmers can
be good at different things; the one who can do low-level deep
optimization may not have that sense of empathy.
Another example: Bernie Cosell talked about how he did debugging, and how
he got a reputation for being a fantastic debugger who was able to fix
just about anything. He confessed that he often reached a portion of the
code that he didn't understand, that seemed too complex and tricky for
what it was attempting to accomplish, and rather than trace through it and
try to understand it, he just rewrote it. And after rewriting, the bug
was often gone. It wasn't really debugging, but at the same time it's
close to the more recent concept of refactoring. Several of the interview
subjects commented on a subjective feeling of complexity and how when it
gets too high that's a warning sign that code may need to be rethought and
rewritten.
A third example: I was fascinated by the number of interviewees who said
that they used printf, assert, and eyeballs to debug rather than using any
more advanced debugging tools. The former Lisp developers would often
bemoan the primitiveness of tools like gdb, but many of them found that
print statements and thinking hard about the code were usually all that's
needed. (There was also a lot of discussion about test suites and
test-driven development.) The general consensus was that concurrency
problems were the hardest to debug; they made up a disproportional number
of the responses to Seibel's question about the hardest bug the programmer
ever had to track down.
I could go on giving similar examples at great length, but apart from the
specific bits of wisdom, the strongest impact this book made on me was
emotional.
Coders at Work is full of people who love programming
and love software, and that enthusiasm, both in general and for specific
tools and ideas, comes through very clearly. I found it inspiring. I
realized while reading this book, and I suspect I'm not alone among
programmers in this, that I largely stopped learning how to program a few
years back and have been reusing skills that I already have. Reading
Coders at Work gave me a strong push towards finding ways to start
learning, experimenting, and trying new techniques again. It also filled
me with enthusiasm for the process of programming, which immediately
helped my productivity on my own coding projects.
This is obviously a book whose primary target audience is practicing
programmers, and while it doesn't go too far into language theory, I was
relying on remembered terms and structure from my master's degree for a
few of the interviews. I think it's approachable for anyone who has a
working background in programming and a few languages or a CS degree, but
it might be a stretch for someone new to the field. But even someone
without any programming knowledge at all would get a lot out of the
anecdotes and snapshots of the history of software development.
Coders at Work is also full of jumping-off points for some
additional research on Google or additional reading in other recommended
books.
I only have one complaint, which I have to mention in passing: for such a
large book full of interesting ideas and book recommendations, the index
is wholly inadequate. I tried looking up five or six things in it,
including the source of some of the book recommendations that are
collected in an appendix, and I struck out every time. It's very hard to
find something again in 600 pages, and more attention paid to the index
would have been greatly appreciated.
But, despite that, for people within the target audience, I cannot
recommend this book too highly. Not only was it full of useful
information, at the level of programming above the code details that's
often the hardest to talk about, but it's consistently entertaining and
emotionally invigorating and inspiring. It made the rounds of tech blogs
when it was first released, to nearly universal approval, and I can only
echo that. If you're a practicing programmer, I don't think you'll regret
spending a few weeks reading and thinking about this book.
Rating: 10 out of 10
I don't know if anyone else has been tracking this recently, but a while back I got curious about the relative proportions of dh(1) and CDBS in the archive, and started running some daily analysis on the Lintian lab. Apologies for my poor graphing abilities, but the graph is here (occasionally updated):
Although dh is still a bit behind CDBS, the steady upward trend is quite striking - it looks set to break 20% soon, up from under 13% in September - compared with CDBS which has been sitting within half a percentage point of 25% the whole time.
Incidentally, was that an ftpmaster trying to sign his name in the graph over Christmas or something? :-)
not many closed RC bugs in the last two weeks. it seems we're running out of
easy-enough-for-me bugs does this mean the freeze is near? :)
After a whole bunch of drastic changes, lots of bugfixes, rewriting and refactoring, I 
Almost all of wiki contents got updated, so please take your time to review it all, once again 
n was more of a symbolic meaning, since in meantime we solved our bids weakest links and pretty much got it mature and at the stage we were aiming it to be. We ll still make some minor changes to it until the final decision date (in 47 hours) but this is it really 
So without further ado, let me introduce you to our n wiki 
Since besides changing pretty much the whole wiki we have also added (important) new pages for:
Banja Luka and Republika Srpska
We have added a new pages to bring 
To remind you, we will get free venue building wheter it s Government Building or Banski Dvori , besides that we re getting them to cover basically all of the costs needed for the conference, and besides that we re getting 5 additional members to our local team (highly capable and educated govt. officials) which even includes city Mayor. Early tomorrow we ll get scan/fax of this memorandum from Chief of Cabinet along with the local team names which will all together be added to this very wiki page.
Local Team
We have almost 
Bosnia and Herzegovina FTW! 
Activity of our current Chinese translator pushed me to do some work on
The recent development of the situation in