Live data from Hacker News

How to build toxic software teams

badsoftwareadvice.substack.com

61–70 of 102 posts

Re: How to build toxic software teams

#61
post #17

Earlier quoted context omitted.

My favorite tool when someone suggests a code improvement is to say ”Cool! Love that. Make it so” Then usually nothing happens. They didn’t think it was good or important enough to use their time, they just wanted others to Do Better. Oh well

AKA "The Wally Reflector" from Dilbert :_)

Looked that up thinking I'll disagree, but actually yes. As you grow in your role, you get to a point where the number of incoming "quick requests" outpaces your ability to keep up.

To most people they're just asking for a quick 10 minutes of your time, what's the big deal. But they don't see the other 20 people doing the same thing. If you devote 200min+ of every day to fulfilling others' requests, when will you have time to do your own work?

The problem grows only worse the higher in the org chart (formal or informal) you get.

Someone like a VPofEng may have 100 people asking "quick questions" all the time. Without the Wally Deflector, there's literally not enough time in the day to even have all these conversations, let alone do anything about 'em.

Re: How to build toxic software teams

#62

I do wonder if people have any experience around doing root cause analysis that doesn't just end up in blame games? I've worked for three companies in a row that claim to have blame-free cultures, and all of them did put work into it (structuring the documents to not assign an individual's name to any given misstep and telling people to be kind and understanding). But in every case, you can feel it in the air that ev…

I really don't know either. When it works for me though, I think it looks like people going out of their way to point the finger at themselves, and nobody going out of their way to wag a follow-up finger at them. I'm not sure hiding it would be helpful, but I haven't tried that.

> When it works for me though, I think it looks like people going out of their way to point the finger at themselves, and nobody going out of their way to wag a follow-up finger at them.

This is how I prefer it too, but the problem is that honesty is a luxury when times are good. When times aren't so good, having a self-documented history of failure doesn't help your case for retention when the jerk next to you who deflects everything appears to be a golden boy.

> I'm not sure hiding it would be helpful, but I haven't tried that.

From the police playbook: after raising awareness of a problem, proactively make excuses for other teams and/or deflect blame to a vendor ("we don't know it's that team's fault; they're understaffed and we don't know what they're having to deal with over there; give them a break because nobody can understand the vendor's fucking incoherent documentation and their software is garbage anyway"). Confusing the issues and misdirecting blame gives the team time to address the problem while saving face. Everybody hates Microsoft anyway so they're an easy scapegoat. (Sorry, Microsoft employees.)

For better or worse, it fosters a culture where people cover for each other, not throw each other under the bus. This is how you wrangle even the most toxic Narcissists-- they recognize and appreciate when someone's doing them a public favor, and (IME) this compels them to respond in kind because they'll want to one-up you as everyone's savior. (We're starting to see this with all the moral crusading and self-appointed "safety" workers. All Narcissists.)

Re: How to build toxic software teams

#63
post #2

Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.

If said teammate decides to follow through on his idea without your explicit permission, transfer him to another team ASAP (without his approval). No teammate can show initiative, self-direction, or autonomy. Furthermore, every piece of work must be represented in JIRA and every team member must report on it —- daily. This happened to me recently. Yes, I’m a little salty about it. Although it’s probably for the bette…

In reality I know what you mean, but not a good look for you imo. Imagine that upgrade causes an issue upstream and someone has to explain who approved it. There's always a way to get housekeeping items approved, sneaking it in isn't it.

Re: How to build toxic software teams

#64
Be highly resistant to replacing outdated tools when they fall out of favor in the marketplace. If you don't have ADD/ADHD, take Adderall or another upper so it makes your personality unstable.

---

In 2020 I briefly worked for a small company. I should have said no, but due to life circumstances, I was uncomfortable passing on the job.

When I joined, there were security problems all over the place. They were self-hosting a Mercurial server with http, not https. I eventually brought up the issue with the (cough) tech lead. (I should point out that the lead had been the lead since graduating college, for a decade, and generally had little to no mentorship in the process.)

First, I asked why they were self-hosting their Mercurial server. I got back a wishy-washy "that's how we're used to doing it" answer.

Next, I subtly pointed out, "You know, if you were using Bitbucket to host source code, you wouldn't have this issue."

The response was, "Oh, don't you remember, Bitbucket dropped Mercurial years ago."

My next response was, "Uhm, then do you think we should switch to git?" (For context, I used to like Mercurial better than git, but years ago moved everything to git when I started using git at a prior job and saw "the writing on the wall.")

The (cough) tech lead then went on a tirade about how we just couldn't switch to git, because he didn't want to have to handhold everyone in figuring out git, and then arguing about minutiae regarding minor differences between the two.

I tried to reason with him in pointing out how, if you build a business around a technology, and that technology loses in the marketplace, you put your business at risk. I mentioned that a business that used Betamax would have needed to switch to VHS once it became clear that Sony was discontinuing it and VHS was winning in the marketplace.

A few weeks later, the (cough) lead mentioned at standup that he was having trouble getting his medication, and acted like he was going through stimulant withdrawal. He never acted like someone with ADD or ADHD off of their meds, though. At that point I put two-and-two together and realized that his behavior was textbook "too many stimulants."

Shortly before my time with this company ended, they very nervously announced they were switching to git. I watched everyone on the team, except the leadership, breath a sigh of relief.

Re: How to build toxic software teams

#65
post #58

Retain rockstar programmers at all costs, even if they push everyone else to quit over being mistreated. Give them fancy job titles. Have upper management crack sexist jokes, and HR laugh with them, so that women at the company who are sexually harassed know reporting it will do at best nothing, and at worst risk their own career. Only hire young men in their twenties, and praise the idea of working long hours. Child…

>so that women

Men aren't impervious to sexism either.

>Only hire young men in their twenties, and praise the idea of working long hours

Young women are working ridiculous hours as well.

>Child care is for their wives to do.

What child care, most of the highly educated aren't having kids to begin with. (Exaggerating, but it's not the big deal given what most career couples in their 30s make.)

>Pay new grads more than you do women engineers

That's universal as well, not specific to women only. Several companies are overcorrecting by overpaying younger women compared to both the older cohort and their male cohort, too.

Re: How to build toxic software teams

#66
post #58

Retain rockstar programmers at all costs, even if they push everyone else to quit over being mistreated. Give them fancy job titles. Have upper management crack sexist jokes, and HR laugh with them, so that women at the company who are sexually harassed know reporting it will do at best nothing, and at worst risk their own career. Only hire young men in their twenties, and praise the idea of working long hours. Child…

>so that women Men aren't impervious to sexism either. >Only hire young men in their twenties, and praise the idea of working long hours Young women are working ridiculous hours as well. >Child care is for their wives to do. What child care, most of the highly educated aren't having kids to begin with. (Exaggerating, but it's not the big deal given what most career couples in their 30s make.) >Pay new grads more than…

> Men aren't impervious to sexism either.

Men aren't impervious to sexual harassment, that's true. But in my career women have been overwhelmingly on the receiving end. I've seen a woman not be hired by a male interviewer because she was "too hot", I've had one woman tell me she was groped, a number been subject to unwanted sexual advances, and I've seen male staff cat call. I've had a manager massage me out of the blue. It's a gendered problem, the statistics bear this out, and acknowledging that is necessary in order to address it.

> Young women are working ridiculous hours as well.

That's not the point I was making.

> What child care, most of the highly educated aren't having kids to begin with.

That's not the point I was making.

> That's universal as well, not specific to women only.

Again, yes, Not Only Men, but there is a gender component to this that I am acknowledging.

Re: How to build toxic software teams

#67

On a positive note, we just had a sprint retrospective today and the entire team gushed with praises for each other and we all agreed that team morale is great, and that we are accomplishing great things despite all the challenges we had been facing recently. I attribute this to a few things I’ve observed. First, we do have some extremely dedicated engineers who lead by example rather than granted authority. This gar…

[flagged]

Re: How to build toxic software teams

#68
post #2

Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.

If said teammate decides to follow through on his idea without your explicit permission, transfer him to another team ASAP (without his approval). No teammate can show initiative, self-direction, or autonomy. Furthermore, every piece of work must be represented in JIRA and every team member must report on it —- daily. This happened to me recently. Yes, I’m a little salty about it. Although it’s probably for the bette…

> We simply got our work done. Imagine that.

Well what happened? Why did you leave? It sounds great!

Re: How to build toxic software teams

#69
post #63

Earlier quoted context omitted.

If said teammate decides to follow through on his idea without your explicit permission, transfer him to another team ASAP (without his approval). No teammate can show initiative, self-direction, or autonomy. Furthermore, every piece of work must be represented in JIRA and every team member must report on it —- daily. This happened to me recently. Yes, I’m a little salty about it. Although it’s probably for the bette…

In reality I know what you mean, but not a good look for you imo. Imagine that upgrade causes an issue upstream and someone has to explain who approved it. There's always a way to get housekeeping items approved, sneaking it in isn't it.

It was in dev environment which I doubt in his world required any sort of management approval.

Re: How to build toxic software teams

#70

Never require the documentation to be complete and accurate! Neither as a gating criterion for merge requests, nor even as part of a larger effort! This ensures job security for the in-crowd who already knows the code base, and ensures only super-geniuses can later join their ranks.

If someone does contribute tests, nit pick the format and style of the test, vs what the test exercises. Formatting and style and variable naming are the truest ways to ensure project success.

Also, if someone contributes tests, never run them yourself.

Bonus points for making changes in other peoples' code without even running it locally before committing and pushing up.

Post reply on HN