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.
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.
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!
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.
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.
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).
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
> 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.
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...
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
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.
The difference is, this one's focus is on stealing credit for others' work -- it squashes a branch into one commit under your name, and backdates it five minutes.
Someone submitted "git blame-someone-else" on another thread, where you give someone else the credit for your own commits, and yes I plugged my project on that one too:
Hey HN! Thanks for all the interest! I have somewhat spotty internet now but feel free to ask any questions and I'll do my best to answer them when I can!
Rather than just the author of a line of code, I want git or something git like that allows you to attach commentary to bits of code. For one thing that would allow you to preserve the code reviews but there are bigger reasons for this.
In every code base there are at least three generations of styles in the code. The way we want people to write code, the way we used to write it, and the things we wanted the old way to replace. You know, the really terrible code.
I find myself from [time] to time wishing I had a way to durably attach commentary to a block of code that doesn’t result in a wall of text and which can’t easily be pruned off in a refactor or a cut and paste.
In every team there are people who cut and paste idioms from code they are familiar with into new code. And the code people are [most] familiar with is often the old old way.
Hey there! This is a really neat idea, and I've been kicking around some semi-similar ideas for a while now but haven't done anything with them. Let me know if you want to bounce around some ideas!
Not in the spirit of the project but I would like to see an alias added to the README to replace `git blame` (to run on your own / teammates / friends computers).
So even if this script is the absolute first thing in your $PATH, `git blame` will always call the builtin rather than this. There are probably more involved ways to make this happen the way you want (like create a different `git` program that shells everything out to the real one except the `blame` command) but I wasn't sure I wanted to go down that rabbit hole.
Feel free to submit a PR if you find a simpler way though!
If they're using bash, it shouldn't be so hard. Just put something like this in your/their bashrc
git() {
if [[ $1 == blame ]]; then
shift
git self-blame "${@}"
else
command git "${@}"
fi
}
edit: this isn't 100% perfect as it won't work (but won't break git either) in situations where the user uses a global flag in addition to blame. I've been using git for years though and the only global flag I've used are --version and --help
Awesome, thanks for sharing! My Bash skills definitely have lots of room for improvement—I think I learned at least three new things from your comment alone. :)
I too had never really used global git flags until they came in very handy for `git self-blame`!
I appreciate the time you took to document your journey in the source file. In most github repos, all we see is the end result of hours or days of work (especially when authors blow away their commit history by squashing prior to to sharing), and the comments that explain everything you tried that /didn't/ work are just as illustrative and educational as knowing what does work.
Thanks, I appreciate the kind words! (And I'm glad at least one person actually read through that.)
In this case, I think I was "helped" by the fact that I consider myself relatively inexperienced with both shell scripting and advanced git usage. This gave me an irrational fear that I would publish this repo and get lots of "why didn't you just do X" responses, so writing down my journey was at least one way of showing that I actually tried a few different approaches and while my eventual solution may not be the best I know it's not the worst :)
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]:
[0] http://svnbook.red-bean.com/en/1.7/svn.tour.history.html#svn...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.
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?
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.
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://github.com/SilasX/git-upstage
The difference is, this one's focus is on stealing credit for others' work -- it squashes a branch into one commit under your name, and backdates it five minutes.
https://news.ycombinator.com/item?id=11049993
As a side note, if you're interested in this sort of thing I also wrote out the steps I went through to build this: https://github.com/JacobEvelyn/git-self-blame/blob/master/gi...
In every code base there are at least three generations of styles in the code. The way we want people to write code, the way we used to write it, and the things we wanted the old way to replace. You know, the really terrible code.
I find myself from [time] to time wishing I had a way to durably attach commentary to a block of code that doesn’t result in a wall of text and which can’t easily be pruned off in a refactor or a cut and paste.
In every team there are people who cut and paste idioms from code they are familiar with into new code. And the code people are [most] familiar with is often the old old way.
So even if this script is the absolute first thing in your $PATH, `git blame` will always call the builtin rather than this. There are probably more involved ways to make this happen the way you want (like create a different `git` program that shells everything out to the real one except the `blame` command) but I wasn't sure I wanted to go down that rabbit hole.
Feel free to submit a PR if you find a simpler way though!
I too had never really used global git flags until they came in very handy for `git self-blame`!
Just rename/symlink git-blame-bob to git-blame-joe
In this case, I think I was "helped" by the fact that I consider myself relatively inexperienced with both shell scripting and advanced git usage. This gave me an irrational fear that I would publish this repo and get lots of "why didn't you just do X" responses, so writing down my journey was at least one way of showing that I actually tried a few different approaches and while my eventual solution may not be the best I know it's not the worst :)
There you go, forked the project and replaced the "$name" with empty spaces.
You would need to rename the from "git-self-blame" to "git-no-blame" though, I can't do it with github at the moment