Most of us in software engineering have, at some point, encountered someone who does not see a difference between technical criticisms of a system and personal attacks on its designers and authors. This is an understandable error in a junior engineer, an irritating bad habit in a mid-tier engineer, and a problem in a senior person. In all cases, the answer often winds up being finding a way around them, much as this describes.
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.
I'm well into the senior years of my career, and I have certainly been all of these things. But a fellow engineer taking things personally is not as problematic as the behavior that often accompanies it: never admitting error.
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.
I am well into those years myself, and respectfully, while I agree with the importance of being humble and remembering the incredible challenge of the task, the bozo bit can be very valuable. Not everyone in this industry is a hardworking talented joy operating in good faith.
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.
Why going through all of that (honest curiosity)? 4 people quit and you had panic attacks just to deliver something for a company that didn’t care much. Wouldn’t it have been easier that the whole team left early on? Your mental health would be way better, as well as of your teammates.
When you’re in the thick of it, the fog of war is real.
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.
Thanks for clarifying, and really sorry that you had to go through all of that. As I read, I see that there were many factors at play, some of them personal, some of them cultural -- in my country, the health insurance doesn't depend on employer, for example. But on the other hand, I also saw some people here killing themselves to work, mostly not to let down others.
> 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.
Dunno, I can't speak with certainty that I wouldn't stay and leave, as everything depends on the situation, but switching to a less demanding job and lower pay seems as something that would benefit me in the long run. My mental health and family are worth any price difference, that is, they can't pay me that much to stay in a shitty situation.
In my case, my bozo list is a handful of names that I use to help choose where I will and won't work. If one of these people is at that company, I will decline to accept a position that will subject me to their leadership. Some may see this as arrogant. It certainly assumes I have the privilege of multiple options of employer. It's not generally been my experience that people react badly to this in general, however. I can easily see how it would be much more disruptive when internal to a team.
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.
As someone rounding off 20 years in this industry, I'll advise you that it is a _lot_ smaller than you think. Some of the people I've met or worked with early in my career are big names now due to blogging, writing, starting companies, etc.
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.
There are parts of
our vast industry that aren’t as large, and the “premier” places to work at are only a few big names. Embedded systems comes to mind for me here as does something like chipset design or telecommunications infrastructure, just to name a few examples I can think of
All complex rewarding software jobs but it’s not the same as say, web development, in terms of choices and volume
> How can a handful of names across an entire industry meaningfully affect your career choice?
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.
>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.
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.
You are absolutely right, and I think the author would agree with you. Sometimes there are strong, compelling reasons that justify not changing things.
Inconveniently, sometimes the reason is "a lot of work went into that".
I think your "rule" makes a good 80/20 rule. I'm only mid-career but at this point I have worked with people that I will never work with again. I would accept code from them but as a team member I would insure that there was an impenetrable wall of management between us.
There is no fixing some people.
They want to believe that a single narrow interpretation of something is right, by their own experience. You cannot change their mind. eg There is no multiple inheritance in Java so you aren't going to use Java.
> There is no fixing some people. They want to believe that a single narrow interpretation of something is right
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 have different thought processes from me are great! There's plenty to be learned.
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.
I always try to pounce on negative feedback since it might be the sort of thing other people are thinking too but aren't mentioning out of politeness. If you think about things that way, you'll optimize your way to senior engineer real fast.
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.