Some books were read: 2019
Here are some notes on a few books I enjoyed and learned from in 2019, not all of which are books published that year.
Turn The Ship Around, L. David Marquet. The story of the Santa Fe’s turnaround from worst performing sub to the best performing on record alone is an extraordinary, often gripping story that’s so well conveyed in this book, but the learnings extracted from it are exceptional. Marquet has an interesting take on leadership called the leader-leader model , which is namely to give away responsibility over time based on improved performance (‘control without competence is chaos.‘) and avoid leadership as charisma or centralisation. Marquet describes four elements: give control, develop technical competence, provide mission clarity, maintain courage to avoid falling back to tradition leader-follower techniques. Easy to say, harder to do, but Marquet brings us through his own and his crew’s (difficult at times) experience. This makes the approach believable and the book seems to avoid cause/effect fallacies and cherry picking anecdotes for the most part. You perhaps want to be careful on saying a business book improved your life, on the other hand, this book has been for me, transformational. Turn The Ship Around is a fundamentally important business book. I’ve read it three times this year already—it is this decade’s From Good to Great, as well as a perfect complement to Stanley McChrystal’s Team of Teams.
Range, David Epstein. I’m hugely biased, as a self-identifying generalist, to like this book. That said, this is a welcome, thoughtful challenge to specialisation and especially, early specialisation. Epstein identifies less controlled or uncertain domains as ones where being generalist has benefit over specialisation. He also puts forward a case against specialisation reference the over-reliance experts tend to have on heuristics from Tversky and Kahneman, to Tetlock’s observations on forecasting, to debunking talent myths. A central argument is that to excel later we should sample earlier (Epstein doesn’t talk about explore/exploit tradeoffs directly, but that is something of the gist of it), and using the cross-functional knowledge gained can be an advantage. Range is a useful, timely counter-balance to the assumption that specialisation is an unalloyed good. The background research is particularly good, lots of breadcrumbs left for further reading. The chapter “When Less of the Same Is More” on the Ospedale della Pietà was worth it alone.
First You Write a Sentence, Joe Moran. Prior to reading this, my go to and recommendation for non-fiction and technical writing was William Zinsser’s classic On Writing Well. While First You Write a Sentence doesn’t replace it (they are perfectly complementary), I’m more like to recommend First You Write a Sentence to begin with, because it works directly with construction, syntax and word choice, and builds on those for pacing, rhetoric, and expression. Moran makes it clear that paragraphs might be the unit of concept, but sentences are the unit of thought, and a fundamental thing you want to get right for your reader. The book is technical and detailed, without ever being ponderous or dull. He’s especially good at explaining why sentences as constructed do and don’t work; he describes how to construct longer sentences, that convey more complex chains of reason and expression, and when it’s good to do so. Or not. An engaging, charming and witty read that’s fun to read for reading’s sake, and could not further from the tedium of something like Strunk & White. I came across this by accident and what a find it was.
An Elegant Puzzle: Systems of Engineering Management, Will Larson. The best software engineering management book published in recent years. The book is a collection of approaches to scenarios and problems you’ll run into as a manager. It’s not a comprehensive thesis on engineering management; on the contrary it reminded me loosely of Dennett’s Intuition Pumps: generally applicable advice and thinking to help you make progress on a problem. This seems valuable in an industry that doesn’t really have a canon of knowledge to teach people how to become effective managers. It’s perfectly suited for a converted engineer who wants to lead a team and then a team of teams. Some of the rubric is presented as just so (such as team size or technical debt management), but if you think of it as defining sane defaults to allow an engineering organisation to function it makes sense. Another cohort that should find this book valuable are expert contributors who need to scale their work across teams or define technical direction for an overall area (something that’s difficult to do without factoring in organisation structures and operating models). I walk both sides of that particular street and this is the first book I’ve read in some time that goes beyond truisms like Conways’ Law to practical approaches. Works well as the team and engineering organisation element of a trifecta in conjunction with Accelerate (for performance/shipping) and The Manager’s Path (for leadership/development).
A Programmer's Introduction to Mathematics, Jeremy Kun. Many of us are less than comfortable with mathematics, some of us are programmers, and this book aims to help us with appreciating mathematical fundamentals. The book starts with polynomials and sets, to ground things, and goes on to cover topics like graphs, linear algebra and calculus. It’s not easy going and not meant to be, but it does provide explanations and mostly avoids big conceptual jumps. As one example, I found the angle of attack on calculus starting with successively less approximate slopes to limits to derivatives, insightful. The book does a good job of starting from a programmer’s frame of reference, moving toward what mathematicians are more used to, and continually points out challenges in the books’ interstitial chapter, including mathematic’s frustrating proclivity for informal ad-hoc notation. One main takeaway for me, was, that mathematical understanding is work, requires patience, and some grit. And it is interesting to contrast Kun’s last chapter, on obtaining successively higher forms of math abstraction to scale complexity, with Ousterhout’s opening chapter on complexity in programming.
The Hundred-Page Machine Learning Book, Andriy Burkov. Given the title, I would have said this was an impossible book, not to be found in The Library, and yet here it is. Burkov makes a good opening decision, to catalog only the techniques that have been seen to work well, such as neural networks, trees, and the main classifier and clustering approaches. The chapter “Basic Practices” is a particularly good overview of real world things that need to happen and get done to obtain useful predictions, such as feature engineering, regularisation, hyperparameter tuning, and how to assess performance. This has become a go to recommendation I now give to engineers looking to get a fast, practical overview of the field.
Doing the Impossible: George E. Mueller and the Management of NASA’s Human Spaceflight Program, Arthur L. Slotkin. George Mueller was the organisational leader for the Apollo program. When he took the job, he did so premised on re-organising the group and applying a strong discipline of program control and general purpose systems thinking over specialisation—‘He considered most of the astronauts good engineers, though not system engineers. They did not have the depth of understanding of changes, nor did they understand the impact on the overall system‘. The same line of thinking applies to perhaps the best known outcome of the program approach, all-up testing over specialised stage and unit testing, arguing against of all people, Wernher Von Braun: ‘"you don't want to be testing piece-wise in space. You want to test the entire system because who knows which one's going to fail, and you'd better have it all together so that whatever fails, you have a reasonable chance of finding the real failure mode, not just the one you were looking for.’ A fascinating element in the book is the amount of infighting and arguing between groups and people. This is not a popular business/science book; rather it’s more written I suspect to make sure Mueller’s immense impact and contribution is part of the record. In doing so, it doesn’t have the same need to create dramatis personae, but it’s clear a lot of what Mueller was doing was dealing with people and trying to blend technical and organisational challenges to achieve the outcome, and induce constraints via program and organisational structure—’Program control and system engineering were two key elements of program management, they were different skills working together to understand the program and its implications’. It’s worth remembering, and this book captures it, that program management at this scale was just as new ground as the technical effort, even allowing for the US Airforce’s advancement of systems engineering and the sensational logistical planning achievements of WW2. In that sense, this is a must read for anyone involved in program management, that makes it clear at sufficient scale you don’t get to easily separate concerns like technology, people, budget or even stakeholder politics—a holistic approach is needed. In that light, we perhaps have lost something since the 1960s by treating Conway’s observation on technology and people as a necessary evil, rather than a truism they are organised best in concert. Amusingly however, some things seem to remain true to this day—‘the thing that really kills programs is the changing requirements’.
A Philosophy of Software Design, John Ousterhout. Short, insightful and valuable, from a legend in the field. Ousterhout lays his cards on the table from the get go: the most important thing in programming is problem decomposition and the most important limitation is complexity. Starting with the simplest and most succinct overview of complexity you’re like to come across, it works through a series of precepts chapter by chapter. Some of these are insightful, such as the content on modules and abstraction; some may be controversial, such as the chapters on comments and naming; all are worth reading. This was a real throwback—we don't see books like this so much anymore, but I suspect that programming is changing and this may be the last, or close to the last of its kind. I really enjoyed writing notes in the margins on this one.
Science: The Endless Frontier, Vannevar Bush. If you work in software or around the Web long enough you’ll eventually come across the 1945 article “As We May Think”, where Bush describe a quaint precursor to today’s Internet and Web called Memex. And in the same year, 1945 he laid down a vision for what became the United State’s overall science agenda for decades, covering anything from scientific education to medical research. But Bush was a colossally important and influential figure during and after WW2 and this book provides insight into why. It’s a landmark text and hugely influential for what we now take as givens and ground truths today. For example, if you want to understand in liberal democracies why we generally separate applied from basic research, provide educational grants for scientific studies, think about things in terms of research and development, the embryonic rationales are here. It’s crisp and very, very well written for a nearly 75 year old text. As an engineer or scientist you can learn a lot on how to motivate interest, intent and investment from non-technical colleagues just by reading how the book frames and presents its arguments.
The Dream Machine, M. Mitchell Waldrop. This will go down as one of the best popular books ever written on computing. The way it weaves together the history of computing from the end of WW2 up to the early 1980s, through one individual, Joseph Licklider, is stunning. It ties thread after thread together to provide the most coherent history of computing and the industry created around it that we have—the early history of some of mankind’s most important technology developments (computer machines, software, and networking) is not well covered. We know quite a bit about what happened after Microsoft and Apple, not so much of the build up before that. Computing prior to the personal computing revolution is more often treated as a discrete set of unrelated events rather than a continuous history. I'd encourage anyone working in the industry or who is simply curious on what motivated the creation and development of so many innovations to read it, as equal parts popular science and history book. It’s no surprise Stripe Press issued a reprint; their hardback edition is a welcome addition to any shelf.
Nudge, Richard Thaler, Cass Sunstein. I am only a decade late to this one! Fine examination of incentive design for optimal organisational/civic outcomes without falling into the autonomy/authority tarpit. Thaler and Sunstein propose what they call ‘libertarian paternalism’: essentially nudging people towards optimal or desirable choices as part of the outcome design, typically by making those choices the default using what they call ‘choice architecture’. Most organisational design work focus on structure. sometimes value alignment, much less so on incentives, never mind considering you can to some degree design a people system for behavioural outcomes. The book devotes a good amount of time to real-world scenarios, such as employees choosing investment plans, and the ideas seem scale free, so you could imaging applying this from anything to a website dialog to a civic population. This is useful reading for leaders working at any scale and who want to think about inducing behaviours. Personally wish I'd read it sooner and I’m a bit surprised designing for incentives hasn’t weaved its way into general business literature given this is a decade old.
Atomic Habits, James Clear. Perfectly articulated uncommon sense, and very useful as a how to—the book is filled with actionable things you can do and try. The book is based around a four stages to habit formation (a cue, a craving, a response, and a reward) and also uses those stages to intercept and change existing habits. I liked that the book is upfront that this requires effort, but even more that the effort is broken down into small and relatively easy changes (hence the title of ‘Atomic’). It’s a hugely tactical approach and all the better for it. I can’t say this for sure, but my suspicion is the content of the book was edited and refined over and over—it’s a very polished read with a delightful lack of filler for a business book. James Clear is a fine writer, with a knack for the memorable—’You do not rise to the level of your goals. You fall to the level of your systems.’ His next book will be an instant buy for me.
Thomas Cromwell: The untold story of Henry VIII's most faithful servant, Tracy Borman. Even with the popularity of Mantel’s Wolf Hall and its BBC adaptation, we still know little about one of the most controversial and divisive figures in English history. Borman is no Issacson and does not apologise for her subject. The book contextualises the historical and political period well, clearly portraying Cromwell as an intimidating, formidable, dangerous figure even by the standards of the day. This is a man, after all who at best had his neighbour’s house moved on rollers; at worst had people imprisoned, tortured and executed, which was the style at the time. As the book says, ‘Perhaps the word that best describes Cromwell’s personal faith was neither reformist nor conservative but rationalist’. You are left with a sense of someone who was both an irresistible force and an immovable object, a ruthless pragmatist and moral polymath, who would have self-made just as well in our capitalist society as the Tudor’s early mercantile one.