Software Engineering As Fiction: Code Ahead
If you’re familiar with some of the writings about software engineering on Yegor Bugayenko’s blog, you might have heard of his recent book “Code Ahead”. His articles often tend to be very “opinionated” and follow persuasive logic, so I got interested in this unusual new book (which, by the way, doesn’t exist as ebook…). Why unusual? Mostly because of its different form and writing style, and because of some of the contents that might surprise you.
The author calls it “a semi-autobiographical fiction book about a software architect who is involved in programming, debugging, releasing, testing, organizing, team work, and management issues.” The book is organized into separate chapters, each covering a main theme from the world of software engineering (SE). All chapters form an entire story that is mostly told in dialogues between the main characters of the book. The writing style somewhat reminds me of “master–apprentice” style conversations that you’ll find in other unconventional tech books such as the “Head First” series or some philosophy books. It’s one of the main reasons why I find it so enjoyable to read since that style can be a fun and approachable teaching method for any sort of matter.
To underpin the perspectives of the characters, the author heavily uses footnotes (making it sometimes hard to follow the main text, though) and cites articles, books, and academic papers. Since a lot of SE literature suffers from their lack of, it definitely helps to give more credibility to the dialogues and reduces the amount of purely anecdotal evidence. Despite the attempt to balance viewpoints, the author’s (or one of the main character’s) view often seems to be obvious and the main arguments follow his persuasive, pragmatic logic.
However, at least for my taste, the amount of references to Machiavellian literature, carrot-and-stick philosophy and the like, is a bit overdone and you may sometimes disagree. You can never really be sure if you’re dealing with the author’s actual opinion or a sarcastic remark but then again, it’s part of the book format and eventually you have to make up your own mind anyway. Some parts even reminded me of Erik Dietrich’s book “Developer Hegemony”, although Yegor’s is focused much more on concrete SE topics. This cynicism component of the book is why I wouldn’t necessarily recommend it to early stage engineers since you need to have worked on a couple of software projects and experienced different team and management structures to be able to relate to the material covered and see things from different angles.
For experienced software engineers, one of the outcomes when reading such a book could be to adjust some of your attitudes. Over time, certain views develop based on one’s own experience, expert opinions, or SE research, and it should be part of a healthy growth mindset to challenge those views from time to time. For instance, you might have regarded it important to have a final technical decision maker in a team of software engineers (often called tech lead or architect) and some of the stories in the book may confirm that view. In contrast, others might lead you to rethink some previously held assumptions, for instance the common belief that the goal of QA and testing is to prove that the software correctly works (and even more controversial, that a programmer is responsible for the software quality). The hero character in the book, however, argues that the primary metric for a programmer is speed of delivery and the goal of QA to prove that the software is broken (and to even be rewarded for finding as many bugs as possible). So, follow the hero’s and his counterpart’s chain of reasoning about the difference and you might eventually tweak your own views about the topic.
The book contains a couple of such narratives where either the counterpart’s arguments are dismantled or the dialogue partner is presented as somebody stubborn (or both). The chapters focus both on the human and management side of SE (project management, task tracking, metrics, team dynamics, conflicts) or more technical topics (static analysis, testing, delivery pipelines).
Overall, I very much enjoyed reading “Code Ahead” and would definitely recommend it; I’m looking forward to the release of the second part. Now with the upcoming anniversary edition of “The Pragmatic Programmer”, I expect having to revise my list of Top 5 Contemporary Software Engineering Books soon…
