3 Essential Books for your Career as a Software Engineer
Over the course of my career I have read several books which have taught me lessons that I make use of every day. There is so much to learn from great books and it is an excellent way to guide your career by learning from others. As a software engineer you will continually have to learn and repeatedly re-learn how to break down problems and work out solutions as you work with new languages, platforms and teams.
The books below are the 3 which I now find to be essential.
One of the first books I read at the start of my career was this book which largely focuses on Seymour Cray who created supercomputers in the 1970’s. Every time a new model was created it was entirely new hardware, leveraging the latest state of the art available which also required entirely new software to run the new supercomputer. These machines were used by governments, universities and large businesses to do all kinds of processing. There are so many interesting stories and lessons in this book.
One quality which stood out is how Seymour would always assemble his boards himself and do all of the binary math while many others would have interns or junior engineers do this work. The advantage of always doing this work himself is that he developed instincts of what the hardware could do and also became very fluent with binary math for handling work run on the circuits that it became second hand. One time a team of engineers had been working out a problem with one of the new models for a few weeks and were struggling to solve it. Seymour walked past and saw they were at the chalk board and they explained the problem. He thought about it for a moment and drew up his guidance on the board and they found it immediately solved their problem. The lesson I’ve taken from this story is that always doing the hands-on work can take up a lot of time but it can allow you to solve very difficult problems in less time.
Seymour also would not use the most cutting edge hardware immediately. He would learn how others who were the early adopters struggled to use new technology. This was work that required a lot of time and experimentation. Seymour would study their work and read about what others had done in the industry and after a while he would jump in and start adopting the new hardware. This way he had the benefit of all the work which had been done for him. In the same way we can see how new software or platform features are being used and learn so much from it. Sometimes we will need to work on the cutting edge, but not always. Leverage the fact that we can learn from those who have come before us.
While I worked at a consulting company every employee was given a copy of this book. One of the main concepts from the book is the group IQ. It is the idea that if you have a meeting with 5 people and only 2 people are contributing to the the discussion it is limiting the IQ of the group. Instead techniques should be used to bring others into the conversation which increases the group IQ. Often meetings can be dominated by just a couple of people because others do not feel comfortable to share their thoughts or even to contradict others.
One story in the book was about a company which had grown from a small number of people to the point they needed a new office which would fit everyone. A few locations were scouted and they were having an all-hands meeting and the owner of the company was laying out the criteria and the locations. One of the key criteria was to keep the commutes of most employees as short as possible since the 3 potential locations were a good distance apart.
The owner of the company was clearly ready to select the location which was the most convenient for him even though it would be much more inconvenient for most of the employees. Nobody felt comfortable about speaking up, because he was the boss. Finally, one of the new employees spoke up and artfully used a technique to contradict the owner of the company without making it confrontational. He asked to go over the criteria again which included the average commuting distance and noted the one the owner was leaning toward was far less convenient than the other 2. And without any push back the owner acknowledged the point and stated that location was off the list.
This book covers several useful techniques to use in conversations, both for work and in personal situations. It also stressed how it is best to be aware of how people are contributing or not contributing to a conversation and how to pause a conversation and prompt others to join in. Applying these techniques will not only raise the group IQ but also ensure that the team feels they are influencing decisions and the direction of the team.
This book was written by Ken Kocienda who worked at Apple during early development of the Safari web browser, iPhone and iPad. One major lesson from the book is the value of the demo. Often we give a demo to our teams near the end of a project after most of the work is complete and all the decisions had been made. Typically it is done to solicit praise and help prepare for a promotion. What Ken explains in the book is that the demo should be part of guiding a product right from the start. Early prototypes can be mocked up, even using animation software which mimics the real behavior, just to allow people to see the vision for the end product and offer their thoughts.
During this process collaboration is key. Discussions with designers and other developers will influence the direction and help with overcoming blockers. There are definitely times when we can go down the rabbit hole which can lose so much time. The book covers how Ken hit blockers and how collaborating with others helped get past them.
There are several useful tips in the book. For one project Ken was having difficulty making progress and met with two developers who he was told might help. After he went over all of the work that had been done and all of the edge cases which still allowed unwanted side effects they advised him that he should collect all of the code which handles the edge cases in one place. Ken’s take away was, “When software behavior is mysterious, get more organized.” This may be obvious in hindsight, but also very powerful lesson. We are often in a rush to get our code working and try a small change here and there which adds up to a complex mess hoping that every small change will make it all work more quickly, only to introduce more edge cases. The way the code misbehaves can often not make any sense and so it should be organized so that it does make sense. And better yet, the code should work well with automated testing. Then unit tests can be created which help to ensure that all of the behavior is what was intended so there is no more mystery.
I’ll keep this lesson in mind for a long time.
What books do you recommend?
