My boss decided to add a “person to blame” field to every bug report • Hacker News Board

Re: My boss decided to add a “person to blame” field to every bug report

#101

Post by mseebach » Fri, Jun 29, 2012, 6:48 PM UTC

slurgfest wrote: post #18

[deleted] wrote: post #14

Earlier quoted context omitted.

[deleted]

In interviews, remember never to mention anything negative about your current job no matter how you are treated, because that makes you seem like a negative nancy! Who knows, maybe you will even complain if you are treated poorly at your next job?

> Who knows, maybe you will even complain if you are treated poorly at your next job?

First, hating your job and not quitting for three years speaks A LOT louder than any badmouthing you can do in a 45 minute interview. You're much better off pretending you actually mostly like the place, but you're just not getting challenged like you used to do and it's time to move on.

Second, setting a positive tone is pretty important for any interaction you want to fall out in your favour. "I want this new job for this positive reason" is better than "You guys seem OK, no way you're as bad as the idiots I'm currently working for".

Someone filling a grunt position in a sweatshop mostly cares if you can show up on time - the ass-kissing in interviews is a nice perk. Someone who likes his job wants to hire someone who will like the job (and be good at it) - not someone who will just not hate it.

Re: My boss decided to add a “person to blame” field to every bug report

#102

Post by bconway » Fri, Jun 29, 2012, 6:57 PM UTC

Things like this rarely happen in a vacuum. There is no doubt a much larger issue of responsibility (or lack thereof) going on that led to this drastic action.

But yes, as mentioned, "Root cause" is a better approach.

Re: My boss decided to add a “person to blame” field to every bug report

#103

Post by eshvk » Fri, Jun 29, 2012, 6:58 PM UTC

groby_b wrote: post #85

eshvk wrote: post #68

Earlier quoted context omitted.

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 d…

2. Erm..because I interviewed there and found out the next day that the question I had been asked was an exercise problem in Skiena?

4. Well, I am not suggesting interviewing if you are happily married to your current job. I thought OP was not happy and wanted to interview to get a new one.

Re: My boss decided to add a “person to blame” field to every bug report

#104

Post by gerts » Fri, Jun 29, 2012, 7:01 PM UTC

sseveran wrote: post #87

reitzensteinm wrote: post #32

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,…

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 w…

yes, who wrote the bug

...and who reviewed the bad design

...and who reviewed the bad code

...and who wrote the bad tests

...and who built the spaghetti system that can't isolate failures

...and who pushed new code to production without smoke-testing

...and who demanded the product ship before it was ready

Re: My boss decided to add a “person to blame” field to every bug report

#105

Post by tomjen3 » Fri, Jun 29, 2012, 7:02 PM UTC

rcfox wrote: post #50

tomjen3 wrote: post #48

Earlier quoted context omitted.

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).

Sure, you can spend your time looking for ways to blame other people. Or, you could just go back to getting stuff done.

I do -- because I work in a shop that values getting stuff done.

But if you work in a shop that values covering you ass, then you should cover you ass and not care too much about getting stuff done (and then make a plan to get out of there).

Re: My boss decided to add a “person to blame” field to every bug report

#106

Post by jarofgreen » Fri, Jun 29, 2012, 7:25 PM UTC

Ummm ... so I saw this Q on Stack Exchange before it hit hackers news. There used to be a lot more comments (yes, many of them jokey but still useful, I'd argue). Apparently, at some point after it hit Hackers News it was cleaned up. What do people think about the moderation on Stack Exchange sites these days?

Re: My boss decided to add a “person to blame” field to every bug report

#107

Post by zithtar » Fri, Jun 29, 2012, 7:37 PM UTC

gerts wrote: post #104

sseveran wrote: post #87

Earlier quoted context omitted.

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 w…

yes, who wrote the bug ...and who reviewed the bad design ...and who reviewed the bad code ...and who wrote the bad tests ...and who built the spaghetti system that can't isolate failures ...and who pushed new code to production without smoke-testing ...and who demanded the product ship before it was ready

I'll agree on everything except that last part.

When is the last time in any business you've seen or even heard of non-technical management (including clients) accepting blame for a technical malfunction?

Re: My boss decided to add a “person to blame” field to every bug report

#108

Post by quantumhobbit » Fri, Jun 29, 2012, 7:44 PM UTC

cletus wrote: post #46

One 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…

That sort of sounds like how Morbidity and Mortality conferences at hospitals are supposed to work. It isn't about assigning blame(unless someone really screwed up) but examining the mistake in front of the whole department so that everybody learns from it.

Re: My boss decided to add a “person to blame” field to every bug report

#109

Post by wpietri » Fri, Jun 29, 2012, 7:49 PM UTC

scott_s wrote: post #16

[deleted] wrote: post #14

Earlier quoted context omitted.

[deleted]

Do more! Practice makes better.

Yes! If you ([redacted]) need somebody to practice on, feel free to get in touch. I'm glad to do an interview and then give you feedback.

Re: My boss decided to add a “person to blame” field to every bug report

#110

Post by jaymoorthi » Fri, Jun 29, 2012, 7:53 PM UTC

[deleted] wrote: post #24

slurgfest wrote: post #18

Earlier quoted context omitted.

In interviews, remember never to mention anything negative about your current job no matter how you are treated, because that makes you seem like a negative nancy! Who knows, maybe you will even complain if you are treated poorly at your next job?

[deleted]

Maybe you could build up confidence working on something else -- an open source project, for example -- that has better personal dynamics. You get something to be proud of, a clear demonstration of your skills, and you've helped the community.