I’ve wasted years of my career winning technical arguments that didn’t matter. That heated discussion about tabs versus spaces? The passionate argument about whether to use Array.map().filter() or Array.reduce()? The philosophical war over microservices versus monoliths for your 10-user internal tool? They’re ego contests disguised as engineering discussions.
After 15 years of watching (and participating in) these debates, I’ve learned that the real skill isn’t winning arguments — it’s knowing which arguments are worth having. Before you engage in any technical debate, ask yourself: “What value does winning this argument create?”
Nothing productive happens in technical debates after 20 minutes. If you haven’t convinced each other by then, you’re not debating — you’re performing.
Just think of it. Twenty minutes gives you enough time to:
After that, if you haven’t reached consensus, you have few options:
Option 1: Call in a referee Grab someone who hasn’t been marinating in this argument. Another engineer, tech lead, whoever has context but not emotional investment. They’ll see what you can’t anymore because you’re too deep in the trenches.
Option 2: DShip it and measure Document your concerns, implement their approach, set a date to revisit with real data. Put there:
Real production data beats theoretical arguments every time.
Option 3: Let them have this one
Sometimes you just ship their weird abstraction. If it’s not actively on fire, it can wait. You’ll refactor it eventually, or it’ll become someone else’s problem when you change jobs. When things break exactly how you predicted (assuming that rare case when you were right), you have to swallow that “I told you so.” It feels amazing for three seconds. Then you’ve burned a bridge with someone you need to work with tomorrow. Instead:
You’re not here to win. You’re here to ship better software tomorrow than you did today.
Your mood hijacks your judgment more than you realize. That “terrible architecture” might just be your blood sugar talking. That “obvious anti-pattern” might be obvious because you’re still pissed about the failed deployment this morning.
Before you die on this hill, ask yourself:
If you answer “yes” to any of these, close the PR. Step away from Slack. Get a snack. Take a walk. The code will still be there tomorrow, and you’ll either see it wasn’t that bad, or you’ll make a better argument without the emotional baggage.
In most technical discussions, nobody’s actually listening. We’re all just reloading our arguments, waiting for our turn to explain why microservices will definitely solve this problem.
Try this in your next discussion:
This feels painfully slow. But it’s the difference between a 2-hour circular argument and a 20-minute conversation that actually ships something.
Your experience is valuable, but nobody wants to hear “Well, at my last company…” for the fifth time today. Instead:
It’s hard to argue with numbers. When making your case, prioritize:
Being right doesn’t matter if you can’t bring people along. You could have the objectively correct technical solution, but if you can’t communicate it effectively, navigate the human dynamics, or pick your battles — your brilliant solution dies. The best engineers aren’t just technically excellent. They understand that software development is a team sport played by humans with egos, emotions, and different perspectives. Your job isn’t to win arguments. It’s to ship software with a team of humans. Every minute spent on ego-driven debates is a minute not spent creating value. Every relationship damaged by unnecessary conflict is a collaboration opportunity lost. Be kind. Listen actively. Choose your battles. Set a timer for 20 minutes. And remember: the code you’re passionately defending today will be legacy garbage someone refactors in two years anyway.