The book is the transcription of a bunch of interviews with a bunch of programmers that in one way or another have become inordinately famous, often by inventing languages or operating systems. It takes decades to become famous, so a lot of the developers interviewed are approaching the world with a 1950 to 1970 mindset. Compilers and OS kernels are a pretty specific variety of programming– the unsung heros writing code that never becomes famous were largely absent, although many of these developers had war stories about working on similar non-compiler non-OS-kernel projects. As an example, most were asked about how they debug and what tools they use– most said “print statements” If all you’ve had for your whole debugging career is a hammer, I guess it isn’t surprising you haven’t switch to nail guns, but it won’t help my debugging skills to put down the nail gun and use the hammer just because that’s how people used to do it.
The book over all is vary ramble-ly and disorganized, like a conversation, but unlike the hyperstructured layout of a novel or textbook that the modern reader has come to enjoy. It could have used some more aggressive editing for size and organization. Some points are raised by multiple developers which is interesting as a poll, but I’m just as happy to read “9 out of 10 master developers find multithreading to be a fiercely difficult problem” I don’t need to read the exposition from each, which in anycase was hard to follow if you haven’t done multithreaded programming much before.
Ironically, the concept of “Literate Programming” was revisited many times, but this book had none of the polish that one would find in a document subjected to draft, rewrite, rewrite, final draft process that English language writer subject their own documents to.
Speaking of Literate Programming– many concepts like this are discussed, but the reader is assumed to kind of know what it is about already. Proving the correctness of programs, compiler design, OS kernel design, low level computer function and and programming (e.g. assembly), were discussed, but the audience was really someone who’s already mastered these things and they are evaluating how effective they are in practice.
As a plus, this story had very little of the typical popular-press IT stories, such as death marches and project management.
I recommend reading 6 out of 10 of the pages of this book. To be fair to the developers, I recommend selecting one developer interview to read at random, subtracting the pages read from total pages then repeating until you’ve read 6 out of 10 of the pages in the book. Please post an more efficient algorithm in the comments if you can think of one, with the formal proof that will eventually stop and has no invariants violated.