How to have tech discussions with a headstrong coworker
Posted by CoroteDeMelancia@reddit | ExperiencedDevs | View on Reddit | 55 comments
I'm currently in a refactoring project with a coworker that, while very competent, is also unbearably stubborn.
As an engineer, I make my decisions based on facts, specifically their pros and cons in terms of reliability, developer experience, and performance, etc. If you can give me the evidence that your way gets us more value or less cost, I will choose your way.
My coworker, however, argues in terms of emotions: "feeling like" it's better, being "used to it", or "I think this the standard way", rarely providing evidence and logical arguments for his views. This gets us into heated arguments where I ask him "why? but why? why is that?" over and over until either I get some actual factual meat so that we can productively discuss costs and benefits, or he gets tired and ends the discussion because it is "futile" and a "matter of preference" (it's not).
I'm unsure of how to deal with this. It gets tiring to have to force him to do things a certain way by getting a majority of the team on my side. I'm thinking of maybe using a discussion document where we list the arguments of each side and our conclusions about them; maybe this will help us stay in track and have meaningful discussions.
What do you guys think of this?
BillyBobJangles@reddit
Is the coworker like this with everyone?
When a similar thing happened to me, it turned out it was personal. She developed beef with me over some imagined disrespect and I had no idea. We were friends for years lol we ate lunch almost every day and played chess.
But unbeknownst to me for some time, she had started trying to sabotage me at work and was insulting me to anyone that would listen. Which was painfully ironic because she was the person that was often ridiculed in the office and I would always defend her and shut down that kind of talk when I heard it...
So anyways I was confused when she started objecting to every single thing I brought up in meetings. Her objections were so off the wall and I would try to debate in good faith not knowing her goal was to just try and undermine me.
Super confusing and hurtful when I found out the truth. The other developers started telling me about her antics including trying to convince everyone to not approve my PRs so that I couldn't finish stories.
Agreeable_Donut5925@reddit
I wonder what their side of the story is lol
BillyBobJangles@reddit
Me too! Everytime I tried to talk it out she'd say everything was fine. From what our co workers told me the main greivance she had with me was that i "disrespected her" by debating the origins of Chicken Tikka Massalla with her. And this one time when we were about to play a drinking game at the bars and I suggested a different girl in our group lead it. She huffed and asked why not her and I was like "idk Nora just seems more authoritative". Which she interpretted as "I don't respect her opinions" according to our friends.
This was par for the course for her other relationships with co workers. She had similar falling outs with probably 8 other people at work, just deciding one day that they were enemies.
Even her best friend was turned into an enemy because at a white elephant party she said "This is the best white elephant ever", and she took that as a personal slight against her because she had hosted the year before...
Xsiah@reddit
That's a pretty weird thing to say to a person TBH. More authoritative? At a drinking game?
CoroteDeMelancia@reddit (OP)
Wow, that's insane. I'm sorry that happened to you, and I can imagine how betrayed you must have felt.
I'll be on my toes, but I don't think that's the case with my coworker. We might not agree sometimes, but I feel that's the consequence of we both being very detail-oriented in a startup team that's very much the opposite -- "move fast and break stuff". He is not like this with everyone, but it's very rare that anyone challenges any opinions here anyways; more reason for us to stand out.
I believe he feels the same way and not only respects it, but might in fact even appreciate it. He himself has told me that although we both have strong opinions, we strive to do the right thing and that conflict is inevitable. In fact, we usually agree on the big picture; it is mostly on the small stuff that disagreement arises.
I think we have a friendly relationship, and I'd feel very betrayed if I found out he was faking it in bad faith.
Tacos314@reddit
90% of solutions are going to come down to preference, asking for hard data is just a way to shutdown the discussion, most times that hard data does not even exists. It would help if you provided an example.
Postgres Vs MSSQL (Correct solution is Postgres, good luck finding data to support that)
java vs C# (Correct solution is Java, I think C# actually has the better data)
VIM vs Emacs (VIM is the correct solution)
Windows Server vs Linux (Linux is the correct solution)
Eclipse vs Anything else (Anything else is the correct solution)
Tabs vs Spaces (Spaces are correct even if tabs have more logical arguments)
Dogs vs Cats (Dogs are the correct option, even if cats are better)
I think your both headstrong and stubborn and you latch on to "Show me the data" to browbeat your co-worker into agreeing. While your co-worker uses open language to signal they are willing to try something but you don't have any willingness to discusses things.
CoroteDeMelancia@reddit (OP)
I'm not asking for hard data, per se, just some logical thinking as to why your choice is better for the team and the business, not just for you, because you like It.
Take Postgres vs MySQL. I will choose Postgres because it has very useful features that MySQL doesn't have, such as partial indexes and excellent BSON support. If you say "I feel MySQL is still the correct choice", and you can't give me a strong reason as to why your choice saves us some headaches, then I'm sorry, but I will bring this to a team discussion if you get stubborn over it.
arguskay@reddit
Maybe Pick the solution you already use? I would pick mysql because I already have 20 of them running somewhere. If i pick postgres i have to learn it and still have to know about postgres. (And vice versa)
Do i really need this superior bson support or is it nice to have but will force me to learn, backup and maintain postgres or can i find a workaround with the current company-tech-stack?
CoroteDeMelancia@reddit (OP)
There ya go: you didn't answer "MySQL because yes" or "I prefer it because it's better". Instead, you provided valid points and good topics for further discussion. I'm confident that discussing a tech decision with you would not be futile or pointless, as you've demonstrated that you think like an engineer -- properly weighing pros and cons instead of going solely by preferences or gut feelings.
That's exactly the kind of discussion that's so hard to have with this coworker. It feels like trying to convince someone to start eating broccoli: regardless of how good it is for their health, if they don't like it, they won't eat it, period.
justUseAnSvm@reddit
Just do some prep, and show why doing something the wrong way is wrong. Maybe it's harder to maintain, messes up some other interface, or whatever reason. If you confront someone with a list of reasons, don't accept that "feels like" is a valid reason. "Used to it" can be used, but it's either an appeal to laziness, or a concern over conceptual simplicity or the readability of everything being the same.
Unfortunately, if people can't defend their decisions, it's impossible to even have an argument, and if they are unable to see things differently, it's unreasonable to spend the time trying
s0ulbrother@reddit
I feel like though reading the post it’s hard to actually gauge who’s in right. OP can easily be the person they are complaining about. He might shout facts but I had a junior claim that to me and 3 other seniors the other week and we had to tell him to essentially shut up.
OP you guys don’t agree with an implementation refer to a style guide or ask a third party. He can be wrong just as much as you are. Not saying you are but we can all be pretty opinionated in this job.
freekayZekey@reddit
yeah, it is sort of difficult to gauge without examples or being there. what are the “facts” OP want? is it something factual like “this will lead to race conditions” or is it “factual” like “always create interfaces” because of “reasons”
CoroteDeMelancia@reddit (OP)
Mostly me arguing for "something optimal, but pretty small in the grand scheme of things" against him arguing stuff like "always create interfaces” because of “reasons”. This is actually a prime example of something we could discuss: I don't like
Entity implements IEntitybecause sure, it's kinda inconsequential, but it's useless fluff, but he does like it because "it's the right way to do it, because yes".Tacos314@reddit
That's a good example "Entity implements IEntity" is the correct way, tons of data and facts support that. Experience has show non of that matters and is just busy work, sounds like in this example they are using facts and your using feelings :)
freekayZekey@reddit
okay, with this example, i side with you. unfortunately, you will have to decide as a team what to do. it’s uncomfortable, but it does establish some sort of line. as someone who always asks questions, i can tell you finding a happy medium will always feel uncomfortable.
there’s a principal dev whom i interact with fairly often. i can still barely grasp if he likes dealing with me, but i still push back on things when i am certain he is full of vibes.
EdelinePenrose@reddit
an example disagreement might help. right now you’re asking us to trust that you’re not the unreasonable one. your post gives me vibes that this might be a strong assumption ngl.
birdparty44@reddit
I think when you have “same level” disputes, you have to establish a “way we work” philosophy that the common manager presents in order to get everyone aligned.
Then you don’t have to argue one against another, but simply refer to “our best practices” and for that reason he needs to relent and get on board. It might force him to start having better argumentation.
besseddrest@reddit
nothing wrong with gut feelings, sometimes they work out
stubborn with gut feelings - i say don't put too much energy into it. You already know how that coworker is, if you can't convince em, that's just the way they are. There's something to that, it's taken them this far
CoroteDeMelancia@reddit (OP)
I can accept that, if there's no other way. We usually only disagree on stuff that's not important enough to be a deal breaker; mild inconveniences at best. But still, inconveniences; costs we pay for no apparent benefit other than to appeal to his desires.
And, let's be real, it's kind of annoying to hear stuff like "you make a compelling argument and I don't know how to retort it, but I still feel I'm on the right about this and I'm going to do it my way".
pydry@reddit
if it's not that important to you why are you arguing?
titpetric@reddit
Does he have the autonomy to do whatever the fuck he wants or how siloed is this? Ownership of something comes across as assholey, but if it's a thing he owns, maybe he'd rather hear feedback/improvement cycle in a different way. Maybe there are better ways of implementing something, but not everything needs a better way, it needs someone to hold a mental model of the thing and make decisions and avoid scope creep.
His way, common standard. If the standard is falling or low, then you discuss that. Trust is valuable.
cougaranddark@reddit
Then stop getting so frustrated by his ideas and let him have some input. Allow people to learn by letting their ideas happen even if they sometimes don't fit the textbook definition of optimal, and where it's possible, occasionally show him where another approach was a worthwhile improvement
CoroteDeMelancia@reddit (OP)
I did learn a lot through the headaches I caused to myself over my own previous bad decisions, so it's more than fair I let him experience the same thing -- or not, maybe his choice is indeed the right one and I'll learn from it.
cougaranddark@reddit
There's the perspective! Good work.
Failure is amazing. My worst managers and leads were too terrified of it, so everyone that worked with them were basically just typewriters for their methods. The best ones gave some guidance, and when possible, a safety net so we could learn from experiences.
besseddrest@reddit
yeah you just pick your battles, ultimately you work with them, you'll prob work on something with them, let them be an engineer. if they're wrong enough, there will be enough people there to like argue for the sake of the code, if he's still stubborn at that point, then that will have a negative effect on their brand
chipstastegood@reddit
Avoid having these kinds of conversations with that coworker - probably the only way to deal with this long term. In the meantime, try to involve other people and have multiple opinions heard, so it doesn’t look like it’s always your opinion vs his.
Ok_Slide4905@reddit
“Have strong opinions but hold them loosely.”
I would first set up a 1:1 and tell him you appreciate his feedback and that he takes his work seriously. You are bother working toward the same goal but in different ways. If you two can align in the important things, that’s what matters.
Then say that the best way to change your mind is to present a solid rational argument and back it up with data or documentation. If the feedback is about preference or opinion, add it to a doc to capture the feedback and then revisit it on a cadence you agree to (monthly, quarterly, etc)
CoroteDeMelancia@reddit (OP)
That sounds like excellent advice! Respectful, diplomatic, reasonable chance of success and doesn't sour our relationship if it doesn't work.
I hadn't considered "preference" as an actual argument, but it does make sense: in the end, if the arguments bring the balance to an equilibrium, preference is what's going to tilt it.
Plus, if I jot it down on a document, it both shows to him that I acknowledge and value his feelings, AND forces him to not only think of other points, but how much his preference weighs in relation to the arguments, his and mine. It also prevents an annoying habit of his: revisiting points we had already previously agreed upon, causing me to have to present the same arguments again.
Ok_Slide4905@reddit
There’s another benefit too - if he truly feels strongly about a preference like a naming convention, then he should have no problem opening up that conversation with the rest of the team and defending it.
Sometimes we can get caught up in the personal back and forth, but if the stakes are higher he might back down.
CoroteDeMelancia@reddit (OP)
We waste no time discussing truly trivial details. Naming convention is very much preference based and we just roll with what the team convenes is the default style.
It might be better to understand with an example. Here's a shortened version of a lengthy discussion we had: - "I don't see a single tangible benefit to be gained from putting this list of constants in the database instead of an enum in the backend; certainly not one that justifies the added complexity of performing an extra query just to retrieve values that we could have easily been imported from a constants file instead". - "But what if we have to add, modify or remove the values?" - "I can't think of an example where we would have to modify or remove a value in this case, and a table does not make it easier for us to add values" - "Alright, but what if we have to add a new column?" - "Ignoring how improbable that is, am I wrong to assume that it would be trivial to switch to a table if necessary?" - "No... but come on, it's not that hard to do this query, why is your way so much better?" - "It's not much better, but it IS better; here's the code with and without it. Which is simpler? Why shouldn't we just use the enum?" - "I don't know, I still think using a table is the correct option, it just feels right" - "Come on, you're going to use a seed to populate this table, aren't you? You're already writing the values in the backend, just with an extra layer of indirection. This table has a single column and does not have and will not have any relationships with any of the other tables other than this entity's, so why is it there in the first place?"
- "Wait, are you saying that the rest of our seeds are not really useful?"
- "Actually, I am; not all of them, but most, yes. Many of the seeds have single, non-customizable columns and no relationships; they could easily be enums instead and this would certainly reduce the clutter in our database"
"But that really doesn't feel like a standard thing to do..."
And it goes on and on.
There were two coworkers in the meeting with me. They initially agreed with him, but they quickly started strongly leaning towards my reasoning. He was still adamant though.
Is it a hill to die on? Probably not. Is it annoying? Yes. I will try your tips and see if the situation improves.
Ok_Slide4905@reddit
Yeah, the tone of that conversation is somewhat problematic on both sides imo and I would definitely try to avoid engaging in ways that escalate tension instead of relieving it.
Avoid using “you” and “I” statements and superlatives like “better” or “more correct”, etc, even when countering a bad argument. Focus on the behavior of the code not on the behavior of the person, so the person doesn’t feel personally attacked.
When deciding what hill to die on it’s worth considering whether accepting a suboptimal change can be easily reversed in the future. There are rarely cases where a change can’t be undone. Amazon calls this the one way door problem.
If you feel like you need to concede, you can also place a reasonable condition on acceptance.
CoroteDeMelancia@reddit (OP)
Thanks, these are very useful tips. I can understand how I might make him feel personally attacked, even if it's not my intention, and how this might make him close himself to discussion; I'll try to better express myself.
skg1979@reddit
I think it’s often a foof idea for bullet out the list of pros and cons. Seeing them layed out can bring clarity.
CoroteDeMelancia@reddit (OP)
I read "a fool's idea" the first time until the second phrase confused me and had me reread it, lol.
skg1979@reddit
I hate phone typing.
Mountain_Sandwich126@reddit
Are you approaching each convo with the bias of getting ready for a fight?
Tell this person to bring you data that it's better, and also not to be in love with their code. Best solution wins.
CoroteDeMelancia@reddit (OP)
I'm not really trying to fight, and we don't actually end up fighting. It's a discussion, it gets heated, but it stays on the topic and doesn't become personal. Telling him to bring data is precisely what prompts him to justify his approach as his personal preference despite the evidence telling him not to do so.
Mountain_Sandwich126@reddit
That's ego. It'll be hard to manage this but gotta being it back to data. Hope repetition helps drive alignment
freekayZekey@reddit
eh, part of this is an art, and the evidence you might require for decisions might not exist. it’s sort of like functional vs object oriented — there’s no hard evidence really; you kinda go with your gut. we’re not around for these disagreements. also, i’d do some self reflection and see if you’re just as stubborn but on a different side.
CoroteDeMelancia@reddit (OP)
I'm not free from criticism: if he's stubborn and the discussion is not critical, that automatically classifies me as stubborn too.
Regardless, I do believe that we, as computer scientists and software engineers, we do actually have to rely, to some extent, on evidence-based reasoning. Functional vs OOP is an excellent example because some people treat them like dogma when, really, there's tradeoffs; it's not impossible, but harder to defend using OOP in certain contexts where well-made FP shines, and vice-versa.
Many other concepts are like this. Take SOLID, for instance. I've met devs that love it, and devs that hate it. I hate them both: one produces over-engineered abstraction and indirection hells for what should be a simple CRUD app, while the other outputs buggy, unreadable spaghetti. No, I'd much rather work with a dev that knows SOLID and chooses when and how to apply its concepts based on a solid reasoning rather than "I feel like it".
Some devs also never formally learn about SOLID, but kinda re-create it "from scratch" after lots of experience. That's where the "I feel that X is better" comes into play: you've come across good code written by a SOLID dev and you absorbed what that code "looks and feels like", even if you can't conceptualize why is it like that.
Still, it's not unreasonable to ask such a dev to try to demonstrate why he thinks his coding style is better. Compare him to someone advocating for 3NF relational databases because "it's the right way" without understanding why this rule exists, its pros and cons, and when it would actually be beneficial to break this rule, as many professional teams conscientiously and rightfully choose to do so today to gain critical speed in place of unnecessary consistency.
Triabolical_@reddit
Can you see if the group in general will be able to have design discussions once a week at lunch? That can sometimes be a more conducive environment to change practices.
I can say that after working on a couple of teams, sometimes there's no winning these discussions. One of the root problems is that Dunning Kruger is rampant in software; it is *very* hard to know how good of a designer your are unless you are actively trying to improve on an ongoing basis and seek out better approaches.
"You know what it feels like to be the worst software designer on your team? Exactly the way it feels to be the best one."
I did find some decent traction using testability as a design requirement, as my preferred designs are testable (that's what I think makes a good design) and that means I can point to specific issues with other approaches that aren't testable. That's assuming you are required to write tests.
CoroteDeMelancia@reddit (OP)
Testability is the factor I most defended as being the top 1 priority of this refactor and it got received well. In that sense, my coworker didn't make any choices that explicitly harmed testability, you could argue that there's room for his personal preferences, even if they harm the developer experience a little bit for little to no tradeoffs. I could just let him do his thing and this wouldn't be a risk to the project, there would just be some unnecessary annoyances.
Instigated-@reddit
To be honest it sounds like you’re both being stubborn and not working well together.
There’s more than one way to skin a cat, weighing up pros and cons can still yield multiple equally valid options however people will weight things differently so what you view as being a better solution may not be a better solution to someone else (solutions are rarely black/white good/bad), and working with others means working with them productively - which takes into consideration how they feel, the quality of the working relationship, give and take.
And, side note, try spending half an hour with a 5 year old who keeps asking “why” so you can learn the error of your ways.
CoroteDeMelancia@reddit (OP)
I don't believe myself to be unbearably stubborn. It's just hard to convince me with "I prefer my way because my instincts tell me it's better" (actual quote btw). At least, not if you're not an expert with a ton of experience backing up your instincts.
I think I expressed myself quite clearly how I see him as a stubborn, but competent dev. If you got the impression I think "all his ideas and work are shit", I'm sorry, that was not my intention.
I agree with the rest of your points, except that I don't think our discussions are really nitpicks, despite being non-critical stuff. I made this post precisely because I want to find healthier, more productive ways to deal with our disagreements instead of spiritlessly acquiescing or using a political leverage. I also don't believe all conflict is inherently bad, and neither does he, from some talks we had.
I DO appreciate how curious children are and I think "why" is a question we should be asking ourselves much more often than we usually do. I've been in this situation and I found it pleasant rather than annoying. Of course, I did have to say "good question, I have no idea" a few times, but I wasn't lying. I get that it might be annoying for stressed out parents, but I can't blame children for wanting to know and not accepting "because yes" as an answer.
I think you misunderstood what I meant by asking "why" many times. Imagine this: I voted in candidate X. Why? Because he's better. Why? Because the other candidates are worse. Why? Because X cares more about the people. Why?... You see how this can go on and on? But then you answer "Well, X was once a factory worker and participated in many strikes, and he also passed those and those bills that really fit my interests". That's a much more powerful and convincing answer, and even if in the end I still prefer another candidate, I trust you as a politically conscientious voter and am totally fine with agreeing on disagreeing with you on certain political views.
reddi7er@reddit
let him do his shit his way and when it blows up, then publicly tell him "told ya so" for one last time...
Odd_Lettuce_7285@reddit
Honestly, I think learn to disagree and commit. If you have both heard each other out, and he gets to be the decision maker--disagree and commit. He might be right, or wrong. Code is malleable. There will be a time in your career where you get to be the decision maker and there will be a junior or mid-level asking you the same thing.
CoroteDeMelancia@reddit (OP)
True, and it's how we do it currently. I concede when he's the owner of the task, if it's not important. When it IS important, he doesn't take it personally when I gather the team to vote. I was just wondering if I could make things a little easier, but the current situation is not that bad.
MathematicianSome289@reddit
“What can be asserted without evidence can be dismissed without evidence” – Hitchen’s Razor
CoroteDeMelancia@reddit (OP)
Not if he's the owner of the task. If we can't come to an agreement, I have to convince the team, or let go. I prefer the first option, but I often have to resort to the other ones; it gets annoying.
costco_meat_market@reddit
Does the coworker have seniority over you?
CoroteDeMelancia@reddit (OP)
Technically, yes, but in practice, it matters little in the context of this startup. All opinions are weighted the same and everyone does the same work; the only one with true authority is the lead, which is the only one that's ever used the "yes but I'm more senior than you so you'll just have to trust me" card.
costco_meat_market@reddit
It sounds like seniority matters in your startup based on the disrespect this person is allowed to show you. How long have you worked for the company?
CoroteDeMelancia@reddit (OP)
Not long, half the time he has. Which is not that much; he's also not a senior. And I don't feel disrespected by him. Discussions get heated, but there's no yelling, insulting or passive aggressiveness; it's just frustrating when it's clear that we are speaking entirely different languages and there's no way for us to agree on the subject.
It's not in bad faith, he just places much more value into intuition and instinct over cold hard logic than I do, and this creates attrition when we disagree.
I find that we often disagree because my way might be simpler or more functional, but his is "more beautiful" and "feels right". He over-engineers stuff and routinely violates YAGNI, often because it solves an edge case that is both unlikely and inconsequential.
fogcat5@reddit
I would present my idea and how we can support it as a team, and if they have another plan (or no plan) it then becomes their project to own. After that happens a few times, you either move along to a more sane place or they will come around to a common understanding of priorities.
Decent_Project_3395@reddit
There is a class of developer who will not do anything unless someone else has already established a pattern for it, and they will always do it that way. Sounds like you got one of those guys.