11 Books All Software Engineers Must Read
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.
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, Jacko, 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.
This book 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.
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.
by Mel Robbins
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.
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.
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
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.
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.
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.
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.
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 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.
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.
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.