Have you ever had to fix a bug in code that you didn't write? Most programmers have. A common thing I hear when this happens is for the developer to say, "That's not my code". In this episode, I talk about how unhelpful that phrase is and why I dislike it so much, as well as offering guidance on what to do if you find yourself consistently fixing someone else's bugs.
I understand how annoying it is to have people constantly be like "no it wasn't me", but the frequency of the statement may not necessarily indicate something is wrong with the team, but that management may be too quick to chew people out over human error. In my last work place, a mid-level manager was constantly, and I do mean constantly, looking for someone to blame for shit that is bound to happen in our work place. Further more, when that manager made an error, they would push the blame onto someone under them and bend the truth; so yeah, it is not always an indicator that the group of people doing the work do not want to work well together, but that management is toxic and people start to worry about their jobs, livelihood and reputation.
ReplyDeleteAnother circumstantial thing to consider is that we do not often get to choose our co-workers; we may think the code that they write is garbage, or that they are not really all the smart, ect, but we have to work with them. When we did not choose them, why would we need to take responsibility (if blame is being directed at us, even implicitly) for mistakes we did not make when we did not choose the members of our team? People get defensive when they feel that there is a perceived threat, and as a programmer our reputation is everything when it comes to maintaining a job: a reputation of clean, concise, bug-free code.
I make it sound like I don't think team cohesion and mutual aide are important, I do, but I feel like the core reason for why people might make these statements was overlooked. I 100% agree that just because you did not write it does not mean it is not your job to help fix it, but being made to fix a mistake may make that person feel they are being blamed for it. I also agree that it is unprofessional to instantly go to "wasn't me" when someone from outside your organization (or has little to no bearing on your employment or standing in the organization) brings a problem to your attention as to them it does not matter who caused the issue, they just want it fixed.
Basically my closing statement is this: no one likes to be blamed (even if the whole team is being blamed) for errors that they did not make.
(P.S. In generally I really like your podcasts, it is just this on that irked me, perhaps because I just left such a toxic environment, but I think my points are still reasonable).
Hey, thanks for the comment!
DeleteYou make some very good points, and I don't disagree. In the past I've worked in some very toxic environments, too, in my case very high pressure, deadline driven situations where we were constantly trying to catch the code up to what the sales team was promising to clients. Those environments generated a lot of "not my fault" from all of us simply because we were shipping so many bugs, and the bad ones turned into witch hunts at the office due to the all pressure and low morale.
When I say a lot of "that's not my code" attitudes from a team are a red flag to me, I don't necessarily mean that there's something wrong with the programmer themselves. It's a culture smell that may not really be the fault of the programmers at all. The situation you outlined is a really good example of that IMO. Toxic cultures and their smells can be driven by all kinds of factors outside the dev team itself.
Re: can't choose our coworkers, I absolutely agree that we can't. I think I mentioned several times in the show that I'm not advocating that you jump on every grenade that gets rolled under your desk. I think I also spent the last few minutes advocating for documenting all the occasions that you have to fix someone else's code for the exact reason you stated, protect your reputation.
Lurking in your points is where a lot of the problem lies: Leadership can be vague and sometimes outright toxic in how they handle these situations. A good leader, whether we're talking about a lead dev, sr dev, manager, whatever, should be doing a good job of communicating to you that when you have to fix someone else's code, they know it's not a reflection of your abilities.
And certainly if it turns into some kind of witch hunt, that represents a total failure on management's part IMO.
Anyway, thanks for the comments! Good points and insights there, I really appreciate it!