Best practices are made up rules for a made up system.
They're a great starting point when you're not sure what you're doing or if you're looking for tips on how to improve a system. However when learning them, know why they suggested, not who is suggesting them. Unfortunately I used to win arguments by doing some hand waving and stating "well [insert X dev here] suggested it and it's considered a good practice".
I used to look at my seniors with abject horror (maybe I still do) when I would hear the opposite. "Isn't that an anti-pattern?", I would say. "That's going to be a nightmare to maintain." And eventually, "Okay, but you're writing the tests for that."
Sometimes I'd be right, but more interestingly - sometimes I'm wrong. Sometimes that was the correct thing to do, given the circumstances.
See, the thing about best practices - they're given in a vacuum. There's rarely context or considerations about your stack, your users, or trade-offs. It's good to know the rules - if only to know when to break them.
Hi, I'm Gregory Brown.
My goal is to help software developers get better at what they do, whether they've been at it for five weeks or fifty years.
(he/him)
Really good point about the need to establish context before you can even make sense of the risks and rewards that come along with a "best practice."
In recent years I've become a big fan of teams keeping their own running notes around any particular working practices they have.
The template I use varies depending on who I'm working with and what I'm working on, but it usually looks something like this:
Here's how we do ThingX.
Here's why we do it that way.
Here are the alternatives we know about and why they don't quite work for us.
Here are some reference materials that helped us make this decision.
Here are things we've learned (both good and bad) while doing things this particular way.
I find that once you strip away that appeal to external authority, it becomes a much more thoughtful and useful way to coordinate on how things get done, and also makes it clear that you are free to change your mind if you learn something new -- something that rarely happens when people take the idea of "best practices" literally.
Best practices are made up rules for a made up system.
They're a great starting point when you're not sure what you're doing or if you're looking for tips on how to improve a system. However when learning them, know why they suggested, not who is suggesting them. Unfortunately I used to win arguments by doing some hand waving and stating "well [insert X dev here] suggested it and it's considered a good practice".
I used to look at my seniors with abject horror (maybe I still do) when I would hear the opposite. "Isn't that an anti-pattern?", I would say. "That's going to be a nightmare to maintain." And eventually, "Okay, but you're writing the tests for that."
Sometimes I'd be right, but more interestingly - sometimes I'm wrong. Sometimes that was the correct thing to do, given the circumstances.
See, the thing about best practices - they're given in a vacuum. There's rarely context or considerations about your stack, your users, or trade-offs. It's good to know the rules - if only to know when to break them.
Really good point about the need to establish context before you can even make sense of the risks and rewards that come along with a "best practice."
In recent years I've become a big fan of teams keeping their own running notes around any particular working practices they have.
The template I use varies depending on who I'm working with and what I'm working on, but it usually looks something like this:
I find that once you strip away that appeal to external authority, it becomes a much more thoughtful and useful way to coordinate on how things get done, and also makes it clear that you are free to change your mind if you learn something new -- something that rarely happens when people take the idea of "best practices" literally.
Those are excellent things to keep track of! Love points 3 and 4, especially.
It would save so much time and effort if someone simply said "we already looked into that and here's why we didn't go that route".