I was in a chat with David recently and he had a hot take:
<blockquote>
Engineering cultures that don’t believe in standardization across an engineering org basically don’t trust themselves to standardize to a higher quality than free for all.
And to me, that just means you either don’t have any good people or you have very weak engineering leadership
</blockquote>
This came up in conversation because a lot of organizations culturally believe that engineers should be allowed to develop however they want, with whatever tools they want, have whatever deploy strategies they want, with whatever code quality they want, with <s>whatever security vulnerabilities they want</s>. To some engineering leaders that I have worked with, this freedom is supposed to be more innovative and fast pace.
I’m curious which side y’all are on and what trade-off y’all have noticed.
<hr>
We make tools to make it easier to standardize at your org. Checkout <a href="https://docs.trunk.io/code-quality" target="_blank" rel="noopener nofollow">Trunk Code Quality</a>.

Hi, Trunk makes developer tools to solve problems developers hate.

But we also love sharing about what we learn along the way as we speak to engineering leaders!

Trunk.io

The discussion revolves around the importance of code standardization in engineering organizations. David argues that organizations that do not believe in standardization may lack good personnel or strong leadership. The post explores the debate between giving engineers complete freedom and enforcing consistent practices, along with the resulting trade-offs.

What code standards says about your org.

I think standardizing the tools the company should use may take a bit of time and resources in the short term, but it would really help out in the long term. So it really depends on the resources you have.

Free for all just leads to junk code, your juniors will copy that junk and perpetuate it, and they won’t understand the shortcut that your senior took (reasonably) to get it done, now that ‘shortcut’ will be used everywhere.
The worst code is made when management comes around looking for code that is just ‘MVP’ a ‘Minimum Viable Product’ something that works but has zero extra polish or effort put in.

People hiring engineers mostly don’t know anything about building software. They just want to get their product! All they care about is to get it working.
I would argue that if there’s some kind of a structure in a company, with development leadership and stuff. They should come up with standard rules and guidelines.
But hey, what do I know. That’s just my opinion.

I’m a CTO and put quite a bit of time into this topic. We have standards because I want the team to focus on business needs not technical issues like standards and quality. We just bake it in and don’t allow for a lot of dissent. We have a process for those changes and everyone knows it takes time to go through the process. That allows us to just focus on the needs of the customer and not bicker about spaces/tabs, etc.

Really depends on the type of company you are in. If your at an early stage startup, your supposed to build and iterate quick. You can’t start making your code SOC3 compliant from day 1.
But if your a mature organisation, then yes, engineering practices should trickle down from the leadership. With bigger teams, practices, uniformity and discipline always pays off.
Armies don’t let their soldiers run about in a battlefield, they plan and use tactics to win battles.