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
As previously mentioned I've switched my webserving over to a mixture of apache2 & thttpd.
I chose thttpd as it is simple to configure for my needs, and supports the execution of CGI scripts. Some of the other simple webservers available to Debian's current stable release (such as nginx) don't support CGI so they were ruled out.
Of course prior to choosing thttpd I looked at the state of the Debian package. Distressingly the package has no current maintainer and has several bugs open, including some that have been open for several years without comment.
I've just made my second upload fixing a couple of bugs, including ones that I could see affecting myself, but now I'm done with it.
In conclusion:
I've been playing around a bit with Geo-Temporal visualization. Here's a
screenshot of an experimental visualization on Google Maps:
The icons are placed on approximate coordinates; multiple events in a small
area are aggregated into a single marker. The red sectors correspond to
temporal information: to the right is the current day, a full turn corresponds
to a duration of 7 days. Typical events listed on this map cover 1 to 4 hours
in the evening of a day, resulting in a rather small sectors in typical angles
corresponding to the seven days of a week. There are three larger events, one
being a weekend workshop in Hamburg (covering the saturday and sunday sectors),
a Friday to Saturday in Leipzig and an event incorrectly set for all tuesday
in Dresden. M nchen on the other hand seems to take a day off on
Saturday (in fact they have a full-week workshop on Lanzarote, on a part
of the map not shown ...).While this visualization is quite fancy and can scale to arbitrary time window,
I will not be able to add it to the public version of this map (which can
be tried out on
Sorry, I didn't had the time to update 
Number 2: Although most of the details were finalised a
while ago, I haven't blogged about this yet. I've been working at
Amino for over four years, developing software for a range of
Linux-based set-top boxes. It's been a good place to work for most of
that time, but recently I've decided that it's time to find new
employment.
At the end of March, I'll be joining ARM as a Staff Software
Engineer, working on Linux and other Open Source / Free Software with
them. The job looks awesome, just about exactly what I've been looking
for. And I'll be joining two more Debian folk who are working there
already. Woo! :-)
Update March 1st, 24 UTC: Reynaldo Verdejo is ok, the list is complete!
Update March 1st, 16 UTC: Alejandro Vald s, Fabi n Arias, Carlos R os Vera and Germ n P o-Caama o have been in contact with others in Chile. 
Probably by now some of you know or are worried about 
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? :)
My 
A while ago, I was asked to recompile
They were happy to get a few bugs and patches forwareded upstream, and
asked me why all of this hadn't happened before. Pitty is that a few
longstanding issues were well known in Debian but not so obvious for the new
upstream maintainers, and are present in 1.8.0. Hopefully all will be
dealt with in 1.8.1 or the next major version. The lesson is: if you work on an
apparently abandoned package, after cleaning the mess in your NMU, try to
spend 15 more minutes trying to contact upstream (if available), pointing
them at the patch tracker and our list of bugs: chances are many are still
useful. Also, contact the Debian maintainer, and if they ask you to take over,
at least post a RFA so someone else can.
If you're a Tinyproxy user, I'd be happy to hear if the current package in
Debian unstable works for you. If you were having weird issues with 1.6.x,
chances are 1.8 will fix them. The package can be installed on stable
with no extra dependencies, so if you're feeling adventurous, go ahead and
upgrade.
I m never sure when my commits to Linux actually make it into an official release. Luckily, since releases are tagged, I can use 
As some people noticed, a driver update to support
