I recently attended several fantastic developer talks where I work. My co-worker, Chris, had a very interesting talk sharing lessons he learnt during 7 months of code reviews with a remote team. He had some great insights I have been thinking through. The one which sticks with me is: how your code reviews are a reflection of you.

Chris had the benefit of helping a remote team get started. It was really hard. I appreciate the work his team put in. His presentation reviewed what he learnt after months of working with the same people. Code reviews were the focal point for most of his interactions.

Things change when code reviews are the primary way you interact with someone. You don’t know them as a person and you cannot see them on a daily basis. If they keep giving crappy code reviews your opinion of them forms quickly. Likewise, consistently great code can help them stand apart.

This was the reality for Chris while working with the remote team. Being a talk on code reviews, he found special examples highlighting lessons learnt. He felt after a while, the code reviews became the main representation of a person’s ability.

This got me thinking about being evaluated and represented by each of my code reviews. I thought about how I often become too attached to my code. It also caused me to reflect on several great blog posts about separating your worth from the code you write. These posts, in a nutshell, explain how ‘you are not your code’. In the end, I think I found a way I can bring these differing ideas together.

Invested

Connecting with what Chris said, I take feedback to code reviews I make to heart. On the receiving end reviewing code from others, I care about maintaining the quality of what we built. When I send code reviews I try to be careful in how I approach making changes. I hope I don’t look stupid.

The dark side is when I treat comments I give or receive like an attack. Reviews should be an open discussion and not used to showcase how brilliant you are. Instead, humility and listening need to be applied to every code review.

It is really easy to become invested in your code. I put lots of effort and care into the work I do. I am emotionally invested. Too often I behave defensively about my code and take feedback too personally.

Feelings of ownership intensify the longer I have been on a project and what role I had in its formation. We have been on our current project since it began and seen it go through many changes. I care deeply about it and want to see it succeed.

Over the last few weeks, I wrapped up a project I worked on over the course of 7 months. At the same set of talks, I presented about how this project evolved. I feel personally responsible for the code. It feels like any feedback on the project or code reflects on me as a developer.

I am self-conscious about by ability as a developer. I often feel like an imposter. Combining those developer doubts with putting myself out there in code reviews, you get a potent mix of feelings and lack of confidence. My inner phony is on display.

You Are Not Your Code

There are many great blog posts about how you are not your code.

Each of these posts is a reminder to not be so serious. The code you write is not your worth as a person. You are so much more. Don’t direct the suggestions and criticism inward. Instead, use the constructive criticism for getting better.

This is a message I need to take to heart. I need to separate myself from suggestions for the code I have created.

In preparing for my presentation I had some great questions from others which forced me to re-evaluate the decisions I thought were rock solid. Incorporating the extra feedback from others made the finished product was even better.

How does ‘you are not your code’ fit if your colleagues think about you based on the code you share in code reviews? This seems like the opposite perspective. Wrestling through this contradiction caused me to rethink Chris’ talk.

Caring Professionally

I think both ideas can fit together. The sum total of your being is not the code you write. How you present yourself, learn, care and interact with others is a clear reflection of what you value. Code reviews are one avenue for expressing yourself.

In talking with Chris, he cares about the humans behind their code reviews. In teasing apart what he said, I think caring about what you do is the most important part of each code review. Not getting emotionally attached to your code to the point where it consumes you. Care about your work and put your best foot forward.

If someone else is going to take the time to review your code be kind to them. One recommendation from the talk was for you to thoroughly review your code before sharing it. Go through the changes on your own and clean up any loose ends. Add comments explaining the decisions you made. Show you care.

I think constantly improving and trying your best is part of being a professional programmer. Learn from your code reviews. Try to make the most out of each review and the feedback you receive.

Be supportive when interactive with others. Don’t stomp around and shoot down their ideas. Treat others how you want to be treated and you cannot go wrong.

Although I don’t count myself as a great developer, like Jeff Atwood I care too much.

Unfortunately, the world is full of people who don’t give a damn about their work. Those of us who love programming enough to become highly skilled at it tend to have the opposite problem – we care too much

The solution is to convert caring into actions which help others.

You are not your code, but your code reviews are a reflection of your workmanship. Care about your work and do your best in every code review.

P.S. Thanks Josh for helping me review this blog post. Without your help I would be stuck in the present and past tense at the same time.