You've spotted something. A bug. A questionable pattern. An architectural decision that makes you want to close your laptop and stare at the ceiling for twenty minutes.
And there's a senior dev whose name is on it.
Congratulations — you've arrived at one of the most awkward situations in a junior developer's life.
Here's what most people do: they either say nothing — smile, nod, commit the code, and quietly suffer — or they say too much, too fast, in the wrong tone, and spend the next two weeks wondering if their job is fine.
After 25 years in the IT industry, I've been on both sides of this conversation more times than I can count. As the junior getting shut down. As the senior being pushed back on. And I can tell you: there is a third option.
Five points. Real examples. No "um, with all due respect."
1. Don't Lead With "You're Wrong"
😬 The Relatable Pain
Most juniors treat a technical disagreement like a courtroom drama. They build their case, present their evidence, and wait for the senior to crumble under the sheer weight of their logic.
It almost never works.
Instead it gets weird. The senior gets defensive, you get flustered, and suddenly you're both arguing about the argument instead of the actual problem.
🧠 How Experienced Devs Think Instead
How you say something matters as much as what you say. A battle-tested senior doesn't walk into a conversation saying "that's wrong." They say:
"Hey, I was looking at this and got a bit confused — can you help me understand the reasoning here?"
Same destination. Completely different energy. The door stays open instead of slamming shut.
💡 Concrete Example
Instead of:
"This approach is going to cause performance issues."
Try:
"I was reading about this pattern and saw some concerns around
performance at scale — is that something we've already accounted for?"
One sounds like an accusation. The other sounds like a curious teammate. You want to be the second one.
🗺️ The Mental Model
Think of it like judo, not boxing. You're not fighting the idea head-on — you're redirecting it. Use their momentum, their own reasoning, to open the door to your point.
✅ One Thing to Apply Tomorrow
Before your next disagreement, swap your opener from a statement to a question. That's it. Watch how differently the conversation lands.
2. Separate the Person From the Decision
😬 The Relatable Pain
Here's a fun thing that happens to almost everyone: they write some code, and then they become that code. Push back on the code, and it feels like a personal attack. Suddenly you're not solving a technical problem — you're in a feelings argument.
And nobody wins a feelings argument in a Jira ticket.
🧠 How Experienced Devs Think Instead
Senior devs learn — often the hard way — to detach. Code is not identity. A decision made six months ago wasn't wrong — it was right given the information at the time.
A calm senior will say:
"Yeah, that made sense then. What's changed?"
They make it easy to revisit without making it weird. That's the skill.
💡 Concrete Example
Instead of: "This doesn't scale and it never would have."
Try:
"I know we went with X for good reasons when this was smaller.
Now that we're handling 10x the load, I'm wondering if we should
revisit it — what do you think?"
You're not saying the original decision was dumb. You're saying the world changed. Big difference.
🗺️ The Mental Model
Think of decisions like they have an expiry date. Context shifts, requirements grow, traffic spikes. You're not attacking the decision — you're questioning whether it's aged well.
Like milk. (Your codebase is hopefully not like milk. But you get the idea.)
✅ One Thing to Apply Tomorrow
Next time you disagree with a past decision, acknowledge the context it was made in before you push back. It disarms defensiveness instantly.
3. Bring Data, Not Feelings
😬 The Relatable Pain
"I just feel like this could be better."
This is the most ignored sentence in software engineering. Feelings don't merge. Pull requests do not have an Emotions tab. Your gut instinct — however correct it may be — is almost impossible to act on without something concrete behind it.
🧠 How Experienced Devs Think Instead
Experienced devs back their instincts with evidence. Not because they're robots — because data ends arguments so much faster than vibes ever could.
A calm senior will say:
"Let's benchmark it. Let's look at the error logs. Let's see what the numbers say."
That's how a hunch becomes a conversation instead of a complaint.
💡 Concrete Example
❌ Vague:
"I think the current query is slow."
✅ With data:
"I ran this query on staging and it's averaging 2.3 seconds.
I tried an indexed version and got it down to 180ms.
Can I show you the comparison?"
One of those gets a shrug. The other gets a pull request approved.
🗺️ The Mental Model
Your opinion is a hypothesis. Data is proof.
Turn your hunch into a tiny experiment, and your disagreement becomes a conversation about results — which is a conversation engineers actually want to have.
✅ One Thing to Apply Tomorrow
Before raising a concern, spend 20 minutes trying to quantify it. Even rough numbers make you 10x more credible. It's one of the best ROIs in a junior dev's career.
4. Pick Your Battles (No, Really — Pick Them)
😬 The Relatable Pain
Some juniors disagree with everything. Every naming convention. Every line of CSS. Every file structure decision. And look — maybe they're right about some of it! But nobody can tell, because they're also upset about tabs vs spaces, and it's hard to take that seriously when you're simultaneously trying to make a case about the auth system.
🧠 How Experienced Devs Think Instead
Seniors have a filter. They ask themselves:
"Is this a hill I want to die on?"
Most things aren't. They let the small stuff go — consciously, deliberately — so that when they do push back, people know it actually matters.
A calm senior says: "I'll flag this one because it genuinely counts. The rest? We can live with it."
💡 Concrete Example
| Not worth it | Worth it |
|---|---|
| Tabs vs spaces | A pattern that'll force a full auth rewrite in 4 months |
| Alphabetical import order | A data model that won't support the next major feature |
| A boolean variable name | A security approach that leaves you exposed |
🗺️ The Mental Model
Think of your credibility as a finite resource. Every unnecessary disagreement spends a little of it. Save it for the things that actually matter, and when you do spend it, people will know it counts.
✅ One Thing to Apply Tomorrow
This week, consciously let one small thing go. Notice how it frees up your energy — and your reputation — for the disagreements that actually count.
5. Disagree and Commit
😬 The Relatable Pain
You raised your concern. You made your case. You maybe even had data. And they still went the other way.
Now what?
Most juniors either sulk quietly — and do a half-hearted job implementing something they disagree with — or they keep bringing it up in different ways until everyone in the room is exhausted. Both are bad. Very bad.
🧠 How Experienced Devs Think Instead
There's a concept called disagree and commit. You make your case fully — honestly, directly — and if the decision goes the other way, you implement it like it was your idea. Why?
Because half the time, you were missing context you didn't know existed. And the other half — you'll have real data to revisit it later. Either way, you win.
A calm senior says:
"I still think Option A is the right call, and here's why. But if we're going with B, I'm fully in. Let's make it work as well as it possibly can."
💡 Concrete Example
"I hear you — I still have concerns about X, and I want to flag
that for later. But I'm committed to making this approach work.
What do you need from me to get it right?"
That is the sentence of a developer who gets promoted.
🗺️ The Mental Model
Disagreement is a moment. Execution is ongoing.
Don't let one lost argument tank the quality of your work — or your reputation. Lose well. Implement brilliantly. Revisit with data.
✅ One Thing to Apply Tomorrow
Next time you lose a technical debate, say out loud: "I'm in." Mean it. Then build the best possible version of the thing you disagreed with. You might just prove yourself wrong — and that's perfectly fine too.
Wrapping Up
Disagreeing well is a skill. A learnable one. And after 25 years in this industry, I'd argue it's one of the fastest ways to go from junior to mid to senior — because it shows you're thinking about the work, not just executing tasks like a very caffeinated robot.
The five moves, one more time:
- Ask questions, not accusations — judo, not boxing
- Decisions have expiry dates — the world changes, don't make it personal
- Turn hunches into experiments — data ends arguments fast
- Credibility is finite — spend it wisely
- Disagree and commit — lose well, implement brilliantly
So the next time you spot something: don't stay quiet. Don't blow up. Ask a question. Bring some numbers. Pick your moment.
And if you lose the argument? Commit anyway — and let reality be your judge. 🚀
Got a war story about a technical disagreement that went sideways — or surprisingly well? Drop it in the comments. I've seen 25 years worth of them and they never get old.
Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.
Top comments (0)