[ComputerGuru]

I do a lot of open source work and unfortunately a very common posion is focusing on “who broke it,” which is especially disparaging when done in public. A particularly nasty habit is when outsider Alice opens an GitHub issue saying “xxxx is broken” and developer Bob replies with “yup, @Charlie’s commit fubar’d everything.”

Unfortunately both very demoralizing and very common.

[silveroriole]

Demoralizing - why? That seems like an attitude problem on the part of “Charlie”, not “Bob”. If “Charlie” is going to slink off with his tail between his legs every time he makes a mistake, he’ll have a tough time of it - it’s not like everyone can’t SEE that he broke it through version control anyway!

I just don’t really get it. Even when I was a junior, if I overheard “this thing is broken,” I was the first to pop up and say “oh, I bet that was me, let me have a look.”

[ComputerGuru]

I’m with you 100% except you’re not taking into account what I said about this being in public and Alice not being a part of the project. Internally assigning blame isn’t the issue, it’s about the “team” facade being shattered when dealing with the outside. If you’ve accepted Charlie into the organization then from without it isn’t about Charlie or Bob, the answer should be “yes, we’re aware; a recent commit broke that functionality and we’re working on fixing it.” I’m not even talking about a dev mailing list or GitHub PR discussion, I’m taking about the specific case of badmouthing a developer to an enduser.

Imagine if Apple came out and said “yeah, that blank root password bug, it was all because of John Smith and his crap patch that caused this.”

Outsiders don’t have the same perspective as insiders. If Charlie’s commit message read “implementing the really difficult thing we talked about,” the team might be aware of mitigating factors that Alice won’t. But even without those mitigating factors, all you’ve done is badmouth your own devs to the public. Additionally, you are not considering whether Charlie is an otherwise stellar developer that has never had a bad patch before. Alice may incorrectly presume that the only reason he’s being called out is because this is a habit of his, perhaps.

[lev99]

I often compare open source projects based on what's visible on the github page.

Drama around a volunteer team in the open is a bad smell.

Edit: I'd like to explain why.

* Open source projects with lots of drama often don't attract new talented developers, and if talent happens to depend on that codebase they are more likely to fork and start a new community, or fork and not submit pull requests.

* If I need to interact with the team for pull requests or bug/support tickets I'd like to feel assured we can do so respectfully and professionally.

* If a community has drama in it I am less likely to recommend the software to a friend or blog about the software because I won't want to be associated with it. I'm more likely to stop using it and switch to a different solution.

[mieseratte]

Two things:

First, it's generally best to praise publicly, and criticize in private.

Second, saying "@Users's commit screwed-the-pooch" blames but, frankly, may not be the whole picture. It's entirely possible that the commit caused the issue, but everything was done by the book in which case it's really an organizational failure.

Personally, I sympathize with your argument. I have no personal problem with Torvald-style correction. I used to work under an asshole who would threaten to have me fired routinely. Personally, I prefer the blowhards because you can always tell where you stand. Still, not everyone is wired this way and part of leadership is recognizing that and playing to various folks strengths and weaknesses.

[taco_emoji]

Right. Is the codebase spaghetti? Did anybody take the time to help Charlie understand the system? Were there unit tests that should've been broken by Charlie's commit? Were there unit tests but no continuous integration, so he didn't know to run those particular tests? Was there no code review where somebody could've caught the bug? Was there a code review but nobody else caught the bug? Was there QA testing performed where the bug could've been caught?

Etc. etc.

[foobarchu]

I think its demoralizing because it's active blaming. Charlie doesn't have an attitude problem just because he doesn't like being publicly blamed for something, Bob has an attitude problem because piling it on somebody else is his first reaction.

The proper thing here is to acknowledge that there is an issue, but not assign blame. Go to the person you think is responsible in private, and let them admit the mistake in public if they want. Assigning them blame publicly shows a huge lack of respect, even if it was their fault, while admitting blame freely shows modesty.

Plus, what if it's not Charlie's fault, and his commit simply revealed the problem? Perhaps the actual issue is in a little used function deep down in the codebase, and his commit is just the first one to actually exercise that area the right way? Maybe this whole thing comes around to being Jim's fault instead.

[commandlinefan]

I wonder, though, how much the culture of "talent" and "rockstar developers" contributes to this. We programmer types often perpetuate this narrative that programming ability is something that you're "born with" and you have it or you don't - unlearnable, unteachable and ephemeral is the mystique of the programmer. So, how do you figure out who the capable ones are and who the incapable ones are? Well, of course - the ones who f'ed something up are the incapable ones, who just didn't "have it" after all.