Here is my latest post for Simple Programmer…
There are many lists of books about becoming a better programmer. They likely include books like Refactoring, Code Complete, The Mythical Man Month, etc.
However, in the workplace, it isn’t just programming knowledge that we programmers need. Learning programming is an essential part of our work — but it’s not everything.
The authors of iconic programming books had remarkable careers, but it wasn’t just their coding knowledge that made their careers noteworthy. They were well-rounded experts and we should strive to emulate that quality as well.
The difficulty with non-programming books that are important for programmers is that they fall into that nebulous category of “we don’t know what we don’t know.” These books won’t figuratively have our names written on them.
Instead, we have to seek them out. Often, we find these books through recommendations of trusted friends. The following books are some of my favourite non-programming books that have made a big impact in how I approach my work.
How — precisely — have they made an impact? Well, all of these books are about taking a higher-level perspective on yourself and your work. They won’t tell you how to solve a specific problem; instead they’ll give you the tools you need so that you’re prepared when you see the problem emerge. Winston Churchill said it best:
To each there comes in their lifetime a special moment when they are figuratively tapped on the shoulder and offered the chance to do a very special thing, unique to them and fitted to their talents. What a tragedy if that moment finds them unprepared or unqualified for that which could have been their finest hour.
We want to prepare ourselves for these situations, so let’s take a look at eight non-programming books you should read to boost your programming career.
Note — I wouldn’t recommend a product I do not own nor use. I own all of these books and they are covered with my own notes. If you choose to buy one, I suggest you do the same. These are not books to be read once and tossed aside.
I wasn’t kidding.
DevOps is a movement, a culture change, a mindset. It is not tooling.
The DevOps Handbook is a nonfiction companion to The Phoenix Project. The Phoenix Project is a novel about how an IT organization falls apart and then is put back together with DevOps practices.
Personally, I found the novel format of The Phoenix Project dense and obtuse whereas the DevOps Handbook is far more practical and usable. The DevOps Handbook talks you through the important notion of a value stream, which is essentially the full flow of how work comes in and out of a business. Think of it like the production line of a technology business.
As a programmer, we’re at the heart of this value stream — so we’re often made responsible for the outcomes, which is usually, but not always, a product.
Ownership of the value stream shouldn’t be a programmer’s job. But that’s a whole blog post in itself. Irrespective of who should rightly own the value stream, programmers are often left in the tricky position of being held responsible for it. So we need to understand not only what the value stream is, but also how to optimise it.
The DevOps Handbook gives you many different ways you can optimise this value stream, including things like “value stream mapping” (making the value stream visible) and optimizing our deployment processes.
Scrum is a very widely adopted framework in the software world and this book is a great intro to the Scrum framework.
Most other Scrum books dive straight into the mechanics of working in a Scrum format. This book, on the other hand, takes the time to explain the origins and the meaning behind the framework.
The purpose of Scrum is far more important than understanding the precise roles, artifacts, etc.
Why? Because knowing the rules is different than embodying them. Unfortunately, many programmers do still dive straight into the Scrum framework without understanding the origins and the purpose.
This leads to confusion as practitioners start barking orders for a 15-minute meeting every morning without really knowing why we need Scrum in the first place. This notion I’ve explained in greater detail in this article.
Read the book, understand the purpose, and be a better practitioner.
My favourite quote, and one that could possibly sum up the The Fifth Discipline, is this:
Different people in the same systems produce similar results.
I’ve watched this quote come to life many times before, and after reading The Fifth Discipline. For instance: When a company lets a developer go, and then hires a new developer into the same team and the same business, interestingly the same results appear again.
At this point you might be wondering why team structure is important to you as a programmer.
Because if not, we can fall into the trap of seeing ourselves as only our little role in a much bigger machine that we believe is out of our control. If we fail to see, and address, the bigger picture (the system), the results and impact we have are limited. We could be that new hire, brought into a new team and doomed to failure — no matter how good we are.
The solution? To understand and be able to communicate the difficulties presented in complex systems and how to solve them. Cultivate a system mindset that goes beyond complaining about the other teams “not doing their job,” and instead think about how the way we have set up our organization is affecting us more than we realise.
4 — 48 Laws Of Power
Every organisation has politics. It’s an irrefutable fact.
When it comes to politics, you have two choices: You can take the blue pill and pretend power plays do not exist. Or, alternatively, you can take the red pill and dive into the world of power, to understand it.
Interestingly, the author Robert Greene even argues that the denial of power plays is in itself a power play. I’ll leave you to ponder this statement.
The 48 Laws of Power presents 48 different ways that people use and wield power. Greene takes you through each one in detail with in-depth stories from history that demonstrate the power play. To top off each chapter, Greene closes with a reversal, an argument in opposition to each power play.
Admittedly, on my first read, I didn’t really “get it.” However, when I came back to it (after working for a company for a few years), a lot of the ideas started to click. I could relate to the different power plays and how I’d seen them act out in the workplace. So don’t quit on the book before giving it a real go. Once it clicks, you’ll understand what I mean. The 48 Laws of Power is not a newspaper, nor is it a Buzzfeed article — it’s not meant to be an easy read, but it will be worth it.
Nassim Nicholas Taleb once said “Never read a book you would not reread.” The 48 Laws of Power falls in this category. It simply cannot be read only once. And for that reason, I’d recommend getting a hard copy and keeping it for life. As each time you re-read it, you’ll relate different areas to your new experiences.
I believe the best programmers are also teachers.
These programmers have an abundance mindset, rather than a scarcity mindset. Knowing that sharing knowledge and helping others will in fact help them in return rather than act against them.
The Coaching Habit is a very straightforward and practical introduction to ideas of coaching. It takes you through seven individual questions that you can ask another programmer as part of a coaching session, or in more general conversation.
These are questions like: “What’s on your mind?” and “What’s the real problem here for you?” Don’t be fooled into thinking these are just a few questions thrown together haphazardly. Each question is carefully crafted to ensure that you can have the biggest impact on others.
It’s seriously like having Jedi mind powers.
The Coaching Habit is recommended reading for anyone who works with people (read: everyone). And if you’re still not convinced, I’ve previously translated the coaching questions to show how they’re useful for a programmer, specifically.
6 — Sprint: A Radically New Way to Test Ideas, Solve Problems and Answer Your Most Pressing Questions
Sprint takes you through a five-day set of exercises, starting with brainstorming ideas/features and prioritizing one of them; then, you’ll elicit the main ideas, sketch it, design it, prototype it, and test it.
It’s a very practical and full framework.
Often all we need is some basic structure when it comes to our “ways of working,” as it prevents us arguing and debating in endless circles. Instead, you can propose to your team: Shall we run a design sprint? And then take the team through this method step by step.
Whether you run these types of workshops in their entirety or not, this book can serve as great inspiration for how to align stakeholders and get to a functioning product.
7 — The Lean Startup
If you’re not familiar with the ideas of The Lean Startup and you’ve already started writing code, you might have already made a terrible mistake in doing so.
The Lean Startup has now become somewhat of a classic in software and products. It advocates that all ideas are just opinions until proven otherwise, which means that we need to test our ideas aggressively before we pursue them to ensure that we’re not being clouded by faulty judgement, or leading with ego.
If you think you’ve got decent proof that your product or feature will be a success, think again. Author Eric Ries will challenge you to think of faster and cheaper ways to get validation on your product before you start building it.
Why is validation important? Because building products can be incredibly expensive. Not only that, but once built, code is notoriously difficult to change. So building the right product and features is essential from the beginning. There are so many ways we can validate ideas without writing any code at all, such a: paper prototypes, splash pages and guerilla/hallway user testing.
You might be thinking about now: Does the idea of constant validation mean that companies will need fewer programmers?
Not at all.
In fact, it means that programmers’ time will be spent more effectively on activities like being creative and thinking of ways to build prototypes, demos, and splash pages. It also means that when it comes time to build, there’s less chance that the business will come back to the programmers every five minutes for re-work, or worse, to blame programmers for a failed product.
All new products and features are simply opinion until proven a success. Before you, or anyone who works with you, start writing any code, read this book.
The other books I’ve presented have been more about the organizations that we work for, rather than about our own self and our career.
Key Person Of Influence takes you through five steps that influential people have taken (knowingly or unknowingly) to rise to the top of their industry.
Being at the top of an industry means getting better opportunities with less (or no) struggle and being rewarded appropriately. No more fighting with your employer for a raise or debating with your boss to showcase your value. With author Daniel Priestley’s five steps, your value will become crystal clear to you, and then Priestley takes you through how you can then showcase this value to others.
Priestley argues that you are already “standing on a mountain of value.” All of your experiences, stories, ideas, and information to date is worth more than you realize. But, you just can’t see the mountain. Why? Because you’re standing on it!
I cannot overstate the impact this book has had on my career thus far. And I believe it’s only the beginning. After reading the book, I realized that I wasn’t taking the most effective steps to build my own career. As soon as I finished it, I put it down and created a plan that will span my entire career. I now consider this book to be the backbone of that plan. All other books seem to slot in to the plan I have created around the five steps that Priestley outlines.
Just like with the laws of power, you can choose to ignore the ideas presented in the book. But, the five steps of the book line up with the career history of any person of influence in any industry.
Ignore this book at your own peril.
Your Finest Hour
There you have it, the best books I’ve read so far that aren’t directly related to writing code.
Be wary not to fall in the trap thinking that more coding knowledge is what you need. It is very likely that one of these books presents the breakthrough you didn’t even know you needed.
Whether that is fighting a political battle with the 48 Laws of Power or realizing that your organization has a systemic issue and starting to tackle it with the Fifth Discipline and The DevOps Handbook. Or putting in place a grand strategy for your career with Key Person of Influence.
Ignoring books, especially these books, might buy you a little time in the short term but can prove to be devastatingly costly in the long run if you’re not careful.
If you read these books, when your figurative tap on the shoulder comes, you will be ready.