This post was first published on CoderHood as 11 Books All Software Engineers Must Read. CoderHood is a blog dedicated to the human dimension of software engineering.
When I started coding back in 1984, there wasn’t much literature available to guide me on my learning path. One of my issues was that I was in Italy and I didn’t know a word of English. It is possible that there were books available in English, but the selection of Italian translations was insufficient. I got the majority of my early knowledge from a few translated programming books and some technical magazines.
Among the translations that were available in Italian, I remember some of the early work of Peter Norton fondly, recognizable by the full front-cover picture of himself with his arms crossed.
Today there are thousands of technical books available and the Internet is a treasure trough of information. Finding what you need to learn a new language or framework is as easy as a running a Google Search. There are also many non-technical books that can guide you on how to think as a developer who can work well in the context of a team and a software organization. Leadership principles, teamwork, development processes, business and general software industry knowledge are very important for a successful career in tech, and I’d like to share with you some of my favorite books, in no particular order.
Extreme Ownership: How U.S. Navy SEALs Lead and Win
by Jocko Willink and Leif Babin.
Inner-game is very important for career development in tech, and this book will help you reach your goals. This book has nothing to do with the software industry and everything to do with the inner-dialog you need to succeed in the software industry.
One of the authors, Jocko, is the scariest man on earth; a Navy SEAL who was sent to lead Task Unit Bruiser in the most violent battlefields in Iraq. There, he forged a mindset of absolute ownership for the results of anything he did.
This book is a translation of the wisdom and principles acquired in the battlefield to a way of thinking that can be applied in business and life. It is a must-read for anyone who wants to take ownership of their career path and stop making excuses. It will change the way you approach work and life.
Scrum: The Art of Doing Twice the Work in Half the Time
by Jeff Sutherland, JJ Sutherland
If your organization uses Agile methodologies to develop software, this book is for you. If your organization doesn’t follow Agile methodologies, you should decide if you need to change that. This book will help in both cases.
It is not only a must-read for Engineers and Scrum Masters, but it is also an excellent book for anyone who wants to understand how software is built. It demystifies the process and makes it clear what an organization can and should expect from Scrum teams. It is not a technical book. It is not a book only for engineers. It is a book for anyone that wants to learn about a method that can be applied to increase the productivity of teams in any field and organization.
It isn’t a detailed guide on Scrum practices, but it will explain in great details why Scrum works and why you should consider it to guide the process of building software. It will help you form the mindset you need to understand Scrum, and will give you the basics for its implementation.
I am acutely aware that not all developers are in love with Scrum or Agile methodologies, but I find that most of the time the reasons are one or more of the following:
- They do not understand Scrum, and never took the time to study it.
- They tried it before because they had to but fought it and decided that it didn’t work.
- They tried it before, gave it a shot, but didn’t give it enough time to get in the groove.
- They tried it before, gave it a shot, but only subscribed to a few principles and ignored others.
- They worked in teams where some of the people were fighting the process at every opportunity.
- They never implemented it well.
- They do not function well in teams.
- They feel like any time spent in activities that are not coding is wasted time.
- They are not used to plan their work, and any attempt to do so goes against their “design as you go habit.
- They feel like they own the code, and do not accept any other developer help or collaboration.
I recommend that you buy this book, read it with an open mind, and see if it will help you get over the hump.
The 5 Second Rule
by Mel Robbins
This book describes a very simple concept, but not an easy one.
You know that defining moment when you are in a meeting, an idea pops into mind, but before you share it you talk yourself out of it? Or that moment that you see someone you know (or want to know), but talk yourself out of saying, “hi”? Or that moment when the alarm clock goes off in the morning, you know you need to get up, but you don’t feel like it and hit the snooze button?
This book will tell you all about that moment. The book is not really about the rule itself. Don’t read it to learn the rule! I’ll save you the money; here it is: “The moment you have an instinct to act on a goal, you must physically move within 5 seconds, or your brain will stop you. 5-4-3-2-1-Go! There, you have it.
The book is more about understanding that moment your brain talks you out of acting to meet your goals. It is a meditation around the topic, that is explored from many different angles.
Usually, audio versions of books read by the author are a hit and miss. This one is excellent, and I recommend the Audio version as the author is an excellent public speaker and it sounds like she is talking to you, and not just reading a book.
Steve Jobs
It took me a few weeks to read it – the thing is 656 pages long – I liked it so much that I am sure I will re-read it again.
The book is an inspiring jump into the fascinating mind and life of a genius who, in some ways, reminds me of a version of Leonardo da Vinci with a gift not only for art, design, and engineering but also business and a deep understanding of what people want. He was able to see what people needed before they knew it and codify his vision in works of pure design art.
I recommend this book for software engineers because it gives a view on the fine art of designing products and understanding customers. It shows how business minds and salespeople are part of the success of a product, and how deeply human geniuses like Steve Jobs were.
Quiet: The Power of Introverts in a World That Can't Stop Talking
by Susan Cain
Not all developers are introverts. In fact, there are surveys indicating that most developers consider themselves as moderately extroverted. Regardless if you consider yourself an extrovert or an introvert, this book will help you understand introverts and how they think and operate.
This book opened my mind to a new understanding of the profound and fascinating differences between introverts and extroverts, the continuum between these two extremes and the great variety in it.
It "talked to me" because it explains why in many engineering organizations that are also customer-focused, groups of different people (especially the “client facing and “product facing groups) are often on a very different page and work very differently. Also, it explains why this diversity is beneficial if you understand the differences at a deeper level.
If you are a parent, this book will help understand your kids a bit better; at least I know it helped me since I am the father of two very different types of introverts and one extrovert. There is so much research in that area and so little that I knew about.
The Practicing Mind: Developing Focus and Discipline in Your Life – Master Any Skill or Challenge by Learning to Love the Process
Software development requires constant learning of new technologies, languages, frameworks, schools of thought, processes, skills. It simply never ends, and it will never will.
How much time have you spent on learning how to learn? Well, this book describes the learning process through practice. It shows how focusing on the learning process, and not the goal, improves the learning experience and reduces the learner’s stress, improving the outcome.
This book is a must-read for all software engineers.
Algorithms to Live By: The Computer Science of Human Decisions
by Brian Christian, Tom Griffiths
If you never studied computer science, have you ever wondered what computer science is actually all about? How do engineers think? Why are they generally good problem solvers? Why is computer science slowly becoming part of basic education?
If you did study computer science, you probably spent a lot of time thinking about how to apply algorithms to everyday life and you probably never got tired of it. It is fun and very useful.
Either way, this book is a non-technical journey into the wisdom given to us by the research of computer scientists on how to resolve problems.
Simple Rules: How to Thrive in a Complex World
by Donald Sull, Kathleen M. Eisenhardt
This book changed my way of thinking. After reading it, I find myself searching for ways to distill behavior, processes, and concepts into simple rules. It is a powerful concept that will resonate well with engineering types.
The book is not a cover-to-cover-super-exciting read, and there are some unnecessary parts. However, I like the basic idea and the philosophy behind it, and I believe it can benefit all software engineers at all stages of their career.
Zero to One: Notes on Startups, or How to Build the Future
The author, Peter Thiel, was one of the founders of PayPal and is also one of the founders of “Fund”, a Silicon Valley venture capital firm that started companies like SpaceX and Airbnb.
If stated in a single short sentence without adding context, his view is perhaps pretty radical: “You want to get as close as possible to creating a monopoly and competition is bad for business.
The reasoning behind his position is fascinating and have to do with the fact that super successful companies are so much better than the competition than they do not worry excessively about competition. They spend very little time competing, and most of their time innovating, marketing and selling. The book goes into details on how that is accomplished, the fallacy of some of the beliefs that were at the root of the internet bubble, and many other interesting topics.
One part that I found particularly interesting is the role of sales in start-ups. The old bubble-era thinking, “if you build it, they will come doesn’t work very well. The book describes how fundamentally important the role of distribution is, and how business geniuses like Steve Jobs mastered not only the art of envisioning products that are 10x better than anything else on the market, but also the art of creating great distribution channels. All of this might be “old news for many of you, but the way it is put, and the thoughts organized, was very enlightening to me.
Make It Stick: The Science of Successful Learning
by Peter C. Brown, Henry L. Roediger III, Mark A. McDaniel
This book contains fascinating research results on how we learn and how to improve the efficacy of learning. It goes into details about the advantage of interleaved learning, varied learning, and spaced learning. It is enlightening on the reason why "mass practice" doesn't work well for long-term learning, why testing yourself is important and why easy is not better when it comes to learning.
It gave me a good perspective on why blended learning is so important, why "parallel tracks of learning" strategies are powerful, why studying for the standardized tests is not a good way to study and why drill and kill is not a good long-term learning strategy.
It is also a good read if you consider yourself a lifelong student and if you consider the process of learning and retaining new material a fascinating subject.
The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution
The book goes through the history of the individuals and teamwork behind the invention of computers and the internet, from A to Z. It is a bit technical at times, going into some very fascinating details of the subjects it comes across, but never too technical to be readable by non-engineers.
What I like the most is that it brings the reader the struggles and personalities of the people that created and ultimately manifested the technological reality that we take for granted today. It shows how innovation is the result of a mix of intuition, personalities, skills and personal drive. It describes the human factors and the teamwork that was required to bring these intuitions to fruition. It explains how one person often drives innovation, but always needs more than one person to become a reality. It also shows how innovation exists in the fabric created by the threads formed by existing innovations and is often discovered by multiple groups of people independently and at the same time.
Individual innovators envision, plan and deliver. Alone they are often visionary geniuses; however, it takes teams of people to envision and plan and deliver significant innovations to the world. When they do, others start weaving new fabrics, and the process repeats.
The Tipping Point: How Little Things Can Make a Big Difference
This book is a great read with a fascinating section on the type of testing that was done to evaluate stickiness of programs such as "Sesame Street" and "Blue’s Clues with preschoolers. The insights of that research are quite interesting and can give software developers an idea of the process that goes into the creation of a product roadmap.
Latest comments (31)
Any list of books that "software engineers must read" which doesn't include Snow Crash is suspect.
Great list. This is practically a Wish List / Gift List. Thanks!
I highly recommend the inclusion of Dreaming in Code by Scott Rosenberg. It's a very insightful (and sometimes funny) look into how software projects play out in the real world, and why things go wrong.
A book that built on ideas that Tipping Point introduced is Made to Stick from Chip & Dan Heath. I'm only about 20% through, but you might enjoy it.
Another one is Crossing the Chasm. It provides more marketing and sales learning but does it with modern high tech context like Salesforce.com's success.
Great list!
Thank you, Alyss!! I actually read both. You are right, those are some great books!!
I really like how you explain why you think the books are relevant. Thanks for writing!
Thank you for adding more books to my reading list!
Would add that "Algorithms to Live By: The Computer Science of Human Decisions" is also brilliant as an audiobook on Audible.
No Clean Code: A Handbook of Agile Software Craftsmanship ? really?
This seems like a pretty random list of books. Certainly not mandatory reading. Nothing against the books on the list, I haven't read most of them after all. But then I have read other books (not on the list), plenty of articles, and generally survived in this industry for two decades.
One thing that sticks out after two decades is the value of working with people who have different experience than me and maybe have read different books and think about problems in a different way. Confirmation bias is not what you are looking for in a team: you want diversity.
The list might seem random but is far from it. The fact that you want a different wealth of experiences and the fact that those books are not traditional "development" book is the reason why I put together this list. Reading that material won't make an engineer a better coder, but it will help making an engineer a stronger asset to teams and companies.
Thanks for sharing, good books
Steve Jobs? Really?
If I may add a suggestion that seems inline with many on this list, "Thinking, Fast and Slow" by Daniel Kahneman is a deep dive into how we think and make decisions. Highly recommended.
I agree. That is a good book.
Thanks for sharing!
My pleasure!
awesome list of books, Lorenzo
My pleasure!
Oh dear ... Steve Jobs, please not again ... sorry, but this dude was just a hype wave and then dissolved. A software engineer needs to learn other stuff.
And scrum is overrated. Too much. Not practicable in most companies.
Unless i'm mistaken, he was recommending the book. He wasnt suggesting you idolize the person.
There's a lot to be learned about the man (good and bad), and the companies/software/teams he built.
(And i have never actually read the book, i'm just looking at this with an open mind.)