Author's podcast: https://neilonsoftware.com/category/podcasts/
p.s. interesting views, so am looking forward to learning more
How to deal with difficult people on software projects
101–110 of 130 posts
Re: How to deal with difficult people on software projects
#102What 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…
That’s a dangerous generalization imo. There are absolutely organizations that value folks who are receptive to constructive criticism and who are willing to keep an open mind about all sorts of things. These companies screen carefully for characteristics that align with that culture and I can say from experience that it produces a much better working environment.
Re: How to deal with difficult people on software projects
#103Earlier quoted context omitted.
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…
That’s a dangerous generalization imo. There are absolutely organizations that value folks who are receptive to constructive criticism and who are willing to keep an open mind about all sorts of things. These companies screen carefully for characteristics that align with that culture and I can say from experience that it produces a much better working environment.
[deleted]
Re: How to deal with difficult people on software projects
#104Earlier quoted context omitted.
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…
That’s a dangerous generalization imo. There are absolutely organizations that value folks who are receptive to constructive criticism and who are willing to keep an open mind about all sorts of things. These companies screen carefully for characteristics that align with that culture and I can say from experience that it produces a much better working environment.
I agree, and pair programming is really the best option to learn a code base.
Re: How to deal with difficult people on software projects
#105Earlier quoted context omitted.
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 m…
This view is a really poor understanding of what engineering is about. If what you are saying is true then we wouldn't be sitting here trying to encourage engineers to learn every layer of the stack. Each of those layers is significantly different and quickly falls out of the domain of a Software Engineer.
Re: How to deal with difficult people on software projects
#106Learn from the best:
Force difficult people to borrow money from adversaries, the marxists, the jihadis, the drug cartel.
Take the difficult people's money.
When the loan comes due, dump them in the ocean. Good luck collecting.
There will be a standoff with your adversaries. To hell with nuclear weapons. How about using recent developments in fusion and matter waves to turn the sun into a giant microwave? Or, better yet, pair production and coherent control to turn the black hole the sun orbits into a giant microwave, and then melt a couple billion people off the earth as easy as adjusting the volume on my speakers.
The article mention heart surgeons. Not like any heart surgeon ever defrauded the public, cashed out in crypto, and flew to Mumbai from Canada with USB stick in their shoe. And not small town surgeons either. Heads of big pharma and research universities.
Re: How to deal with difficult people on software projects
#107Earlier quoted context omitted.
> This is a horrible website and you will likely experience diminished tenure if you follow it's advice. I'm pretty sure it's supposed to be at least somewhat humorous/tongue in cheek. I can certainly recognise the tropes both in myself and in others. It's just kind of fun, and I'm certainly not planning to take any of its advice that seriously.
I'm baffled that some people might think this is serious. I found it hilarious.
Indeed, and there are loads of them on this subthread. I'm dating myself here but it just goes to show that, absent body-language, voice tone, and other contextual cues, humour still sometimes doesn't communicate well on the web.
Re: How to deal with difficult people on software projects
#108Earlier quoted context omitted.
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 m…
Alright, keep cooking up the ideas in an ivory tower and us lowely well paid devs will just code it up. Because that is how outsourcing works. Really, may as well outsource your in-house devs.
Re: How to deal with difficult people on software projects
#109Where is the category for devs that will weasel out of any work by claiming a ticket is out of scope, or that the responsibilities for handling a certain piece of work lies with some other team, or that you should go through the project manager so that the work can be done 5 sprints later?
the first thing I ask myself in this sort of situation is whether the person is actually correct. part of being effective in a specific role is refusing to take on random work people throw at you. estimates can't be valid if key players are spending lots of time on stuff that wasn't on the schedule. if the person is really just being obstructive, explain to their manager (or have your manager explain to that manager)…
Worked in an environment were anything vague in ticket/story would cause team to reject considering it.
At first I was horrified at this. “You can’t tell the boss no!”
Six months later I had to admit it was by far the most productive team I had or have ever been on.
Re: How to deal with difficult people on software projects
#110Earlier quoted context omitted.
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.”
I feel like between this and the sibling comment my point was misunderstood - to clarify, I wasn't trying to say "our industry is unsolved but should be solved," rather, "there is no 'solve' for these sorts of things which aren't even 'problems' so much as difference of opinion, even outside of the technology industry, and within the technology industry there is an even greater breadth of opinion around product and project scheduling and management" - so, the linked article is triply ridiculous.