> I did not mean for the title to be a "click bait" but rather tried to sum my question to fit into the title's limit
I was part of an interesting discussion today across our Engineering organisation where we debated applying strict standards (tools, code styles, deployment methods, etc.) across the engineering teams. I can see lots of value to have guidelines and standards from promoting a sense of unity, maintainability, code reuse, etc. On the other hand, I can see how teams (especially those who have not participated in creating those standards) see these imposed standards as bottlenecks which will only slow them down into achieving their goals and ultimately decide not to follow them.
This becomes apparent especially with the rising trend of "you build it, you ship it you own it" where teams are encouraged to own their code from the "inception" point up to the deployment bit. Teams start to find what works best for them and might ignore completely anything put in place in favour of being agile, fast and modern (use the coolest and latest tech).
I am wondering what the larger engineering community feel and if there are any best practices or pieces of advice that people can share especially when applying to a growing engineering organisation.
If you’re going to implement a coding style, make it easy to follow. Provide a linter that works with multiple editors, and that can automatically fix common problems or design choices.
If the project is intended to be short-lived or you know for a fact your won’t update it after two years, then who cares. Try something new or get it done quick and dirty.
Pick the right tools and methods for the job, and make sure those methods decrease friction with your team (communicate and get feedback often).