Dude, I'm slagging your code. Not you.

I wrote this a few years ago on Medium, but thought I'd re-share it with this community as I strongly believe that the experience and resulting realization were incredible for my career progression. Hope others can learn from or identify with it.

I spent the first decade of my now roughly 16 years of writing code being overly attached to the code that I wrote. I took pride in what I designed and wrote. It was my baby. I’d spent hours painstakingly writing, refactoring, rinsing and repeating. I watched my code and libraries mature. I was generally happy with the output. Nobody could attack it without me immediately taking on the role of the parental defender. After all, that code was a part of me. It was the sum of all of my years of learning and practice. I was blinded by love. No child is cuter than your own.

I’m sure many folks who have spent years writing code can identify with the above. Unfortunately, it’s really a horrible mindset to have in practice. Here’s a case study, based on an experience years ago from yours truly:

I put an inordinate amount of time into writing an OAuth 2.0 client in Python (this is during spec draft days before many clients were available). There was another client available at the time, but it was a monster and really seemed like overkill to me. I spent a good deal of time digging through the RFCs, understanding the protocol to the lowest level. I spent just as much time researching deviations in provider implementations, which reminded me of early client side browser development days. I then spent a good amount of time designing and implementing a library that I was proud of. It beat the code footprint of the other library by over two orders of magnitude and as far as I could tell, offered just as much functionality.

I understood that I’d written this library in a vacuum and wanted to get some feedback from someone more entrenched with the Python community. I’d watched a talk given by someone and enjoyed it, so decided to reach out to them and ask for a code review. Much to my horror, he ripped it apart. It felt like I was having my heart torn out and stomped on. How could he ever see anything wrong with this body of perfection that I’d created?! I found messages on his social media accounts poking at various areas in the code (not actually linking back to the code as to maintain anonymity). My jaw hit the floor. I couldn’t believe what had just happened.

I fired back. I sent him an email directly with my feathers all ruffled. Something to the effect of “)&#$ #$()& #$)#(&ASD&!!!”. His response was:

“Dude, I’m slagging your code. Not you.”

I slept on it. While I still felt there’s a much better way to deliver feedback, it did force me to consider some bigger questions. How on earth could he have a clean separation between my person and my code? Weren’t they effectively one and the same as my code is a product of my efforts?

Then the lightbulb went off. I was wrong. What I realized is that, while code that I’ve written is indeed mine, in no way, shape or form does it represent me as a person. Not only that, but no two software engineers will ever solve the same problem in the same way. The trick is to listen to what others are saying, to understand that:

• Everyone solves problems differently,
• Everyone has a different delivery mechanism, with wildly varying degrees of tact, and
• They’re not talking about you, they’re talking about code

The person with the least amount of tact will say “this code is terrible”. They’re not calling you a jerk. They’re not saying you’re incompetent. They’re saying your code is suboptimal. Funny as it may sound, once you come to this realization, handling the most brutal code review or even having code that you’ve written entirely obliterated from source control becomes a cakewalk. No longer are you taking things folks are saying as personal attacks, but as sources of knowledge to enhance your own learnings and professional development. If someone says “this code sucks”, you tend to ask why they think that and how it can be improved rather than getting into arguments that are based on passion instead of sound technical reasoning. You’ll also likely be surprised by the number of times people think your code sucks because they don’t understand the problem domain well enough. You’ll be surprised at how often you can learn great stuff from those who are a little less savvy around conversational tact.

Of course, I’m not advocating that ripping someone’s code apart verbally or over social media is a good thing by any stretch. It’s usually best to have one on one discussions with someone who’s reached out to you for a review. What I’m trying to get at here is the importance of being able to separate yourself from the code that you write. It’ll help you tons throughout your career.