Tell me an engineering murderboard story (2017)
pluspora.com
pluspora.com
> 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.
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.
- 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.
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.
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 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.
In 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.
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?
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.
> "Yes."
> "It means you cannot statically analyze Python code."
Is this a typo, or is my understanding of "manifest typing" incorrect?
> 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