The Rules of Programming

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

Forgive me for the following brief descent into metaphor.

Programming is about bridging gaps. You’ve got some problem you want to solve, and you’ve got some pile of code and tech to work with. In between, there’s a gap. You’ll build a bridge across it by extending the code you have and recombining bits and pieces of it in new ways, solving a bit of the problem at a time until you’re done.

Sometimes you only have a small gap to cross. The code you have on hand nearly solves the problem, or just needs to be called in the right way. It barely even takes programming to build the bridge: you’re just invoking your code with the right parameters set.

Sometimes the gap is huge. It’s not at all clear how your code can solve the problem. Sometimes it’s not entirely clear exactly what problem needs to be solved! That’s particularly likely when you’re working on a video game, where it’s hard to predict what’s going to be fun before you have it working. At Sucker Punch it’s depressingly common to solve a tricky problem only to discover there was no point in solving it because the result isn’t fun to play.

Every gap has two sides. You’re standing on one side, looking across the gap at the other. The question here is—are you standing on the side that holds your existing pile of code, or are you standing on the other side, with the problem?

In other words, putting the bridge metaphor aside, are you thinking about the problem ...