If you've been working in software development for a while, you probably have more than a few things that you once thought were Super Important but now don't give much thought to (or vice versa).
If you're new to the field, you probably had some ideas for how you expected software development was going to be. Then after a few weeks or months, you may have realized that things were quite different than you expected.
Either way, I'd love to hear your story, and in particular what made you change your perspective on things.
Top comments (4)
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".
Early in my career, I treated every decision I needed to make in every project (no matter the size) as if it were Very Important and Very Urgent.
I thought this is what it meant to be conscientious and to pay attention to detail, but it really was a combination of perfectionism and a lack of experience that lead me to treat everything with equal weight.
All decisions in software projects involve trade-offs. But sometimes the difference between one option and another leads to a 100x difference in end results, sometimes it leads to a 0.001% difference. Most bike shed arguments fall into the latter category, and not only do they waste time, they burn relationships.
Over time I eventually also learned that things that are low priority concerns at one stage in a software project's lifecycle can become very high priority later on (and vice versa), and so having the "right argument at the wrong time" can be a big net loss as well.
This only became clear to me after seeing how things play out in practice on many different projects, over long time scales. But I sort of wish that I had learned earlier to always put the micro-scale decisions I made day to day into perspective by remembering the big picture end goals I was trying to achieve, and then figuring out from there what a proportional response looks like in any given situation.