Books for software engineers and managers

Coders at Work

Coders at Work

Reflections on the Craft of  Programming

by Peter Seibel

Categories:
Tech Lead,
Star Engineer

How strongly do I recommend Coders at Work?
7 / 10

Review of Coders at Work

Coders at Work is a series of interviews with highly respected software developers and computer scientists like Donald Knuth, Ken Thompson, and Peter Norvig.

Knuth and company were interesting but my favorite interviews from this book came from lesser known developers:

  1. Bernie Cosell, developer at BBN which pioneered early internet infrastructure. Cosell talked about ideas like refactoring and readability before they had names.
  2. Joshua Bloch, formerly Chief Java Architect at Google. Bloch offers solid advice on developing APIs that developers actually want to use.
  3. L. Peter Deutsch, developer at Xerox PARC. Deutsch offered perspectives I hadn’t considered before like viewing software as a capital asset.

Coders at Work is 600 pages but reads quickly, especially if you skim over the questions about how each person got into programming. There’s only so many ways to say you were a teenager in the 60s and got access to a monster IBM machine that filled an entire room.



Everyone prefers print statements for debugging because they provide shorter feedback loops than  debuggers

I rely heavily on print statements for debugging and felt relieved to read that the most respected software engineers also prefer print debugging.

A few reasons they cited were short feedback loops, simplicity, and how print statements encourage you to think through the program’s logic more than a debugger.

Development has shifted from writing code that touches metal toward code that glues together  layers

The developers interviewed expressed bewilderment and sadness that coding has shifted toward gluing together layers.

Even the most respected software engineers and computer scientists feel imposter  syndrome

Many of the developers interviewed expressed feelings of not doing things the proper way along the lines of, “I should probably learn to do X or use Y, but here’s what works for me.”

As a developer +15 years into my career, I’ve learned that imposter syndrome never goes away even for people we consider to be the best. Perhaps especially for them.

Math is not that important in most software  development

Interviewees repeatedly said that math just isn’t that important. At lower layers like language, framework, and low-level library development, math matters a bit more.

But for most programming, understanding communication between humans and systems is more important than understanding math.

As you grow older, your ability to hold an entire program in your head will  decrease

Most interviewees said that as they’ve grown older, their ability to understand a full program has decreased. In some ways, this made them worse programmers because they understood the code worse. But in other ways, they’ve become better engineers because they rely more on testing and documentation.

The barrier to entry in modern programming is paradoxically high because of the options available across languages and  frameworks

Back in the 60s and 70s, there just weren’t many language options to choose from when entering programming. Today the options feel endless.

This also explains some exasperation from junior developers applying to entry-level roles, but running into huge barriers because the breadth and depth of knowledge required is so large.

Nobody gets entirely through Donald Knuth’s  books

The author asked each interviewee for book recommendations and nearly everyone expressed some guilt for having not read Donald Knuth’s books either entirely or at all. Knuth’s books were getting more love as monitor stands than reading material.

Turns out Donald Knuth even has trouble getting through a Donald Knuth book. When asked about his reading his own books, he recommended not reading them straight through but rather in pieces and that frankly he struggles to understand some of the math.

Coders at Work