Live data from Hacker News

It's about what broke, not who broke it

rachelbythebay.com

61–70 of 105 posts

Re: It's about what broke, not who broke it

#61

My manager at work especially has the reverse attitude where the person who broke it is more significant than what broke/how we fixed it/ how to avoid it in the future. I have seen people get taunted for a bug they caused two years ago, a bug which didn't affect any revenue or was pretty easy to fix. And of course it still gets pointed out during appraisals. Its a nightmare, because there's no room for experiment lef…

Im going to say this - When it is all said and done, if you fucked up, you should get some shit for it. However this should be good natured, YOU should be laughing at it and everyone else laughing WITH you.

> if you fucked up, you should get some shit for it

If you're intending that you (and the rest of your team) should learn from your mistakes, then I fully agree

Re: It's about what broke, not who broke it

#62
post #46

It makes sense for a logical perspective, but in practice that's not how it works. In reality if something breaks, and you are stupid enough to mention it, then (a) you are considered an a-hole for blaming even if you didn't and (b) responsible for fixing it. So your main job is somehow make your stuff work despite all the other stuff that doesn't work and all the other people that try to stop you, silently. The less…

"The best hope they have is that you go away by yourself."

I'd recommend you satisfy their hope maximally by running the hell away from that dumpster fire of bullshit office politics.

Re: It's about what broke, not who broke it

#63
Mishaps occur on a spectrum, and may be categorised from mistakes, carelessness, recklessness, through to malicious intent, and any combination of the above all along said spectrum.

Though these categories may seem like they are orientated on individuals' actions, they may be used to determine where the risk lies in systems (and people's use thereof) and how measures can be taken to avoid the same problems being repeated.

Much of the time, the complexity of systems (using the term in the widest possible sense) is under-estimated, and automated integrity checks are not used as religiously as they may be.

Re: It's about what broke, not who broke it

#64

Earlier quoted context omitted.

code rots, whether it is being used in production or not, and should be consistently refactored and updated to accommodate the current status quo

So much so that I don't think "refactoring" should even be a concept - that's what coding is. Every feature, bug fix or change should take into account the new relationships and structure of the model. Leaving refactoring for later is ignoring the fundamental required task of coding.

The problem is that 99.9% of MBA types don't understand what you just said. Worse, they will probably NEVER understand it. In their world, your code is part of an investment. The products in their world, be they software, or whatever, have a cost and that cost is incurred to generate revenue for the company. They don't view software as a living organism, they see it as a cost with a fixed $ attached to it. Maintenance is not a capital expense.

If you begin to understand the world in their terms, you realize why our world is so fucked up. You can also maybe approach them with solutions (at times).

The other problem with MBA types is that it's all about them and their personal arc and career. They routinely take full credit for any of your success while shifting blame at all times to you.

This is how the world is. This is why being a software engineer is an exercise in cognitive dissonance.

Re: It's about what broke, not who broke it

#65

My manager at work especially has the reverse attitude where the person who broke it is more significant than what broke/how we fixed it/ how to avoid it in the future. I have seen people get taunted for a bug they caused two years ago, a bug which didn't affect any revenue or was pretty easy to fix. And of course it still gets pointed out during appraisals. Its a nightmare, because there's no room for experiment lef…

Im going to say this - When it is all said and done, if you fucked up, you should get some shit for it. However this should be good natured, YOU should be laughing at it and everyone else laughing WITH you.

No one has right to demand what I laugh about or not. There is enough shit I have to take regularly to have zero desire to have to pretend laugh to it.

The discussions about everybody mistakes should be open, with emphasis on everybody, but leave mockery out of it. Inform everyone when they make mistakes without mocking them or attacking their egos and keep it factual. Don't assume everyone is friend with everybody nor that everybody is happy, it is not true. The line between laughing at it and with me is thin and oftentimes muddled.

Relaxed laughing at mistakes is result of good teamwork, but you don't get to good work by demanding that people accept being laughed at or mocked.

Re: It's about what broke, not who broke it

#66

My manager at work especially has the reverse attitude where the person who broke it is more significant than what broke/how we fixed it/ how to avoid it in the future. I have seen people get taunted for a bug they caused two years ago, a bug which didn't affect any revenue or was pretty easy to fix. And of course it still gets pointed out during appraisals. Its a nightmare, because there's no room for experiment lef…

We don't touch production. We don't upgrade. We are are a X million company we can't afford the risks. These are some of the excuses they put up. And then they sit 10 years or more with that bad stuff in there, build even uglier ways around it. But the time comes to actually do something about. And what was once a one day job becomes "we will hire a consultancy firm to guide us".

This must be how data leaks/vulnerabilities happen.

Re: It's about what broke, not who broke it

#67
Reminds me of when someone ran "rm -rf /" at Pixar and deleted all of Toy Story 2.

The backups were crap and the only reason it survived was because someone took a server to work from home.

When all was said and done, they never really found who did it, they just made organisational changes to ensure it didn't happen again. No blame game.

Re: It's about what broke, not who broke it

#68

I don't know. Where I work no discernible pattern can be found with the "what" that broke. It's always the same f *ing people that break it though!

It amuses me that the sibling comments appear unable to imagine the possibility that someone is incompetent. Of course there are other possibilities - the people breaking things are doing the hard bits that no one else dare to.

But wouldn't that imply that the "daring, thing-breaking" people are actually incompetent to some degree? Otherwise they would mitigate the risk before performing any dangerous operations on a live system.

"Bravado is no excuse for lack of preparation." - Leeroy Jenkins

Re: It's about what broke, not who broke it

#69
I do a lot of open source work and unfortunately a very common posion is focusing on “who broke it,” which is especially disparaging when done in public. A particularly nasty habit is when outsider Alice opens an GitHub issue saying “xxxx is broken” and developer Bob replies with “yup, @Charlie’s commit fubar’d everything.”

Unfortunately both very demoralizing and very common.

Re: It's about what broke, not who broke it

#70
post #53

I work in the nuclear industry, where most places are pretty good about maintaining a "blame-free" culture. You focus on what processes and procedures failed, what controls were missing, etc., that allowed somebody to make a mistake. As this attitude was adopted, things shifted too far (at least in the opinion of industry groups, and my observation) to the point where people underperforming to the point of negligence…

Well, that's just it, the fact that underperformers aren't recognized is also a symptom of the process, and the fix is fixing the process, not throwing away the process.

Every problem is organizational, even those caused by individuals, because it's the organization's job to recognize and remove those individuals where appropriate.

Post reply on HN