Every new engineer eventually asks why the codebase looks the way it does. The question is usually polite, often prefaced with "I'm not trying to be a dick but…" The answer is almost always the same: it made sense at the time.
That does not mean the code is sacred. It means the team that wrote it had reasons, and those reasons deserve a hearing before anyone starts rewriting history.
At a glance
- New engineers question existing patterns within their first weeks on a team.
- Code that looks wrong today was usually the best answer with the team and tools available then.
- The healthiest response is curiosity first, judgment later.
- "Disagree and commit" is a workable tactic when the fight is not worth having.
- Interview-stage signals often tell you whether a team is moving forward or stuck in old habits.
Why "why is it done this way?" is the wrong opener
The question is not hostile on its own. The problem is the implicit suggestion that the current approach was wrong. Senior engineers who have been in the codebase for years tend to hear it as a critique of decisions they made, sometimes under deadline pressure, with fewer tools, and with a different team.
Most of the time, the answer is "because at the time, that was the answer." That is rarely satisfying for a new hire who wants everything refactored by Friday, but it is honest. Reframing the question from "why this" to "what problem was this solving" lowers the temperature instantly.
There is also a generational gap. Code a senior engineer shipped five years ago was probably reasonable then. Asking them to defend it today is asking them to relitigate a decision that has already been overtaken by new libraries, new runtimes, and new team members. Patience is part of the job.
How to handle code feedback without burning bridges
Default to curiosity. Ask what the original constraint was, what alternatives were considered, and what the failure modes looked like at the time. You will learn more about the system in fifteen minutes of questions than in three days of refactoring.
Assume good intent. People rarely set out to ruin a codebase. Decisions get made in discussions, often after long debate, and the resulting code reflects the compromise that survived the room. Treat that compromise as a starting point, not a target.
Pick your battles. Some fights are not worth having. If a team has standardised on two-space indentation, do not stage a four-space uprising on day three. If you truly cannot live with a convention, raise it once, lay out the trade-off, and let the team decide. If you lose, "disagree and commit" is a mature way to keep the work moving.
Lead with questions, not edits. New pull requests that rewrite working code without explanation are how trust evaporates. A comment that says "curious why we use this pattern here, can you walk me through the trade-off?" almost always gets a useful reply. The same question phrased as "this should be X" usually gets defensive silence.
Our analysis
The pattern here is not unique to engineering. Every discipline has its dogma, and every newcomer eventually decides which dogmas to defend and which to dismantle. The difference in software is the speed at which old choices become invisible load-bearing walls, and the speed at which new hires can rip them out.
The trade-off is real, though. Teams that welcome every challenge ship less, because consensus becomes impossible. Teams that resist every challenge stagnate, because the people closest to the work stop pushing. The sweet spot is a culture where questions are expected, answers are required, and refactors come with data, not vibes.
Watch for the team that cannot answer the question.** If you ask three times why a pattern exists and the only reply is "we have always done it that way," that is a signal worth noting. It tells you the codebase is fossilised, and no amount of polite questioning will change that.
Who should care
| Situation | New hire | Senior engineer | Tech lead |
|---|---|---|---|
| First code review comment | Ask "what problem was this solving?" before proposing changes | Treat questions as curiosity, not critique | Set the tone by answering context first |
| Disagreeing with a convention | Raise it once with trade-offs, then commit | Share the history without defensiveness | Create space for debate without letting it stall work |
| "We have always done it this way" | Treat as data, not invitation | Fill in the history when you remember it | Either explain it or flag it for cleanup |
A worked example
Say you join a team and the first module you open uses a custom global chain for dependency injection that the rest of the company has moved away from. Before you open a pull request to swap it out, message the tech lead and ask for a 20-minute pairing session on the history. Listen for the words "we tried that and it broke X" or "we have a migration plan for Q3."
If the answer is the first, drop the refactor and pick a smaller win. If the answer is the second, offer to help drive the migration rather than replace it. Either way, you have learned more about the system, kept a senior engineer's trust intact, and shipped something that mattered.
Bottom line
Most code that looks wrong was right once. Ask why before you ask how to change it, and you will be a better teammate by the end of your first month.
Key takeaways
- Treat "why is it done this way?" as a request for context, not a battle.
- Question conventions early and politely, then accept the team's call.
- "Disagree and commit" is a legitimate tool for staying effective on a real codebase.
- A team that cannot explain its own code is a red flag worth taking seriously.
Frequently asked questions
How should a new engineer push back on bad code without burning trust?
Start with a question, not an edit. Ask for the history, the trade-offs, and the constraints. Refactor only after you understand the original decision.
What if the team simply insists "we have always done it this way"?
That is information. It usually means the codebase is fossilised. You can raise the concern once with data, then decide whether you want to stay.
Is "disagree and commit" just giving up?
Not necessarily. It is a way to stay effective when a fight is not worth the cost. Save your energy for the battles that actually matter.
How do you tell during an interview whether a team is open to feedback?
Listen for how they talk about past decisions. If every choice is defended with reasoning, the culture is healthy. If every answer is "we have always done it," be cautious.