3 ms·

This may be true, but when things break people will look for a scapegoat. So when things break, and you are mostly-responsible for initiating the failure, use

This may be true, but when things break people will look for a scapegoat. So when things break, and you are mostly-responsible for initiating the failure, use collective language ("we" and not "I"), frame the failure as a systems failure when you are talking to management or the executives, look cool even if you are feeling stressed out. Manage the narrative! Sure, you flipped the switch or whatever, but try and survive the event. Just because you think its a system's failure doesn't mean other people share this belief, don't volunteer to be thrown off the bus.

ChrisMarshallNY 5y ago
In my experience, working at a "classic" Japanese engineering firm, scapegoating was discouraged. During postmortems, we would often decide something like "Chris made an erroneous assumption that the fix introduced no bugs." (That's a classic "oldtimer" mistake, BTW. I make it all the time -I'm a slow learner). Absolutely no blame would be affixed. It was really important for Chris (that's me) to assume Responsibility for the error, and the team would develop a solution. This being a Japanese company, of course, said "solution" usually ended up being another punchlist item, like "Perform complete regression tests for even the smallest bug fix release," etc. I'm not thrilled with people using "hero programmer syndrome," or "bus factor" as an excuse to write naive or deliberately dumbed-down code, though. Sometimes, a program needs to be maintained by skilled, experienced, well-paid, and motivated people. If a company insists on developing code, using advanced techniques, then turning over maintenance to junior staff, or do a bad job, writing a program, because they want it to be maintained by the absolute cheapest programmers possible, that's a problem.