A clever piece of code is one that makes the next reader pause. The pause is the cost. Multiplied across a team and a year, those pauses are what teams mean when they say a codebase has slowed down.
We write a lot of code at the studio that another engineer might call boring. Long names. Repeated structure. Conditionals you could fold into a one-liner, left unfolded. The work happens in the architecture, not the syntax — and we try to keep the syntax out of the way of someone trying to read at three in the morning.
What we ask in review
Our pull request template carries one prompt above all the others: would a senior engineer who joined the team last week understand this without asking. If the answer is no, the change is incomplete — even if the tests pass and the diff is small.
- Names that read like sentences, not abbreviations.
- Branching that is flat where the logic is flat.
- Comments that explain why, never what.
- Functions that fit in a single screen, with one exception per file.
The brilliant code in our repos is mostly in the seams between systems. The functions are dull on purpose.
There is a place for cleverness, and it is usually a hot path or a primitive that everything else stands on. We let those parts be dense. We try not to let the rest of the codebase aspire to them.
The slow advantage of writing dull code is that it stays dull. Three years in, the parts of the system that have aged worst are almost always the parts a younger engineer was proud of. That is the receipt.