I wrote a little while ago about the advisability of teaching software patterns to beginning developers as well as experienced ones. But it occurs to me there’s reason for doing it that I may not have covered completely.
I’m going to take as my starting point Donald Knuth’s idea that the main task in software development is to explain to other developers what we want the computer to do, that the primary audience of source code is a human, not a machine. That seems obvious enough to not need much supporting evidence. Nobody lives forever, no one stays in the same job forever; everybody gets replaced, either voluntarily or involuntarily.
While the syntax of the language makes this communication possible, we still need a common conceptual base to make it efficient. Even in English it’s easy to come away from a single sentence with multiple meanings; development languages, with their near-total focus on what over why, can be even more adept at hiding meaning.
Noted psychologist Adrian deGroot performed a number of experiments with the minds of chess players (you just knew I was going to work chess into this, somehow, didn’t you?) but the one that is most relevant to this involves testing memory and understanding of chess positions.
He gave players of varying playing strength a few seconds to look at a “normal” chess position, meaning one that quite easily could arise during actual play, even if it hadn’t. He then asked the players to reconstruct the position from memory on an empty chessboard. The better the player, he found, the more accurately they could reconstruct the position.
Then deGroot repeated the experiment using random diagrams, with pieces in improbable (even impossible) positions. Interestingly, he found good players were no better than anyone else at recalling those “nonsensical†positions.
There’s a reason for this that extends beyond chess. The brain simply isn’t good at remembering lots of little details. It’s as if the brain only has so many short-term “slots†to hold things, no matter their size. So it takes what it sees and “chunks” it into larger groupings that make sense to it. In this way, a grouping of chess pieces that commonly occurs in a game can be remembered as a single unit.
But we’re talking about software, not chess. Or are we? Think about a batch of unfamiliar code in front of you, that you’ve been brought in to revise and extend. If both you and the developer(s) who originally created the code have learned the same patterns, you can take many lines of this code and group them mentally under that pattern, keeping them in your mind efficiently while continuing to read more code.
If you and the original developer(s) of the codebase you’re working on did not have this common “pattern language†to call upon, you would still end up grouping lines of code into “chunks†in order to comprehend it, but you would additionally have to create your own “chunking algorithm†to do it. “Reinventing the wheel†like this is not only inefficient, it runs counter to today’s more pragmatic development principles.
And because you’ve been using a common pattern language, you not only group many lines of the code into a single “slot†in your memory under the name of a pattern you already understand, the odds are you and the original developer(s) had the same chunks in mind. You can build your mental model of the code more quickly and reliably, and your model will more closely resemble the original ideas behind the existing code.
This means even if you’re a new developer, you’d be more productive with a new codebase faster knowing the patterns than if you hadn’t learned the patterns in the first place.
