The Most Valuable and Underrated Books for Software Engineers

You want to become a better software engineer. You learn new tech stack, you do hackathon, you’ve read Code Complete twice and follow Kent Beck on Twitter. That’s all good. But focusing only on the technical side is a mistake.

It is important to do cross-domain learning as well. Arts, fiction, biology, physics, woodworking, etc. By learning from other domains, you look at similar problems or concepts from a different point of view. This lead to more insight into your own craft. And THAT is what will make you a better software engineer. Better than your peers.

While I encourage others to keep this broad and diversified, I have found some books to be particularly relevant to software engineers.

I’ll explain why I picked those books below, but for the impatiens…

TL;DR Every software engineer should read those 4 books, but most haven’t :

• The Design of Everyday Things, by Don Norman
• The Mythical Man-Month: Essays on Software Engineering, by Fred Brooks
• How to Win Friends and Influence People, by Dale Carnegie
• The Elements of Style, by William Strunk JR and E. B. White

Software engineering is about building stuff. And other people will use what you build. Design is about interaction, how what you build interact with others. This goes at all levels, from GUI to physical interaction to APIs.

While not all software engineers need to be good at graphic design, it is a critical skill to be good at UI/UX, even if what you create is a low level library, other software engineers will use it.

Understanding design also provides a lot of insight about UI/UX designers do and how they think. Whenever you communicate with someone, the more you understand his world view, the more you can empathize with them. So learning about design improve both your own work, but also your communication ability with a key person in the software world.

Yes, it’s old. Yes, some parts didn’t aged well. Still, the main findings from Mr. Brooks seems forgotten every now and then. As a software engineer, you don’t NEED to know everything about management. But knowing the basics of it, the “common sense” on this topic (which isn’t as common as what’s implied) is very valuable.

And while the book is well known for “the mythical man-month” discussion, there are a lot of other really insightful findings in there.

Most software projects are done with others. You might have a hobby project that only you care about, but for most of the stuff you have to interact with others. As such, knowing how to interact with others in an appropriate way is a critical skill to master.

That might sound stereotypical, but for most software engineers social skills aren’t their main force. But like every skill, you can learn it, improve it, become good at it.

There are many books on this topic, some focusing on specific aspects of professional social interactions (networking, 1:1, delivering feedback, etc.). But I prefer a book that looks at this topic from a wider point of view, for the general public. Then you can apply what you learn, whatever the context is.

You’ll spend most of your time writing. Either writing code, writing documentation, writing emails, writing code reviews, writing design, writing architecture, etc. Better become good at it.

Also, a lot of good advice for writing well apply to other forms of communication as well. Pay attention to what you learn, and see if that’s applicable to other spheres too. That way, you get even more value out of the same book. I got some good management advice from that book, since some concepts are almost universal.

And that’s it. Again, those are the books that everyone should read and learn from. But the most important thing to remember is :

1. Read from other domain than your own.
2. Pay attention to what you learn, and think about how where that could be applicable, where this could be useful as well.
3. Keep expanding into new directions, that’s a great way to bring new ideas into your own specific domain.

That is the key to rising above the crowd.

Originally published on Medium