Navigating Evolving Code Standards Without Chaos
Dev Leader Weekly 91
TL; DR:
Code evolves -- it's okay!
Come up with strategies for alignment.
Check out the livestream on Monday, April 21st at 7:00 PM Pacific (it's recorded!)
Navigating Evolving Code Standards Without Chaos
If you’ve been on a software team long enough, you’ve likely seen it:
A developer creates a pull request using a new pattern.
Another reviewer flags it because it doesn’t follow the team’s established standard.
The author replies “won’t fix,” removes the reviewer, and merges anyway.
... Well, hopefully you don't see that last part too often. Unless you're the author of the Reddit post I responded to:
But this isn't just about one developer "breaking rules." It’s about how teams handle the evolution of a codebase -- how they deal with misalignment.
I've seen this pattern again and again -- at startups, at Microsoft, and in my own lovely projects. The problem isn’t that people are malicious. It’s that we don’t always have alignment on how the code should grow and change.
So let’s talk about what to do when the codebase has old standards, emerging patterns, and not enough clarity in between.
The Reality of a Growing Codebase
Let’s start here: codebases evolve.
Unless you're working on a dead product, your codebase is changing. Features are added. Patterns are introduced. Technologies shift.
Here’s what that leads to:
Legacy patterns that no one really likes but are still everywhere
Newer, preferred approaches that aren't widely adopted yet
Well-meaning developers copying the wrong example
Frustrated reviewers trying to correct course
And PRs that become battlegrounds
This isn’t a failure of individuals. This is a byproduct of growth.
Actionable Tip:
Start from a position of empathy. Assume the developer didn’t ignore the standard out of defiance -- they may not even know the standard has changed.
Standardization Doesn’t Mean Perfection
There’s a temptation to say, “We need to fix the whole codebase to match the new pattern.”
That sounds nice. But if you’ve got 100,000+ lines of code? Good luck. You'll be pressing pause on shipping value to brush the cobwebs off other areas of the codebase.
In most cases, you’ll have to live with inconsistency for a while. That’s just reality.
The goal shouldn’t be to instantly make everything perfect. The goal should be clarity on what the preferred direction is going forward.
Actionable Tip:
Document emerging patterns. Even if it's just a shared Google Doc or README in the codebase. Make it easy for others to follow the "new right way."
The Danger of “Won’t Fix and Merge”
Let’s go back to the Reddit example: someone bypasses review feedback by marking a comment "won’t fix," removes the reviewer, and merges.
That’s not a code style issue. That’s a process breakdown.
Code reviews exist to build shared understanding -- not just catch bugs. When someone shuts down discussion and pushes through anyway, they’re skipping the team part of software development.
... And that's a REALLY REALLY big part.
Actionable Tip:
If you see this happening:
Don’t assume malice.
Reach out with curiosity.
Start a conversation -- not a confrontation.
Example message:
“Hey, I noticed the PR used a different pattern than we’ve been moving toward. I’m curious -- what led to that choice?”
Leading with curiosity invites dialogue. Leading with judgment invites conflict.
Senior vs. Junior Dynamics
Sometimes these conflicts involve power dynamics.
A junior dev leaves a comment.
A more senior dev dismisses it without explanation.
The junior dev walks away thinking,
“I guess I’m not supposed to give feedback.”
Or worse,
“I guess I was wrong to speak up.”
That’s not healthy for the team. That's not what we want to promote.
If you’re the more senior person, you have a responsibility to:
Teach.
Explain.
And yes, sometimes accept feedback from more junior folks.
Actionable Tip:
Never close out review feedback without at least a comment. Even a quick note like:
“I get your point. Here’s why I went this direction instead...”
...goes a long way in keeping the conversation constructive.
Patterns Don’t Just Emerge -- They Need Advocacy
Let’s flip the script:
What if you’re the person introducing a new pattern?
You’re not wrong for wanting to improve things. But the burden is on you to explain why this new pattern is worth adopting.
If you drop a novel approach into the codebase without context, don’t be surprised when people push back. We all have a habit of wanting to resist change.
Actionable Tip:
When introducing a new pattern:
Call it out in your PR description.
Provide a rationale for the change.
Offer to pair or present it to the team.
Change is easier to accept when people understand where it’s coming from. Trying to convey all of the details directly on a PR may not be the best way to get it done.
Use Conflict as a Teaching Moment
Let’s say you notice a teammate using an outdated approach. You’re tempted to just leave a passive-aggressive comment or something short like,
“This isn’t the right pattern.”
But that’s not helpful. Instead, treat it as a learning opportunity.
Actionable Tip:
Use comments like:
“We’ve been moving away from this because of insert reason. Here's a more recently updated area of the code for reference.”
“This works, but there’s a newer pattern we’re preferring -- want me to link you to it?”
Better yet, offer to refactor it together.
The way you deliver feedback can either build trust or erode it. Your tone matters just as much as your content.
When to Escalate (and How)
What if you’ve tried to resolve things directly and it’s still not working?
Maybe the same person keeps merging code without review. Or they consistently ignore team standards. They're the person referred to in the Reddit post who keeps dropping reviewers to get their code merged.
That’s when escalation might be necessary -- but not as a “gotcha” move.
Actionable Tip:
When escalating, frame it as a team health issue:
“I’ve tried discussing this directly, but it’s starting to impact our ability to stay aligned.”
“I’d appreciate help reinforcing expectations across the team.”
Good managers won’t see this as tattling. They’ll see it as a sign that you care about team culture. They can always use it as a feedback and coaching opportunity for the individual too.
For Managers: Set the Expectation of Alignment
If you’re a manager reading this, here’s the takeaway:
You can’t enforce every standard. But you can set the expectation that alignment matters.
It’s not about rigid enforcement -- it’s about creating a culture where:
People feel safe asking questions
Feedback is expected, not avoided
And decisions are communicated, not bulldozed through
Actionable Tip:
In your 1:1s or team meetings, make space for these conversations:
“Are we clear on which patterns we’re preferring?”
“Do we feel comfortable pushing back in reviews?”
“Have we had any confusion lately about review process?”
Proactively surfacing these topics helps normalize them.
Legacy Code Isn't the Enemy
Let’s be honest: your old code probably sucks. So does mine. Some of the code I wrote yesterday sucks.
It’s inconsistent. It uses patterns you now avoid. It’s sprinkled with TODOs, FIXMEs, and tech debt.
That doesn’t mean your team is bad. It means your team is learning. There are newer and better ways to do things.
The real issue isn’t that old code exists -- it’s that people don’t know what to do when they encounter it.
Actionable Tip:
Instead of trying to rewrite everything, adopt this mindset:
Seek to understand the code you see.
Use reviews to educate, not just evaluate.
Advocate for new patterns, but don’t expect instant buy-in.
Refactor the code incrementally -- don't slam on the breaks to rewrite it all before moving forward.
Progress over perfection.
Wrapping Up
Misalignment happens. Standards evolve. People disagree.
That’s all normal.
What matters is how your team communicates through that change. Whether you move forward together -- or whether you fracture into silos.
To recap:
Assume good intent
Lead with curiosity
Make feedback constructive
Advocate for patterns with context
Escalate only after trying to resolve directly
And document the “new right way” as it emerges
You don’t need a perfect codebase. You need alignment on where it’s heading.
Want to improve your team’s code review culture?
Try starting your next PR review with a question, not a correction.
Then watch what happens.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!