While there are many books I have read during my career as a software engineer, there are a handful that have been influential in my thinking. Here are my top 2 books for software developers. If you’ve read them before, you might want to read them again through the experience lens of your development career.
These are authors that have years of real world experience with various customers, so they’ve seen a lot and have done a lot. They’ve also collaborated and refined their thinking with many developers and other ‘thinkers’. The style of writing is approachable and easily read, these are not dry text books. These authors are candid about their failures, and highlight that it takes them several revisions to get to the point of being content. They acknowledge that it can be hard work.
The books include a lot of sample code to illustrate the good, the bad, and the ugly; and yes it can be painful to read code on paper. Did I mention the basis of their material is not academic, it’s from real experience and vetted with others?
Clean Code: A Handbook of Agile Software Craftsmanship
by Robert Martin (“Uncle Bob”)
Available on Amazon.com
Covers a lot of practices distilled from his work and those of others.
“Learning to write clean code is hard work. It requires more than just the knowledge of principles and patterns. You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch other practice it and fail. You must see them stumble and retrace their steps. You must see them agonize over decisions and see the price they pay for making those decisions the wrong way.”
Broken into three sections, intentionally listed out of order:
1. The first section describes the principles, patterns, and practices of writing clean code (no joke, Uncle Bob wrote a previous book with a similar title).
3. The third section lists smells and heuristics gathered from experience. It is similar to Martin Fowler’s approach in the Refactoring book.
2. The second section is all about code. There are several case studies on improving code, noting reasons for the changes. IMO it’s dense and requires concentration to work through it. I think its valuable to do so in order to appreciate how the principles are applied, and to incorporate that into what you know about your code.
4. There’s an appendix that is equally valuable where heuristics are cross referenced with where they were used.
Growing Object-Oriented Software, Guided By Tests
by Steve Freeman, Nat Pryce
Available on Amazon.com
Design of software using tests, employing an object-oriented paradigm of tell, don’t ask. They call it Test Driven Development, I think they should change Development to Design because that is what this approach really reveals.
“This book is about the techniques of using tests to guide the development of object-oriented software…”
“Test-driven development combines testing, specification, and design into one holistic activity.”
“In this chapter, we want to show something of what we’re trying to achieve when we design software, and how that looks in an object-oriented language; this is the “opinionated” part of our approach to software. In the next chapter, we’ll look at the mechanics of how to guide code in this direction with TDD.” (from the second section on object oriented style)
Broken into five sections:
1. The first section is a brief introduction covering why TDD, the different kinds of testing, how object-oriented design influences testing.
2. The second section covers how to get started with TDD and keep it going (the process) and how design goals relate to TDD and can be used to guide the structure of the code (the last quote above was from this section).
3. The third section is a working example of the incremental process and code that comes out of it; and the inevitable backtracking and rework when previous decisions were wrong. “We want to show how the techniques fit together over a larger scale than the examples usually presented in books.”
4. The fourth section talks about how to keep TDD going by considering test code equal to production code and providing some guidelines.
5. The fifth section provides some guidance on some cases that people tend to have trouble with TDD: persistence, threads, and asynchronous code.
And a runner up…
by Kent Beck
Available on Amazon.com
How day-to-day choices in code reflect communication and intent. Or maybe it’s how to communicate intent in code.
“This book is about programming–specifically, about programming so other people can understand your code…It’s like all writing–know your audience, have a clear overall structure in mind, express the details so they contribute to the whole story…The implementation patterns here are Java programming habits that result in readable code.”
This is my hot list. What would you suggest for reading next, and why? — Jamie