DEV Community

loading...
Cover image for Dude, I'm slagging your code. Not you.

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

Demian Brecht
Currently a Lead Member of Technical Staff @ Salesforce. Polyglot with a focus on Python. OSS Advocate.
Originally published at engineering.salesforce.com ・4 min read

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.

Discussion (10)

Collapse
scottshipp profile image
scottshipp

My favorite perspective on code reviews is Philip Hauer's Code Reviews for Humans. It echoes this post in some ways:

Repeat after me: You are not your code. Criticism on your code is not a criticism on you as a human. Don’t connect your self-worth with the code you write. You are still a valuable team member even if there are some flaws in your code.

In the end, programming is just a skill. It improves with training - and this improvement never stops

Thanks for the article!

Collapse
demianbrecht profile image
Demian Brecht Author

Yep, pretty strong parallel there. Thanks for sharing the post too, great one!

Collapse
jwp profile image
John Peters

Funny. I thought I was an awesome guitar player (20 years+) until I joined a band with a real drummer. I sent him some tapes to overdub tracks. He sent it back telling me how I had no sense of timing... ha, and he was right.

Collapse
buinauskas profile image
Evaldas

I luckily managed to adopt this kind of thinking very early in my career. Also, while reviewing pull requests, if I had lots of criticism for the code, I would always highlight this is all about code, improvement and nothing personal. This has also helped to establish better relationship with peers 🙂

Collapse
demianbrecht profile image
Demian Brecht Author

That's awesome, definitely wish I'd figured it out sooner. It would have made a lot of things (i.e. feature cuts) a lot easier to swallow along the way.

Collapse
nickwu007 profile image
Nick Wu

Very nice read Demian!

As a junior dev, I have experienced this quite recently. After a decent period of working in a small team, I got to a point where I thought I was getting good at writing code, at least when it comes to code within the team. When I saw a review like "this cannot be usable, please write it again", I almost lost it.

Separately I have come to the same conclusion as you mentioned above, that the intellectual product I made does not represent me as an engineer. Fiercely defending my code probably won't make it better, but taking in feedback and working it in has a better chance. Sometimes we just forget to be patient, objective and grounded. Reading your post also let me see it from others' perspective, which just helps complete the picture.

Great content!

Collapse
cottagegrove profile image
Rafae Ashraf

sometimes its just a job

Collapse
demianbrecht profile image
Demian Brecht Author

Sometimes for sure! In this case though, it was a side open source that I had worked on. I find that the tendency to become even more personally attached to your work is even stronger in those cases.

Collapse
icyjoseph profile image
Joseph

Often in projects people end up befriending me and recognize I have patience to do pair-programming or even teach a little bit of what I know.

I put good effort on reviewing, even my own code, and surprisingly, I manage to measure myself with the same bar I measure others. Because, at the end of the day, it is just code.

However, one time, someone got fired up, and nothing could change their mind. I'll still review the way I do, but oh boy, I did not have the skill needed to handle such a situation.