This article first appeared on the Triplebyte blog and was written by Joseph Pacheco. Joseph is a software engineer who has conducted over 1,400 technical interviews for everything from back-end, to mobile, to low-level systems, and beyond. He’s seen every quirk, hiccup, and one-of-a-kind strength you can think of and wants to share what he’s learned to help engineers grow.
You can be blamed for every line of code you commit. That's the message of one of the most popular tools in software engineering.
Our profession is fundamentally creative and collaborative. Yet with Git being used everywhere, so is the negatively-framed git-blame command, a system feature that tracks down who merely contributed a line of code — buggy or not. My issue here is not about sensitivity (or oversensitivity). The blame command is bad for business, not to mention our individual growth trajectories as engineers.
Related: The insanely common algorithms mistake you're probably making in interviews
In Case You Don’t Know Git-Blame
For those of you who don't know, Git is a tool software engineers use to keep track of different versions of their code. This "version-control system" is the hottest one out there; all the cool kids use it. If you want to know who last changed a particular chunk of code, you use Git to run a special command. That command is called "blame." In other words, you don't ask who the author is, you ask who's to blame for a particular contribution.
‘Blame’ Is a Pretty Negative Word
On one hand, the use of the word "blame" for this command is kind of cheeky. It can evoke seemingly harmless, competitive play. But there's no beating around the bush: It's a fundamentally negative word. The Oxford dictionary defines it as "assigning responsibility for a fault or wrong." Playful name or not, it's one of the most frequently used commands in all of software engineering. Do we really want to be referring to all code contributions as a potential fault or wrong? Even well-intentioned, this kind of repeated negativity could have some serious consequences on the bottom line (for engineers and the company or team they work with).
Blame Is the Right Hand of Shame
I remember the first time I learned about the blame command. It was one of my earliest jobs as a software engineer. There was a bug in the code that was impacting some users, and a senior engineer and I were trying to find the problem. We finally narrowed it down to a few lines. He invoked git-blame, and there was my name on the screen.
Let me just say, I was already pretty insecure as a very junior engineer. But when I saw my name was to “blame,” the pang of sheer anxiety I felt was next-level. My veins were flooded with cortisol, and I was suffocated by shame. The bug itself was stressful enough. Users were being impacted by something I did. But this direct (and public) association with this shame-inducing label was the icing on the cake. At that point, my ability to contribute productively was reduced to dust. I was in no position to learn about debugging or be actually helpful. I just quietly ate my feelings and got through the next few hours sub-optimally.
Shame Stifles Innovation
I do not believe emotional discomfort needs to be avoided at all costs. It's one of the primary catalysts of human growth. Even in the above situation, I was able to grow and become a more hardy version of myself. I just think shame has no place in the workplace because it's profoundly bad for business, particularly if it's invoked on a regular basis.
Brene Brown is a research professor at the University of Houston and perhaps the world's leading expert on shame and vulnerability. In her best-selling book, Daring Greatly, she quotes Peter Sheahan, the CEO of global consultancy Karrikins Group. He explains:
The secret killer of innovation is shame. ... Every time someone holds back on a new idea, fails to give their manager much needed feedback, and is afraid to speak up in front of a client you can be sure shame played a part. That deep fear we all have of being wrong, of being belittled and of feeling less than, is what stops us taking the very risks required to move our companies forward. ... Shame becomes fear. Fear leads to risk aversion. Risk aversion kills innovation.
Even Seeing Negative Words Can Kill Performance
If you're not sold on this narrative so far, that's fine. I've got some other data that will blow your mind. Christine Porath is a researcher at the University of Nevada who designed a very clever experiment about the power of words on productivity. At the 5:17 mark of her TED Talk, she explains:
Incivility is a bug. ... It even affects our attention and can take some of our brainpower. And this happens not only if we experience incivility or we witness it. It can happen even if we just see or read rude words. ... To test this, we gave people combinations of words to use to make a sentence. But we were very sneaky. Half the participants got a list with 15 words used to trigger rudeness: impolitely, interrupt, obnoxious, bother. Half the participants received a list of words with none of these rude triggers. And what we found was really surprising, because the people who got the rude words were five times more likely to miss information right in front of them on the computer screen. And as we continued this research, what we found is that those that read the rude words took longer to make decisions, to record their decisions, and they made significantly more errors.
That's right, folks, just reading negative words in a list — even when not directed at the reader personally — was shown to decrease quality of work by 500%. These words "hijack performance" at a lizard-brain level. Now, the blame command is often invoked when debugging, and debugging requires lots of cognitive power and attention to detail as it is. I wonder how seeing a negative word repeatedly, let alone one potentially directed at you personally, impacts one's ability to debug effectively. I would guess it's pretty bad. And this is bad not only for the company, but for engineers who are trying to progress in their careers and skills.
Positive Words Have the Opposite Effect
Again, I'm not arguing that we should rewrite every source of emotional discomfort in our lives. But if we can do something that materially improves our ability to grow and achieve our goals, why not do it? As it turns out, changing the blame command would not only dissolve negative influences, but it could potentially add actively positive value.
This article from inc.com explains:
According to Andrew Newberg, M.D. and Mark Robert Waldman, co-authors of the book, Words Can Change Your Brain, "a single word has the power to influence the expression of genes that regulate physical and emotional stress" and can kickstart the brain's motivational centers.
Fortunately, there are about a million easy alternatives that have a markedly more positive twist:
- git credit
- git who
- git author
- git contrib
- git collab
- git comrade
Any one of these would turn the negativity of the blame command entirely on its head.
Aliasing Is Not the Answer
Now, you may be thinking, why not just create an alias? Nobody is forcing anyone to use the blame command. It’s possible to turn git-blame into anything you want: git-unicorn, git-rainbows, git-ninja, git-jedi. We even have git-annotate already set up, which does basically the same thing as git-blame. And Subversion (a.k.a. the other huge version-control system out there) gives you three options: svn-blame, svn-praise, or svn-ann. So what’s the problem?
The problem is that git-blame is the default. The overwhelming majority of engineers use git-blame simply because it’s the default. And they will continue to do so. If git-blame was just a preference that had a net-neutral impact on everyone, I’d say the onus is on each user to customize the choice that’s best for them. But since git-blame is actively negative (and has been known to terrorize junior engineers like I was), I see no reason why the change shouldn’t come top-down to give us a replacement that's fundamentally constructive.
Next Steps
There are so many great things about engineering culture. Git is too prevalent to have one of its most commonly used commands be saddled with negative associations and materially negative effects on our core values. It's time to do some spring cleaning and shine a big light on this little corner of our world so everyone can benefit in unexpected ways. Not only could this make us better engineers and entrepreneurs, but it might even increase our ability to be inclusive and take some of the stressors out of the entry point for prospective engineers from underrepresented backgrounds. Blame is not even that clever or meaningful. It's time to let it go.
Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.
Top comments (1)
I like git who! Great post!