gistfile1.txt

"All "best practices" and thought leader advice is geared
towards the baseline generic system in that field.

The baseline generic distributed system, the baseline
enterprise app, the baseline agile team, the baseline test suite.

No project is "baseline generic". All of them have complications,
whether technical, historical, or domain-related, that make them special.

Ideal "best practices" and "conventional wisdom" are those that still
give pretty good outcomes, even for the special cases. They may not be
*perfect* for your use case, but following them is still on the whole
better than doing nothing at all.

The best outcomes, though, come from figuring out which "generic ideas"
need to be adapted, or rethought, or ignored entirely in your situation.
This is a lot harder to do, and also a lot harder to *teach*. Which is why
it's not as much talked about.

(The only good way I've seen to teach it is to create a *new*, more specific
"baseline generic", like "high-volume distributed system" or "enterprise app in K12 education"
or "fully remote agile team". You still have the same problem with project uniqueness, but the
"differences" from the baseline are less pronounced.)

Since we don't talk about it, this creates the impression that "best practices" are literally
that— ALWAYS best. Senior engineers know this is a convenient fiction, but junior engineers
don't start out knowing that... until they get burned.

This is why thought leaders should be clear about the motivations behind their advice and where
it breaks down. When shouldn't you write formal specifications? What clean code is *too* clean?
Where does solo work trump mobbing? When do you want globals?

Even if you think the breakdone zone is *extremely* niche, it's still important to talk about it.
You never know what weird problems your audience is dealing with!"