Ask HN: Do you work with dogmatic, stubborn developers/sysadmins? Are YOU one? | Hacker News Reader

Ask HN: Do you work with dogmatic, stubborn developers/sysadmins? Are YOU one?

33 pointshoodoof84 comments

For some reason there seems to be a very large number of highly dogmatic, stubborn and difficult-to-get-along-with people who work in development or as sysadmins.

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?

View on HN

This sounds very much like you're advocating for the exact thing I was talking about when I coined the phrase "Kumbaya approach to Project Management" a few months ago in a HN thread. In short, you favour "everyone's opinion is valid" over technical correctness.

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?

I agree. Often I would find myself arguing for the right thing to do, opposed by 9to5 "engineers" who are hell-bent on taking the easy way instead, just because doing otherwise would mean a learning curve (trivial most of the times) for them. The crowd I'm talking about could only be described by "when your only tool is a hammer every problem looks like a nail".

> 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.

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.

It's really not a black and white thing. People that shout can be right or wrong, the same goes for people that are less assertive about making their point.

The focus should be on the point that's being put forward, not the way it was expressed.

When I say "fight and argue to make their point" I mean someone who can actually put forward points in an argument.

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.

I fully agree. Sorry if this sounds like a thread hijack, but I would rephrase the question as

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

You say "that's great you thought of all those things. Let's prioritize them and see how many we can get through in the time we have allotted to the log in page project."

Deadline-driven development? At least for security, that sounds like a dangerous approach. What if something that's not the first priority but is still important doesn't make the cut? Likewise, should you be adding non-important features that will increase your maintenance burden just because you have free time to write them?

I think this is an important point. Culture plays a huge part in the decision making process. Good security generally starts from an organizational acknowledgement that security is important. Everyone has deadlines and budgets so you must actively prioritize what will actually make the cut.

> Deadline-driven development? At least for security, that sounds like a dangerous approach.

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.

You balance the need for absolute security with the cost, risk and impact of failure, and go from there.

I once worked in a place where "It's more important that everyone be harmonious and come to a consensus, than to necessarily come to the best/correct technical solution." (paraphrasing engineering leadership) It was maddening, and as you can imagine, the product quality often suffered as a result.

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.

Consent even over consensus.

> 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.

The only toxic part here is "you are an idiot". If code sucks, it sucks, and calling it out is healthy, if done constructively.

Both perspectives are valid. As someone guiding a technical solution I care about the difference between the best solution, the right solution, and a successful solution. They are not the same thing.

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.

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.

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?

> 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.

Its what happens to me. I usually switch back to damage control as soon as i realise that they don't get it. I also plan on leaving as soon as possible.

It's not always easy to explain something when you are being interrupted by a loud narcissist after every third word you say. And not tempting to stay in such a place either, I would also minimize the damages and focus my energy on looking for a new job unless the boss deals with the source of the problem.

So you're suggesting they're correct but can't explain their point of view with basic facts/information/references/logic?

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.

> The people who know what they're talking about say it once, coherently and concisely.

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.

That part about "Human relationships" was odd, but I think OP was talking about people who get aggressive when confronted.

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.

That's a false dichotomy. You basically say that the stubborness usually comes from a deeper understanding, which is a ungrounded assumption at the very least.

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.

> Lets reverse your example

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".

gotcha

> 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?

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...

A good SysAdmin can be both friendly and sociable, and also insistent that you follow good practices internally to create a stable product. :)

I think that's fine - argue hard, but politely. However, once the agreement is made you have suck it up and do your hardest to make it work. Not bitch and moan after the fact.

> However, once the agreement is made you have suck it up and do your hardest to make it work. Not bitch and moan after the fact.

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 your extreme case, yes. Other cases are more nuanced EG which javascript frameworked should be used?

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.

> 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?

Bingo.

> People like this get grumpy and sulky when the technical decisions aren't what they agree with.

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.

Interestingly, I feel like the more experienced I've gotten the less I find there to be "technically right" decisions. There are just trade-offs and picking the set of trade-offs that make the most sense at the time of the decision making is the best you can do.

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.

I can agree with that. Every option is likely to have pros and cons. If you know what they all are, you can make the choice based on which cons you can live with, and which pros are the most important to you.

   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".

The question you should be asking is: A coworker tells me or my coworker that we're wrong, and it hurts our feelings, how do we deal with it?

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.

I've seen those people everywhere, for decades. They suck.

I 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.

I think the questions imply one side of the argument. I thought there's one reasonable side to this argument. Then I was a stubborn person one day. Why?

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.

If the world went on following that agreement, then (I doubt?) you're the kind of person that the OP is talking about. If you had that disagreement and then let it color your team interactions for the next week, if you couldn't let it go, and if you harped on it for the next several weeks, then you'd probably be the annoying and difficult person.

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.

There's a whole range of possibilities here. Sometimes you get the strong-willed person who has perfectly sensible arguments and may even be fully technically correct, but for non-technical reasons you can't go with their choice, and that really bothers them. Sometimes you get the strong-willed person who has a choice in mind, and doesn't have strong reasons, just strong opinions. Sometimes you have the person who thinks they know the right answer, but a senior person is fighting with them because their experience tells them there's still a problem tomorrow even if it's all fine today. And sometimes you've got someone who is the very definition of fair and rational fighting you tooth and nail because you are trying to do something very, very stupid.

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.

Well said.

The "SQL query with string interpolation from a limited set" argument is a tough one and usually happens when dealing with younger or more junior devs. Someone, please provide a script of criticism that lets the junior dev save face!

> 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.

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?

It was a helper script rather than an existing project, so it was in the "unregulated" region It's hard in my experience to have a coding standard that's team-wide, cross-project and doesn't get in the way. But you're right that parametrised queries could be one requirement that you have to keep.

I think that's an excellent issue to be stubborn about. Even if the string interpolation didn't matter in that situation, whatever alternative you were using, an orm or prepared queries, must have been equally convenient. So the reason your colleague used string interpolation must have been because he didn't knew about the better alternatives. Then insisting on him refactoring his code to use prepared queries is correct because for a small time-investment he learns to use the correct api:s and can write better quality code in the future.

I think there's an important difference between a person who needs to be right, and a person who is right and refuses to allow sloppy work to jeopardize the company. The former certainly suck, and you'll find them among any department, or among your clients, or even in your own family. The latter are exactly who you want to be working with.

Yes exactly. The OP was asking a social question.

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.

Remember you are in a business. It exists to make money, not to be a form of kindergarden (yeah I am one of those people when it comes to producing the best possible outcome to the company). Also being 'technical' not equal 'grumpy' and 'sulky' does.

At parties I'm pretty fun though.

You keep a pair of birkenstocks in the car?

high heels mate... out of cork

Protecting personal feelings over the correct technical decision is the wrong thing to ask of someone that is hired to make the correct technical decisions.

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.

Technical decisions are not meant to make anyone happy unless it is the customer.

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.

You're advocating political correctness instead of engineering. That's wrong.

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?

Heh,when I was a junior dev we had a senior guy on our team who would stay after hours and refactor literally every line of code our team of four devs had written that day.

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.

If he had time to consistently rewrite all of the code to a better standard that the entire team produced while also covering what he himself was responsible for, he was probably working in hell. That shouldn't be possible unless the code was generally pretty bad.

> 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.

No, I left because he had poor interpersonal skills. I'm a senior developer now in a position similar to his and I would never behave in the manner he did.

I enjoy mentoring junior devs and I can't recall this ever being at odds with getting shit done correctly in the end.

one of the most difficult things to learn when you become more senior is that 'not how i would do it' is a different thing to 'this is broken'.

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.

This can't be an "all or nothing" proposition in either case. There are technical decisions that are absolutely worth fighting for, that would be pretty devastating for the product or the company, and you're right, in those cases, you might feel like you have to fight against the preconceived mood -- but even then, keeping account for feelings, because these are the people who are going to need to build your "vision". Compassion without compromise is a real thing.

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.

I've been working with Linux since 1994 and my last job was over 8000+ systems in 12 Datacenters. Currently I work at a hardware company and we develop Android for the hardware we create. Daily occurrences are developers insisting that Unix files must be owned by certain users and that permissions must be 777 on CIFS shares. When I got here they all had admin/root and open ports on the firewall inbound for no apparent reason. We are in a small building and they don't get why we can't add more 40 core Xeon servers to a tiny computer room. They modify the Jenkins build server and then get bored and move on to something else. Thus the releases we have to deliver every Wed. and Fri. are broken come Wed. and Fri. morning.

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.

So you're clearly not the guy the OP thinks he's talking about. :) I've always appreciated your brand of admin+.

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.

If you are the one getting a call at 3am when something breaks, your opinion _should_ matter more than someone else's.

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.

Unfortunately, I've been the dogmatic person in a lot of cases. Often the feel good viewpoint is just clueless and going to lead the company into real problems.

I was recently at a company that was working on a custom AOSP build. Their engineers had no clue what the repo tool used to download AOSP source was and every day started arguments about how they wanted to replace it with git submodules and things like that. Generally so they could do something the repo tool already did, but they just didn't know how to do using it, such as documenting the sha1 commit hashes used for a particular build.

If they had tons of engineers, fine, start rewriting core tooling, but it just made no sense at all for a small startup with strong time pressures for shipping and few engineers. Every other company from Google to drivers to system on a chip companies is using repo so making their own incompatible submodule based method would have 1) taken them a long time to reconfigure ~60GB of source code into a different format 2) made it really tough to bring in later changes from the old format 3) made it really tough to do things like integrate drivers and other code which typically ship with a README for how to integrate into AOSP repo manifests.

Most of the people pushing the submodule rewrite had never even managed to build AOSP using repo in the first place, so their estimates and explanations usually made no sense. Yeah, it would have been the feel good solution to let them stupidly make their attempt and fail or waste a month of time, but that's going to hurt the company too, isn't it?

In almost all cases, it's not that they're dogmatic, stubborn, or difficult just for the sake of it. Don't make it personal and imagine them to be poor empathizers or know-it-alls.

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.

First I think your "problem" is more with the attitude that the actual point of these people. There is nothing wrong with being right, quite the opposite, however it is wrong to hurt somebody feeling or completely ignore them because you happen to be right. We are not robots, if you can't convince people that you are right when it is the case, either the dude/girl in front of you is dumb as fuck or you are the problem.

Personally if the guy in front of me is right I just agree with him and I learn something in the process so it's cool.

If I'm the one being right and the others don't want to listen, I just say my opinion and my arguments and the fuck with it, I won't argue forever we are adults not kids, I couldn't even play this game as a kid, boring as fuck.

Granted I NEVER encounter situations like this, usually people listen to the guy being right, if a compromise has to be made (quality vs. time to release for example) then we do it, I never worked with childish people and probably never will as I would most likely leave (if possible of course).

> 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.

This seems like someone who is not making technically correct decision but still wants to be the winner. In this case, I actually think it's good that people would fight such stubborn people who are not right and still want to have their way. There are a ton of those kind of people out there.

> 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".

This sounds like the case of ethics. Do you work to make someone happy or do you do the right thing.

I both the two cases, technically correct decision should be the way to go. Otherwise you are compromising work ethics and then you get into the ugly office politics arena where you are only working to make people happy without caring about the architecture, tools that could benefit the software.

I might be a difficult person few years back, but today I give up and see that not many people are passionate about software as I am. For many it's about family, progressing their career and not about software and its users, which is what it should be. I have also come across a lot of people who have tried and succeeded in making the wrong technical decisions and still got the promotion. After nearly 10 years, I think software industry has become an ugly place because now it has too many people who are pseudo software lovers.

Ah yes the old "We're not arguing about how to do it, we're arguing about why you don't want to do it my way, which also happens to be the right way!"

Being a good software engineer is also about being able to articulate why a particular solution is the correct one and gain consensus rather than forcing a decision on people.

Oh yes, most other comments here seem to assume that the stubborn guy is actually right technically and objectively, many times they are not, many times there is no right or wrong and many times there are multiple right answers. NIH is one effect of it and you can see it each day here on HN with new js frameworks popping up all the time, half of them essentially doing the same thing. If you haven't experienced it, it can be hard to believe but NIH can be observed within teams also, with certain individuals always wanting to do things their way, often deciding that before they even looked at the solution the others have come up with.

This happens when someone's job is deeply tied to their identity. I find that people who have a separation between their self-identify, and what they do for work are less likely to get defensive when their technical "correctness" is questioned. People who suffer from job-identity are also more likely to adopt the "You don't understand why I am right, because I am smarter than you" stance.

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.

Yes. Yes. Yes.

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.

IT operations will be seen to be responsible for something that was thrown over the wall by developers months ago. And the developers have moved on.

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's more frustrating are the people who are dogmatic and have the technically wrong solution. When things get done a certain way because everyone is just tired about fighting about it and the most stubborn person wins.

At low-end jobs only. The high-end, most desirable, generally highest wage jobs absolutely do enforce a type of "no asshole rule" that prevents hiring these kind of people, and fires them fast if they're discovered later.

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?

For the record, this is the definition of a BOFH: Bastard Operator From Hell.

No mention of a cattle prod so more PFY I think.

> highly dogmatic, stubborn and difficult-to-get-along-with people

Not a problem. They have a way of doing things. That is their way. If it is wrong, how do we persuade them?

> They might even shout or yell at other people to get their own way.

Not good. It becomes a personal problem, and people forget their roles as problem solvers, and turn it into becoming winners.

> 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.

Key word here is 'opinion'. Can it be changed to fact rather than opinion? Opinion is personal. Break it down and go back a/several steps, to get logic out of the opinion. If they're getting personal, as above, this may take hard tactics, but being non-personal is key. Open questions, act as the idiot if you're in a position of authority.

> They value "the right technical decision"

Great. They're committed. They want the best answer, and rationality is the appeal [key - 'from their perspective']

> over human relationships

Bad. Perhaps they're engrained and don't recognize other interests. Take the conversation back and get them to focus on long term interests. This can be interesting, as often you may find the 'suborn, non-team-player' is trying to act in everyone's interests, they've just made it a personal 'win' and others don't recognize they recognize the win-win but are so engrossed they don't express it (or there's a small thing they're afraid of giving up).

> the right outcome might be the one that makes someone else happy, or is the most diplomatic

Negotiation is not win-lost. It is win-win. Often the term 'diplomatic' puts someone in the losing corner "give this one up for the team, we'll win at something else". That is not diplomacy. Diplomacy is recognizing there is a problem for everyone and giving something up is not a good option. Stick to facts, logic, and encourage the exploration of everyone's long term interests. Remember, you're problem solvers. "Technically right" often is right. Information is key here - is someone unaware of a constraint in budget, personnel, timeline, or other? Lacking information makes one feel weak, and emotionally responsive.

> How do these people impact your technical team's work environment?

I try to impact theirs. The above is not wishy-washy. It is not focused on making everyone happy. It is focused on people acting as problem solvers and being tough on each other, while not getting dogged down on specifics to the extent long term interests are ignored.

Source: Experience and reading. Do read 'Getting to Yes', a seminal book (for me) and try some negotiation exercises with the team. Alternate who plays the trainer. Awesome learnings within.

This has been posted and discussed several times on HN and I consider it to be the best approach:

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.

You're missing one side of the equation. Some of those technical decisions matter a great deal. Some don't, but language and tooling choices affect careers. If we (at hypothetical company X where I work at a given time) become a Spring/Hibernate/POJO/VibratorVisitorFactory hellhole, there is no place for me. Over time, that means that I don't have a job. So, damn right, I am personally invested in fighting that garbage before it gets in. Same when it comes to that trendy "Agile"/Scrum shitshow.

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.

>Same when it comes to that trendy "Agile"/Scrum shitshow Honest question. What alternative would you suggest?

What alternative would you suggest?

Hiring adults and trusting them to get their work done.

This is far too pragmatic.

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?

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".

> If we become a Spring/Hibernate/POJO/VibratorVisitorFactory hellhole, there is no place for me. Over time, that means that I don't have a job. So, damn right, I am personally invested in fighting that garbage before it gets in.

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 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".

If it isn't "technically right", it isn't right. Nothing to add.

Reply on news.ycombinator.com