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.
How to deal with difficult people on software projects
91–100 of 130 posts
Re: How to deal with difficult people on software projects
#92This 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…
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
#93Re: How to deal with difficult people on software projects
#94This 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…
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
#95Earlier 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 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
#96The 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.
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
#97I 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
#98This 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
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
#99What 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.
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
#100This 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…