I think we've all been through a highly stressful early career moment when we made a mistake the cynical aspect of the culture made us think that we were being singled out or shamed. But I also think that as we grew we all learned that everybody makes mistakes and that our experiences weren't quite what we thought they were and while they were stressful they did prepare us for the nature of the job.
Software is inherently error prone and high stakes, where a single mistake could cost thousands or tens of thousands of dollars an hour and mistakes are frequent. The cynicism does guard against complacency and breeds a suspicion of faults as much as possible. Some business cultures handle this in a healthy manner and others allow that cynicism to get directed at people.
I think there is a key distinction that needs to made between negativity towards people and towards things and that we could do a better job of making that clear to new developers.
Yeah, great points! I agree that programming can be a stressful endeavor. And that can breed negativity. No code is perfect, and at the same time every small mistake or inefficiency can make waves, etc. I don't think anyone would disagree that it's helpful to have a thick skin, or at least an understand attitude, when you're doing it -- if you can. Ultimately, I believe these days teams everywhere are continuing to grow best practices on how to roll in new developers as nurturingly as possible, because like Spurr-Chen says in his blog, the walls are coming down and more people than ever from all backgrounds are getting into programming.
The thing is, Git is not a person. Engineers are people. The name of a silly command does not necessitate the existence of an actual blame culture in the workplace, and I think focusing on it actually detracts from serious root problems in your company if people are being finger-pointed in harmful and disrespectful ways. Our company makes extensive use of git blame to quickly pinpoint problematic code and fix it, but we also maintain a strict “no-blame” policy and work strongly as a team to come up with a solution. In a healthy company, “git blame” blames *commits*, which happen to have been authored by someone who likely has context to help fix the issue quickly; not *people*, who happened to have made a mistake.
I think we've all been through a highly stressful early career moment when we made a mistake the cynical aspect of the culture made us think that we were being singled out or shamed. But I also think that as we grew we all learned that everybody makes mistakes and that our experiences weren't quite what we thought they were and while they were stressful they did prepare us for the nature of the job.
Software is inherently error prone and high stakes, where a single mistake could cost thousands or tens of thousands of dollars an hour and mistakes are frequent. The cynicism does guard against complacency and breeds a suspicion of faults as much as possible. Some business cultures handle this in a healthy manner and others allow that cynicism to get directed at people.
I think there is a key distinction that needs to made between negativity towards people and towards things and that we could do a better job of making that clear to new developers.
Yeah, great points! I agree that programming can be a stressful endeavor. And that can breed negativity. No code is perfect, and at the same time every small mistake or inefficiency can make waves, etc. I don't think anyone would disagree that it's helpful to have a thick skin, or at least an understand attitude, when you're doing it -- if you can. Ultimately, I believe these days teams everywhere are continuing to grow best practices on how to roll in new developers as nurturingly as possible, because like Spurr-Chen says in his blog, the walls are coming down and more people than ever from all backgrounds are getting into programming.
The thing is, Git is not a person. Engineers are people. The name of a silly command does not necessitate the existence of an actual blame culture in the workplace, and I think focusing on it actually detracts from serious root problems in your company if people are being finger-pointed in harmful and disrespectful ways. Our company makes extensive use of git blame to quickly pinpoint problematic code and fix it, but we also maintain a strict “no-blame” policy and work strongly as a team to come up with a solution. In a healthy company, “git blame” blames *commits*, which happen to have been authored by someone who likely has context to help fix the issue quickly; not *people*, who happened to have made a mistake.