When I started at Palantir, my desk was in a typical Silicon Valley office space. My team was in a room with six standing desks, no windows and a bean bag chair in the corner. I came back to my desk one afternoon feeling pretty good. I had just sent one my first decent sized PRs for review and I was proud of it.
I sat down and saw my teammate had left feedback on my PR. I opened it up, expecting to see a glowing review of my amazing code. Instead I saw more than 20 critical comments. I started reading through them but before I finished I was so frustrated I got up to go for a walk around the neighborhood and cool off. How could my code possibly be that bad?!
I eventually came back and thought "I'll show him! I'll address these all super quickly then he'll be annoyed having to read through it all again!". So I churned through them one-by-one, working quickly and grumbing and muttering in my head the entire time. I finish going through all of them in the same amount of time I'd spent angrily walking around Palo Alto.
I leaned back in my chair and inspected my work and realized I was actually more proud of the code I'd written than before. I immediately felt silly and a little ashamed of being so angry just an hour earlier. The code was obviously better after applying the comments.
I was a junior engineer only a year out of university so I was used to my code reviewer being a grader and each comment having a negative impact on my GPA. That review was a first step to make the mental shift to seeing code review comments as gifts from my teammates who were taking the time out of there day to help me be successful.
PrinciplesThe purpose of code review is to write the best code possible as efficiently as possible.
A code author should take responsibility for their code all the way from development to production. This means during code review they are responsible for:
If you're skeptical of a comment and want to push back, try implementing the suggestion first. It is always easier than you think and even if you do decide to push back, the follow up conversation is so much more productive when you start by saying "I tried to implement your idea but here are the issues I ran into...".
As a reviewer, your job is to be a resource to the developer. How you do that will vary based on the situation but universally you should be curious and supportive. The author is your teammate and has good intent, they are not an advisary trying to ruin your perfect playground. When you have concerns be clear and direct but also make sure to comment on things you learned and that they did well.
Time spent reviewing other's code is often the highest leverage time for a developer. The author did all the hard work of actually writing the code and now you can help get it over the finish line.