My three favorite non-programming books for developers

Back when starting my first software development job I thought my success at work would be directly determined by my programming skills. Of course, that's not the case. One can be the most productive and clever programmer in the world, but that alone isn't sufficient for a satisfactory career in software development. You'll need to get along with people, know which problems not to fix, deal with pressure, etc.

So while keeping up with the latest advances in software development is important, I think it's just as important to keep learning other aspects of a software developers' working day. Sometimes such skills such as getting along with your colleagues are called "soft skills", a term I find a bit patronizing considering that the actual coding is only half the job.

What's a better way of learning than reading books? Here are three of my favorite non-programming books I think developers could enjoy.

How to Win Friends and Influence People by Dale Carnegie

Dale Carnegie said "Dealing with people is probably the biggest problem you face." I think this applies to software development as well. Every day you're dealing with other people and their needs, be it customers, clients, team mates, or your boss.

This is the best book I've read on interacting with people. It may be old (published in 1936) and the title may lead you believe this book is about manipulating people to like you or have them do what you want. That's not the case at all: In contrary, Carnegie repeatedly shows how sincerity and empathy are the keys to satisfactory relationships with people. All in all, they are the keys to a more satisfactory career and life.

"Don't condemn, judge or complain", "talk about others' interests", "if you're wrong, admit it immediately", "let others save face", "consider others' needs before you speak", "never say anyone you're wrong". These are some of the advice Carnegie teaches, be it talking to your boss, team mate or potential customer. It may feel hard to deal with people in a professional setting with such hard constraints, but I think Dale Carnegie makes compelling statements how it's possible and why it pays off.

Here's a tongue-in-cheek stereotype description of programmers from The Clean Coder by Robert C. Martin:

"Programmers tend to be arrogant, self-absorbed introverts. We didn't get into this business because we like people. Most of us got into programming because we prefer to deeply focus on sterile minutia, juggle lots of concepts simultaneously, and in general prove to ourselves that we have brains the size of a planet, all while not having to interact with the messy complexities of other people."

It's a stereotype, but there's a hint of truth in there. And just because such stereotypes exist, I think we developers should spend extra effort on learning how to collaborate and get along with people.

The Lean Startup by Eric Ries

Imagine your company is thinking of launching a new product. You can see in your head how the customers will love it and how your company will make a lot of money by selling it. At this point, we engineering-minded people would love to jump to the whiteboard, figure out the technical implementation details, and start coding.

However, not all great ideas are worth pursuing. You could be spending a ton of engineering effort and money on a product no-one actually ends up using, just because the reality didn't match the idea in your head. All business plans are uncertain, and the best book I've read on dealing with uncertainty in product management is the Lean Startup my Eric Ries.

The Lean Startup is a scientific method for dealing with uncertainty. It shows how to put your assumptions (hypotheses) on paper, how to find ways to validate those hypotheses with minimal waste and how to know whether to persevere or pivot.

Every developer should care for the product. Your boss may be telling you to code a feature because a client is asking for it, but before getting to work, it's your duty as a developer to carefully think if (a) the feature actually solves the client's problem and (b) the feature improves the product as a whole. In the language of lean, what you need to do is always think about minimizing waste.

The Lean Startup is a great book on data-driven decision making. We developers like to think we're doing a great job because our users say they like the changes and we're getting more users. But how can we be sure that the improvements are because of the changes we've made, and if the numbers are showing our efforts actually paid off enough compared to all engineering effort? When developing new features, we need to carefully think how to measure their effect and how to decide if our assumptions were valid or not.

The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin

Robert C. Martin, or "Uncle Bob", is a somewhat controversial figure: he's definitely a legend in software development, but he's also more than once got into trouble about expressing his views on the differences between men and women a bit too eagerly. Some may also find his writing style a bit arrogant. Putting that aside, I think The Clean Coder is a very good read for anyone serious about a career in software development.

The book gives one perspective on what it means to be a professional software developer. After reading the book, you'll probably hesitate saying "I'll try" next time when your boss asks you to launch on Friday. Instead, you'll tell them "I'll do it"', "It's impossible", or "There's 50 % chance it'll be ready on Friday but it could be as late as Tuesday". You'll refuse to do quick and bad work just to be the hero of the day who managed to deliver fast.

In addition to how to commit, the book teaches how to estimate, collaborate, mentor, deal with pressure, get over writer's block, and so on. If you're looking for another all-around book on the life of a professional developer, I recommend The Pragmatic Programmer. I did not include it on this list because I count it as a programming book. As a book on programming best practices, I think The Pragmatic Programmer has stood the test of time a lot better than The Clean Code, especially if you pick up the 20th Anniversary Edition of Pragmatic Programmer.

Conclusion

This concludes my favourite non-programming books. What are your favourite books and do you agree with this list? Let me know in the comments, and thanks for reading!