5 ms·

I realize this is a bit of a joke, but does anyone else think "blameless" culture has gone a bit too far? I think it's important to stress that everyone makes m

I realize this is a bit of a joke, but does anyone else think "blameless" culture has gone a bit too far? I think it's important to stress that everyone makes mistakes, and that it's okay to make mistakes, but at the end of the day, if someone broke something or caused a bug, they should know about it so it doesn't happen again.

thegeomaster 9y ago
I think you're right. Here's a personal anecdote that leads me to agree with you. During an internship, I fixed some code style issue in a file that I touched for some unrelated reason. The tests had a blind spot just there, and I didn't manually test after the fix, as it was very minor and I couldn't imagine it causing any problems. But it completely broke the feature, and just testing the most basic user scenario would have revealed the screwup. So the bug made it into staging for a 1.5 MAU web application. Fortunately, manual QA caught it early on, so no real damage was done, but while I didn't suffer any serious consequences, people definitely let me know that my actions were irresponsible. That's had a lasting impact on me. I often recall this anecdote when I catch myself thinking "no need to test that, it was a small change", and it's saved my ass a couple of times since. (Of course, better automation is the right way to avoid these kinds of situations, but that's often not attainable in practice due to a number of constraints.)
- gmueckl 9y ago
  I guess every developer has to have that moment of hubris in their career. I remember checking in a seemingly trivial change, telling everybody that it works - only to get told in return that it wouldn't even compile, let alone work when the syntax was fixed! Oops... Sure enough, I became much more cautious after that.
- linuxftw 9y ago
  I don't think your actions were irresponsible. I would assume someone with domain knowledge of the area you changed did a proper code review, especially since you were an intern. If there's not time to write proper tests for code, there's not time for manual testing either. Testing every line of a code change can burn a lot of your time up. Additionally, if a seemingly strange way to do something is necessary for proper function, there should have been a comment in the code to explain why it was doing something in such a particular way.
tomca32 9y ago
Absolutely. I see people saying how "blame" has a terrible name and to use git praise instead. In the end, it's all irrelevant. If you work in a company/team that has a blame and shame culture, you're going to have a bad time regardless of what the git command is called.
- reificator 9y ago
  > If you work in a company/team that has a blame and shame culture, you're going to have a bad time regardless of what the git command is called. I can confirm this can happen even when only two people in the entire department use git or any form of version control at all. In fact I find it even more likely.
- groby_b 9y ago
  Well, since you have no emotions around it whatsoever, and a large chunk of the rest of us likes praise better than blame, there should be no objection to renaming it, right? The point is, on a subconscious level, names matter. Calling it praise instead of blame frames the entire issue, and primes a different kind of reaction. It's subtle, yes. The underlying data is the same, yes. But if a subtle change can make life better - or, at worst, keeps it the same - why not do it?
watwut 9y ago
Where is this blameless culture? The culture I see, especially online, is the one where people jump on any chance to blame others, whether deserved or not.
- matfil 9y ago
  It's real. Not so much online, but within organizations. Goes hand in hand with insisting that all successes and failures are down to "the team", and being reluctant to give much thought to what individuals can and do achieve.
- runlevel1 9y ago
  The "blameless culture" doesn't typically extend outside one's own organization.
blablabla123 9y ago
Yes definitely. Too often I have experienced people taking advantage of that. Like delivering low quality output, knowing that nobody will talk about this. Because when you talk about this, you are the bad person...
- tdb7893 9y ago
  In my experience the blameless culture is supposed to talk about problems but not blame people for them. Maybe it's like agile and people took the idea and implemented something almost opposite of the original intention
elvinyung 9y ago
I think you're conflating two different aspects. Not being publicly named-and-shamed (named-and-blamed?) about it doesn't necessarily imply not being told about it in private. I would describe it as just an logical extension of avoiding ad hominems in a multi-party communication situation.
krebby 9y ago
I've always liked the idea of aliasing "git blame" as "git praise". Makes me feel a bit more warm and fuzzy and focuses on the positive aspects of committing code. To your point, I think we shouldn't be shaming people for a bad commit, but we should help the next coder (or myself 6 months down the line) find the issue and solve a bug in as little time and with as little headache as possible.
gmueckl 9y ago
I used svn blame a lot recently, but never to trace the cause of bugs. I break out the usual tools (debugger and brains) for that. I only resort to blame to understand how a particular odd piece of code came to be (e.g. commented out leftovers that were last touched years ago and forgotten). Even then, I mostly need to see how line changes relate and when they were made. The author is merely a reference of last resort - a pointer to a person who might, with some luck, still remember that he worked on that part. When I find a bug in code that a colleague has written I simply tell him about my changes to it. That keeps him in the loop and gives me a confirmation that my attempted fix should indeed be OK. Of course, in more formal projects, tickets and code reviews would replace that process. Blame is not about assigning blame. The feature has a terrible name because it brings up this undesired association. It is about understanding the lineage of the code.
- jacobevelyn 9y ago
  Totally agreed! I use `git blame` to look into the history of a piece of code but never think about it as actually "blaming" anyone or using it for bug-hunting.
- darrenf 9y ago
  > The feature has a terrible name But in svn the feature is actually called "annotate"; "blame" and "praise" are mere aliases for it. To quote the book[0]: you may find yourself typing svn blame … or svn praise … instead of using the canonical svn annotate command form. That's okay—the Subversion developers anticipated as much, so those particular command aliases work, too! [0] http://svnbook.red-bean.com/en/1.7/svn.tour.history.html#svn.tour.history.browsing.annotate http://svnbook.red-bean.com/en/1.7/svn.tour.history.html#svn...
  - gmueckl 9y ago
    Without looking at the archives, I believe that annotate and praise were introduced well after the initial implementation which used blame as the command. I may be wrong, though.
jondubois 9y ago
It's often too complicated to allocate blame. People tend to get blamed for making small obvious mistakes but usually no one gets blamed for making huge structural or systemic mistakes because they are less obvious. As a software developer, sometimes you can find yourself forced to work around other people's mistakes and it can make your own work sub-optimal. There are times when it's not feasible to fix the problem at the root.
madeofpalk 9y ago
This is the first time I’ve heard of this “blameless” culture, so I’m find it difficult to think anything is going too far.
- skybrian 9y ago
  For example, see [1]. At least as practiced at Google, a "blameless postmortem" doesn't mean nobody learns that something they did was partially responsible for an outage. But the focus is on finding out all the things that should have prevented the outage and fixing them. There's no point in blaming anyone, since they probably feel bad enough about it already. For open source work: you file a bug. You don't call people names. The person who wrote the code is often consulted and may volunteer to fix it, but the focus is on fixing the bug, not blaming people. [1] https://codeascraft.com/2012/05/22/blameless-postmortems/ https://codeascraft.com/2012/05/22/blameless-postmortems/
  - madeofpalk 9y ago
    Somehow I don't think this is what the parent was referring to.
coherentpony 9y ago
Those are two different things. Why are you linking them together?
ehnto 9y ago
The last place I worked was great. If you caused a bug and you were available, then you fixed it, because who else better understands the context you were writing in than you? We had a mutual understanding that a) the work is complex, b) given the opportunity you are smart enough to get it right, and c) sometimes people make small mistakes and that's not a disaster. It gave you the respect of offering the opportunity to learn and be better, and it treated you like the professional you were hired to be by giving you full responsibility.
- hinkley 9y ago
  One of the bad dynamics I see with some coworkers is an inability to accept that they make mistakes. I think it’s important for personal growth of the team for people to connect cause and effect in their actions. I cut a corner and it blew up. Oops. CI was great for this. You break stuff and you find out about it while it’s still floating around d in your short term memory. Unfortunately “CD” as practiced has lost some of that by focusing on automated deployment and forgotten about the operational excellence part.

thegeomaster 9y ago

I think you're right. Here's a personal anecdote that leads me to agree with you. During an internship, I fixed some code style issue in a file that I touched for some unrelated reason. The tests had a blind spot just there, and I didn't manually test after the fix, as it was very minor and I couldn't imagine it causing any problems. But it completely broke the feature, and just testing the most basic user scenario would have revealed the screwup. So the bug made it into staging for a 1.5 MAU web application. Fortunately, manual QA caught it early on, so no real damage was done, but while I didn't suffer any serious consequences, people definitely let me know that my actions were irresponsible. That's had a lasting impact on me. I often recall this anecdote when I catch myself thinking "no need to test that, it was a small change", and it's saved my ass a couple of times since. (Of course, better automation is the right way to avoid these kinds of situations, but that's often not attainable in practice due to a number of constraints.)

gmueckl 9y ago
I guess every developer has to have that moment of hubris in their career. I remember checking in a seemingly trivial change, telling everybody that it works - only to get told in return that it wouldn't even compile, let alone work when the syntax was fixed! Oops... Sure enough, I became much more cautious after that.
linuxftw 9y ago
I don't think your actions were irresponsible. I would assume someone with domain knowledge of the area you changed did a proper code review, especially since you were an intern. If there's not time to write proper tests for code, there's not time for manual testing either. Testing every line of a code change can burn a lot of your time up. Additionally, if a seemingly strange way to do something is necessary for proper function, there should have been a comment in the code to explain why it was doing something in such a particular way.

tomca32 9y ago

Absolutely. I see people saying how "blame" has a terrible name and to use git praise instead. In the end, it's all irrelevant. If you work in a company/team that has a blame and shame culture, you're going to have a bad time regardless of what the git command is called.

reificator 9y ago
> If you work in a company/team that has a blame and shame culture, you're going to have a bad time regardless of what the git command is called. I can confirm this can happen even when only two people in the entire department use git or any form of version control at all. In fact I find it even more likely.
groby_b 9y ago
Well, since you have no emotions around it whatsoever, and a large chunk of the rest of us likes praise better than blame, there should be no objection to renaming it, right? The point is, on a subconscious level, names matter. Calling it praise instead of blame frames the entire issue, and primes a different kind of reaction. It's subtle, yes. The underlying data is the same, yes. But if a subtle change can make life better - or, at worst, keeps it the same - why not do it?

watwut 9y ago

Where is this blameless culture? The culture I see, especially online, is the one where people jump on any chance to blame others, whether deserved or not.

matfil 9y ago
It's real. Not so much online, but within organizations. Goes hand in hand with insisting that all successes and failures are down to "the team", and being reluctant to give much thought to what individuals can and do achieve.
runlevel1 9y ago
The "blameless culture" doesn't typically extend outside one's own organization.

blablabla123 9y ago

Yes definitely. Too often I have experienced people taking advantage of that. Like delivering low quality output, knowing that nobody will talk about this. Because when you talk about this, you are the bad person...

tdb7893 9y ago
In my experience the blameless culture is supposed to talk about problems but not blame people for them. Maybe it's like agile and people took the idea and implemented something almost opposite of the original intention

elvinyung 9y ago

I think you're conflating two different aspects. Not being publicly named-and-shamed (named-and-blamed?) about it doesn't necessarily imply not being told about it in private. I would describe it as just an logical extension of avoiding ad hominems in a multi-party communication situation.

krebby 9y ago

I've always liked the idea of aliasing "git blame" as "git praise". Makes me feel a bit more warm and fuzzy and focuses on the positive aspects of committing code. To your point, I think we shouldn't be shaming people for a bad commit, but we should help the next coder (or myself 6 months down the line) find the issue and solve a bug in as little time and with as little headache as possible.

gmueckl 9y ago

I used svn blame a lot recently, but never to trace the cause of bugs. I break out the usual tools (debugger and brains) for that. I only resort to blame to understand how a particular odd piece of code came to be (e.g. commented out leftovers that were last touched years ago and forgotten). Even then, I mostly need to see how line changes relate and when they were made. The author is merely a reference of last resort - a pointer to a person who might, with some luck, still remember that he worked on that part. When I find a bug in code that a colleague has written I simply tell him about my changes to it. That keeps him in the loop and gives me a confirmation that my attempted fix should indeed be OK. Of course, in more formal projects, tickets and code reviews would replace that process. Blame is not about assigning blame. The feature has a terrible name because it brings up this undesired association. It is about understanding the lineage of the code.

jacobevelyn 9y ago
Totally agreed! I use `git blame` to look into the history of a piece of code but never think about it as actually "blaming" anyone or using it for bug-hunting.
darrenf 9y ago
> The feature has a terrible name But in svn the feature is actually called "annotate"; "blame" and "praise" are mere aliases for it. To quote the book[0]: you may find yourself typing svn blame … or svn praise … instead of using the canonical svn annotate command form. That's okay—the Subversion developers anticipated as much, so those particular command aliases work, too! [0] http://svnbook.red-bean.com/en/1.7/svn.tour.history.html#svn.tour.history.browsing.annotate http://svnbook.red-bean.com/en/1.7/svn.tour.history.html#svn...
- gmueckl 9y ago
  Without looking at the archives, I believe that annotate and praise were introduced well after the initial implementation which used blame as the command. I may be wrong, though.

jondubois 9y ago

It's often too complicated to allocate blame. People tend to get blamed for making small obvious mistakes but usually no one gets blamed for making huge structural or systemic mistakes because they are less obvious. As a software developer, sometimes you can find yourself forced to work around other people's mistakes and it can make your own work sub-optimal. There are times when it's not feasible to fix the problem at the root.

madeofpalk 9y ago

This is the first time I’ve heard of this “blameless” culture, so I’m find it difficult to think anything is going too far.

skybrian 9y ago
For example, see [1]. At least as practiced at Google, a "blameless postmortem" doesn't mean nobody learns that something they did was partially responsible for an outage. But the focus is on finding out all the things that should have prevented the outage and fixing them. There's no point in blaming anyone, since they probably feel bad enough about it already. For open source work: you file a bug. You don't call people names. The person who wrote the code is often consulted and may volunteer to fix it, but the focus is on fixing the bug, not blaming people. [1] https://codeascraft.com/2012/05/22/blameless-postmortems/ https://codeascraft.com/2012/05/22/blameless-postmortems/
- madeofpalk 9y ago
  Somehow I don't think this is what the parent was referring to.

coherentpony 9y ago

Those are two different things. Why are you linking them together?

ehnto 9y ago

The last place I worked was great. If you caused a bug and you were available, then you fixed it, because who else better understands the context you were writing in than you? We had a mutual understanding that a) the work is complex, b) given the opportunity you are smart enough to get it right, and c) sometimes people make small mistakes and that's not a disaster. It gave you the respect of offering the opportunity to learn and be better, and it treated you like the professional you were hired to be by giving you full responsibility.

hinkley 9y ago
One of the bad dynamics I see with some coworkers is an inability to accept that they make mistakes. I think it’s important for personal growth of the team for people to connect cause and effect in their actions. I cut a corner and it blew up. Oops. CI was great for this. You break stuff and you find out about it while it’s still floating around d in your short term memory. Unfortunately “CD” as practiced has lost some of that by focusing on automated deployment and forgotten about the operational excellence part.