Consistency matters, but it’s naive to push for it as if it’s a universal truth (suggesting it as a “best practice” and walking away), especially taking into consideration what I like to call the locality of consistency meaning it matters more across tighter, local contexts and much less as you try to keep things consistent across broader remote contexts.
In plainer English, it’s much more appropriate to enforce consistency across a single line of code or a function than it is across the codebase of an entire organisation. Without a really really good reason (can you think of one?) you’re not getting this approved:
if (!oneThing && anotherThing == false) {
if (somethingElse)
{
await onePromise();
anotherPromise.then(() => {
const my_var = 'some data'
const anotherVar = 'some other data'
});
}
}
Whereas I’ll be a bit looser to some inconsistencies across a file, and then across the repository in general and certainly across multiple repositories. People are smart, different standards in different areas aren’t unusual or hard to follow and tooling does heavy lifting anyway. There’s no need to force Service A to follow the style and standards of Service B, especially if owned by different teams and/or covering different domains. How else are you going to gradually refactor things or experiment if you can’t abide inconsistency at any level?
This goes beyond code - people should be consistent with themselves, a team should align on a way of working across its people, but go wider and I don’t think an organisation should be telling all teams to move to 3 week sprints just because one team needs to (I’ve been there). Think back to your job history - no doubt you’ve experienced different styles, tooling, principles as you’ve gone role-to-role, and have you really suffered from it? Wouldn’t it be absurd to expect each role to be consistent with the others?
As a creative field, being overly-prescriptive can lead to stagnation as well as a lack of autonomy, agility and ownership. Context switching and a lack of predictability is harmful, but a mature engineer should be able to acknowledge consistency has a price too and when not to pay it.
And to borrow a grounding quote from a friend in a past job:
Do you want to be consistently shit?