First, if you do the work never resign simply because someone made you feel like your best wasn't good enough. Second, if you are on the verge of resigning or breaking down due to the culture then you should request some time off to seek out counseling. People may die if something doesn't work but it doesn't sound like the company was paying you like it was critical to human life. Therefore, if anyone screwed up it was management and sales for not demanding more money and more time.
Valuing yourself and setting boundaries will prevent this precise outcome in all but the most extreme cases (where you probably need to do more than just leave, because if the abuse is that extreme it becomes criminal).
You can set boundaries all you want, some people will still stomp all over said boundaries anyways - either because they do not care, or because they cannot help themselves, or think they're in the right for doing so - and those people are often well versed in doing so without running afoul of the law, HR, or your coworkers. Being merely persistently unpleasant to be around is not a crime.
Especially when setting boundaries with those who hold power over you, often the most leverage you have is a BATNA and the ability to leave for greener pastures, and the willingness to exercise said ability should they choose to call your "bluff".
I won't say leaving will necessairly be your first tool, but it'll certainly be an important one, and one that might be worth using well before things get to criminally extreme cases.
If you get fired, you can apply for unemployment. A company that is going to fire you for setting boundaries or requesting time off due to toxic culture is the same type that will bad mouth you if you resign.
These companies and groups will attempt to destroy your reputation no matter what if you are not properly submissive. Whether they fire you or you resign. Or even when you stay with them.
On one hand, the murderboard guy raised the kind of valid concerns that make an engineer great.
On the other, I really don't like units that pride themselves on being difficult to the point of abuse. It's often glorified in film, but completely unnecessary in real life. You can have high standards without being mean.
I’m working for a customer at the moment that has a rather intense review board. It’s “difficult” because it’s thorough and is supposed to be rather confronting in regards to design compromises or any oversights that might be discovered. But how you feel about that I think is a matter of perspective, I don’t think there’s any animosity involved. Personally I think every intense review session I have makes me better at my job. The most frustrating thing that can happen is when a significant controversy arises during the review session (which is pretty much what the author is describing in their), but this usually only results from a failure in stakeholder management (which seems to be the general lesson the author took from their experience).
Just don’t be apprehensive about failing in front of an audience, don’t excessively defend or justify mistakes, and then these types of processes become rather easy going.
> You can grill someone without bringing them to tears
Perhaps the reviewers in the OPs story could improve their tone a bit, but I really don't think this assertion is true at all. Fear of failure, fear of having your failures exposed, and fear of confrontation are all incredibly commonplace. A thorough review is always going to expose "failures" on some level, even if they were necessitated by project constraints. People who struggle with those fears will always find that kind of process incredibly difficult, regardless of the demeanour of the reviewers. I would even suggest that overcoming those fears and anxieties is a rather fundamental part of the human condition in general.
The title and the final sentence of the first paragraph made me think I'd be happier not reading on. Anyone braver than me want to summarize what I'm missing or just tell me it's as depressing as I assume.
Seems like the problem is either on the authors end, or the specifics of how things were said in the meeting.
He outlines a situation where a life-critical project undergoes technical review.
The reviewers raise various reasonable concerns which reflect the sort of thing that gets raised when a company gets sued after a fatal incident (e.g. a car crash caused by an ECU error). Presumably this is done to document a reasonable excuse so that they have something to tell the court after the project staff have moved on.
With these excuses recorded, the project is approved, although the boss expresses concerns.
The author takes the process as personally insulting, "shaking with anger and reduced to tears".
I've had miserable situations where change stays in code review for weeks over disagreements on doce formatting. I've had design documents bounce of a board again and again because one board member wants his own team to have the first shot at the project and needs to hold me off until their spec is done. Those are miserable.
This just sounds like a company systematically covering it's ass and doing a thorough review to avoid killing people.
Concluding, I suspect the author has an ego problem, but he maybe implies that the objections raised were presented to him unpleasantly. Although I don't, for instance, see any personal insults in what he reports, so I lean towards ego issue.
I think it's a bit more nuanced than that. I've gone through a similar "murderboard" experience during my Ph.D. jury. I've been put down, borderline insulted, people knowing me personally behaved like they're my enemies knowingly.
I can understand my code and design decisions put through its paces. I can understand my writing is criticized. Jury is for that, and corrections are for improvements.
But implying that I'm a stupid, incapable human being just because I didn't write a paragraph about something which can be inferred from a graph easily, or my code is inferior because I didn't use that library but, my code's running almost as fast as the leading code (almost: 99% of the performance) with a much easier to maintain libraries.
Or to put it another way, it wouldn't hurt a jury or a murderboard to point the problems in a nice, but firm manner, both making the points more prominent and learning a lot of respect in the process.
We're humans at the end, we're doing stressful things. Removing extra personal abuse and fuzzing from the equation will just improve things, across the board.
Sounds like shitshow management with hazing rituals thrown in for good measure.
If DoE approval is needed on the final result, why not save everyone time and stress by having the lead developer discuss with and get sign off from the DoE before starting the project? Then if the director thinks C should be used instead of Python, fine, you're not going to get a nasty surprise at the end once the damn thing is near done.
> if the project failed in a production environment it would be a “go home, stare at a revolver, wonder if you should use it” situation.
Oh mate, you are taking your job too seriously. You should go and do 100% of what you can, and if the project still fails, hey it wasn't your fault. Some tasks are FUBAR before they arrive at your desk and there is no point in worrying about that.
> “Why were you using Python?” the Director of Engineering asked.
Why are you asking that after the project is done? What kind of twisted upside down world is where this question is appropriate at that point? I don't know what exactly a Director of Engineering is expected to do at that joint, but if this question even comes up after development that means that they are very hands-off and the company doesn't have the right processes.
> “Yeah, well. Murderboard.” DirEng shrugged.
Oh jees. That level of casual indifference. They are probably even proud of their terrible processes.
I couldn't quite understand why the answer to the "Why were you using Python? question wasn't "We carefully assessed the client's ability to maintain and use the code - which is a critical requirement..."
Seriously, what the fuck. There is no good part to this story. If I'm the Director of Engineering and I have to deliver a project and I find out at the last minute that they've been doing it wrong for months, it's my fault and nobody else's.
If it's fine, why would I chew an employee out? This story is fucked up (not just screwed up).
I mean, presumably that's why it's called "murderboard".
This reminds me of the old BOFH stories. There's a lot of casual verbal brutality in older engineering/ops cultures, that's why people invent things like "#hugops" to try to soften it a bit. It is not how things should be done in 2021.
> Oh mate, you are taking your job too seriously. You should go and do 100% of what you can, and if the project still fails, hey it wasn't your fault. Some tasks are FUBAR before they arrive at your desk and there is no point in worrying about that.
Agreed. This is exactly the type of person that shouldn't be working on these types of projects.
Yes, take the job seriously. Yes, feel responsible for your own actions. But don't assign all blame to yourself before you even start. Treat yourself as you treat others.
Hmmm, another red flag. Knowing the difference is just as important as naming it correctly IMHO; it demonstrates both familiarity and reasonable investment, the combination of which reassure me that there is soundness of judgement and competence.
The director of engineering was just an unprofessional asshole here. There is no legitimate reason to ever bully anyone in a professional setting, let alone reason to ever make them cry.
This company is a WTF and I would not want to work with that Director of Engineering for the sake of my own quality of life.
I see an organizational failure here. If management were paying attention and had processes set up from the beginning:
- The output of the meeting with the clients' ops team would not just decide that Python was the right language, but communicate that to the director of engineering immediately. The question would not need to be raised again.
- The spec ambiguity would be captured in a written bug, the bug would be resolved with "talked to tech rep, received this guidance".
- A final critical review meeting should be about how well the program works, how well the documentation is written, what last-minute changes the client is asking for that are delivery requirements and which ones can be handled in a subsequent release.
Calling the process a Murderboard is the first strike. The DirEng not being involved in the design for a project this critical is the second strike. The DirEng being antagonistic in the meeting is the third. Three strikes and you should be out, for your own health and sanity.
I have been in process meetings where we went over what went right, and what didn't, and how we can do better in the future. They were called retrospectives. I have once also been in a meeting, after the project failed (due to funding/requirements mismatch), to determine why. Even that was called a post-mortem, and that name also didn't sit well. It's insensitive, and there's no good reason.
I will tell you this was kind of normal in the 90's and early 2000s at enterprise settings.
For what is worth, maybe it is still the same, but I managed to get away from those kind of companies a long time ago.
> And if you screw up? The storage array will run our of space and data will get dropped and people might die. Or you’ll delete data before the system is done with it and people might die.
personally I don't think any situation with life on the line should be considered "small" or have any fewer then 3 people on it
"And is static analysis a non-negotiable requirement of life-critical code?"
I started grinding my teeth to slivers. "Normally yes."
I feel like this story is missing something. If static analysis is a non-negotiable requirement, shouldn't he have had to get explicit approval from higher-up before using Python?
38 comments
[ 2.8 ms ] story [ 105 ms ] threadIn such situation, it is fairly good guess that counseling will teach you to value yourself, set boundaries and leave culture that is abusing you.
Valuing yourself and setting boundaries will prevent this precise outcome in all but the most extreme cases (where you probably need to do more than just leave, because if the abuse is that extreme it becomes criminal).
Especially when setting boundaries with those who hold power over you, often the most leverage you have is a BATNA and the ability to leave for greener pastures, and the willingness to exercise said ability should they choose to call your "bluff".
I won't say leaving will necessairly be your first tool, but it'll certainly be an important one, and one that might be worth using well before things get to criminally extreme cases.
On the other, I really don't like units that pride themselves on being difficult to the point of abuse. It's often glorified in film, but completely unnecessary in real life. You can have high standards without being mean.
In any case, this was an excellent story.
Just don’t be apprehensive about failing in front of an audience, don’t excessively defend or justify mistakes, and then these types of processes become rather easy going.
Perhaps the reviewers in the OPs story could improve their tone a bit, but I really don't think this assertion is true at all. Fear of failure, fear of having your failures exposed, and fear of confrontation are all incredibly commonplace. A thorough review is always going to expose "failures" on some level, even if they were necessitated by project constraints. People who struggle with those fears will always find that kind of process incredibly difficult, regardless of the demeanour of the reviewers. I would even suggest that overcoming those fears and anxieties is a rather fundamental part of the human condition in general.
He outlines a situation where a life-critical project undergoes technical review.
The reviewers raise various reasonable concerns which reflect the sort of thing that gets raised when a company gets sued after a fatal incident (e.g. a car crash caused by an ECU error). Presumably this is done to document a reasonable excuse so that they have something to tell the court after the project staff have moved on.
With these excuses recorded, the project is approved, although the boss expresses concerns.
The author takes the process as personally insulting, "shaking with anger and reduced to tears".
I've had miserable situations where change stays in code review for weeks over disagreements on doce formatting. I've had design documents bounce of a board again and again because one board member wants his own team to have the first shot at the project and needs to hold me off until their spec is done. Those are miserable.
This just sounds like a company systematically covering it's ass and doing a thorough review to avoid killing people.
Concluding, I suspect the author has an ego problem, but he maybe implies that the objections raised were presented to him unpleasantly. Although I don't, for instance, see any personal insults in what he reports, so I lean towards ego issue.
I can understand my code and design decisions put through its paces. I can understand my writing is criticized. Jury is for that, and corrections are for improvements.
But implying that I'm a stupid, incapable human being just because I didn't write a paragraph about something which can be inferred from a graph easily, or my code is inferior because I didn't use that library but, my code's running almost as fast as the leading code (almost: 99% of the performance) with a much easier to maintain libraries.
Or to put it another way, it wouldn't hurt a jury or a murderboard to point the problems in a nice, but firm manner, both making the points more prominent and learning a lot of respect in the process.
We're humans at the end, we're doing stressful things. Removing extra personal abuse and fuzzing from the equation will just improve things, across the board.
If DoE approval is needed on the final result, why not save everyone time and stress by having the lead developer discuss with and get sign off from the DoE before starting the project? Then if the director thinks C should be used instead of Python, fine, you're not going to get a nasty surprise at the end once the damn thing is near done.
> if the project failed in a production environment it would be a “go home, stare at a revolver, wonder if you should use it” situation.
Oh mate, you are taking your job too seriously. You should go and do 100% of what you can, and if the project still fails, hey it wasn't your fault. Some tasks are FUBAR before they arrive at your desk and there is no point in worrying about that.
> “Why were you using Python?” the Director of Engineering asked.
Why are you asking that after the project is done? What kind of twisted upside down world is where this question is appropriate at that point? I don't know what exactly a Director of Engineering is expected to do at that joint, but if this question even comes up after development that means that they are very hands-off and the company doesn't have the right processes.
> “Yeah, well. Murderboard.” DirEng shrugged.
Oh jees. That level of casual indifference. They are probably even proud of their terrible processes.
While I can only speak for myself, if I'm getting talked at the way this guy was being talked at, I'd probably forget the requirements too.
If it's fine, why would I chew an employee out? This story is fucked up (not just screwed up).
This reminds me of the old BOFH stories. There's a lot of casual verbal brutality in older engineering/ops cultures, that's why people invent things like "#hugops" to try to soften it a bit. It is not how things should be done in 2021.
Agreed. This is exactly the type of person that shouldn't be working on these types of projects.
Yes, take the job seriously. Yes, feel responsible for your own actions. But don't assign all blame to yourself before you even start. Treat yourself as you treat others.
> "Yes."
> "It means you cannot statically analyze Python code."
Is this a typo, or is my understanding of "manifest typing" incorrect?
This company is a WTF and I would not want to work with that Director of Engineering for the sake of my own quality of life.
- The output of the meeting with the clients' ops team would not just decide that Python was the right language, but communicate that to the director of engineering immediately. The question would not need to be raised again.
- The spec ambiguity would be captured in a written bug, the bug would be resolved with "talked to tech rep, received this guidance".
- A final critical review meeting should be about how well the program works, how well the documentation is written, what last-minute changes the client is asking for that are delivery requirements and which ones can be handled in a subsequent release.
I blame management, the whole way.
I have been in process meetings where we went over what went right, and what didn't, and how we can do better in the future. They were called retrospectives. I have once also been in a meeting, after the project failed (due to funding/requirements mismatch), to determine why. Even that was called a post-mortem, and that name also didn't sit well. It's insensitive, and there's no good reason.
> And if you screw up? The storage array will run our of space and data will get dropped and people might die. Or you’ll delete data before the system is done with it and people might die.
personally I don't think any situation with life on the line should be considered "small" or have any fewer then 3 people on it
I started grinding my teeth to slivers. "Normally yes."
I feel like this story is missing something. If static analysis is a non-negotiable requirement, shouldn't he have had to get explicit approval from higher-up before using Python?