[gedaxiang]

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.

[gmueckl]

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.

[darrenf]

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

[cornholio]

An interesting case of Poe's law, applied to command lines: an alias made in jest becomes so successful that users are actually using it for the ridiculed purpose fully believing it's the intended use.

[gmueckl]

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.

[darrenf]

It seems the command is listed as `blame` even in the v1.0 book, but does even then have the `annotate` and `praise` aliases. In all the years I used svn I firmly believed annotate was the canonical form and it was the one I always used, so I've learnt something here (about svn, and maybe about myself).

[Arkanosis]

Indeed, both were added in late 2003: - annotate: http://svn.apache.org/viewvc/subversion/trunk/subversion/svn... - praise: http://svn.apache.org/viewvc/subversion/trunk/subversion/svn...

[jacobevelyn]

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.

[racer-v]

I only resort to blame to understand how a particular odd piece of code came to be

Right. The idea of downplaying "blame" in corporate culture isn't to conceal where bugs came from; it's to make it more socially acceptable to confess when you've caused a bug, instead of keeping quiet.

"Blame" culture is when people take your transparency and use it to create a scorecard against you, which can quickly become toxic.

[thegeomaster]

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]

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]

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.

[elvinyung]

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.

[jondubois]

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.

[ehnto]

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]

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.

[watwut]

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]

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]

The "blameless culture" doesn't typically extend outside one's own organization.

[krebby]

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.

[tomca32]

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.

[groby_b]

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?

[reificator]

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

[blablabla123]

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]

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

[madeofpalk]

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]

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/

[madeofpalk]

Somehow I don't think this is what the parent was referring to.

[coherentpony]

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