I’d imagine many people don’t think to read software engineering books to hone their skills. Watch tutorials, read articles, sure. But I’d argue that there’s much to be learned from the best software engineering books. Toward that end, I’ve compiled three must-read books all Software Engineers should know about.
Accelerate: Building and Scaling High Performing Technology Organizations is a must-read book on software development. It’s a data-based look at what separates high-performing software engineering teams from mediocre ones.
The authors looked at four measures for delivery performance for engineering teams:
Delivery lead time, i.e., “the time it takes to go from code committed to code successfully running in production”
Time to restore service
Change fail rate
What they found isn’t super surprising, but useful to have quantified. First, when it comes to revenue and productivity gains, technology decisions are more important than mergers and acquisitions, and entrepreneurship.
I also learned that going faster doesn’t necessarily mean making more mistakes. “There is no trade off between improving performance and achieving higher levels of stability and quality,” the authors write.
High-performing teams perform better on all four measures. And the highest performers are pulling away from the pack. Organizations with high-performing technology teams were consistently twice as likely to exceed profitability, market share, and productivity goals as low performers.
The book offers helpful advice based on their research and from other important sources such as Westrum’s Typology of Organization Culture to improve your organization’s software craftsmanship.
The book takes you through what it takes to improve performance. For example, they found teams that use continuous delivery have statistically significantly less unplanned work. In addition, version control predicts IT performance.
Published in 2003, this isn’t the book with the most recent recommendations or hottest takes. It’s not the most practical book for software engineers. But, it is fun to read, and that counts for a lot. Joel Spolsky took his favorite posts from his popular blog and arranged them into a book. The essays cover a wide range of topics, including hiring, motivating, and otherwise managing software engineers. He also addresses project management tasks like estimating and writing specs. And plain-old software engineering advice like common pitfalls in software development, data structures, and how to choose a programming language.
It’s clear that Joel enjoys writing. His language is colorful, “Specs are like flossing: Everybody knows they should be writing them, but nobody does.” He uses storytelling from his own life and hypotheticals to illustrate his points. Like Shakespeare, he invents his own vocabulary, e.g., “Shlemiels.” The book is, at times, profane and always to-the-point.
I had to include this excerpt, The Joel Test: 12 Steps to Better Code, because he makes a great case for Focus Time:
With programmers, productivity depends on being able to juggle a lot of little details in short-term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can't remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm) and you have to keep looking these things up, which slows you down a lot until you get back up to speed.
Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, let's put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff. Ahhh!
This is a great read for people starting out or considering starting out in software engineering. After a year of self-study, author Cory Althoff learned to program well enough to land a job as a Software Engineer II at eBay. One problem with a lot of how-to books is that they’re written by prodigies. And people to whom things come naturally are generally not the best at teaching.
Althoff is an exception. He’s written a super accessible, concise, readable book that covers topics ranging from how to program in Python to the soft skills you’ll need to succeed in the job. The glossary at the end of each chapter alone is worth the purchase price. It’s a practical book, with few wasted words.
I appreciate the thinking behind leaving theory until the end. First, you learn the difference between functional and object-oriented programming, and how to use a command line. Then, it goes into getting qualified for a job, common interview questions, and succeeding in your first job.
Word of warning: The Kindle version doesn’t support multiple fonts or other cues to separate text and code.
There are a ton of great software engineering books. People have recommended:
I personally enjoyed The Manager’s Path.
Which are the best software engineering books will always be somewhat subjective. But for me, these are the must-read books software engineers can start with and learn a lot from.
What are your favorite software engineering books? Let me know at cathy at getclockwise.com.