The Rules of Programming

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.

Over time, we found other important bits of Sucker Punch philosophy that could be distilled into easy-to-remember phrases—aphorisms, to be precise. There’s a long history of aphorisms—those short, pithy statements that capture some essential truth. I bet you can rattle off quite a few from memory. Shoot, I could limit you to bird-related aphorisms, and you’d still be able to come up with at least two! I’ll offer a few:

• Don’t count your chickens before they’re hatched.³

• A bird in the hand is worth two in the bush.

• The early bird catches the worm.

• Don’t put all your eggs in one basket.

Aphorisms stick around because they work. They’re viral, in the modern sense—aphorisms have been “infecting” people with bits of wisdom for thousands of years.⁴ It’s not surprising that they’re an effective way of infecting new team members with the Sucker Punch coding philosophy.

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.

Are the Rules equally contagious in book form? Let’s find out.

¹ The eagle-eyed among you may have noticed I left out Rocket: Robot on Wheels, the first Sucker Punch game. That’s because very few of you have played it; if you’re one of the few, you have my gratitude.

² All code committed to the Sucker Punch project gets code reviewed. See Rule 6 for more details.

³ In its original form, from Thomas Howell’s New Sonnets and Pretty Pamphlets (1570): “Count not thy chickens that unhatched be….” A small demonstration of the staying power of a good aphorism.

⁴ The word aphorism itself was coined by Hippocrates around 400 BCE. Well, strictly speaking, the word he coined was Ἀφορισμός. That was the title of his book of rules for medical diagnosis and treatment, some of which are still spot on millennia later, like aphorism 13 from section 6—“a sneezing attack will cure a case of hiccups.” So true.