Years ago I heard the phrase "set to bozo bit" to describe what you're calling a personal blocklist. It was described as an anti-pattern, and setting the bozo bit as a poor choice in nearly every case. It combines the bad parts of an ad hominem attack with the bad parts of personal arrogance and negativity. Don't think your other teammates won't realize you've "blocked" a teammate. Some of them will react badly, and potentially see you as arrogant.
I end with this quote from E.W. Dijkstra:
We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.
ACM Turing Lecture 1972, "The Humble Programmer"
To give a concrete example, at one point in my career, I was leading a team trapped on a death march project. We did not have the option of abandoning it, due to a meaningful fraction of the company’s revenue riding on its success. We did not have the option of more resources for the usual reasons. And we did not have the option of more time, because executives had already de facto announced when it would be done. Unfortunately, our direct upstream dependency in the company saw us as a rival - because they had wanted to own this project - and spent multiple years trying every way they could to sabotage and undermine us, including lying to us in meetings, lying about us to others, changing key system aspects to make our problem harder to solve, denying access to critical resources and people, pitting vendors against each other, and giving unsolicited negative peer reviews to people working on our team.
To say this was a difficult experience would be an understatement. I had four employees quit. I myself started having panic attacks twice a week and was in therapy for over a year to work through the crippling anxiety I was feeling every waking moment. I still have persistent health issues from the incredible stress of those years. We landed the thing, got our pats on the back, and then I quit.
The main guy responsible for this campaign of sabotage and mistreatment was much higher level than me in the company and punching down as hard as he could. He left successfully for a larger role at another company once it became clear that our team was going to hurdle any roadblock he threw at us. It was a knock-down, drag-out fight. I will never do anything like it again.
If I ever found myself working with that person or any of his leads again in any capacity I would quit instantly. The bit is set.
I also agree with the utility of the bozo bit. I worked somewhere where a long time engineer got Peter/Dilbert Principled at just the level of Team Lead. Once you've done four years or so in the org, they don't fire you just motivate you to quit. Anyway, this person gets moved into a Lead role with a team of one person where he can do the least harm. He's awful to work with, can't communicate properly and derails every meeting he's in with complete tangents.
Bozo bit!
It’s hard to overstate how hard it is to leave this kind of project as a manager. You spend years of your life building relationships with engineers and trying (and sometimes failing, admittedly, but trying) to protect them. You know the situation is a disaster and you want to get out of it. But you’re afraid of letting down your people and hurting their careers. You’re afraid the next person won’t be able to protect them as well. You’re afraid of losing the years in your resume and not accomplishing anything. You’re afraid of being a failure if you give up. When your body is breaking down due to the stress, you’re afraid to lose your health insurance.
You’re right - I should have quit as soon as it was clear it was a death march. But in the shit, I found it almost impossible to lift my head up and say “this is literally killing me, I quit”. When each individual day is at your maximum trauma threshold, it’s hard to work up the time, willpower, or ability to interview prep and change companies.
I regret it immensely.
> We did not have the option of abandoning it, due to a meaningful fraction of the company’s revenue riding on its success. We did not have the option of more resources for the usual reasons. And we did not have the option of more time, because executives had already de facto announced when it would be done.
And immediately concluded that the company has already committed to suicide and it's time to start sending resumes. Cross-team sabotage is icing on the cake but actually doesn't change anything here.
And unless you live somewhere where new jobs are available that match your skills and current pay that can be enough.
That said, I have seen whole teams set the bozo bit on other parts of the organization. For example, I saw the head of an infrastructure group refuse to maintain or patch key services while insisting on ownership. The security organization set the bozo bit on this person and worked to protect the organization from the consequences of their choices. As an organizational tool, it can be a useful caution about known bad-faith actors.
As to your broader point, I think you're correct. Programming is difficult, error-prone, and thus benefits from an intellectual humility. Approaching it with the mindset that you are incapable of error makes this much more challenging.
Is this some close knit "paypal mafia" corner of the industry where people only work with people they already know?
When I interviewed for my current job, it turned out that I had separate, personal, previous-work-experience connections to all four of my interviewers and it only surfaced during each of the interviews.
And this is after changing my role/specialty.
----
And along these lines, be careful who you shit on in this industry and be default-nice to everyone. I'll never forget one role I had that was fully remote where I was mentoring a guy who was a bit on the weaker side technically for the job that we were doing. Everyone else was constantly telling him that he sucked and was pushing him to quit.It turns out that he was learning the ropes to transition to a huge leadership role in the company and no one knew it. He had previously led an entire division of a massive computer manufacturer, but 2008 wiped out most of his retirement and he had to come back to work. The very first thing that he did with his new responsibility once his role was announced was to give me a huge promotion to work directly under him with no interview.
All complex rewarding software jobs but it’s not the same as say, web development, in terms of choices and volume
I've found myself approached by recruiters for the exact large company and sizable department that one of these people has substantial rank in. It's already had an impact on my decisions.
You are saying this as a senior engineer who is in a better position to do something else about being on the receiving end of those personal attacks. I respect that and I hope you are able to keep doing it. But that isn't the case when the abuse is continuing over a long period of time, that means no other senior person stepped up to do anything about it, and the people on the receiving either have to quit, or risk getting fired for "insubordination" because they filed a complaint against a senior employee. Playing the office politics game and trying to avoid the abusive employee is not sustainable, as you've acknowledged.
I was mildly troubled by the comment towards the end, "There were third- and fourth-generation members who I had no idea about who had signed up to talk about reliability without being second-guessed to death and hounded by people who just wanted to talk about [...] "a lot of work went into that"."
I've been sensitized, I guess. Yes, the way we do things is probably stupid. Yes, your favorite new framework or method or language or whatever might trivially fix all the problems that you can see. Heck, you might even be the smartest person in the room. But, there might also be a reason things things are stuck at a historical, local maximum.
Inconveniently, sometimes the reason is "a lot of work went into that".
How would I not be doing the same thing if I looked at other people as needing to be "fixed" any time their thought processes don't work exactly like mine?
People who are Always Right and who believe that anyone who disagrees or sounds like they might be disagreeing is Always Wrong and must be shouted down... those people are not worth fixing. I assume these people are what GP is talking about.
And yes, those people are real. Quite rare, but real, and a major pain in the ass to route around.
Always assume that it is possible for you to be wrong. Even if you think you are not wrong... just consider what the world might look like if you were wrong, and you'll be fine.
It's not personal. It's strictly business.
I've been places where such people have found their way to technical leadership. Finding ways to improve things can rapidly become exceptionally difficult.
At this point my only way forward is to have a personal blocklist of people whose technical leadership decisions I refuse to ever be subject to again. It's a shame, because some of them are also brilliant engineers.