Recommended Reading for Developers

Steve McConnell’s Code Complete 2 is the Joy of Cooking for software developers. Reading it means that you enjoy your work, you’re serious about what you do, and you want to keep improving. In Code Complete, Steve notes that the average programmer reads less than one technical book per year. The very act of reading this book already sets you apart from probably ninety percent of your fellow developers. In a good way.
I like this book so much that the title of this very website is derived from it – the examples of what not to do are tagged with the “Coding Horror” icon. There’s nothing funnier than a Coding Horror – until you have to deal with one yourself. Then it’s suddenly not so funny any more. Do yourself a favor. Make this the first book you read, and the first book you recommend to your fellow developers.
Arguably the only classic book in our field. If you haven’t read it, shame on you.
I challenge any developer to pick up a copy of The Mythical Man Month and not find this tale of a long-defunct OS, and the long-defunct team that developed it, startlingly relevant. This twenty-five year old book boldly illustrates one point: computers may change, but people don’t.
Reading this classic work will certainly be a better use of your time than poring over the latest thousand page technical tome du jour.
The single best book on usability I’ve ever read. The title says “web usability” but don’t be fooled by its faux specificity. Steve Krug covers every important usability concept in this book, and covers it well. It’s almost fun. If you choose to read only one book on usability, choose this one. It’s chock full of great information, and it’s presented in a concise, approachable format. It’s suitable for any audience: technical, non-technical, user, developer, manager, you name it.
(The solution to most usability issues, by the way, is quick and dirty usability testing. Imagine that: making decisions based on actual data instead of never ending, last man standing filibuster style religious debates. Revolutionary!)
The full title of this book is Rapid Development: Taming Wild Software Development Schedules, which isn’t just long-winded and vaguely ridiculous, it’s also an unfortunate misnomer.
Rapid Development isn’t about rapid development. It’s about the reality of failure. The vast majority of software development projects will fail: they will overrun their schedules, produce substandard results, or sometimes not even finish at all. This isn’t an argument; it’s a statistical fact. The unpleasant truth is that your team has to be very good to simply avoid failing, much less to succeed. While that may sound depressing – okay, it is depressing – you’ll still want to read this book.
Why? Because half* of success is not repeating the same mistakes you, or other people, have made. The epiphany offered in this book is that making mistakes is good – so long as they are all new, all singing, all dancing mistakes. If you’re making the same old classic mistakes, you’ve failed before you’ve even begun. And you probably have no idea how likely it is that you’re making one of these mistakes right now.
Our field is one of the few where change is the only constant, so it’s only natural to embrace that change and try different “Rapid” development techniques. But the converse isn’t true. We can’t assume that so much has changed since 1970 that all the old software development lessons are obsolete and irrelevant when compared to our hot new technology. It’s the same old story: computers have changed; people haven’t. At least have some idea of what works and what doesn’t before you start – in McConnell’s words, “read the instructions on the paint can before painting.” Sure, it sounds obvious enough until you read this book and realize how rarely that actually happens in our field.
*According to the book, technically, one-quarter. But I think it’s more than that.
If you’ve ever seen the performance of an all-star sports team suffer due to poor coaching, you’ll appreciate this book. It doesn’t matter how many “coding superstars” you’ve got when none of them can talk to each other, or agree on anything. No developer, however talented, can work effectively when constantly being barraged with minor interruptions. Developers aren’t known for their people skills, per se, but here’s the ironic part: the success of your project may hinge on just that. If you have any legitimate aspirations to be a “Team Leader” in practice instead of in name only, you need to pick up a copy of this book.
While Peopleware is full of great, totally valid points, it also implies a level of employee control over the workplace that is pure fantasy at most companies. But at least you’ll know when your work environment, or your team, are the real problem – and more importantly, what to do about it.
Speaking of people, what about the community that forms around your software? What’s the point of software that nobody uses or talks about? Cultivate your community. Tend to your software garden and invite others to help. Maybe you’ll get lucky one day... who knows? 🍀
If you’re reading this far, congratulations! You should probably write a blog, too – ask Piotr and Cynthia if you don’t believe me. Or Philip!
It can be incredibly frustrating to develop software, because so much can go wrong.
A lot of what we do is defensive: trying to anticipate what will go wrong before it does. It’s mentally fatiguing, and can eventually manifest itself in some negative ways. I sometimes describe this to non-technical people as building a watch with a thousand moving parts, all of which can fail randomly at the slightest provocation. Good times!
Designing software is difficult, to be sure, but designing a door is difficult too. The nuances of design extend into every object you touch, whether it’s some hot new SQL engine, or a humble shoe. This book will give you a new appreciation of the “devil in the details.” If designing a door isn’t the no-brainer we though