The Rules of Programming

Rule 17. Sometimes the Bigger Problem Is Easier to Solve

“Pick the most boring approach to every problem you encounter; if you can think of an exciting approach to solving a problem, it’s probably a bad idea.”

If this is how you’d paraphrase most of the advice in this book, I wouldn’t blame you. A lot of these Rules can be a bit of a buzzkill. They point to some interesting or clever technique you might use to solve a problem, then immediately inform you that it would be a bad idea to use that technique. And it’s true that the simple, boring approach is almost always the best approach. But only almost!

On some very special occasions, the clouds majestically part and you’re bathed in the warmth of a single ray of sunlight spearing down from the heavens to illuminate you at your keyboard.¹ And in this brief, glorious moment, you realize that it would be simpler and easier to solve a more general version of whatever specific problem you’re working on.

Revel in these occasions, because they don’t come very often. When they do come, be ready to take advantage. Write the simple code, solve the general problem, and glory in the moment.

Jumping to Conclusions

Here’s an example. In one of the early Sucker Punch games, the player bounds through levels as the master raccoon thief Sly Cooper. Sly is very agile, leaping into the air, then landing on tiny outcroppings or alighting on thin tightropes strung between buildings. The controls are simple—press the X button to jump, bend Sly’s midair ...