The more blame you try to place the fewer commits you're going to get (and the ones you do get will be larger and full of "defensive code"). Less commits, less often will make the problem worse, not better because the merges will be larger and more painful, and more subtle systemic errors will become the norm.
This is one of those solutions that causes more of the problem its trying to solve. Management will love it.
and if he'd rather check it out in his car, have him listen to John Allspaw and Mike Rembetsy talking about blameless postmortem on the food fight podcast (the relevant part starts around the middle of the show):
http://www.foodfightshow.org/2012/05/episode-14-live-post-mo...
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.
Scott means practice at interviews. Interview regularly, even when you have a job that you love, so when it matters, you are smooth and natural instead of rough and stilted.
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).
Indeed I do, since it sounds like his difficulty with interviews is the social, not technical, aspect of it. And the good news is that just like the technical aspect, you get better at the social the more you do it.
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 github account, publish code, keep a social media profile etc. At the very least, this gets you interview calls.
2. People are not that creative with tech questions. Even Google (at least these days) asks you questions that come out of a textbook. So go through one, say like Skiena's Algorithm Design Manual and solve all the problems on a white board. This sucks a ton because when I sketch out code for a project, I never go do it on a whiteboard. The trick is to get to the stage where you can mentally compose the main blocks of the problem in your head and then writing down the answer on the whiteboard. This means that when you hit the whiteboard with the engineer staring at you from back, you know pretty much what way you want to go at the problem.
2.1. Statistically speaking of the countless interviews I have done, I think a large proportion of questions have been on trees, graphs and dynamic programming. I feel like this is because "some people" think that these are exotic enough that solving these problems have some correlation with smartness. Again, solve a few problems from any textbook on these or maybe go through the TopCoder tutorials on the matter and they start getting as easy as a day to day programming problem.
3. Accept the fact that people are paranoid about false positives and don't really care about false negatives. Sometimes if you have a bad day, it is not you.
4. Someone mentioned this before but interview more. Talk to people you like, you hate and people whom you have no intention of working with. This will help you get over your insecurities and make you realize that interviews are just a game: You will get more confident, and believe me, that helps. (This is just like dating, the more you do of it the more you get better ;-)
4.1 Organize your interviews so that your dream bets are towards the end of your process by which time you will have done so many problems, attended so many behavioral interviews, talked to so many people that you will be absolutely amazing!
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.
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.
I hate stupid algorithmic trivia too! All of my interviews have been giving the person a laptop and asking them to make a very simple app while I watch. For iOS for example, I ask them to make a table view that shows 1 to 5. I let them use documentation and the web too. I ask them to add features if they can complete the app before 30-60m, and the more features the better. I'm totally fine with leaving the room too if they don't like someone looking over their shoulder. I try to do this with something they are skilled with.
Many people can't complete the first item, something that would take me 5-10 minutes. I feel like it's about the equivalent of fizz buzz, but scalable. It also respects their time, since I don't ask them to sacrifice a weekend day to make an app for me or similar and by the end of the interview series and a huddle, they'll have an offer or not.
I can see a match-making service for finding people to give mock interviews being really useful for folks like [redacted] -- People who may be good coders, but their confidence is crappy.
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?
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.
> 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.
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.
Seriously, if that's the case then get the hell out. It's going to stifle your whole career if you stay in a place that is poisonous. And it will kill your confidence (if it hasn't already).
Sorry to hear that. There are a lot of insecure nerds who work in technology and they enjoy making others feel as insecure as they themselves do. The best advice I can give you is to ignore their ridicule (unless you can learn from it), and move on. And don't be like them when you see a young person make a mistake. Make the world a better place.
That is exactly the same situation I was in over a period of years working in a company with someone similar.
In the end I decided that I would do the best job that I could possibly do with the knowledge I had and to hell with the over-inflated opinions of my line manager.
The best seniors are those that answer questions you have, steer you in the right direction and are open to new ideas and suggestions.
Oh, how I know this. The worst part is, this tends to stay with you in other jobs. In takes time to consider the possibility that maybe bringing a new idea to the table isn't a risky affair.
Now, others already advised you to quit the job — but that's obviously not so easy. But be careful, and if you can, find another outlet for creativity, because this can seriously damage both what you can offer to other companies, and how much you'll be able to enjoy any job.
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 was a nice change of pace from the usual pissing contest fare)
Perhaps a beter approach would be "root cause of failure". It's easy to jump all over this guy, but what he's trying to achieve is a good thing. I just don't agree with the tactics.
As one commenter already said: the best way of avoiding blaim is to not make any major modifications or write difficult code. This way you avoid creating bugs. So there is a huge risk that this will reduce productivity.
A root cause analysis should ask "five whys" as to why this happened. Tight schedules, bad specs, improper training? Blaiming everything on the individual who checked the code in is not going to be very accurate, and probably very bad for morale.
Blame the product manager or customers for coming up with the new feature requests. If they didn't give you anything to code, there wouldn't be any bugs.
Although I tend to agree that morale would decline I do not know the full story of the working environment.
If you have an idiot coder that has been there forever and is hard to get rid of then this field would come up in their evaluation. Needless to say it may get overlooked on other peoples evaluation. It may be used as a way to manage some muppet out the company for wasting everyone's time.
But I don't know the full story, the boss may be a control freak and an idiot himself but he may be actually trying to improve working conditions, he just chose the wrong terminology for the field.
I wish bug trackers were better equipped to help find the real root cause of bugs, and more teams actually tried to track that data. Were the specs bad? Is there a problem with our process? Did we not write enough tests? Did someone just screw up?
As it is, bug trackers are good at collecting information and letting you create a process that is as convoluted as you'd like to track the work towards coming up with and releasing a fix, but leave much desired when it comes to trying to reduce your overall defect rate.
That said, trying to pin the blame on someone is the absolute worst way to accomplish any of this, and virtually guarantees that any "root cause" information you try to gather is going to be completely useless.
> I wish bug trackers were better equipped to help find the real root cause of bugs, and more teams actually tried to track that data. Were the specs bad? Is there a problem with our process? Did we not write enough tests? Did someone just screw up?
Some of that comes back to the concept of requirements traceability. Unfortunately it didn't quite make the agile cut. So it's languished in the pre-agile SEng world, locked up in clunky, heinously expensive tools.
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, which randomly shuts
down processes. Ensures the system can survive any failure
* VLC, Unity3D, Windows, 3D Studio Max and many more applications phone
home crashes, which allows developers to quickly patch frequent issues
* Code reviews and pair programming ensure no one person's mistake
can break critical code sections
* Similarly, multiple people should sign off on copy written. For newsletters
and press releases the whole team should, since they can't be withdrawn
* Well designed systems automatically backup, and those backups are
automatically tested, so nothing is deleted forever
Change "who" to "why" and a horrible idea turns into a brilliant one. Well designed systems can reduce the risk of almost any mistake, at the cost of speed and flexibility.
Ultimately it's up to the company to decide where the balance lies, and to live with the consequences. Startups will accept a drastically different risk profile to banks and Fortune 500 companies.
I'm usually arguing against stereotyping management around here, but I find it a stretch to believe a boss who thinks "Person to Blame" is going to be willing to pay the cost for true root cause analysis.
I have a feeling it's more like: <git annotate>; "Oh, it's Bob's fault."
I completely agree with that - the boss in the story sounds like a lost cause. My post was more of a speaking in general kind of thing.
I was going to go off on a tangent about the importance of good management, but I haven't ever had a boss (self employed then startups), so by missing half the picture I didn't really feel qualified.
We actually had a tradition at one of the places I worked at, where someone along the way brought in a trophy and the title was changed to something along the lines of best bug write. Anytime a bug broke the system the trophy was passed to the person that broke the system. It was actually light hearted and effective. We would make a big deal of passing the trophy, but no one wanted that trophy. It was not punitive, but more of a joke, kind of a simple reminder that I don't want to be the guy with the trophy on his desk.
If you tell me to blame someone every time there is an issue, and you don't let me find out why, I'm going to blame you. Because it's your fault as the boss of the department till you let us prove specifically otherwise. That's what responsibility is.
+1 on "root cause" being the field rather than "person to blame".
"person to blame" pre-supposes that the root cause is a person, which is not true in most cases. While programmers do introduce bugs due to oversight, I have seen that systemic issues (build environment doesn't allow for tests to be written, missing patches in legacy architecture, bad staffing decisions etc...) introduce a large percentage of defects, especially in larger projects.
If your manager is really interested in reducing defect injection, you will want to champion root cause analysis (read up on it - Karl Wiegers and others have some some great work on this).
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.
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?
* Well designed systems automatically backup, and those backups
are automatically tested, so nothing is deleted forever
How much software automatically backs itself up? I'm solving this problem with my startup, http://www.restbackup.com/ . I provide online backups that software makers can bundle and sell to users.
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 that aren't your responsibility. Force the problem people to do the same.
That undermines the system, as your putting the problem person in the uncomfortable position of taking responsibility for his actions. The whole point of "blame assignment" is to deflect blame from the golden children.
In my case, the blame regime lasted a few months. It collapses when the person pushing the regime is on the defensive too often.
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).
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).
This is so much better advice than "fight the system", "convince your boss", "use these talking points", etc.
If the poster really wants to keep that particular job, but wants to also improve the environment, they need to start following all of the rules they don't agree with totheletter. The worst thing that can happen is that it actually improves the team somehow.
It's not always the right way to make change, but in these situations it really can be the best route. Bad rules and procedures can only be (officially) recognized as such when they're actually being used. There's no need to make a mockery of this stuff, either, because time will tell whether the new rule is really helping or hurting.
Or they could replace the "person to blame" field with a commit revision. It is less personally offensive as the "person to blame" field and still gets to the same analytic data for reviews.
I do agree a "person to blame" field was obviously implemented by a "management only" oriented person to probably cover his/her own ass. Essentially this is a scorecard to give to his higher-ups to say "Hey look Bob is the one with all the issues, no me".
"Fix the problem, not the blame." - I first heard this in the movie Red October, I think. The other one that come to mind is John Wooden, the famous basketball coach, claiming that he liked players who made mistakes because those were the ones trying to make things happen.
144 comments
[ 3.2 ms ] story [ 111 ms ] threadThis is one of those solutions that causes more of the problem its trying to solve. Management will love it.
and if he'd rather check it out in his car, have him listen to John Allspaw and Mike Rembetsy talking about blameless postmortem on the food fight podcast (the relevant part starts around the middle of the show): http://www.foodfightshow.org/2012/05/episode-14-live-post-mo...
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).
1. Get a github account, publish code, keep a social media profile etc. At the very least, this gets you interview calls.
2. People are not that creative with tech questions. Even Google (at least these days) asks you questions that come out of a textbook. So go through one, say like Skiena's Algorithm Design Manual and solve all the problems on a white board. This sucks a ton because when I sketch out code for a project, I never go do it on a whiteboard. The trick is to get to the stage where you can mentally compose the main blocks of the problem in your head and then writing down the answer on the whiteboard. This means that when you hit the whiteboard with the engineer staring at you from back, you know pretty much what way you want to go at the problem.
2.1. Statistically speaking of the countless interviews I have done, I think a large proportion of questions have been on trees, graphs and dynamic programming. I feel like this is because "some people" think that these are exotic enough that solving these problems have some correlation with smartness. Again, solve a few problems from any textbook on these or maybe go through the TopCoder tutorials on the matter and they start getting as easy as a day to day programming problem.
3. Accept the fact that people are paranoid about false positives and don't really care about false negatives. Sometimes if you have a bad day, it is not you.
4. Someone mentioned this before but interview more. Talk to people you like, you hate and people whom you have no intention of working with. This will help you get over your insecurities and make you realize that interviews are just a game: You will get more confident, and believe me, that helps. (This is just like dating, the more you do of it the more you get better ;-)
4.1 Organize your interviews so that your dream bets are towards the end of your process by which time you will have done so many problems, attended so many behavioral interviews, talked to so many people that you will be absolutely amazing!
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.
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.
Many people can't complete the first item, something that would take me 5-10 minutes. I feel like it's about the equivalent of fizz buzz, but scalable. It also respects their time, since I don't ask them to sacrifice a weekend day to make an app for me or similar and by the end of the interview series and a huddle, they'll have an offer or not.
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.
You can start to overcome this by telling yourself that your are amazing at interviews. Eventually you will start to believe it.
At the end of the day an interview is just explaining why you are awesome, and then getting the interviewer to tell you why their company is awesome.
I hope you can get out of this toxic environment. No one deserves that kind of disrespect.
Also, interviewing is a skill that gets better with practice.
In the end I decided that I would do the best job that I could possibly do with the knowledge I had and to hell with the over-inflated opinions of my line manager.
The best seniors are those that answer questions you have, steer you in the right direction and are open to new ideas and suggestions.
Now, others already advised you to quit the job — but that's obviously not so easy. But be careful, and if you can, find another outlet for creativity, because this can seriously damage both what you can offer to other companies, and how much you'll be able to enjoy any job.
Good luck.
PS. Your boss is stupid.
A root cause analysis should ask "five whys" as to why this happened. Tight schedules, bad specs, improper training? Blaiming everything on the individual who checked the code in is not going to be very accurate, and probably very bad for morale.
If you have an idiot coder that has been there forever and is hard to get rid of then this field would come up in their evaluation. Needless to say it may get overlooked on other peoples evaluation. It may be used as a way to manage some muppet out the company for wasting everyone's time.
But I don't know the full story, the boss may be a control freak and an idiot himself but he may be actually trying to improve working conditions, he just chose the wrong terminology for the field.
As it is, bug trackers are good at collecting information and letting you create a process that is as convoluted as you'd like to track the work towards coming up with and releasing a fix, but leave much desired when it comes to trying to reduce your overall defect rate.
That said, trying to pin the blame on someone is the absolute worst way to accomplish any of this, and virtually guarantees that any "root cause" information you try to gather is going to be completely useless.
Some of that comes back to the concept of requirements traceability. Unfortunately it didn't quite make the agile cut. So it's languished in the pre-agile SEng world, locked up in clunky, heinously expensive tools.
Ultimately it's up to the company to decide where the balance lies, and to live with the consequences. Startups will accept a drastically different risk profile to banks and Fortune 500 companies.
I have a feeling it's more like: <git annotate>; "Oh, it's Bob's fault."
I was going to go off on a tangent about the importance of good management, but I haven't ever had a boss (self employed then startups), so by missing half the picture I didn't really feel qualified.
"person to blame" pre-supposes that the root cause is a person, which is not true in most cases. While programmers do introduce bugs due to oversight, I have seen that systemic issues (build environment doesn't allow for tests to be written, missing patches in legacy architecture, bad staffing decisions etc...) introduce a large percentage of defects, especially in larger projects.
If your manager is really interested in reducing defect injection, you will want to champion root cause analysis (read up on it - Karl Wiegers and others have some some great work on this).
...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
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?
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 that aren't your responsibility. Force the problem people to do the same.
That undermines the system, as your putting the problem person in the uncomfortable position of taking responsibility for his actions. The whole point of "blame assignment" is to deflect blame from the golden children.
In my case, the blame regime lasted a few months. It collapses when the person pushing the regime is on the defensive too often.
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).
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).
If the poster really wants to keep that particular job, but wants to also improve the environment, they need to start following all of the rules they don't agree with to the letter. The worst thing that can happen is that it actually improves the team somehow.
It's not always the right way to make change, but in these situations it really can be the best route. Bad rules and procedures can only be (officially) recognized as such when they're actually being used. There's no need to make a mockery of this stuff, either, because time will tell whether the new rule is really helping or hurting.
Like you say, humble, honest, and calm.
I do agree a "person to blame" field was obviously implemented by a "management only" oriented person to probably cover his/her own ass. Essentially this is a scorecard to give to his higher-ups to say "Hey look Bob is the one with all the issues, no me".
That the records are personal -- they belong to the programmer -- is repeated again and again.
Because when you keep management-accessible records like this, three stages occur:
1. "We won't use this to judge your performance and it will not be connected to reward or punishment".
2. It is eventually connected, directly or indirectly, to reward or punishment.
3. The indicator is gamed.