Reading notes: The Manager's Path

On the one hand, The Manager's Path is pretty conventional: it reads like a business book and it's structured like a business book. On the other hand, the experience of reading it is totally unlike that of reading most other business books. Fournier is clearly writing from real experience and expertise, and--however thoroughly the book was edited after its first draft--its origins as a Nanowrimo project show in the book's urgency. (In the best way.)

I'm reminded of the poker world, where every so often an expert decides to transcribe a lot of their expertise in book form, usually without much regard for the traditional menu of literary forms. Fournier is a much more disciplined and skilled writer than most poker players, but I'd still put this in that category.

Miscellaneous notes:

1. Fournier recommends budgeting 20% of a team's time for "generic sustaining engineering work." I take this as evidence for my claim that Ousterhout, if anything, shot too low when he suggested 10%-20% for (roughly) analogous purposes.
2. She notes that "a common dysfunction of technical teams is not shipping code." This is simple and profound. There are software-team-specific reasons for this, but most fundamentally, an underrated barrier to doing as much as possible is not doing anything. (See #6 here.)
3. Here's a great sentence: "Think of process as risk management."
4. Here's a very good clause: "Code review is largely a socialization exercise..."

Highly recommended, even if you aren't particularly interested in becoming a software manager.