Some of My Favorite Books about Programming
Clinton R. Dreisbach, Former Viget
I'm always telling people about books that made me a better programmer, and it's a fun and controversial topic to bat around. I thought I'd throw the list out there.
This is the obvious book and is usually not controversial. Every time I go back and read parts of this, I learn something new. Before I read PragProg, I was a decent coder and could hack my way through problems, but my code never was better than I found it. This taught me how to remove requirements between parts of my code and stop repeating myself.
I don't think The Pragmatic Programmer gets enough credit for teaching people how to teach themselves to learn to program, though. It has great advice on how to create and improve your "knowledge portfolio," as they call it, and how to figure out what to learn.
If you never read another book about development in your life, please go and read this. I consider it mandatory reading for having a programming career.
One time, I tried to read Refactoring by Martin Fowler. It's a good book, but with apologies to Mr. Fowler, it made me want to take a very long nap.
Working grabbed me, though, and I quickly figured out that it was teaching me a lot of the same stuff as in Refactoring. I learned how to safely unentangle code and reorganize it without pulling down the whole house of cards. What's more, I learned to love working with legacy apps. Most developers hate this, and I don't blame 'em. It's hard work and it's easy to break an old app. But armed with the skills I learned from Mr. Feathers' book, it started to feel like spelunking. By being aware of my surroundings, I could dive deep into old code, fix a bug or add a feature, and get back out without injury.
Even if you only work on greenfield apps, I think this is a good book to read. Your code will become legacy code soon enough.
This is the one that trips up some of my peers. It's a giant book from Microsoft Publishing. I avoided it too for years. When I did read it, it took over six months on the john. It was worth it, though. You might think that you don't need to read an entire chapter on naming variables, but seriously, you do.
I understood what I do every day so much more after this book. It helped me get software methodologies, why I should unit test, and how to comment code effectively. There's nothing else I've read that took me from designing software systems all the way down to the merits of having a maximum line length in your code.
I recommend reading this book after being a developer for 8 or 10 years. Before that, I think you might dismiss it as too detailed or too big. When I read it, I thought I was at the top of my field and didn't have a lot left to learn. After I read it, I realized I had so much more to learn.
Wrapping up #
None of these are particularly surprising: I see them on lists on Hacker News or Reddit all the time. I think they too often end up in the pile of books to read someday, though. Pick one up, read it, and then drop me a comment about it. Even better, tell me a book you've read that you've found inspiring.