How to teach things badly

A quick primer on pawns. Pawns generally move forwards one square at a time, with two exceptions: their first move can be two squares, and they can capture opposing pieces by moving one square diagonally.

Today’s idea isn’t directly technical, but by the end it should hopefully be clear how it can apply to programming and software development in general.

Recently I’ve been caught up in watching chess videos on Youtube. I’ve never been particularly interested in chess, but a handful of videos have made it really interesting.

At some point I ended up being curious about a weird old chess rule I remembered called “en passant” (a French word, so pronounced very roughly like “ahn passahn.”)

Whenever I’ve read about en passant before, it’s been a list of rather arbitrary-sounding rules like this:

A pawn on its fifth rank may capture an enemy pawn on an adjacent file that has moved two squares in a single move. The conditions are:
- the capturing pawn must be on its fifth rank;
- the captured pawn must be on an adjacent file and must have just moved two squares in a single move (i.e. a double-step move);
- the capture can only be made on the move immediately after the enemy pawn makes the double-step move; otherwise, the right to capture it en passant is lost.

Hopefully, at this point, you’re as confused as I was. The way these rules are described is very technical and precise, but doesn’t at all help us understand the rule itself. It makes en passant feel like a glitch or a bug, rather than an intentional rule. Why does this thing even exist? Is it just an unnecessary complication?

Often the way we teach concepts feels a lot like this: a list of arbitrary rules, with no context or explanation. Badly-commented code can also put us in a similar situation. It’s certainly possible to get across the essential facts this way, but we’re doing ourselves an injustice.

Further down the wikipedia article, we see some historical context:

• In earlier versions of chess, pawns could only move one square at a time.
• At some point, around the thirteenth to sixteenth century, people changed the rules so that a pawn’s first move could be two squares instead. (Presumably to speed up the early game and make it more interesting? Would be fascinating to know more here.)
• However, this two-square move potentially allows pawns to evade captures that would have happened, had they moved one square at a time.
• The en passant rule was introduced to correct this perceived injustice.

This historical context is much more interesting than the list of conditions above, and it allows us to figure out the en passant rule for ourselves, from scratch! We could come up with something like the following:

- If an enemy pawn moves by two squares, skipping over a square in the middle,
- And we have a pawn that could have captured that skipped middle square,
- Then, on our next turn, we have the option to move our pawn to that middle square and capture the enemy pawn.

This set of rules is much less precise than the ones above, but much more intuitive. I hope you’ll agree that this extra context makes it much clearer both why the rule exists, and how we could apply this rule in a chess game.

Teaching why something is a particular way is often more important than teaching the thing itself! When we understand the reasons that particular rules exist, then we can figure out the rules for ourselves. More importantly, we can see when the context for those rules might have changed.

Of course, the rules for chess are unlikely to change any time soon. But when working on software (or many other fields) we come into contact daily with decisions, architectures or design patterns that impose similar kinds of rules. Knowing the context for these rules — especially the original goals that the rules were supposed to implement — allows us to be much more deliberate when making decisions.