Review of Programming Beyond Practices by Gregory Brown. Published by O’Reilly Media, October 2016. 132 pages.

In the interest of transparency, I’ll start off by mentioning that I’ve known Gregory Brown, via online channels, for several years. We’ve had some interesting discussions over Slack in the past. He was even kind enough to mention me in the acknowledgements for this book, which I was really glad to see. So while I’m going to give my honest opinion here, I’m not going to claim that my review will be completely unbiased.

With that out of the way, here’s what I think about Programming Beyond Practices.

It is a well-written (and funny) book that contains a ton of good advice, especially for developers in the early stages of their career. But also for someone like me, having programmed professionally for almost two decades, there are a lot of great insights along the way.

The book is written in second person, which may not work for everyone. It took me a few pages to get used to, but after that I quite enjoyed it. I found it engaging to have the author speak directly to me, putting me at the center of various narratives.

Programming Beyond Practices takes us through a journey of increasing levels of experience, a “full career in software development”. We start as a “competent programmer” and end up at the master level. To be quite honest, I’d forgotten about this progression until re-reading the introduction as I sat down to write this review. I worry that I may be missing an important overarching point in the book, but I actually just enjoyed the chapters individually and did not notice the skill level progression.

Most of all I enjoy the very simple and explicit writing style: You are in this situation, here is what happens, this is how you react. The concepts in the book are taught by example, and it is easy for me to relate to all the stories in the book (except for the last one which I’ll get to later). There is no speculation and no lengthy explanations or theorising. Just several (fictional, I assume) case studies. This is a great way to teach these kinds of topics, because they inherently belong in the field.

Each chapter concludes with a list of key points to take away from the case. I found this to a be a very elegant way of extracting the essential learnings after going through a real-life scenario. Many books will get this backwards: Explain concepts in the abstract, then provide a few examples. I like the structure of this book much better.

It is important to note that the book is not actually about programming, it is about understanding the needs of other stakeholders while developing software, and about appreciating the messiness and hidden complexities of real world systems. And about several other topics you’re bound to encounter as you pursue a career in software development.

Coming up with useful and realistic cases must be really hard, and I think Gregory did a good job in most chapters. However, I do think chapters 4 (about rigorous problem solving) and 5 (about bottom up design) missed the mark slightly because they are not about actual production software. I don’t have the imagination myself to come up with real-life scenarios that would have served as a good backdrops for the particular topics in these chapters, but I did miss the more realistic settings from the rest of the book.

The last chapter in the book was particularly interesting to me, because I knew after the first few sentences that I would be disagreeing with much of it. And I did, but I still loved the chapter and the way to wrap up the book.

The chapter is an exploration of what software development might look like many years into the future when programming by hand is no longer necessary and when interaction with computers is verbal and completely natural: “Overlay this map with that data, extract these statistics…” etc. Much like the UIs of science fiction movies.

As fun as it is to imagine this possible future, Gregory goes on to discuss the most interesting question about it: How would it affect and empower us as problem solvers? (The title Developer loses much of its meaning). If we could do the number crunching and solve the real-world problems without actually writing code…would our jobs be more satisfying than they are today? Not an actual question from the book, but it does come out in the discussion.

This is where I knew right away that I would disagree with Gregory. Having followed him online for a while it seems obvious that he his primary interest is in solving real world problems, and he sees writing software simply as a tool to accomplish this goal. I respect this a great deal, because it obviously focuses on the value that we as developers bring to the world.

But personally, I just enjoy the process too much to feel the same way. There is a great quote towards the end of the book: It’s true that some folks among us are here solely for the tools, the code, the intellectual challenge of it all. But for the rest of us, that’s a matter of necessity and the environment we work in, not a defining characteristic of who we are.

I’m slightly ashamed to count myself in the group of “some folks” in that statement. Maybe it is because I never went to university and studied the basics of computer science, but as my career progresses I find myself drawn towards the challenges of actually writing the code and becoming more skilled in the craft of software development. I’ve written a huge amount of code, but actually understanding how programming languages work, how typing works, how algorithms work, that is something else altogether. And I am hungry to learn more about this theoretical side of my craft.

Of course I care about the problems I’m working on. I would not find joy in simply churning out features for a company I did not care about, which has also shaped my career path. Working on systems that are meaningful to real people is very important to me. But I’ve come to realise that my main interests are technical. I love the challenge of taming the complexity and writing concise, error-free programs.

This was a tangent that probably doesn’t belong in a book review at all. I apologise for the rambling. The connection to the book is that the last chapter offered me another perspective on my own values as a developer.

Wrapping up, I will highly recommend this short and well-written book to developers of any experience level. If you’ve spent a lot of time doing “agile” development (is that even a thing anymore?) you may find that parts of the book don’t teach you much new. But I would be surprised if you didn’t find that some chapters offered you new or more systematic ways of approaching problems you’ve faced many times on various projects.