Established Practices
Hey!
Welcome back to another week of musings.
Last week was a short week for me, and this past Sunday, we had the finals before the Super Bowl. I hope you rested and enjoyed your weekend with your loved ones.
Was this email forwarded to you? You can subscribe here!
Things I discovered in the past week
- Crushing JIRA tickets is a party trick, not a path to impact its short blog on why just closing Jira tickets won't move the needle in the long term.
- The Must-Read Books To Have On Your Radar In 2025 is a post by Service95, a magazine I recently discovered and have started following.
This past week, I talked with my manager about how some other team didn't discuss accessing user profiles because, many years ago, they chose to send that information in context with every message or request.
That made me think about the value of established practices and the family of errors and conversations they save simply by existing. I spent the week analyzing if we could have this conversation if we had established a convention.
Which of those conventions would have the most leverage today? The best time to plant a tree, as they say.
I'm sure you've encountered repeated conversations where having a convention would either solve it or avoid it altogether. I noticed this more often when working on API design or publishing messages. Other cases come from audits or regulators; if you have solved a regulatory requirement in a way that is documenting and conventional, you can reuse it yearly or however often the regulator asks for it.
On the flip side of conveniently established practices, we have practices that everybody has dealt with for so long that nobody thinks they're losing time by doing them. Generally, you'll hear, "We've always done it this way."
While these practices might save some time, and embarking on the journey to change the culture might be long and arduous, when done correctly, they pay dividends in the future both by time saved and by providing feedback that we can change the processes at play. The role of staff engineers is to figure out which of these established processes will give the most leverage; while it might seem that everything is broken slow or bureaucratic, not everything is worth fixing right now.
Your turn!
Have you ever looked around your team or organization and noticed which processes or practices were so established that no one thought about them? Were they efficient? Have you tried discussing them with your peers?
Happy coding!
website | twitter | github | linkedin | mastodon | among others