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
Folks at last year's Wikimania may remember the presentation I gave
there. It was essentially a literature review of Wikipedia and
Wikimedia scholarship from the previous year. The idea was to give a
bird's-eye-view as well a series of highlights -- all aimed at
Wikimedians.
Apparently somebody found it useful because I've been asked to do it
again! I'm going to be paired up in a longer session with Felipe
Ortega -- whose excellent dissertation I summarized as part of my
talk last year -- and Mayo Fuster Morell has also agreed to help
out. Felipe is program chair for WikiSym this year and will be
focusing on providing folks with a summary of the papers published at
that conference. It will be held immediately before Wikimania in Gdansk.
For my part, I'm going to be focusing more broadly and talking about
papers published, well, anywhere else.
And this is where you come in!
With search engines and all, I've got a pretty good idea of breadth of
the work that's out there. I also "just know" stuff from my own areas of
interest and study. That said, I don't have as strong of an idea of
what's good and what's relevant beyond what I can grok from citation
counts. And after one year (or less!), that's clearly not very much
information.
As a result, I'm looking for suggestions or recommendations from anybody
on interesting, useful, important, or otherwise noteworthy scholarly
papers on or about Wikipedia or other Wikimedia projects published in
the last year. Feel free to leave a comment, email mako@atdot.cc, or
edit this page.
Nearly a year ago people starting worrying about the complexity of SHA-1 being reduced and the potential availability of viable attacks against things such as PGP keys that used SHA-1. Many people (myself included) generated a new key, or updated preferences on keys that were otherwise strong enough. There were worries about what this might mean for Debian. We were getting ahead of ourselves a bit though. Firstly there haven't been any public viable attacks that I'm aware of (though of course this doesn't mean we shouldn't continue to migrate away), but secondly there's a much easier method of attack. PGP v3 keys. To quote 
The entries matching /Debian, which you requested could not be found.
Upload 
The following is an invitation to the Latvian Ubuntu Bug Jam (in Latvian) sent for a bit of a wider circulation to catch people that monitor 
