This philosophy-of-programming guide presents a unique and entertaining take on how to think about programming. A collection of 21 pragmatic rules, each presented in a stand-alone chapter, captures the essential wisdom that every freshly minted programmer needs to know and provides thought-provoking insights for more seasoned programmers.

Author Chris Zimmerman, cofounder of the video game studio Sucker Punch Productions, teaches basic truths of programming by wrapping them in memorable aphorisms and driving them home with examples drawn from real code. This practical guide also helps managers looking for ways to train new team members.

The rules in this book include:

• As simple as possible, but no simpler
• Let your code tell its own story
• Localize complexity
• Generalization takes three examples
• Work backward from your result, not forward from your code
• The first lesson of optimization is don't optimize
• A good name is the best documentation
• Bugs are contagious
• Eliminate failure cases
• Code that isn't running doesn't work
• Sometimes you just need to hammer the nails

Table of Contents

Rule 1: As Simple as Possible, but No Simpler

Rule 2: Bugs Are Contagious

Rule 3: A Good Name Is the Best Documentation

Rule 4: Generalization Takes Three Examples

Rule 5: The First Lesson of Optimization Is Don't Optimize

Interlude: In Which the Previous Chapter Is Criticized

Rule 6: Code Reviews Are Good for Three Reasons

Rule 7: Eliminate Failure Cases

Rule 8: Code That Isn't Running Doesn't Work

Rule 9: Write Collapsible Code

Rule 10: Localize Complexity

Rule 11: Is It Twice as Good?

Rule 12: Big Teams Need Strong Conventions

Rule 13: Find the Pebble That Started the Avalanche

Rule 14: Code Comes in Four Flavors

Rule 1 5: Pull the Weeds

Rule 16: Work Backward from Your Result, Not Forward from Your Code

Rule 17: Sometimes the Bigger Problem Is Easier to Solve

Rule 18: Let Your Code Tell Its Own Story

Rule 19: Rework in Parallel

Rule 20: Do the Math

Rule 21: Sometimes You Just Need to Hammer the Nails

Welcome to The Rules of Programming, a set of easy-to-remember and easy-to-apply Rules that will help you write better code. Programming is hard, but following the Rules makes it a little bit easier.

Here are some tips on reading the book:

• All of the Rules stand on their own. If you see an interesting-looking Rule in the table of contents and want to jump straight into the middle of the book, feel free. That reading pattern is fully supported.
• That said, I’d suggest starting off with Rule 1, “As Simple as Possible, but No Simpler”. It’s a good setup for the rest of the Rules.
• The examples in the book are all written in C++. If you’re a Python or JavaScript programmer, you’ll be happier if you read Appendix A, “Reading C++ for Python Programmers”, or Appendix B, “Reading C++ for JavaScript Programmers”, before getting too far into the Rules. The two appendices act as Rosetta Stones to translate that C++ into the concepts you’re used to. If your experience is with some other language and you find the C++ examples hard to follow, then I suggest the phenomenal website Rosetta Code.
• If you’re a C++ programmer, note that I’ve simplified a few things in the code examples to make them easier to read for non-C++ programmers. For example, the examples use signed integers in a few places where unsigned integers would be more typical for a C++ program, and I disabled warnings about implicit conversion between signed and unsigned values. I also compiled the examples with an implicit “using std” to avoid a boatload of distracting “std::” references.
• And finally, I’m capitalizing Rule when I refer to an actual Rule in the book. If you see rule, it’s just a regular old rule, not an officially sanctioned one. The distinction between the two senses of the word was confusing without the capitalization; I hope that excuses me.

I hope you enjoy what follows! I think you’ll discover a few useful thoughts that help you sharpen your programming skills.

The Story of the Rules

The Rules of Programming were born of exasperation.

I’d spent about a decade running programming teams at Microsoft, then cofounded the video game company Sucker Punch in 1997. Both companies have been successful—in large part because of their ability to recruit and develop top-notch programming teams. At Sucker Punch, that’s led to a 25-year run of successful games. There were the three Sly Cooper games, which let kids of all ages experience the thrilling life of the master raccoon thief Sly Cooper and his pals. There were the five inFamous games, which gave gamers superpowers and the choice to use them for good or evil. And then there’s what is to this point our magnum opus, Ghost of Tsushima, where gamers play a lone samurai fighting back against the 1274 invasion of Japan.

A big part of the recruiting strategy at both Microsoft and Sucker Punch has been hiring smart young programmers, then training them in the ways of professional developers. This practice has been undeniably successful, but it also leads to a particular flavor of frustration.

I kept running into one problem over and over again. We’d bring a new programmer onto the team, often someone fresh out of college. I’d review some new feature they planned to introduce into the code, usually to solve a very simple problem—only to discover that they’d written code that attempted to solve a much bigger problem, one that included the very simple and concrete problem as a small subcase.

Aargh! We didn’t need that bigger problem solved, certainly not right now! Invariably, the solution to the bigger problem was a mediocre solution to the simple problem we did have—more complicated to use, more complicated to understand, and capable of hiding a lot more bugs. But just saying that in the code review—that we didn’t need the bigger problem solved, that they should only try to solve problems they understand—was ineffective. They kept doing it.

Out of frustration, I put my foot down. “OK,” I said. “Here’s the new rule. Until you have three examples of a problem, you’re not allowed to write a general solution.”

To my surprise and delight, this actually worked! Turning the general philosophy into a specific rule with specific criteria was an effective way of getting the message across. Sure, most of our new programmers made the premature generalization mistake once, but the rule helped them avoid making it again. It also helped them recognize when it was time to generalize. Fewer than three examples? Don’t generalize. Three or more? Start looking for opportunities.

The rule worked because it was easy to remember, and the situations where it applied were easy to recognize. When coders could see that they had started moving past the bounds of the well-defined problem at hand, they could take a step back, count the number of concrete examples of that sort of problem they’d run into, and make a better decision about whether to generalize or not. They wrote better code.

...

So, bit by bit, what was once a single rule grew into a list of rules: the Rules of Programming described in this book. They represent many of the most important aspects of Sucker Punch engineering culture: the things that we believe have led to our success, the ideas that new coders on the team need to absorb to be effective. The things that even senior coders like me need reminding of at least once in a while!

Each of the chapters that follows describes a Rule, with plenty of examples to illustrate the thought behind it. After reading a chapter, you should have a clear idea of the coding practice the Rule encourages and the situations where it applies.

Review

The Rules of Programming combines great guidance for beginners with subtle lessons that may teach even the experts. Zimmerman keeps it fun, too - proving that it's possible to be both entertaining and instructive.

Mark Cerny

Lead System Architect, PlayStation 4 and 5

The Rules of Programming provides great insights for both new and experienced coders. Zimmerman's style makes it an entertaining read, and the 21 rules are an important contribution to better software at a time when technology is pervasive in every part of business and society.

Paul Daugherty

Group Chief Executive of Technology and CTO, Accenture.

The Rules of Programming is full of pragmatic rules of thumb which any Software Engineer can use to level up their skills. I love the mix of pithy sayings and detailed concrete examples - such as "Generalization Takes Three Examples" with many code samples putting that rule to practice. I was fortunate to learn these lessons directly from Chris early in my career, and have successfully applied them across a wide variety of software disciplines. With this book, you have the opportunity to do the same.

Chris Bentzel

Director of Software, Boston Dynamics

The Rules of Programming fills in the gaps that most programming books and CS departments leave out—the practices that differentiate a novice programmer from a seasoned professional.

Jasmin Patry

Rendering Lead, Sucker Punch

On the one hand, Chris takes a certain pleasure putting his fingers on controversial opinions. And thanks to the precise examples being brought to the readers, challenging your own way of thinking is made a lot easier. On the other hand, Chris has put in words things that some of us are doing intuitively. Chris just made training way easier. A must read!

Julien Merceron

Chief Technology Officer, Bandai Namco

The Rules of Programming is a fun read and provides some insight into practical game engine development. The stories and guidelines presented should provide interesting food for thought for experienced programmers and valuable starting points for the less experienced.

Adrian Bentley

Development Manager, Sucker Punch

Reading this book gives you a sense of what it's like to work on that rarest of treats: the large, well-functioning engineering team. Each chapter presents hard-won lessons illustrated with code and leavened with interesting anecdotes from some very successful projects. Above all, Zimmerman's book inculcates a proper sense of developer humility — working in a collective manner that acknowledges, and is resilient to, normal human fallibility and the gravity-like pull of complexity in growing projects. Reading this as a group would be a great team exercise.

Jan Miksovsky

graphorigami.org

The Rules of Programming deftly articulates a lifetime of real-world engineering lessons into a fantastic handbook of core concepts that are both helpful reminders to experienced developers and a guidepost to those just starting their journey as software engineers. If you're looking for practical ways to ensure the success of your project, you need to add this book to your library.

Wes Grandmont III

Lead Technical Art Director, Sucker Punch

I really appreciate the set of helpful tools Chris provides that can be used for those critical 52/48 design/coding decisions that come up so often.

David Oliver

Principal Group Engineering Manager, Microsoft

This book belongs in every professional software developer's toolkit. It is full of techniques that are sure to increase your productivity and your team's, reduce bugs, and result in more easily maintainable and extensible software systems.

Chris Heidorn

Senior Staff Engineer, Sucker Punch

From the Author

I decided that writing a book would be way more fun if it benefited a good cause. And I couldn't think of a better organization to support than Girls Who Code, the direct recipient for all royalties from this book. 

Girls Who Code is working hard to help young women discover just how rewarding programming can be. When I graduated from college, over a third of computer science graduates were women. These days, it's more like a fifth. That's ridiculous. I think we'd all be better off with a more representative gender balance. You probably do, too. And supporting Girls Who Code through donations or volunteering is a step toward making that hope a reality.

Or even the small act of buying this book. Learn to write better code; support a good cause. Everybody wins.

About the Author

Chris Zimmerman co-founded the video game studio Sucker Punch Productions in 1997 and led the coding team through twenty-plus years of successful video games, including three Sly Cooper games and five inFamous games, culminating in 2020's Game of the Year candidate Ghost of Tsushima. He split his time between designing and writing code, like the melee combat in Ghost, and the day-to-day work of building and managing a twenty-something person coding team. Prior to Sucker Punch, Chris spent roughly a decade at Microsoft, but the things he worked on there were much less interesting. He graduated from Princeton in 1988, and as a result owns more orange clothing than you do.