Developer Book Club

I’ve worked in Ruby shops for over a decade and I’d even seen Sandi Metz give a talk at Abstractions in Pittsburgh in 2016, but I never read her book until 2022. For organizations that primarily write Rails and don’t write too much pure Ruby, it’s a great book. It illustrates that you can write Plain Old Ruby for your Objects, and walks through a number of good design patterns that work well for Ruby. Lots of Factory classes and Facades.

This book by Felienne Hermans is a dense but accessible one. It goes into great detail about how programmers, whose entire job is about abstractions, can best deal with working with those abstractions in their brains. There’s a lot of great exercises in this book, including one related to expanding one’s knowledge about a programming language quickly, that I have used to learn both Go and Python a lot faster than I have other languages.

Developers are expected to give critiques on each other’s code, but giving and receiving critique is not something that’s really covered in software development courses or in online guides. Additionally, I’ve know a good number of developers who have worked in less-than-ideal environments, where critique was wielded as a weapon against them. The book only talks specifically about visual design in a few areas, and it’s pretty simple to find software development analogs to those sections. Adam Connor and Aaron Irizarry’s book is one I would suggest to any engineering department that wants to improve their team’s pull requests, architecture discussions, and interactions with product and other areas of the company even better.

Do this one after POODR and The Programmer’s Brain. This book defines software complexity in a way that’s easy to apply to your code, and then provides a series of tools that you can employ to reduce your code’s complexity. All of the reviews of this book I’ve read all take away different conclusions, which I always find to be a sign of an interesting book. I highly recommend John Ousterhout’s book, especially if you have a sizable chunk of source code you’re working on refactoring while holding the concepts in your working memory.

Michael Abrash’s high performance 90s DOS PC programming book probably won’t interest many developers nowadays – they’re dealing with CPUs that can run hundreds of copies of DOOM all at the same time (and they might not know what DOOM is anyway…). However, the first chapter gives a fantastic description of when to crank up the performance knob, eschewing readable, clean code in exchange for speed, and when it doesn’t make sense. PoSD’s performance chapter is good, but I like to pair it with this book’s as well.

But give devs on your team bonus points if they try writing some x86 assembler after reading!

The first three parts of Cal Newport’s post-student-advice-books book gives plenty of examples of what you need to do to become exceptional at what you do. The formula: get really good at something through study and practice, don’t hop around looking for the perfect job, and figure out the currency that matters most in the field you’re working in. For software developers, that currency is raw knowledge and experience with the fundamental ideas of software development, and not individual languages, frameworks, or technologies. The last section – connecting your work with a mission – I find to be a more personal thing you need to be ready to do yourself, rather than trying to force while mentoring.