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.
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!
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.
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.)
Sure enough, I became much more cautious after that.
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.
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.
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.
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.
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.
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.
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?
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/