Anything like this automatically makes me reach for a suitable Dilbert reference... oh, here's one - http://dilbert.com/strips/comic/2008-06-02/
My boss decided to add a “person to blame” field to every bug report
81–90 of 145 posts
Re: My boss decided to add a “person to blame” field to every bug report
#82The 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,…
Changing who to why is brilliant. That encourages investigation and understanding of the problem.
Re: My boss decided to add a “person to blame” field to every bug report
#83Earlier quoted context omitted.
That is a toxic work environment, and I'm not sure from verb-tenses if you're still there or not. If you are, find another place to work. Your quality of life will improve.
[deleted]
Beware. If the environment is as bad as it sounds, the issue may get forced on you sooner than later. Something will draw the Eye of Sauron onto your boss and he will need to fire a scapegoat or get blamed himself. As the guy who doesn't give a crap you'll be both threatening and vulnerable. Getting fired can turn out to be a good thing in the long run but it's stressful and best to avoid if possible.
Re: My boss decided to add a “person to blame” field to every bug report
#84People make mistake, 100% of them. People who don't haven't tried hard enough or haven't gone out of their comfort zone often.
Re: My boss decided to add a “person to blame” field to every bug report
#85Earlier quoted context omitted.
[deleted]
Just as the parent post said: Interviews are hard because there is extremely low correlation between what is asked in Interviews and actual job work. I firmly believe the system of asking stupid algorithmic trivia is hackable and should be hacked because it is a broken rotten system that keeps incredibly amazing hackers out. There has been a ton of stuff said about interviews so I will keep this brief: 1. Get a githu…
1. Absolutely.
2. Where did you get the idea that Google asks questions out of a text book? But yes, practicing your whiteboarding skills is a good idea. It comes in handy once you actually work as a team on designs. (I love to sit down and sketch out things for myself, but from a certain problem size on that's largely practical)
2.1 It's a basic filter (and should be part of the phone screening, before you waste a day on interview). A surprising number of people really has trouble understanding even mildly advanced data structures. If (and only if!) those matter in what your company is doing, screen for that as early as possible. Trees do the job.
4. Be careful about that. If you keep interviewing successfully and turning down offers because you like your current place, you are (at least temporarily) closing doors. So be sure to know at what conditions you'd be willing to switch, because you just might get an offer that's hard to refuse.
Re: My boss decided to add a “person to blame” field to every bug report
#86One tradition I really appreciate at Google is the post-mortem. Any serious outage or bug will be followed by a detailed post-mortem detailing a timeline of what went wrong and why. 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 ab…
A good programmer will feel shame from that whole process even if nobody points the finger at them. The blame game just isn't needed. A bad programmer shouldn't work there in the first place, and if they need to be blamed, they're probably doing other things to destroy morale.
If we stay in common sense ranges, a bug is not something you have to shame or proud. It is just part of the working process.
Re: My boss decided to add a “person to blame” field to every bug report
#87The 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,…
While the why is important the who is important as well. In any organization of sufficient size there are going to be B grade developers, or even just young developers. It is important to understand if certain people are writing most of the major bugs. Now there might be a good reason for it such as the difficulty of certain pieces of the application, so bug density is not the only thing to look at. However knowing who is writing bugs that cause outages is very important for proper accountability.
Re: My boss decided to add a “person to blame” field to every bug report
#88[deleted]
Sounds identical to my first job outta college. I knew that some of the senior neckbeards were just toxic people, but at the same time I knew I was really inexperienced so it was hard not to second guess everything I did. In the end I quit (5 years later) but felt like at least I learned a lot about code and even more about people and how to not run a company. Thicker skin too. (p.s. thanks for posting, your comment…
[deleted]
Re: My boss decided to add a “person to blame” field to every bug report
#89Reminds me of a case a friend had at his work. They had a (chinese) subcontractor that failed to deliver the component on time so they asked for a report on why this happened and the how it could be prevented in the future.
They expected a long report with the root causes behind the delay, like unclear specifications, wrong estimation scope, unforeseen technical issues etc. Instead they got back a very short and concise reply: "We will find the guilty, and we will punish them"
Re: My boss decided to add a “person to blame” field to every bug report
#90One tradition I really appreciate at Google is the post-mortem. Any serious outage or bug will be followed by a detailed post-mortem detailing a timeline of what went wrong and why. 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 ab…
At a prior job I was a key member of a team that did a 2 week long, intense root cause analysis of a prod issue that threatened a multi million dollar contract. I consider it one of the most interesting and rewarding things I've done in my career. All obstacles were removed, we could follow the clues wherever they took us, use any resources etc. In the end it took careful analysis, many simulations and hard work to find and fix the root cause, and no fingers were pointed, instead we learned some good lessons and were better for it.
When done right, RCA is a great thing.