Code review

Counsyl is the first job I've worked that has a formal code review process. At first it was intimidating (it still is sometimes), but I really have been impressed how review leads to better code. I still make mistakes in my own code, and sometimes I miss bugs in other's code. Bugs are going to happen, though, so I won't spend time talking about how to write bug-free code. Instead I'll write about some things I've noticed that make the review process go more smoothly. I've seen that a lot of productivity and good will can be gained by how you approach the person whose code you're reviewing, and the person reviewing your code.

While these suggestions may be helpful to you, I should say up front that I still mess up all the time -- so this guide is as much for me as it is for you.

The "Inception" way to fixing bugs

When someone points out an obvious flaw in my code and I can respond in two ways:

  1. I can get defensive and try to justify the code, denying my mistake.
  2. I can accept the other person's judgment, admitting my mistake.

Neither of those options feels all that great. The first can be really counter-productive, and the second injures my pride. But what about a third way:

I am able to find and fix the mistake myself.

This is kind of like "Inception" and one of my colleagues did a great job of it on a review he gave me the other day. I had added some code to change an object's state in a place where it seemed logical to me at the time. Instead of saying, as he could have, "Move this code to the foobaz function", he said "Do you think this code would work in the foobaz function?" I thought about it and realized he was right, but he never told me to fix it -- he planted the idea of fixing it in my mind and trusted me to see the fix. When I saw that it made sense the idea had more force than if he had simply told me. Additionally it allowed me to save face by not having to admit to making a mistake.

This is such a valuable technique. By asking a thoughtful question you can often accomplish the same result as a more direct approach with none of the bad feelings.

Praise the good stuff

Nothing makes me feel better in my work than when one of my teammates complements me on some code I've written. The thing is, recognizing the excellence of someone else's work may seem like admitting, in a way, that they did a better job than you might have. This may be why at literally every programming job I've had people say things like "We really need to work on recognition." It's hard. When I look at something awesome somebody wrote, in one moment I'm thinking "That's awesome!" and in the very next I'm thinking "Could I have done that good?" When you have no investment in being that good it's easy to complement the person, but when it's your territory it's a lot harder. Being able to allow the other person to be better, to allow them the complement, will absolutely not hurt you and will only make the other person feel appreciated.

As much as we treat code reviews as a way to fix mistakes, we can also treat them as a way to recognize the great work our teammates do.

Disagreement about design decisions.

Sometimes I will disagree with someone about the best way to solve a problem. I think it should be one way, they think it should be another, and there doesn't seem to be a way for both of us to feel good about things.

What I usually do when this happens is make a list of reasons why I am right and the other person is wrong. As if the other person is going to read that list and all of a sudden see the light. As if the other person doesn't have their own list containing all their reasons for being right! Instead of spending time justifying my own point of view, it's been useful to me to try hard to look at the problem through the other person's eyes. I operate under the assumption that my teammates are smart, talented and rational people, so it's safe to assume that they have smart reasons for thinking as they do.

By putting myself in their shoes I can come to a broader understanding of the problem. Maybe some flaws in my plan are apparent. Or maybe I can come up with some thoughtful questions that the other person may not have thought about. These questions can help uncover any shortcomings in their plan (this goes back to my earlier "Inception" comment).

So I try avoid list-making and focus instead on understanding the problem through the other person's eyes.

Other things

When people take a stand

There are hot-button issues that some programmers get excited about. I'm sure it depends a bit on your industry, but some popular ones I've seen are crypto, security, and testing. Any time these issues come about it seems like that person is there to take a stand.

I've found it helpful to remember that this person cares sincerely about this issue. So first I try not to take it personally or get defensive.

Beyond that, the other person wants to feel important for caring about this issue. Recognizing them for their care and attention, and being appreciative for their help will make them feel important and defuse the situation, so why not just do it?

Let the other person win

Sometimes more good can be done by letting the other person win than by asserting yourself. Maybe I've written a really long method that needs to get refactored into several smaller ones -- I know it, my reviewer points it out -- but sometimes it is OK to let it slide. This is particularly true on large code reviews where there may be a lot of discussion going on.

In the same vein, nobody likes the teacher's pet -- the person who is always right, always seeming to go the extra mile, always garnering praise. If that sounds like you, you might stop to think about how your work is impacting your relationships with your teammates. Is it worth it if everyone resents you? This doesn't mean to stop doing good work, it just means to try to spread the work so your teammates can get credit, too.

Reading more

Some of these suggestions are taken from the excellent book How to win friends and influence people. Reading this book made me see relationships with coworkers in a totally different light. It clarified the importance of good interpersonal relationships, both as a way to be more effective at work, and as an end in itself. I would definitely recommend picking up a copy (and it's a pretty quick read).

Thanks for reading, I hope you found this post interesting. Feel free to leave a comment below!

Comments (0)

Commenting has been closed, but please feel free to contact me