The Number One Rule Of Programming Is Leave Emotion At The Door

As programmers, we take pride in our work. We show this pride by doing the best work that we can. We show it by meticulously getting everything right, even down to variable and method names. We show it by choosing the right classes to get the job done, even though we know the user doesn't actually care whether we used List<KeyValuePair<Guid, string>> instead of Dictionary<Guid, string>. We show it by any number of neurotic perfectionisms that normal people think are OCD.

But what happens when a developer invests too much pride into the code that he or she wrote? What if that pride causes that developer to have an emotional stake in the code itself? What happens when a developer can no longer separate him or herself not just from his or her code, but his or her methodologies, decisions, and general behavior as a developer?

We've all dealt with this kind of developer before. This is the developer that always gets defensive when you ask a question about his or her code. This is the developer that gets into emotionally-charged arguments when you propose a slight tweak or suggestion to what the developer has already done. This is the developer that pouts when his or her way has been shown to be incorrect, and will probably harbor a grudge against you for showing it.

The thing is, we've all been this developer before, too. Especially when we were junior developers, we often were so gung-ho about getting out there and writing code while understanding so little about whatever technologies we were using that we inevitably wrote suboptimal code that we thought at the time was great. We've all known that sinking feeling inside when a more senior programmer shows you a better, more correct way to solve the problem you were trying to solve. We've all felt a little crestfallen when we found a built-in class that already does what we just spent half a week doing ourselves.

But as we gain experience, as we thirst for more and more knowledge of whatever technologies we use, most developers learn to separate themselves from their own work. Most developers learn finding a better way to do what you just did, even if it's from an intern or a fresh graduate, isn't any sort of commentary on our technical proficiency. Most of us reach a point where we really enjoy finding out those new and interesting things. As our proficiency with a specific technology increases, the more likely that something we don't already know will be an outlier that really eases our lives, and we like that. Unfortunately, not all developers make it to that point. Some developers stay at that immature stage and can't ever handle any kind of criticism.

What causes this kind of behavior? My guess isn't spitefulness, immaturity, or an actual belief that one is that much smarter than everyone else. If anything, I think it's borne out of insecurity. When I was pretty green, I always felt like being corrected or shown a better way to accomplish something in code meant that I was dumb. I think developers who get defensive about their own code secretly fear that their value is somehow diminished when their code is shown to be wrong or suboptimal.

Regardless of the why. there exists several ways to deal with this kind of developer. The first is to talk to him or her. Let the developer know that they're becoming too attached to their work and are starting to negatively affect the quality of shipping code. For many of these kinds of developers, this will be enough. No one wants to be responsible for bad code, and if you frame it such that the developer understands that his or her attitude is affecting production code, the developer will usually get their act together.

If that doesn't work? Well, you're left with less desirable means. If the developer never relents, then the next best thing is to get buy-in from the rest of the team. Unless that developer also happens to be a lead or manager of some sort, their bad code (and attitude) will not stand up to the rest of the team.

The next step is making all your suggestions to the manager or lead directly. This has a petty “backstab-y” feel to it unless you also have the developer in question in the room with you. Offer your suggestion to the manager, allow the other developer to defend his or her stance, then let the manager make the decision. It's out of your hands at that point, and it may not end up going your way, but at least you tried.

As developers, we all need to become a little less emotionally attached to our code. Remember that the next time you find yourself arguing against what is obviously a better solution than the one you used.