We software developers use a tool every day called “git.” Yup, that’s a funny name. You can blame Linus for it.
Git is like a farming co-op; each farmer (developer) can tend to their own plot (branch), experiment with different crops (code changes), and when the harvest is bountiful (the changes are beneficial), they can contribute it back to the main field (master branch) for everyone to enjoy.
Git has a function known as ‘git blame.’ Its name suggests a tool designed to point fingers, to scapegoat, to assign fault.
It looks like this:
0d4f6aee (John Macdonald 2023-05-04 15:04:39 -0400 137) 'asvt': ['ASVT', 'ASVT-Development'],It tells me who contributed that line of code (in this case, me) and when.
But ‘blame’ is a bad name for this function. Because it’s really about understanding. It’s a detective tool, a guide that leads us through the tangled forest of code revisions to the genesis of a line, a change, a function. Its aim isn’t to identify culprits, but to provide insights into the ‘why’ behind each alteration.
Today’s social and communicative technologies have turned people into public blamers. When problems arise, it’s tempting to locate a target for our frustrations, to find someone to blame. We blame to assign fault, boost ourselves, and diminish our enemies.
Someone is to blame. And if it’s someone else, it’s not me.
Yet, much like ‘git blame’, our real aim should be understanding. To seek the ‘why’ instead of the ‘who,’ because ‘why’ grants us the tools for long-lasting resolution and growth.
Rather than blame, let’s find empathy.
