41–50 of 145 posts
What is the point of posting this on stackexchange? I found the comments quite childish: > Put your bosses name in that field for every bug. Convince your teammates to follow that practice, then wait how long this nonsense will last. > Quit. No, don't look back. Just... quit. In your resignation letter, put Person to Blame: [Boss's Name] What I would do is try to explain to them calmly and patiently why this is a bad…
What is the point of posting this on stackexchange? I found the comments quite childish: > Put your bosses name in that field for every bug. Convince your teammates to follow that practice, then wait how long this nonsense will last. > Quit. No, don't look back. Just... quit. In your resignation letter, put Person to Blame: [Boss's Name] What I would do is try to explain to them calmly and patiently why this is a bad…
Boss to 'A': what happened ? why the bug ?
'A' to boss: I just checked in the code. It was done by 'B'.
Boss to 'B': hey what happened ? Why the bug ?
'B' to boss: I just merged the code from 'C'.
boss to 'C': hey what happened ? Why the bug ?
'C' to boss: My code worked fine when I unit tested. I gave it over to 'D' to integrate.
boss to 'D': hey what happened ? 'D' to boss: I integrated fine when I did. It is the damn software that might have crashed at the time and code was not integrated properly.
boss to himeself: Fuck it was the damn software.
Sometimes this will go as far as establishing a "war room", possibly for weeks, dragging in people from a number of different areas to address a particular issue.
It's not about pointing the finger or otherwise apportioning blame. It's about learning from mistakes and preventing them from happening again.
That being said, I've worked at other places where shame is attempted to be used in such situations (which is what this is). In my experience it just fosters a hostile environment.
The top answer has it exactly right. This should be Root Cause, since ultimately even bugs caused by human errors are really caused by systemic flaws. Some examples: * SQLite has 1177 times as many tests as code (not a typo) * Live television is broadcast with a 5-10 second delay * IMVU automatically reverts commits pushed to the site if regressions are detected * Netflix implemented a system called the Chaos Monkey,…
I have a feeling it's more like: ; "Oh, it's Bob's fault."
I was a senior manager in an organization where one of my peers essentially inserted a similar blame regime into our incident management process. It is a poisonous practice, but I actually loved my job and wanted to improve the place. So my team fought back. The way that you defeat a system like this is to use it. Be humble, honest and calm, and go out of your way take the hits. But refuse to be blamed for things tha…
And in development there is always somebody else to blame if you look hard enough (because every time a choice is made, it has costs).
Earlier quoted context omitted.
Do more! Practice makes better.
[deleted]
Technical skills can only go so far. It is rare that a person who is a technical master but doesn't appear to be able to participate in a design will succeed. Fortunately, that is easily fixed by getting out there and interviewing (with a bonus of maybe finding a job you love in the interim).
I was a senior manager in an organization where one of my peers essentially inserted a similar blame regime into our incident management process. It is a poisonous practice, but I actually loved my job and wanted to improve the place. So my team fought back. The way that you defeat a system like this is to use it. Be humble, honest and calm, and go out of your way take the hits. But refuse to be blamed for things tha…
That doesn't work when you have somebody like me who would never accept blame if it was to be written in a permanent file, because I know it would end up being used to fuel some KPI. And in development there is always somebody else to blame if you look hard enough (because every time a choice is made, it has costs).