Foreword

    You’ve probably heard the old adage that experience is something you don’t get until after you need it. For those of us in the coding world, this book was written to solve that problem. But it’s not what you might be thinking—this is a book about the culture and practice of coding rather than the coding itself.

    Alex presents these lessons in a way that speaks to developers like me then and developers like me now. His book recognizes and names a set of antipatterns that are common in engineering teams—antipatterns that are not conducive to productivity and sometimes even for the health of both team and individual. It’s worth asking here why antipatterns exist at all. If the subject of an antipattern is such a bad idea, why doesn’t everyone intuitively understand and avoid them?

    I think it’s because, at first glance, antipatterns present us with a mirage—a faint, hazy illusion resembling that which we do want to promote. What makes something an antipattern is that it seems to be the shortest path between where we are, and where we want to be. But there are at least one of two qualities present in an antipattern that are missing from positive patterns. The first is that where we want to be and where we think we want to be are not the same destination. (With apologies to the early developers of Twitter, imagine writing a microblog when what you really wanted was a message broker.) The second (and worse possibility, in my opinion) is that the shortest path leads us directly into a gaping maw of despair that we don’t see until it’s too late—a "pitfall," if you will.

    The tragedy of this second quality and the pitfalls it portends is that there is nearly always a way to avoid the looming disaster if only we have both awareness and knowledge of how we will arrive there.

    Alex has structured this book as a series of case studies centered on the aforementioned antipatterns. There are chapters that warn about cultural antipatterns—for example, the rockstar who believes they can hack their way through all the code themselves and won’t collaborate with team members. There are also chapters that walk us through the pitfalls of process antipatterns—for example, the bikeshedding team who bicker about the asinine detritus of their current feature specification rather than building literally anything of value with that energy.

    Alex and I worked together as engineers at a startup in Austin a few years before the pandemic. When we were stuck on an intractable block of code for a thorny set of features, Alex would often suggest that we go for a walk. I’m not much of a walker, and I don’t like to be interrupted when I’m in the zone. But he always knew when to pause and how to coax me outside. Those walks were a chance to breathe, test assumptions with one another, and remember the larger goals we shared. Alex knows how to frame and reframe a challenging issue so that his coworkers and friends come away from conversations with a new perspective.

    There are several times in my life when I would’ve benefited from reading this book. First, as a new developer early in my first couple of roles, I struggled greatly with hubris (as many young coders are wont to do) and could have used a reality check. For example, at one of my first startup roles, I was convinced that the language (Visual Basic, for the curious) and some nebulous aspect I called "the architecture" were at fault for difficulties and a lack of productivity. (Certainly, it wasn’t my lack of experience or understanding that could be at fault!) Moreover, I was unable to ask for help when I needed it. I was not even able to recognize that I needed help, though I’m not sure I would have sought it out if I had.

    Alex’s own stories ground each case study—they are relatable looks at what it feels like to work on engineering teams today. Many developers, especially early in our careers, can become quickly enamored of the new hotness: new languages, new tools, new libraries, new techniques. In The Shiny New Objects Pitfall chapter, Alex highlights the risk of glossing over the drawbacks of a new library or language. The story Alex shares here—one in which he was evangelizing for some shiny new text editor widget and was pulled back by his product manager—offers a mildly cautionary tale about unforeseen consequences. Keep Calm and Code On is honest, avoids jargon, and offers readers the opportunity to reflect on their own potential pitfalls.

    As a mid-level engineer, I had enough experience to know there was a better way of doing things. I had been exposed to teams with better working habits and more developed workflows—for example, I’d seen teams prioritize work-life balance and test-driven development. I’d also seen teams shortchange themselves by failing to complete a migration to a new tool or by ducking the difficult conversations required when they needed to say, “No.” At that point in my career, I had enough experience to sense some of what worked and what didn’t work. The problem was that I had no real mentorship—no one to help me name the problems my teams were encountering, and no one to help me work through those problems. Not only does Keep Calm and Code On offer readers the feeling of recognition when our work challenges are clearly named, but it extends hope that we might be able to find a path forward.

    Alex is frank about the challenges confronting engineering teams and leaves us with questions to guide our thinking rather than offering platitudes and prescribing canned solutions. For example, often pressure outside our immediate development teams leads to decision-making driven by short-term objectives. In The Default to Yes Pitfall, Alex makes clear the problems when engineers end up overcommitted when implementing features or specifications that may solve a problem but not the right problem. He advises those of us who find ourselves in that situation to consider pushing back and guides us through the drawbacks when we don’t. Reading this book feels at times like venting with a colleague or having beers with a mentor.

    Reading early drafts of some of these pitfalls helped crystallize for me the challenges I’d so often experienced but hadn’t verbalized even with decades of experience. By the time I moved into more senior roles, I had the intuition to make the right calls and (mostly) avoid the wrong ones. In fact, when leading teams I often have the sense that we’re headed somewhere I’ve been before. And yet, encountering familiar problems and helping others navigate through those problems are two different tasks. In naming the pitfalls, Alex offers senior developers new tools for leading teams by providing a shorthand for discussing the complex problems that arise in our work.

    Ours is not a field that pauses long for reflection. With this book, Alex has distilled the most fraught moments developers will stumble through and offers us the chance to consider what he’s done, what we might do differently, and how we might help others avoid these pitfalls of programming.