Hacker News Reader

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

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.

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

Consent even over consensus.

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

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.

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.

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.

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.

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?

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

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.

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

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

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.

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

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.

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