I hate such things. It creates a terrible work environment. Instead of focusing on the git blame and git punish, everyone should just focus on git commit fixes to make the code work. Does it really matter who put the bug? We are all humans, we all make mistakes.
While the name maybe a bit unfortunate or maybe made just for fun, git blame has actual use. While it's useful to see the commit log and figure out how the bug came to be, it can also be useful to talk with the respective developer if available and get an even better perspective.
Indeed, but this is a different thing entirely. Getting a perspective to a problem and working together to fix it is one thing, going and pointing fingers, even in playful manner, is different. In the long run, it creates an unpleasant work environment.
In our office, I always take the blame jokingly to lighten the mood. It's a running gag, we have three people who are more senior than the others, and we always say "it's his fault, and if not, it's the other one and if not, then it's Leo's fault" (I am the most senior). When a problem arises, it doesn't matter who inserted the bug, but how to fix it the quickest.
They both came from the earlier `cvs annotate` command. annotate is the original name (from 1996). While it was common to talk about cvs annotate as 'blame', I think it first became the name of a command in subversion 0.32.0 (~2003, rcs blame was ~2004, cvs annotate grew the blame alias ~2008)
I agree. I once worked for a large software company that had a lead dev who relished calling people out and belittling them in front of the other devs. Long story short, turnover rate was quite high for that business unit.
This tool might have an actual use if all it did would be to create a page with the relevant piece of code and commit metadata, so that when asking authors about it they would just open a link and didn't have to clone/locate/open anything.
But shaped like this, with the name, the graphics, the "whyyyyy" and the overall implication that the commit author had screwed up, it's indeed hostile and counterproductive.
100% agreed. Along with a review sent to the person that wrote the bug. Ideally with a non accusatory note like "I think this code had an issue and I think this fixes it. Yea?". That way they can double check you understood the issue and they can learn from their mistakes. When I get a CL like that I usually write a "Doh! Sorry about that. Thank you for the fix".
What, just because he's suggesting to use curl to download a file?
There's a difference between "curl ... | sh -" and this.
He's even separated it nicely into steps, so you can view that (very short) file in between.
What worries me more is that he doesn't properly quote $@, so this script will break when there are spaces in the filename. One of the reasons I hate bash.
Wow, one of these days someone needs to make a russian roulette binary that has a 1 in 20 chance to delete your home directory and post it to HN. Bonus points for including a link to the source without the russian roulette so that people can 'read the source for the binary' before running it.
"Don't worry, you don't even need to 'sudo' this so it can't do any harm!" See, it's not running as root while it wipes clean your home folder.
TLS wouldn't help; the greatest risk is the author himself sending a malicious script (no offense, Sergii).
So everyone needs to check the script before running it anyway. Which is easy, because it's a very short script.
(Of course, it's so short that it might as well have been an alias or, even better, just a copy-pasteable git command, but I guess the author really wanted to call it 'git punish'.)
How is this any different than any app/executable/script period? When you download VLC did you read all the code to check it's not installing a root kit? When you added some python lib do you go through all the code and make sure that on the 20th run it doesn't upload your private ssh keys? Have you checked all the vim or emacs code in your latest download before running it? Maybe I'm missing the issue but they all seem about the same level of bad.
This is symptomatic of something that has been bothering me lately. Programmers seem to be in some sort of twisted abusive relationship with their tools. Tools that other fellow programmers have written.
Why do programmers hate other programmers so much? Why do they have so little empathy and care?
Too much staying in one own's head?
Lack of exposure to diverse opinions and emotions?
The tools provide some value and we depend on them, however they also abuse us by being very unfriendly and disrespectful of our time.
I think this emerge of a certain way that programmers think of other programers.
There are of course exceptions, but often tools made by other programmers don't seem to respect us as users and have bad user experience:
- Few thoughts given to make common operations good,
- Lots of clunky menus,
- Poor performance,
Basically going out of their ways to make us do something else than programming by killing the feedback loop. (Think libraries that are slow to compile, tools that run slowly or require assistance or are otherwise too granular)
The absolute worst example I can give is something like Hudson or Jenkins.
> The absolute worst example I can give is something like Hudson or Jenkins.
Though I agree with you to some extent, IMO you chose a bad example. Jenkins has one of the most shallow learning curve of any the tools I use, and doesn't require a lot of fussiness. If I can it to build from a terminal window, I can get it working on Jenkins in 30 minutes.
Might I suggest Appium for your example? The one where, in the official docs, it says "If install fails, keep trying to install a few times." Rest assured that you'll need those instructions. Gawd, I hate Appium.
My experience is using Jenkins with Matrix jobs (and various plugins) for building native code on multiple platforms. There, the Jenkins UI doesn't shine.
Problems navigating between pages and knowing what one is looking at abound. Organizing jobs in various tabs works but isn't extremely easy. The UI doesn't handle well dealing with large lists of nodes/labels.
The plugin based architecture might be to blame for it, however I think it's a conscious choice from the original designers and they should be hold responsible for it.
Hacker News is full of bully lurkers? I personally despise those who ridicule instead of working with a dev who does not happen to grasp the error of his or her ways.
What may seem like banter to one person may be extremely hurtful to another. This is especially true for new devs, who are acutely vulnerable to Imposter Syndrome.
Of course, banter between long-time colleagues is usually harmless. But it's often difficult knowing where to draw the line.
You also have to praise and reward devs for their successes. It's not black and white - you don't have to pick between banter OR praise. You can have both. It's a dynamic. Show them that you care and that they're doing good work, genuinely. Tease them about small mistakes with tools like this, sarcastically and socially, and it helps build up rapport and make the team that much more tightly knit. Pointing out simple mistakes in a tongue in cheek manner is a good way to show someone that they've made a mistake, but it's not a big deal and no one is actually upset with them about it.
It's still difficult to know when the line has been crossed. What's perceived as harmless (even productive) banter by everyone else may still be hurtful to the recipient. You never know whether someone is okay with it, or simply hiding their emotions well.
I do agree that a copious amount of praise goes a long way toward developing a healthy environment.
As a tool this would be pointless and unhelpful. A graphic splash that does not explain why the code is bad and how it could be improved. Junior coders would be just shamed while seasoned professionals would be just irritated. Shame and irritation are usually unhelpful emotions.
You just need to let the person that made the mistake post it themselves. Personally I think it's fun to laugh at myself though I agree it's not fun to be laughed at sometimes.
Yeah, it's obviously for funning around. The problem is that it just turns into (at best) passive aggressive nonsense at offices where the kind category of banter needed to playfully respond is generally not allowed. In that case, all the wet blanket responses do alloy.
This doesn't seem very effective at what it's trying to do. Once you create the page, what then?
It should be a service that mails all other contributors in the commit log something like this: "Mr. <insert name> introduced a CATASTROPHIC security bug right here! Look at that! <insert code> <insert insults> Are all his contributions hidden landmines that might jeopardize the project at any time? Clearly they need to be checked! <insert list of all his other commits>"
Maybe "git shame" would be more appropriate too.
And yeah, you should probably not do that if it's a company project or a noncritical open source project.
My best guess is that it takes a file and a couple of line numbers/ranges and then uses git blame to figure out who introduced/worked on those lines. From there, it creates a public page with the code snippet in question along with a question to those responsible as to why the code was introduced.