Software Development: The Books

Part of the job of a software engineer is to keep learning. The development discipline is still relatively new and changes come frequently. Not only are there new frameworks and technologies sprouting every day (how ubiquitous has Docker become in the last decade?), but also new patterns and best practices of how to build software and software systems. There are slews of talks on YouTube and online courses, but sometimes nothing beats a book for a good, deep-dive into a topic.

The following are some books that I’ve read during my career that I think are good for every developer to be familiar with. I’ve broken them down into three tiers based on career levels: Novice, Intermediate, Veteran. It never hurts to go back and brush up on the fundamentals, so even seasoned programmers can benefit from reading (or re-reading) these books.

My target audience is people who want to stay on the technical track. If you’re looking to become an engineering manager or director, you should read these books, but also add books about leading and managing people.

Novice

For my definition, a novice developer is a college student or someone in the first three years of their professional career. In this part of your career, you should be open to try different technologies and projects to get a broad picture of what career options you have. You never know which skills you acquire will benefit you later on. What matters most is developing good habits and learning new technologies and techniques.

Code Complete, by Steve McConnell.

This book belongs on any serious developer’s bookshelf.

McConnell writes about the process of development in clear, straightforward language without proselytizing a specific strategy. What he cares about more is making developers more thoughtful and preaching the idea of developing your own software development heuristics. He draws on quite a few other books and papers to buttress his ideas with hard data about how even mundane things like variable naming and commenting can improve software development and maintenance.

Favorite chapters 9 (the Pseudocode Programming Process), 21 (code reviews and inspections), and 34 (an overview of all ideas presented in the book).

The ideas in Code Complete will help newbies skip some of the early mistakes and help experienced developers become master craftsmen.

A Deep Dive Into Your Language of Choice. This entry may seem like a cop out, but it’s solid advice. If you’re a C# developer, get a book about the entire .NET framework. If you’re a Python developer, get a book on Python. You pick up bits and pieces of the language in your day-to-day, but knowing the depth of stuff available in your given language is worth its weight in gold. You will find something that you didn’t know about and would never Google to solve the latest feature you’re writing.

A Different Programming Language. This can be an online course or book. Pick a language you haven’t been exposed to before and learn how to write a simple program. Each language has its on programming paradigms, and learning a new one may help you approach your preferred language in a different way. I have my language of choice (C#), but I once wrote a 5-line Python program that more elegantly solved my problem than writing a new C# library and embedding it in a dozen running systems. My philosophy has always been the language is just a tool. The more tools you have in your toolbox, the better you’ll be.

Intermediate

At this point in your career (5 years or so), you’ve written some production code, pulled some all-nighters, and may have had to deal with production outages. You’ve probably worked at more than one company and have an idea of where you want your career to go.

The Gang of Four Design Patterns book and Head First Deisgn Patterns

These two books go hand in hand. Since design patterns are an important part of programming, some may include the GoF book in the first group of books. I’ve included it in the second because I think a developer is better served by being exposed to working software systems first. The temptation for every developer, regardless of career level, is to shoehorn every people they encounter into a pattern or principle they’ve just learned. It’s better to find a solution to a problem you have than to morph your problem to fit a preconceived solution.

The Gang of Four design patterns book is a catalog of different patterns that have emerged over the years that you may have heard of (strategy, facade, adapter, etc). It is a great resource to stop you from reinventing the wheel. The text, however, is a bit dry and academic. The Head First book tries a bit too hard to be funny and clever, but it has some great code-along exercises to help you understand and implement the patterns. There’s nothing that teaches as well as getting your hands dirty.

Software Architecture for Developers, by Simon Brown

Anybody who’s spent time around me knows how much of a fan of Simon Brown I am. His YouTube talks on visualizing software and the lost art of software design shifted my perspective on development. I even got my company to adopt the C4 Model of diagrams for our systems.

Brown’s two books are aimed toward the developer in the trenches. It’s his reaction to a number of software companies misinterpreting Agile. We went from Big Upfront Design in waterfall to No Design in Agile. His book is a way to think about code and system design in a way to find the happy middle between the two extremes. He talks about the -ilities (scalability, reliability, etc), identifying non-functional requirements, constraints, and principles you need to take into account when building an enterprise grade system.

Veteran

This is where I am in my career, so I only have one book at this level. I’m constantly reading, so if you have any good books, feel free to pass them along.

The Software Architect Elevator, by Gregor Hohpe.

In the modern digital world, the software architect must do more than just design systems. It is his or her job to combine the business and technology sections of the business to accelerate the rate of change. Only by rapid (and controlled) change can a company deliver value to both its customers and its shareholders. This is the thesis Gregor Hohpe’s The Software Architect Elevator is built on.

You won’t find descriptions of architecture styles or methods to analyze them in this book. The Software Architect Elevator focuses on the soft skills an architect needs to be effective. Hohpe starts by defining his concept of the elevator. In his or her position, the architect has the unique opportunity to communicate with both the top-level executives (CEO, COO, etc) and the technical workers who actually get stuff done. They can convey technical topics to upper management without losing the essence of the message and can translate the business strategy into technical decisions that support it.

The book is divided into several sections. The first describes the various ways an architect can act and the ways Hohpe thinks they should act. The second is how the enterprise should act in terms of systems thinking, automation, and change control. The third is in communicating architectures. The last few sections deal with analyzing the organization the architect works in and how to promote change. Each section has some great takeaways.

The book is conversationally written and is chock full of helpful tips and stories. It’s a good read for anyone who is (or wants to be) a leader of change in their company. I’m a firm believer that architects need to be in the codebase to be effective, but this book doesn’t require any technical skills to read and get something out of.

Honorable Mentions

I enjoyed these two books by Neal Ford and Mark Richards. I’ve already gotten some value out of them, but I’m not sure if they’re on the same level as Code Complete and The Software Architect Elevator. Time will tell.

The Fundamentals of Software Architecture is a well balanced guide to being an architect. It combines some good, practical examples of how to analyze different architecture styles for their properties and risks, as well as some more philosophically discussion on how to be an effective change agent inside your company.

My big takeaways from this book are the First Law of Software Architecture (everything in software architecture is a trade-off) and its corollary (If an architect thinks they have discoverd something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet), as well as the Second Law of Software Architecture (Why is more important than how).

The book also is a catalog of different architecture styles, which the authors have given star ratings denoting how they feel that style matches a particular quality attribute.

Software Architecture: The Hard Parts

Modern software architecture is a tricky business. The choices of technologies, methodology, and software patterns are rapidly expanding and one that may work for one product or company may not work for a different product or company. Following on the first law of software architecture (“Everything in software architecture is a trade-off”), this book shows you how to analyze those trade-offs.

When designing a software system, context is king. To provide that needed context, the authors describe the different things architects need to consider by walking through a fictional example of a tech support ticketing system (think Best Buy’s Geek Squad). At the beginning of the book, the system is a monolith in trouble and at the end of the book, it has been refactored into a microservices architecture. It’s a helpful framing device to ground what can be a very theoretical subject. The authors step through everything from service granularity to data decomposition to distributed transactions and offer ways to do qualitative (not quantitative) analysis.

It’s a handy guide for anyone who has or wants to architect enterprise-level solutions today.

Conclusion

The world of programming is continually evolving and to be a truly great developer, you must evolve with it. These are just some of the books that have helped me in my career and shaped my thinking with how to build systems that provide value to our customers and shareholders, as well as make them easier to work with. I hope you can take some value from them, too.

Happy Learning!