Live data from Hacker News

How to deal with difficult people on software projects

howtodeal.dev

91–100 of 130 posts

Re: How to deal with difficult people on software projects

#91

This is a horrible website and you will likely experience diminished tenure if you follow it's advice. First, there is a complete lack of empathy for the person being labelled. What are the motivations and constraints that led to this person acting this way? A key question and the foundation for building healthy productive relationships. Second, the 'solutions' are horrible. "Go around the person" is terrible advice…

The only one that kind of bothered me was "The Legacy Maintainer" which argues that your legacy maintainers _want_ to be stuck on a legacy project with their career in ruins. In my experience, nobody wants that, but neither can they do anything about it. Then again, the world already looks down on LM's as effectively an "untouchable" caste, so any excuse will do.

I've worked with tons people who have built their careers around a particular piece of technology, get comfortable in that role, and never leave.

Re: How to deal with difficult people on software projects

#92
post #22

This is a horrible website and you will likely experience diminished tenure if you follow it's advice. First, there is a complete lack of empathy for the person being labelled. What are the motivations and constraints that led to this person acting this way? A key question and the foundation for building healthy productive relationships. Second, the 'solutions' are horrible. "Go around the person" is terrible advice…

Fully agreed. Amusingly, every single archetype in the "manager" section of this site contains advice which runs exactly counter to the advice from the also highly-upvoted "Common Mistakes of New Engineering Managers" article currently on the HN home page. This just goes to show the extent to which our industry is still very "unsolved" and contains a multitude of often completely-opposed opinions - which means that r…

But that’s just because managing software development is about managing people, and the behavior of people can’t be captured by logical rules. In other words, I doubt that there is something that can or even should be solved here.

I think this quote says it best: “The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function.”

Re: How to deal with difficult people on software projects

#94

This is a horrible website and you will likely experience diminished tenure if you follow it's advice. First, there is a complete lack of empathy for the person being labelled. What are the motivations and constraints that led to this person acting this way? A key question and the foundation for building healthy productive relationships. Second, the 'solutions' are horrible. "Go around the person" is terrible advice…

I can not say it's a true piece of art, but looking at the engineering row, I have met every single cliché in this list and the description are perfect.

Each individuals are unique, so the "solutions" part is foolish, only a bad manager would follow them blindly but I would definitely say that the labelling is on point

Re: How to deal with difficult people on software projects

#95
post #74
post #60

Earlier quoted context omitted.

I hope you have better experiences with product orgs in the future, because based on what you're saying, you have worked with some really bad ones. Requirements gathering is the main job of the PM, and it's most definitely not technical (or at least not remotely to the level of technical knowledge required to actually write code). For example, a PM at Twitter defined that Tweets should be 140 characters (at least in…

Wow. You probably have high dev turn over rate or extremely complacent ones. Mistake many pms and execs make is assume dev is only worth they’re coding skills. We are humans who also have a non technical creative side. But the assumption is someone has already done all the high level thinking so we don’t have to.

It's not about assuming that devs are only worth their coding skills, it's about recognizing that their coding skills are what they're hired for (and also what they're extremely highly paid for).

It's fine that you have a non-technical creative side, but it's frankly not what you're paid for. That's true of everyone in the organization - I'm really enjoy writing and am very good at it, but I don't believe I'm being mistreated or underutilized because I'm not asked to do copywriting. That's the purview of marketing, not product.

This is even true within engineering - if you have experience working on both iOS and Android apps, but you interview for and are hired for a role on the company's iOS app team, nobody is undervaluing you because they don't also ask you to work on their Android app.

Businesses benefit from specialization and focus of their employees. Product exists to gather requirements and define specs not because dev can't, but because that's not what developers are hired to do.

Re: How to deal with difficult people on software projects

#96

The author is clearly a developer, as there are some positive stereotypes in that category, but no positive stereotypes in any other category. I'm guessing their perspective on the related roles is either only through the lens of a developer, or through no lens at all, just squinting from afar.

The site is titled "how to deal with difficult people..." Not nice, competent, or all people, just a specific negative subtype.

I totally agree with the comments about not stereotyping coworkers. The way this site is setup is naturally contrarian to that idea.

Re: How to deal with difficult people on software projects

#97
Whilst technically leading a software project, I worked with a contractor who was so arrogant it defied belief. He told me he was smarter than everyone else in the organisation, and repeatedly told me that he used to work "at board level" whenever he wanted to override my decisions. You know what - I'm fine for anyone in a team to express different opinions and happy to take them on board, but there's a way of going about this without being so hostile. You don't accuse colleagues of being "stupid" (which he repeatedly told us) and then go on to make massive errors in the codebase, over-engineer everything and refuse to read documentation because "I know better". He seemed to really have it in for me, which is odd considering I've worked with plenty of software contractors some of which still message me years after they left just to say "hello".

I was ready to walk out the org but then COVID hit and thankfully I no longer manage him.

I was ill SO much during the time I worked with the guy - my body was definitely trying to tell me something.

I guess he would fall under "The Diva"?

Re: How to deal with difficult people on software projects

#98
post #26

This is a horrible website and you will likely experience diminished tenure if you follow it's advice. First, there is a complete lack of empathy for the person being labelled. What are the motivations and constraints that led to this person acting this way? A key question and the foundation for building healthy productive relationships. Second, the 'solutions' are horrible. "Go around the person" is terrible advice…

Go around is a valid strategy, eventually your entire team will go around the difficult person and the difficult person will no longer be part of the solution chain essentially relegated to obscurity. Works in big teams with sufficient overlap not in small ones

I had a “hostage taker” running devops and CI on a project last year that I had warned the product owner about multiple times.

This person would not respond to basic developer experience problems and could not get a release out the door without some manner of basic code merging problems.

Repeated direct and polite feedback would not move them an inch. It was like they knew they didn’t have to change and could keep their job.

The manager should have been able to identify this and handle it but they were distracted and not able to do it.

Eventually this hostage taker‘a failure to execute and complete sandbagging of any attempt to wrest control over deployments endangered a major new enterprise sale.

We went around this person, rebuilt what they had been responsible for and got back to work completing the product.

They were sidelined and let go eventually and the project is way better for it.

Re: How to deal with difficult people on software projects

#99
post #38

What a toxic little website. Do not follow the advise here. Do not label your co-workers. Trust them, listen to them. If you see them exhibit traits you perceive as negative (and fall into these crude buckets) - talk to them, and give them feedback. Chances are, they will appreciate it, and your working relationship will improve.

This coaching fallacy is actually quite toxic in my experience... many/most people in the workplace don't want to change, and they don't want constructive criticism.

Every ineffective manager that I've ever known thinks that they can coach people into being more productive, better team members... but in the end those managers simply pat themselves on the back while the employee goes on causing headaches for the rest of the team.

Re: How to deal with difficult people on software projects

#100

This is a horrible website and you will likely experience diminished tenure if you follow it's advice. First, there is a complete lack of empathy for the person being labelled. What are the motivations and constraints that led to this person acting this way? A key question and the foundation for building healthy productive relationships. Second, the 'solutions' are horrible. "Go around the person" is terrible advice…

I sense that you may fall into one of these categories and you don't like that...
Post reply on HN