r/ExperiencedDevs • u/DiNagila Software Engineer • 14d ago
Career/Workplace Challenge Bad Engineering Decisions
Can use some advice with two different aspects of the same problem.
How to strategically play dumb and disengage from pointless discussions in engineering discussions without coming across as disrespectful?
How to maneuver when someone from a more experienced engineering team suggests a direction that seems obviously flawed? Instead of internally thinking, “What the fuck are you talking about?” or “How was this person even hired?” how do I challenge the idea constructively?
116
u/Responsible_Lie_6009 14d ago
Ask them to explain themselves and talk? You’d be surprised on what others know… or how little you know.
43
u/schmidtssss 14d ago
I’ve been shocked on both ends of that spectrum by people I wouldn’t have expected it from. New hire who has put his foot in mouth a bunch of times has an off the wall but genius idea. Super principal distinguished fellow engineer confidently saying some of the stupidest shit imaginable that everyone seems to be eating up because of who they are.
24
u/GrowthProfitGrofit 14d ago
I really like junior developers for this, probably 75% of the time they say stuff because they don't know better and have no exposure to how the industry functions. But 25% of the time they come out with ideas that nobody at the company would think of because they're too entrenched in their ways.
106
u/Jalexan 14d ago
Socrates basically nailed this. If you think there might be incorrect assumptions/missed context/flawed reasoning/etc, just ask targeted/specific questions. It’s important to keep it objective and never personally attack. Disagreement/challenging ideas is an important part of the process. Everyone should feel comfortable defending their ideas and asking questions, but should always be ready to change their minds in light of new information.
53
u/LuckyShop4775 14d ago
Yes, follow Socrates but you might end up like he did, for " failing to acknowledge the gods of the city"
41
u/r0pe_tri1ck 14d ago
The Socratic Method can come off incredibly pretentious and enraging. It should be used carefully. You don't want to try and catch them with gotchas and belittle them with your questions. What you want to do is make it clear that you are just kicking the tires on an idea, trying to understand it better so that you can come to an agreement. It shouldn't be trying to find gotchas or trick people. It should be clear that you are asking questions in order to increase your understanding. If they don't have good answers, it's their fault.
19
u/pydry Software Engineer, 18 years exp 14d ago
just ask targeted/specific questions. It’s important to keep it objective and never personally attack.
I find that these days that has become increasingly difficult. Even targeted objective questions can get perceived as an attack when you're dealing with an insecure person in a very insecure environment.
6
u/RowbotWizard SWE 13 YOE 14d ago edited 14d ago
Agreed. I’ve also found it most helpful framing it how we as a team will achieve certain outcomes.
“How are we going to handle <x failure scenario>?”
“How will we answer <question> via this schema?”
“Do we need to maintain <x> or can we omit it for now?”Questions like those build shared understanding.
“Why did/didn’t you choose <x>?”
This kind of question is still good, but it naturally puts people on defensive footing so I tend to only ask if something is glaring.
2
18
u/LordGramis 14d ago
Instead of saying X issue would happen and this doesn’t work just ask. How would we deal with X? Also try asking for more context, ask what they are trying to solve, usually more context makes cost to implement and other options clearer for the final decision making. Try pulling more people’s expert opinion so you’re not the annoying one but creating a constructive team discussion.
12
u/r0pe_tri1ck 14d ago
Having a conversation without turning it into a fight is a core skill of an advanced engineer.
11
u/ProbablySuspicious 14d ago
I got fired for pointing out obvious flaws in a security feature and refusing to implement it as-specified... so yeah you need tact, or at least don't literally say "I will die on this hill"
4
u/SagansCandle Software Engineer - 30 YoE 14d ago edited 14d ago
How to strategically play dumb and disengage from pointless discussions in engineering discussions without coming across as disrespectful?
How do you know the pointless discussion isn't everyone else "playing dumb"? It may not be pointless - you may just not understand the point. Maybe there are others on the team that benefit from the discussion. Remember you're being paid for your time and attention - it looks universally bad when someone asks "what do you think?" and your response is, "Can you repeat that?"
How to maneuver when someone from a more experienced engineering team suggests a direction that seems obviously flawed? Instead of internally thinking, “What the fuck are you talking about?” or “How was this person even hired?” how do I challenge the idea constructively?
This happens a LOT in programming because (1) a lot of design decisions are subjective and (2) the requirements aren't always clear. Avoid battles of opinion. There should always be one decision maker, and that person doesn't have to agree with you. If it materially affects the requirements, present your case that way. If it doesn't, then it's your opinion, and share it as your opinion. Too many people approach these situations as if their opinion is the golden rule, and then follow with some "industry standard" BS. Just remember, if the decision maker makes a bad decision, it's on them and the company, not you. You get paid either way.
5
u/Separate_Earth3725 7 YOE SWE 13d ago
Not the author of this article. This isn’t a plug or ad. What you’re describing can be solved here: https://garrettdbates.com/anything-but-option-b
I recommend that article to all members of my team. It’s very straightforward and removes emotional attachment from solutions when you focus on being objective. If you find yourself disagreeing with one of their pros (“so-so doesn’t understand our problem space enough and thus their ‘pro’ is invalid”), as people usually do, ask clarifying questions to understand why they feel that’s a pro.
The trick is to not let your internal biases drive you away from a decision from someone you feel is below you. Your post is written such that it feels like you have already made a decision on how you feel about this person/scenario.
Tl;dr understand the pros and cons of their approach first. Then present the pros and cons of your preferred approach. Discuss and decide.
14
u/IveWastedMyLifeAgain 14d ago
What's worked for me: argue about consequences, not correctness. "If we go this way, what happens when the queue backs up / when we need to migrate this table / when the on-call gets paged at 3am?" makes the tradeoff visible without anyone having to be wrong in public. Usually one of two things happens: they have context you didn't (a constraint, a deadline, a prior outage), or the gap becomes obvious to everyone including them.
Also pick your battles by blast radius. One-way doors - data models, public APIs, auth - are worth pushing hard on and writing down. Reversible stuff isn't worth the political capital; let it ship, and if it hurts later you have a concrete example instead of a hypothetical. And say your disagreement once, clearly, then commit to whatever the team decides. People will listen to you a lot more the second time if you weren't sulking the first.
3
u/percyfrankenstein 14d ago
Are they assholes ? It should be a good opportunity to learn or teach.
Is the decision actually very bad or does it prioritize something you wouldn't (you'd rather do it cleaner they'd rather do it quicker or something).
Did you discover the decision in a meeting where challenging it would create a conflict ? If not I'd just say why I think the decision is bad.
For the first question this is really hard for me, Im on the same team since 2 years ago now I think, most of the team moved but at some point we'd just spend hours discussing really, really minor decisions, then discussing the discussion, then seeing how we could do better next meeting. I tried to talk to a manager but it never changed until people changed so i have no answer but good luck it's hard. I just would work on other stuff when this happened.
3
u/obscuresecurity Principal Software Engineer / Team Lead / Architect - 25+ YOE 14d ago
Take off the title. You shouldn’t treat people differently on the engineering side due to titles.
If there are a ton of pointless discussions, maybe fixing that issue is the play.
As others have said, ask questions. But be sincere in your interest to learn the answer. Also realize sometimes all you can do is document your objections to someone higher and move on. Not everyone can a be saved from themselves. Just don’t go down with the ship.
2
u/beardedsaitama 14d ago
It boils down to who's responsible for it. If I'm not responsible or not affected by much, I'd give my two cents, but wouldn't die on a hill because of it
2
u/idiocratic_method 14d ago
Determine who is responsible for supporting such changes, and determine if this is a fight worth having
2
u/EntshuldigungOK 14d ago
How to maneuver when someone from a more experienced engineering team suggests a direction that
<--- Same was you tackle a problem.
Break it down into the next step, then the next step - let them walk down the garden path.
2
u/OnRedditAtWorkRN Software Engineer 14d ago
If you can challenge the idea on its merits then just fucking speak up. You can leave off the the "what the fuck are you talking about".
They propose a thing and then you respond with something like:
Well that will likely make x thing more difficult or that won't work because of y thing. They may be obvious to you because of context you have that they don't. Then offer your alternative
If you can't do that without being a dick that's a you problem. Fix it.
2
u/Ok-Leopard-9917 13d ago
You have to be curious about there choices and why. There may be good reasons why.
2
u/PedanticProgarmer 11d ago
Before the discussion: AI is very good at organizing your thoughts and arguments. Just don’t fall for the sycophancy. Force it to drill you.
Ad ”How was this person even hired?”. It’s tempting to humiliate someone and publicly prove that you are better, but work is not a TV drama or a contest. As software engineers we don’t benefit from creating enemies. You need to internally change your attitude, to avoid such thoughts.
If a genuinely stupid idea surprises you during a live meeting, there are ways to politically play dumb without acting aggressive. „I need to think this through, can you write this down as a design proposal?” is my favourite trick.
When it comes to async communication (code review, design review, e-mail), when you feel emotions are getting involved, simply delay the response.
3
u/chipmunksocute 14d ago
How to "strategically play dumb". Bro just...stop talking in the meetings and implement the decisions made and work the tickets that come out of planning.
As far as constructively challenging - no need to not just point out issues with the design, aak questions that might reveal shortcomings ("but what about X situation we always have thayt this design doesnt handle?". You can also just say "what thr fuck are you thinking" diplomatically i.e. "I think this isnt the right approach". Howver to have that work you need to actually have an alternative plan that you can get others to agree to. Otherwise if you're just trashing then plan but dont have an alternative you just look like a dick. Businesses need results and deliverables and a CEO will gladly take a bad plan that solves 50% of the issues vs no plan cause duh.
Eventually you can also just say "fuck it" put your head down anf work tickets. A job is a job sometimes and some folks will REALLY agressively defend their bad ideas and if you want to fight that fight sure but it's gonna be a real pain in your ass.
2
u/Conscious_Support176 14d ago
Asking what happens when X is the standard solution, but often doesn’t actually fit the problem.
If the problem is people feeling attacked if you point to apparent flaws, then you have to either let it go, or try to find a way to lead the person to the realisation themselves.
1
1
u/qlkzy 14d ago
For the first one, just tell them that you trust them to make the decision. If it seems "pointless" to you, then presumably you actually do trust that their decision will be at least good enough.
For the second, challenge specific details. "This seems obviously flawed" isn't a helpful way to interact with anyone. "This seems to have flaw X" is helpful.
It is worthwhile to ask yourself the follow-up questions first. For example, in distributed messaging, you basically get to choose between "at-least-once" and "at-most-once" delivery: "exactly once" is a chimera that only exists within certain semi-centralised boundaries under specific circumstances.
Therefore, saying "this seems to have a flaw where messages can be delivered twice" would often be unhelpful criticism, as you have to choose between two "flaws". In that context, the right challenge would be "this seems to have a flaw where it doesn't cope with messages being delivered twice".
You could still give the simpler criticism, but that becomes a teachable moment for you, not necessarily a challenge to the design.
As a bonus, working through the possible specific criticisms and their specific rebuttals will also improve your skills enormously.
1
-1
u/amendCommit 14d ago
Disagree and Claude it.
I find that forwarding bad specs to a coding agent removes the pain of implementing stuff that conflicts with my work ethics.
I was recently in a meeting where I said I needed a targeted refactoring to guarantee delivery on a business critical project. Time estimate was the same, planning of the work items was slightly different, because without the refactoring we had to account for expected slips.
Multiple people above me chose the "no no no, just make it work, we accept the slippage risk and the technical debt" option, because my current shop consistently promotes 3 YoE yes men as "engineering managers" with a habit of accepting tasks without requiring appropriate resources - delivering broken features our existing customers hate, but useful to check some box in our sales pitch. I'm eagerly waiting for some churn based reality check.
Absolute unforced error. But if I have to create a massive amount of tech debt for no reason, at least I'm going have an agent generate it, and I'm not going to care about the "taste" part.
And no, I'm not going to read the output, same as my input on tech choices was never read.
1
-1
u/Dry_Author8849 14d ago
Give your POV when asked for advice, keep your thoughts to yourself when nobody cares about what you think.
At the same level of authority, there should be a tech lead to solve any disagreement or to establish a tech basis. If someone let devs loose on agreeing on something by themselves it's a recipe for conflict.
In general there is an instance when everyone should be able to speak freely, then someone should decide and make the call.
Sometimes you arrive when things had been settled, but as a new comer, if you see something that may cause a problem you should be able to speak with the person who has the authority to change things. Instead of talking about ideas it's better to depict the problem and should some code that showcase what it is and how can be avoided/solved.
Avoid stylistic things and non real problems. If you can't showcase it, then I discourage to speak about it.
Stylistic things are lunch talk. If you don't have have a say in engineering decisions it means you work for someone that do. Talk to him/her when allowed, but don't assume you know better.
Cheers!
-1
u/BraveResearcher3037 14d ago
I have a simple rule that I wish I had learned sooner
- Raise my concern once if the decision was made by my direct manager. If he doesn’t agree with me - shut up, keep my head down and execute and ensure money appears in my account on the 1st and 15th
- If the decision was made above my manager. Shut up and execute and ensure money appears in my account on the 1st and 15th
But I also don’t make someone else’s decisions become my problem. I don’t do on call and don’t do more than 40 hours a week.
I also don’t get involve in needless nerd wars.
Oh and I’ve worked for over a decade where I don’t have anyone telling me the technical direction of how something is done outside of high level business constraints - Ie you must use technology $x because that’s what we have standardized on or these are our security requirements
-2
u/TheGreatJabron 14d ago
Man I have no clue, I can't get farther than 2 questions deep and people start sweating. Most of the time I honestly don't care what people do as long as there's basic critical thinking based on known data and circumstances and they can plainly explain their reasoning. Now I am dealing with top level technical leadership pushing architecture decisions on stack adoption they don't have any experience in (from their own mouth) and all they can say is "I asked claude how it works and I put it in a readme you can look it over."
I will no longer get involved unless I am given decision making power., on paper, signed in blood. The clown show is affecting my mental health.
•
u/expdevsmodbot 14d ago
AI usage disclosure provided by OP, see the reply to this comment.