DEV Community

Cover image for 4 Books Guaranteed to Make You a Better Programmer
Blaine Osepchuk
Blaine Osepchuk

Posted on • Updated on • Originally published at

4 Books Guaranteed to Make You a Better Programmer

Figuring out what to work on next is one of the hardest problems in software engineering.

I know that's a bold statement but I believe there's ample evidence to support my claim. In a recent post, I talked about the value of always working on the most important thing. In it I wrote:

It's difficult to identify the most important thing [to work on next] because the solution space is huge and it's difficult to compare stories. But I've found the Theory of Constraints to be a helpful way to quickly zero in on high value areas without looking at the whole business in excruciating detail.

The problem is that learning the Theory of Constraints from a textbook is hard. So, over the years, several experts have written novels about people learning about and applying the Theory of Constraints to make it easier for you pick up the basics (the novels are entertaining too).

1. The Goal: A Process of Ongoing Improvement

By Eliyahu M. Goldratt and Jeff Cox

This is the book that started it all. It's the 1980's and Alex runs a factory that is headed for bankruptcy unless he can turn it around. Orders are late, inventories are too high, and his competitors are stealing his customers. But Alex finds a mentor who teaches him the Theory of Constraints. And that opens his eyes to how his factory really works. Alex shares what he is learning with his senior people and with a lot of hard work they figure it out and save their company.

Of the four, I read this book first. And it gave me a really good appreciation for the complexities of optimizing systems and how badly you can mess things up with good intentions. It's also easier to get the concepts when you are dealing with physical things in a factory. You can literally see work-in-progress piled up in front of the constraint in a factory, which is not true when your product is software.

2. It's Not Luck

By Eliyahu M. Goldratt

This is the sequel to The Goal. Alex has been promoted and is now in charge of a division of three companies. Profits need to improve or the board will sell Alex's companies. Alex learns more about the Theory of Constraints and how to apply it to other kinds of problems, not just manufacturing problems. He uses his new skills to save the day one more time.

Of the four, I recommend you read this book last, if at all. It introduces the "Thinking Processes", which are Goldratt's tools for logical analysis. I've tried them and they are truly powerful but learning them is a big investment. And my guess is that less than one percent of you will want to take your learning to that level. Here's a brief description of the "Thinking Processes". And if you really want to learn them I recommend Goldratt’s Theory of Constraints (by H. William Dettmer).

3. Velocity: Combining Lean, Six Sigma and the Theory of Constraints to Achieve Breakthrough Performance

By Dee Jacob,‎ Suzan Bergland,‎ and Jeff Cox

Amy is made interim president of a failing company, despite being unqualified for the position. She attempts to implement a Lean-Six Sigma hybrid improvement program that was thrust upon her by her parent company. The program throws the company into chaos and makes things worse. It's only when Amy truly comes to understand how her company works and learns about the Theory of Constraints, that she's able to make intelligent decisions and save her company.

Velocity contains a subplot about improving the performance of a research division, which will be of great interest to any software developer. After reading this book you'll also gain an understanding of the strengths and weaknesses of Lean, Six Sigma, and the Theory of Constraints. These systems are popular in the business world so it won't hurt you to know something about them.

4. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

By Gene Kim, Kevin Behr, and George Spafford

Bill is a mid-level IT manager for an auto parts manufacturer. One morning he gets called into the CEO's office and learns that his boss and his boss's boss have been fired and he is now in charge of IT. The future of the company hinges on the successful launch of a new IT project named Phoenix, which is already millions of dollars over budget and more than a year late.

The project must launch successfully and at a predetermined date or the entire IT department will be outsourced. Bill quickly learns that IT is an absolute mess. The company is drowning in its own chaos but Bill starts learning about the Theory of Constraints and DevOps and he slowly starts to make progress. And through a lot of hard work, Bill and his allies manage to save the company.

I enjoyed this book the most. In fact, I couldn't put it down.

How these novels are going to help you become a better programmer

What we're really talking about here is systems thinking. And that's a hard topic for most people to get their head around. I read several textbooks on the subject and I can tell you without hesitation that you are better off reading one of these novels first.

Each of these books follows the same pattern. The protagonist is promoted into a bad situation where they quickly learn they don't have the skills they need to succeed. They are overwhelmed by chaos and problems and can't figure out what they can do to turn things around with the resources available to them. Eventually each protagonist finds a mentor to coach them. They learn about systems thinking and the Theory of Constraints from their mentor. Then they apply what they learned to focus their improvement efforts on their constraint to maximize their impact.

Programmers often find themselves in similar situations. We are frequently under-resourced, drowning in tasks, and up against a deadline. If you learn enough systems thinking and Theory of Constraints, you can start to see the patterns and use them to find your constraint. Once you've identified your constraint it becomes easier to ignore the other stuff (because working on it is a waste of time). Instead, you focus on your constraint and making the largest possible contribution to the results of your company.

Recommendations for reading

You don't need to read all four novels to become a better programmer. These suggestions might save you some time:

  • start with The Phoenix Project. It's the newest book, it will be the easiest book for most programmers to relate to, and it has a great resources section at the end of the new edition
  • read Velocity next if you still want to learn more
  • read The Goal if you work in manufacturing or you really want to read about the Theory of Constraints from the guy who invented it
  • feel free to skip all the subplots about family drama (except those with Amy's boyfriend because he is also her mentor)--these subplots don't add much to the story
  • if you do choose to read more than one book, don't read them back-to-back. Try to space them out so you have a chance to apply what you learned from the first book before you dive into the next


These books are entertaining and educational. And I guarantee reading any one of them will change how you approach your work as a programmer. Once you understand the Theory of Constraints and what it means for your work, you'll never see your backlog the same way again. I promise.

Have you read any of these books or think that you might? I'd love to hear your thoughts in the comments section.

Enjoy this post? Please "like" it below.

Top comments (8)

tinmanjk profile image
Ivan Petrov • Edited

I think you've forgotten the first and especially the second rule of Theory of Constraints Club :)

It's a remarkably effective approach to problem solving. In fact it might be the only approach that delivers actual results as opposed to "local optima".

What I want to touch upon is my experience with trying to apply the mindset - looking for the bottleneck is not as easy as doing what you would like to do. You have to fully open your eyes, fighting the cognitive dissonance within you (and possibly your team) and pinpoint that "problem area". And most of the time it is a "problem area" for a reason, i.e. it requires more thinking and/or more grunt work to be overcome. Well, this means more investment of energy on your part. But it is the right thing to do, so you do it and elevate the constraint. Then comes the next bottleneck, followed by the next one and the next one. Although you can celebrate the victories along the ways, it can lead to the feeling of treading water because although actual progress is being achieved, our attention is constantly seeking "problems". Or in other words, we are continuously testing our problem solving abilities aimed at the most difficult problems all the time. If not in the right mental or work environment this could cause a lot of unmanaged anxiety and can lead to all forms of burn out.

Have others had similar experience or found a way to employ effectively the approach in a team setting?

bosepchuk profile image
Blaine Osepchuk • Edited

Thanks for your comments, Ivan. You bring up some good questions.

Yes, always working on the constraint can be exhausting.

Thoughts on burnout:

  • knowing where the constraint is makes it easier to say no to a whole array of low-value activities. I don't feel so stressed about all the things on my to-do list because I know where to put my energy
  • you have to know your limits. Just because you know where the constraint is doesn't mean you can directly effect it. It could exist outside your organization, it could be a law or regulation, or it could be a person who just isn't interested in hearing from you. You can only control what you do. And you might have to face the reality that you are not in a position to elevate the constraint (right now).
  • you're right about that "problem area" being a problem area for a reason. If the constraint was simple to identify and elevate, someone would have fixed it already. You'll likely find all kinds of tangled issues that are way above your pay grade if you dig deep enough.
  • if the true constraint is beyond your influence, work on the next biggest constraint that you can influence. Yes, it's not a global maximum but it's still miles ahead of the average prioritization system most people use. You should still be able to make an outstanding contribution even if you can't change the constraint that much. And always express your willingness to work on the constraint if something changes and you find yourself in a position to do something about it or team up with someone else to tackle it.
  • don't work all the time and try not to think about work excessively when you're not on the clock.
  • remember that it's just a job. You can't control everything and you're not responsible for the entire company. I paid like $30 for my copy of "Goldratt's Theory of Constraints" and I got the rest of the information from the library and online. The information is widely available so your bosses and/or the owners of your company need to take a huge amount of responsibility for how the business is run. If you've told whoever you can about the constraint and they aren't interested, that's their business.
  • there's no getting around stupid meetings and email and other low-value activities. Just accept it. I work on the constraint when I can and I take comfort in knowing that I deliver value to the company that is many multiples of my salary.
  • final thought: there will always be a constraint by definition. So, there is no end to this process. Therefore, you must set a sustainable pace. In fact, that's the optimum strategy unless your company is in a life or death crisis.

Thoughts on applying the approach in a team setting:

  • this way of thinking isn't for everyone. Some people avoid structured/logical analysis. Others don't have the necessary business or domain knowledge to apply the concepts, even if they knew them. So, don't try to make everyone work this way.
  • introduce the idea informally and see if anyone is interested in learning more. Let people pull the ideas out of you (don't push them on people).
  • try to get an ally on your team. Talk through your business opportunities together. If you get to the thinking processes, make the diagrams together or review each other's diagrams.
  • many people don't care to understand how you figured out where the constraint is and what you should do about it. They just want to have clear direction and do work that's meaningful to them. So if you pitch a project to elevate the constraint, you might only have to explain that it's a really valuable project to get people on board.
  • the only person who truly needs to understand what's going on is the person who sets the work assignments/priorities. Everyone else can catch up over time and to the level they desire.


tinmanjk profile image
Ivan Petrov

Thanks for the insights, Blaine. They are most appreciated.

A mistake I have been making in the past is to take for granted that my colleagues are on the same page (theory of constraints thinking) when working on the same project. However, this has mostly not been the case.

As I cannot unsee and ununderstand the points of the paradigm, I guess I have to work on my soft skills more trying to get people to acknowledge the benefits of the approach while not being too pushy or impatient.

Another facet of the problem is how to present constraints to those above your pay grade without putting them in too tough a spot and avoiding their resentment. Most people, and especially these at higher levels in an organization, would not appreciate a lower level colleague presenting them with difficult problems only they can handle. How would you do that?

Thread Thread
bosepchuk profile image
Blaine Osepchuk

You're welcome.

I wrote a whole series of posts on this topic. You might want to check them out.

Where to look for the constraint in your company and Build your influence in six steps answer some of your questions directly.

Reply here if you still have questions.


aliadolfo profile image

Thanks so much my friend , it's wonderful this rich content.

bosepchuk profile image
Blaine Osepchuk

Thanks so much. I appreciate your feedback.

iglesk profile image
Omar AlSabek

Thank you so much for the amazing list, I just finished "The Pheonix Project" Novel
I really enjoyed it so much, reading your post motivated me to read more about the other novels.

bosepchuk profile image
Blaine Osepchuk

You're very welcome. Enjoy the books!