About five years ago I wrote a post like this.
Simply put: when you design something from scratch or solve a problem, start from best practices — gather that information.
I still agree with that. But after five years, what changed isn't so much the underlying ideology of how much to prioritize best practices as the emotional stance around it.
In other words, I've come to think: even if it isn't best practice, if it meets the necessary conditions, that's fine.
Put another way: dig deep enough and best practice can slide into armchair theory (extreme, I know). I've had more experiences than back then of realizing that dealing with the problem in front of you matters more than matching the playbook.
Best practices are easy to abstract, so shared understanding is easy to build, and they're extensible — that's a big plus. But I've also felt that clinging to them can leave the problem in front of you unsolved.
I won't share a concrete story, but as an example: even if people say "we don't usually write code this way" or "this code is messy," if it solves what's in front of you and it runs, that can be enough.
Stretching the point a bit: rather than drilling "how it should be" and studying that forever, it's better to just solve the problems actually happening in the work.
When I wrote that earlier post, I already thought that way when those moments hit — but because a fix often felt usable only for that one problem, anxiety about a lack of extensibility for whatever came next often won out.
Looking back, even small problems yield solutions and experience that transfer far more than you expect.
And sometimes best practices are less transferable than you think. The more abstract they are, the more that seems true.
What I wanted to say here isn't "best practices are meaningless." I wanted to stress the value of solving the problem in front of you and of that experience — and that you don't need to fear, more than necessary, whether something is "best practice."
More personally: in my career I was less often taught by a boss and more often thrown into "nobody else knows this, so you do it" guerrilla roles.
That was exactly around when I wrote that first post. It was a lonely fight. On top of loneliness, I was terrified: Am I doing this right? Is this best practice? Am I stuck in some legacy method far from the cutting edge, doing something worthless? And it was always "I handled it, but there's no answer key."
I want to tell that past me that the experience really was valuable — and if I'd heard that then, I would have felt much more at ease.
And I think my career outlook afterward would have been completely different.
That's all.
Tweet© 2025 ZUUHE