Keep Calm and Code On is a book that discusses what it takes to develop software professionally, not so much the technical aspects but lessons learned through experience. The subtitle is “A tactical guide for navigating the pitfalls of software development,” which while lengthy, accurately describes the layout and structure of the book: a series of case studies that go into specific antipatterns while developing software, presented as pitfalls to recognize and avoid.
I should note that Keep Calm is written by Alex Lau, a former colleague on my engineering team at Mystery Science. I was asked to, and happily provided, a recommendation of Alex’s book for marketing; you can see my dated professional headshot on the book’s landing page. So while I can’t claim objectivity in my review here, I’ll try to be as fair as I can.
Up front, the author makes it clear that this book is written by a software developer, for other developers, coming at the topic with 15+ years working across teams and companies large and small, with codebases to match. It’s a small detail, but I do appreciate it when books begin by giving the reader instructions on how to read the subsequent sections, setting expectations for content and therefore appropriate audience. As I’m practicing smarter reading this year, knowing that each chapter stands alone allows the book to act as a reference manual1.
Structurally, the book is divided into 3 sections with almost 20 case studies in total. These pitfalls cover a lot of what it means to be a professional software developer: that is, what it means to build software for the long haul, some of the common issues that befall development teams, as well as pointers for longer-term career arcs. The set of advice here is appropriate for those who already have a couple of years of work experience under their belt, and are striving for that next level of professional development that’s a bit unchartered and ill-defined, attributes that are often asked during interviews but hardly ever explicitly spelled out. In aggregate, it represents a level of maturity that hiring managers look for, separating the mid-level solid contributors from the senior- and staff-level engineers who can be trusted to lead them.
An alternate use for this book, beyond taking and living its advice, is to use its tenets as an evaluation tool for development environments. Back in the day, Joel Spolsky—an early blogger on software and tech at the turn of the 21st century, and the co-founder of Stack Overflow—published a set of criteria for what he looked for in good software teams2. Similarly, the reader can take some of the pitfalls described in Keep Calm, and see if their surrounding development environment guards against the anti-patterns or conversely encourages them. Many of the pitfalls can be avoided with diligence and practice, but some do require a supportive team and manager to hold the line, when all the incentives and business pressures relentlessly nudge the team towards a cliff’s edge.
A reservation I have with Keep Calm—though this is a criticism of many books targeted at software engineers—is that the advice is garnered from Alex’s experience, which means that its aperture is limited by the types of companies, teams and systems Alex has built his career around. Specifically, the advice applies well in the context of web apps and web services; the release cadences and user expectations and development environment common in this part of software development may not apply universally and require at least a bit of adaptation. Alex recognizes this as well: at one point he mentions that it’s better to iterate on some marketing sites and make low-stakes mistakes along the way, but that’d be less acceptable in more mission-critical situations, where failure can cause global disruptions.
Admittedly, I’m not the target audience for Keep Calm, though many of its points resonate with my own experience as a tech lead, and I’ve dispensed similar advice as an engineering manager as well. The guidance here is best suited for software engineers looking to build from software development competence toward excellence; if that sounds like a precipice you may be facing, then this is an easy recommendation.
Another book in a similar vein, but focused on management topics, is An Elegant Puzzle.↩
Yes, if you go through the list now, it’s a bit esoteric, though some of the steps are still relevant; hey, we’ve had a quarter of a century to evolve how we write software.↩
