Ask HN: Do you work with dogmatic, stubborn developers/sysadmins? Are YOU one?
People like this get grumpy and sulky when the technical decisions aren't what they agree with. They might even shout or yell at other people to get their own way. They'll deride the technical opinions of their teammates so they that can be "right", and "the winner" of the technical point in question.
Such people find it hard to empathise with others and think they they are the smartest and that their opinion is more valuable than everyone else's.
They value "the right technical decision" over human relationships and it doesn't seem to occur to them that the right outcome might be the one that makes someone else happy, or is the most diplomatic, even if it isn't "technically right".
Have you encountered many people like this in your IT career? Do you work with people like that now? Are YOU a dogmatic, stubborn and difficult person?
How do these people impact your technical team's work environment?
85 comments
[ 2.9 ms ] story [ 199 ms ] threadI don't think I've been dogmatic. Maybe stubborn. I have been a very difficult person, and that almost cost me my job.
I've been on antidepressants for awhile, and I have a completely different inner and outer life. Besides my mental health, it's allowed me the space to see that most decisions don't matter all that much. Everyone wants to get the job done, and whatever is decided, the job will get done, for better or worse.
It's also taught me that when other people suck, it might be because of other issues. For me it was depression. Other assholes may be depressed, or have some other condition, or some stress in their lives that they aren't currently able to handle well. They may be overwhelmed by something.
Or they might just be assholes. But it doesn't matter much either way. Find a way to live with them or leave.
Because someone wrote an SQL query with string interpolation of variables and no escaping. Why? Because the values at that time were actually coming from a limited set and were safe to provide that way. Yet I argued that it should be a prepared query anyway, so that we avoid it potentially exploding in the future.
Was he right that it doesn't matter at the time - yes. Would I be the annoying, stubborn, difficult person who knows better again in a similar situation? Yes! And I know some people will be angry about it while others will agree with me. That's life.
Working with other people means obvious disagreement, and sometime your disagreement will be productive and cause change, and other times it won't. Theres a lot of people who cross the fine line of productive discourse and unproductive disagreement though, and there's some people that seem to thrive on the other side of that line in this industry -- I imagine that's the attitude that a lot of people find off-putting.
And sometimes you've just got yourself an asshole.
It can be hard to tell which is which from someone's self-report. Presumably hoodoof (the original poster) has one or more people in mind which prompted hoodoof to write this, but from a one-sided view we really can't tell which is which.
Of course, in the end, I'm not aware of any career path which is populated solely by happy, healthy, well-balanced people that everyone loves to spend time with. Not even therapists or the clergy.
I'm curious if you had coding standards (internally developed, or adopted from another party / standard) that stated best practice?
In my experience, an objective standard is really important in these discussions. If you did, and they wanted to avoid it, was it referred to? If you didn't, was developing a standard taken as a learning point to be adopted in the future, or not pursued?
http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engi...
I'm not here to "win", I'm here to implement the best technical solution.
At parties I'm pretty fun though.
noir_lord said "[Having to argue against less experienced people is] pretty much the life of a lot of more experienced developers."
Hopefully an experienced developer has gained the ability to advocate his position without being a shouting dick about it. It's the shouting dick that I think the OP was asking about.
Personally, no matter how right a shouting dick may be, I tend to shut down and tune out shouting dicks. It's not my responsibility to find the diamond in a flow of shit. Stop the shit and I'll consider your diamond, and be grateful to learn from it, even if we don't happen to pick that particular diamond.
Someone else mentioned kumbaya project management, which I agree is the other extreme and just as harmful. It's a way for managers and individuals to ignore their responsibilities.
No we're paid to do a job. The right outcome is the one that achieves that job. Making you happy while you implement something that will cost the company money isn't the right outcome.
When you are dealing with a highly technical field, such as software development or server/infrastructure administration, why on earth would you not value being technically correct above all else?
If five people on your team think it's ok to accept logins via plain HTTP and one person says "uh no, you need to use HTTPS" would you ignore what he or she says, because the other five disagree?
In my experience, the highly opinionated people who are willing to fight and argue to make their point are usually the ones you need to listen to.
If someone don't care (or doesn't know enough about the subject matter) enough to argue at length for their point of view, why would you listen to anything they have to say?
My experience is completely different. People that shout during the meetings are usually the same people that don't listen to other people enough to understand the problem and continue to promote their idea of "corrections" no matter the facts.
The focus should be on the point that's being put forward, not the way it was expressed.
Someone who yells "we need Mongo because it's Webscale" at the top of his/her lungs isn't going to "win" an argument - they have no substance to their argument.
How to deal with people that are trying to "win" an argument.
We need secure logins. How should we do it?
(a) We should use https
(b) https is not enough. you need to guarantee that nobody is recording keystrokes on the client; you also need to guarantee the CA certificate hasn't been compromised and there is no man in the middle; you also need to guarantee that this password can only be used once... and so on
This is a valid opinion, but management better be privy to these discussions. I've interacted with technical teams who believe their technical opinions and decisions were completely not the business of the people who were signing their checks. Actually, even a subset of management being privy to the conversations isn't always enough - unless there's a good reason, I'd advocate for the details of conversations and especially differences of opinions to be publicly available to most anyone within an organization.
In contrast, places where the norm is "You're an idiot, your code sucks, and that commit has the following enumerated list of bugs which I easily found in a mere 5 minutes..." are toxic and make you not want to come into work every day.
Like most things, there's a spectrum (or maybe a 2-dimensional competence/civility graph) with a sweet spot somewhere in the middle.
The only toxic part here is "you are an idiot". If code sucks, it sucks, and calling it out is healthy, if done constructively.
The problem most projects face is that technology is easy, and people are not. You might face political circumstances that are bad but immutable. You might have budgetary or schedule constraints that are fixed. You might be dealing with a user base with cultural preconceptions that are plumb wrong.
These are all factors that might steer a project away from the best technical solution, but towards a successful one.
Managing the loudmouth or "personality" on a project is not always easy.
My experience is the opposite. Very much so. The loud, opinionated fighters tend to be the insecure and inexperienced. The people who know what they're talking about say it once, coherently and concisely. If the company/management routinely listens to the loudmouth, the skilled people drift away to other projects or other employers.
If someone don't care (or doesn't know enough about the subject matter) enough to argue at length for their point of view, why would you listen to anything they have to say?
Maybe because they're correct? I thought you said that was what mattered?
So you're suggesting they're correct but can't explain their point of view with basic facts/information/references/logic?
That.. doesn't sound likely.
No, I am not. Let's look at my words again.
"The people who know what they're talking about say it once, coherently and concisely."
I thought that was pretty clear. They can explain their point of view. They explain it coherently and concisely. What about that equates to "can't explain"? Are you measuring correctness by how long someone takes to explain it?
That.. doesn't sound likely.
Of course it doesn't. That's not what I said. Not at all. I genuinely have no idea how you ended up thinking that's what I said, but I'm starting to understand why you're in favour of the loud-mouthed Dunning-Kruger victims.
In my opinion this generalization is only sometimes correct, I have been a personal witness (and participant) in many cases where it most definitely does not hold true.
Also: There are people out there who have used a language, a tool, a framework or anything like that and thought: "Wow, this is good". And from that day on, started to fight to use it for everything.
Lets reverse your example: If five people on your team think it's ok to accept logins via HTTPS and one person says "uh no, HTTP is enough, and also cheaper and faster" would you ignore what he or she says, because the other five disagree?
I've seen countless people arguing even before looking at the code for example, or advocating software solutions they never tried.
I've also seen people frustrated enough by the pointless arguing that happens in some workplaces to just give up on their opinion and switching to the try-to-limit-damages mode.
The problem is one of character and team collaboration, not a merely technical one.
I was specifically replying to this, quite frankly terrifying part of the OP:
> They value "the right technical decision" over human relationships and it doesn't seem to occur to them that the right outcome might be the one that makes someone else happy, or is the most diplomatic, even if it isn't "technically right".
It's engineering. Hopefully, you make decisions base not on "How many people agree" but on "what is provably the most correct way of doing things".
It is easy to prove that for login screens, HTTPS is better than HTTP...
That's pretty much the epitome of "Kumbaya PM". Just because a manager decided (or listened to an engineer who said) an SSL certificate isn't necessary doesn't make him right, and doesn't mean you should stop trying to explain why they're wrong.
In addition (and this may shock your world view) technical considerations aren't the only things of relevance when creating a software product. Particularly in the start-up world, time to market can matter more than technical purity.
You're allowed an "I told you so" when things go wrong, but actively work to undermine a decision would be a career-limiting move.
Bingo.
Am I going to tell a front-end engineer with 15 years of exprience that he has to use PureScript because I, personally, think JavaScript is a poorly-designed language? No. That would be dogmatic. I generally prefer letting domain experts call the shots that affect them. It's about getting the right decision, regardless of whether it's my decision, and I may not have all the information.
There are times to step back and let someone else call the shots, and there are times to stand your ground and fight. Make no mistake, though: promotions and demotions and firings result from these decisions and their long-term consequences, so getting them right really matters.
Hiring adults and trusting them to get their work done.
We all need babysitter "scrum masters" updating poorly written "user stories" and doing "bug grooming."
Can we have a retro, please? Now it's time for planning poker!
Are we still in junior high? I gotta laugh. Why do people put up with this bull?
Because software engineers are terrible at managing their own social status, both individually and collectively.
Social status determines how your work is evaluated, whether you are punished or rewarded for taking initiative and working on what you think is important, and how often you are held accountable for short-term results and visibility into your work. Manage your social status poorly, and you'll get daily status pings (the other meaning of "status"). Manage it well, and you can work on whatever you want with a low level of interruption.
However, our industry is full of young, delusional people who haven't been burned (i.e. had difficult life experiences) yet and still believe in the corporate "meritocracy".
Not saying that Spring/Hibernate/etc. are good, but since you haven't proven that they are bad, you sound like someone who is fighting over his interests first before the companies. An enterprise java programmer could give you the same argument, replacing "Spring/Hibernate/POJO/VibratorVisitorFactory" by "Haskell/Clojure/Functional Programming/Hipster stuff". Disclaimer: I myself prefer programming in a functional style and tend to despise (maybe due to ignorance) design patterns.
It's MUCH easier to find these kind of low-end people who are looking for work, since it's so much harder for them to get a job. That's the only reason they're so over-represented, versus how many there really are.
Note that sometimes entire cities become filled with bad-behavior people, as almost all of the good behavior people move to a different city. Look at whether your city has a high emigration (moving out) rate among top-performers in your industry. Do the most career ambitious people tend to move away from your city, or move to your city?
I've been in this situation a lot. I'm a social and diplomatic guy with a passion for programming but I've also been nonchalant or even careless and get told off for it a lot by colleagues with superior discipline and experience.
It hurts when you think you're good at something, and someone points out a flaw that in retrospect is obvious or even dangerous. For me it helps to think highly of the people who gives me the criticism, even if I think they're dull and over-disciplined.
I strive to one day be as cautious and knowledgeable as they are so code I write will be as reliable and robust. And ideally someday I'll look at their code and point out their negligence.
In a team, I would try to publicly compliment the grumpy programmer on his feedback, and initiate conversation on how to set the tech straight. A positive reaction will temper his grumpiness and make him rethink his attitude, they might even backpedal and say 'well its not that big a deal' when you list the downsides of the 'right technical decision' as hurdles you are planning on overcoming. Once you've accepted someones feedback fully, it's much easier to negotiate.
Note that you should only do this when it is 100% the case that this person is technically right.
Imagine been a life guard, telling a mom there is a shark off the beach and not to send the kids in the water, having the mom then send the kids in the water and then blame you for the shark eating them.
That's pretty much the life of a lot of more experienced developers.
> They value "the right technical decision" over human relationships.
That's because if the wrong decision is made those human relationships go to shit when they get blamed anyway.
> it doesn't seem to occur to them that the right outcome might be the one that makes someone else happy.
This isn't flower arranging, there are a limited number of solutions that will fit the requirements, if one of those can include "makes sunshine and unicorns appear" cool.
> Are YOU a dogmatic, stubborn and difficult person?
I don't think so (but then how would I know), I've never been fired in my entire life and survived 5-6 rounds of redundancies so I can't be that hard work.
That decision may turn out to be wrong for a wide variety of reasons, most of which do not invalidate the decision at the time it was made.
When I was less experienced, I thought there were right answers and I strove to get to them. Now I just want to be explicit about the trade-offs I'm making.
In this all too common scenario there is a lot of value in being conservative.
That said, I do agree that it goes too far, and the occasional sysadmin cam be most unpleasant.
What was even more infuriating than his condescending smugness about it is that he was a really, really brilliant developer, so you couldn't really win an argument with him over it. His code was indeed better, but never enough to justify his being such a prick about it.
Also, during planning and architecture discussions he wouldn't say a word, just go and rewrite everything we discussed.
I left for another team after about 3 months of this.
> Also, during planning and architecture discussions he wouldn't say a word, just go and rewrite everything we discussed.
Wild-assed speculation here, but if he didn't think that the rest of the team would listen to his expertise (which you admit was strictly dominant over the rest of the team) and didn't think they were qualified to argue with them about it or teachable enough to learn from him - that could lead to a strategy of silence and just fixing it after everybody else was done.
There are some things that one just can't argue about with some people without it being a complete waste of time.
If he was basically running the show and ultimately responsible for the high quality of the product, IMO he probably should have been tested as the manager of the team. Being able to dictate the standards of the final product would remove the need to argue, and require the team to learn what he wanted them to learn.
> I left for another team after about 3 months of this.
If you were consistently wrong in your disagreements with the best member of the team and instead of using that as motivation to improve, it simply resulted in (traditional anti-egghead/smartypants) rage at the person who had the nerve to be better than you at everything, it was probably better for everyone.
I enjoy mentoring junior devs and I can't recall this ever being at odds with getting shit done correctly in the end.
Also, I find it strange that you put "the right technical decision" in quotes here. Are you thinking of specific instances where (perhaps) you didn't understand why someone was being stubborn about a choice, so you didn't value their stubbornness? Maybe their reasoning is sound, but their articulation of the reasoning could have been better.
People who insist on 'their way' for no reason are one thing. People who insist on the right way, because they have dealt with a lot of problems in their careers from doing things the wrong way, are another. The first is a detriment, and the second is an asset. You have to be able to tell the difference.
But if you're dealing with people who are being difficult for the sake of being difficult, that really does suck.
And perhaps it's you who's wrong and stubborn and that's why people with more experience need to scream at you to get their point across?
That said, dogmatic people CAN be an issue, but it is important to recognize why, so things can be explained to them.
Typically technical decisions are a trade-off between cost now, and cost later, and people dogmatic about technical decisions are happy to incur large cost now, if it means reducing long term costs.
In doing so they however often overlook that the budget may not support the now-costs they wish to incur, either because right now there it is too small, or because the expected profit is too small.
Upon explaining this clearly they often remain unhappy, but become willing to accept things for how they are.
If it isn't "technically right", it isn't right. Nothing to add.
Math is immutable. Feelings aren't.
I'd rather work with a guy driven to be technically correct and ruthless about describing why than someone who throws garbage in or allows garbage in, just to make me feel better about myself and have a better relationship.
In other cases, you need to keep in mind personal biases, and also keep in mind the pyrrhic victories are a very real thing and a very real danger, even potentially catastrophic in certain environments. Hiring an engineer, when you figure in staff costs in interviewing and possible recruiter fees, can cost 5 figures easily. Lost opportunity costs in training and losing corporate knowledge can push those figures even higher. Always have a good understanding of what you're doing, what the consequences might be, and whether your issues are worth those consequences.
If it feels like someone who questions your opinion is attacking you personally, take a step back, and remember that you won't convince anyone you are correct by insulting their intelligence.
I am dogmatic, stubborn until proven wrong, and I can be perceived as difficult if I know that the product/consumers will be sacrificed only so sensitive people feels better.
Having said that, there are ways and ways to discuss differences. There are many ways to deal with conflict resolution.
So far, every time I have been asked to come back and train the rest of the team.
By shouting and getting frustrated, they're really just demonstrating that you and they have poor communication skills - in both directions. They either aren't actually understanding the broad requirements for the decision being made, and/or aren't really articulating why their take on it really is the right way to do it. They have the confidence to think that their solution is the right one for the problem as they understand it -- which is why they get loud and forceful -- but don't make legitimate progress in decision making because either the problem or solution just isn't making its way across the table effectively.
Poor communication skills are indeed very hard to deal with and rampant among people across all divisions. They may be the ones who are having a hard time regulating their emotional investment into the debate, but there are things you can do to make them more comfortable and better heard.
It would be ideal if everyone was pleasant and accommodating of everyone else's ideas at all times. There are usually ways to 'win' or otherwise arrive at the correct solution without having to browbeat everyone into submission. IMO the people who can do this tend to be good at a lot of other things; they are just talented people, and in my experience end up being the 'good' higher level management and technical leadership.
That said, I think you are seriously oversimplifying the work environment. People are frequently overworked; or participating in a group where other people are trying to make decisions they don't have the experience to make (but don't realize it); or are having decisions made in front of them about the effort they will expend towards x, without their input, by people who do not understand what they are asking and/or don't care; or are otherwise not being given the level of respect they deserve. Consider that some of these people take a lot of pride in what they do and are personally invested in the success of their work. Consider that over time, in this situation, these people may become grumpy and combative.
And that's just in the work environment. I don't personally have a work/life balance, but other people I know do have this and sometimes their personal troubles bleed over into their work behavior. We're not all able to compartmentalize.
This is a long-winded way of asking you not to jump to the conclusion that there is something wrong with the personality of your grumpy coworker. Consider that maybe it's an effect, and that you could even have helped cause it.
Most of these guys are Windows guys with 3-5 years experience using TFS. They don't understand why we can't just buy all Microsoft Products when are budget is allocated to getting them Jira among IT needs. They think we should implement LDAP on everything instead of delivering to customers who are paying us millions. Meanwhile I've got to do IT, Linux Engineering, Devops and manage 100+ developers in India in only 60+ hours per week.
You wonder why I value "the right technical decisions" and get grumpy? Oh but I don't sulk I just take away access and tell them to go write code and stop breaking the infrastructure. In my off hours rather than sleep I'm setting up a Cloud environment on AWS to provide sandboxes to devs in India and provide CI. I'm not dogmatic in anything, I believe in the right tool for the job and the most efficient way to get work done properly. Since clients pay for our T&M they appreciate me and I got a promotion on my 9th week. Now that the developers are writing code and don't have to think about IT needs there is no problem.
They've learned to appreciate doing thing "technically right". That means to me using the tools you have to provide scalable infrastructure and making sure deliverable are always met. I've seen many companies struggle for years to turn profit only to go borrow more money. I learned from those mistakes and my last companies revenue doubled to 300 million in one year after 20 years in business. My current company had one project three months ago and we now have 10 starting up. We should have 10x revenue in the next 2 years.