On book recommendations

There’s a great tool called stack.app, which I use to keep track of book I’ve read. It’s like Goodreads but without the bloat. I made a rule for myself that I would only list books that I would recommend to others, so that keeping track of the books wouldn’t become a chore.

What does it mean to recommend a book?

I thought about the context in which I read these books, and how these books seem amazing to me, full of insight. This context, however, only makes sense for a small subset of the entire population of people that I could recommend books to. People who are not looking to build new technology products might find that Peter Thiel’s Zero to One is not applicable to them. They might learn about another person’s perspective, but it wouldn’t be the greatest book they have ever read.

Even within a narrow field, it might do you well to dismiss some recommendations. Like computer programming, for example. Maybe there’s a technique for software development that a friend thinks you should learn about. But what if you’re already a step ahead, having actually used that technique at your previous job? It might tempt you to read a formal book about the technique, but reading a book is a considerable investment of your time. Spending an hour discussing the book with the friend, before reading it, might save you from ten hours of reading if you discover during the discussion that you’ve already learned the technique.

If, after the discussion, you find that this book will potentially be useful, there’s no harm done. You gave your friend a chance to explain what they have learned, and you can read the book afterwards.

The lesson

At a certain point, working smarter becomes the only way to make progress. One person might read several books a week, and another might read only one. If that one book is chosen carefully, then the net result is usually greater.

This is a shift from short-term thinking to long-term thinking in which you evaluate not only the immediate results, but also the future ones.

This comes up a lot in software development in the form of technical debt, where it might seem good in the moment to choose the 20 minute solution over the 8 hour one. The problem arises when that 20 minute solution has certain drawbacks that eat away hours later, often many multiples of the amount of time that the original “long” solution would have taken.

In many areas of life, putting in a little more time right now often saves a lot of time in the future. It’s just so hard for us to do this because for thousands of years, humans never had the opportunity to think about anything other than their immediate needs.