Books I've Read That I Think You Should Read Too
Header Photo Credit: Unsplash (Creative Commons Zero License)
I don't read a lot of books, as I prefer blogs and the like, but occasionally there's a book that's not only worth reading, but worth recommending to others. Below is my list of books that I've read and I think people in the software industry should read too.
Rob Conery has made a name for himself helping people learn and understand technical frameworks, languages and the like, through his video-based learning company TekPub (which was acquired by Pluralsight). But Conery, like many people in the software industry, never got a Computer Science degree and, despite his vast volumes of self-taught knowledge on technical subjects, suffered from Imposter Syndrome due to his lack of formal training. So he set out to learn the "essential skills and ideas every developer should know" that a typical CS degree would cover and put them into this book in easily-digestible, well explained chapters.
While I do hold a CS degree, even though Conery was targeting people who don't, it's been almost 20 years since I learned many of these topics, and I've forgotten many (most?) of them, or have only a vague shadow of a memory of their true meanings (BigO notation, for example, was something I've used throughout my career, but the full details eluded me). I highly recommend this book to everyone writing software, regardless of their level of experience or degree status.
Brooks was a project manager on the IBM System/360 project and wrote a series of essays based on his experience. Despite some of the essays in the book now being several decades old, the art of managing software development project hasn't really changed that much and there are many great lessons to be learned from his experiences. I've recommended this book and even leant my copy to pretty much every project manager I've had in my career. It's a must-read if you are, or are interested in becoming, a project manager or team lead.
Now, any software developer worth their salt will tell you that the Gang of Four's seminal works on the topic of design patterns, Design Patterns: Elements of Reusable Object-Oriented Software is the authority on Design Patterns. While that is true, it's also a great way to cure insomnia. I've tried to read it a few times now and can't force myself to finish. But the subject matter is very important for software developers to know and understand. So I "cheated" and read the For Dummies take on the subject and found it to be a very good reference. As is the modus operandi for the For Dummies line of books, they break the topic down and explain it in a way that is easily consumed and doesn't require you to load up on caffeine beforehand.
I'm a huge fan of unit testing and have found Test Driven Development to be my preferred development style. In this book, Osherove walks through the fundamentals of automated testing, including unit testing and mocking frameworks, common terminology, patterns and approaches to writing meaningful and maintainable tests. I read this book with my team and it help set a common understanding and vocabulary for how we approach automated testing. I even used a chapter out of this book as the basis for my Mocking .NET Without Hurting Its Feelings talk.
Jon Skeet, the #1 user on Stack Overflow is one of the world's foremost experts on the C# language and in this book (which he updates with each major language update) he walks us through the history of the language and it's major features, digging deep into how/why they work the way they do. One of the things I loved about this book is Skeet's ability to delve into very complex technical topics in a very conversational tone. I really enjoy Skeet's writing style and find it much easier to consume and stay engaged (ie: not fall asleep mid-sentence) than most deeply-technical books.
If you want to learn about the underpinnings of C# and some of the history behind the language's progression over time, this is the book you should read.
Disclaimer: Jon Skeet is an avid user and promoter of Stack Overflow, my current employer, though I read the book well before I started working there and that is not why I recommend it.
I read CLR via C# with my team at InRule (a team doing some very technically-complicated coding in C#) after I read C# in Depth. There was a lot of overlap between the two books, but not completely. Richter takes a feature-by-feature approach (vs Skeet's timeline-based approach) and goes very, very deep into the CLR features and implementation details. I think this book is a must-read for any C# developers who are doing any kind of advanced application logic. Even among the brain-trust of folks at InRule, every chapter had something new that at least one of us didn't know, and in several instances, something that none of us knew.
This collection of some of the best posts (45 of them) from Spolsky's popular blog Joel on Software (at least up until it's publish date in 2004) includes a lot of good, practical advice for experienced and fledgling developers alike. This includes The Joel Test: 12 Steps to Better Code, which has become a litmus test for any potential future employer for many software developers. Now, you could just read them directly from the Joel on Software blog today, but I found the PDF/Kindle option very convenient for reading during my train commute where internet connectivity was spotty.
Disclaimer: Joel Spolsky is the CEO of Stack Overflow, my current employer, though I read the book well before I started working there and that is not why I recommend it.
If ever there was a guidebook for being a great software developer, this is it. The authors provide practical, pragmatic adviCe for the practice of software development, the role of personal and professional responsibility, and career development advice that is worth revisiting every few year. They provide guidance on writing defensive code, preventing and attacking bit rot, keeping your code flexible and adaptable, and delighting your users.
One of my favorite stories from this book is the concept of Rubber duck debugging. How many times have you gone over to a coworker to get advice about an issue and, purely by having to explain the issue out loud, figured out the solution yourself? Rubber duck debugging suggest instead explaining your issue out loud to a (real or imagined) rubber duck -- you'll get the same mental stimulation as having explained it to a peer -- without bugging any actual people! Since reading this book, I've kept a rubber duck on my desk right under my center monitor as a reminder of this concept.
Unlike the other books in this list, this is not a technical book. The core message of this book is to focus on what's important, be it in your work life or your personal life, and generously say "no" to everything else. This book was recommended to me by a friend during a time I was struggling with burnout, and it really stuck a cord with me. I hesitated, though, to include this book in this list. After reading this book, I became painfully aware and particularly irritated by, in my opinion, the immense lack of focus and strategic direction from the leadership of my employer. Ultimately, this lead to my increasing frustrations with the company and made it much easier for a recruiter to convince me to leave. In hindsight, I'm not sure this was in my best interest, though ultimately, I've landed in a good place. So, while I feel the message of the book is one that everyone could benefit from, it may also be a magnifying glass on the otherwise benign splotches in your life.