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 huge purple bean bag in the corner. I came back to my desk one afternoon feeling pretty good. I had just sent one my first decently large PRs for review and I was proud of it.
I sat down and saw the notification that my teammate had left feedback on my PR. I opened it, expecting a glowing review. Instead, I saw critical comment after critical comment. I started reading but got so frustrated that I had to go for a walk around the neighborhood to cool off. How could my code possibly be that bad?!
I eventually came back and thought "I'll show him! I'll address these super quickly then he'll be annoyed having to read it all again!". So I worked through them one-by-one, working quickly and grumbled in my head the entire time. I finished going through all of them in less time than I'd spent angrily walking around Palo Alto.
I leaned back in my chair and inspected my work, realizing I was now more proud of the code I'd written after incorporating the feedback. I felt silly and ashamed of being so angry just an hour earlier. The code was obviously better with the comments addressed. That review was a first step to shift my mindset to seeing code review comments as gifts from my teammates who were taking the time to help me.
Principles of code reviewA code author should take responsibility for their code from development to production. This means they are responsible for the following during code review:
If you're skeptical of a comment and want to push back, try implementing the suggestion first. It's easier than you think. Even if you decide to push back, the follow-up conversation is more productive when you start by saying "I tried your idea but here are the issues I ran into...".
As a reviewer, your job is to support the developer. Your approach may vary, but you should always be curious and supportive. The author is your teammate who has good intent, not an adversary trying to ruin your perfect playground. When you have concerns, be clear and direct, but also highlight what they did well.
Reviewing code is often the most impactful time for a developer. The author did the hard work of writing the code and now you can help get it over the finish line.
Key takeawaysThe purpose of code review is to write the best code possible as efficiently as possible.
Code review is a practice of giving and receiving criticism and it’s your job to do both sides of this well.
