Reading "How To Make Your Code Reviewer Fall In Love With You", Part 2

Okay, so after what happened with the VSCode course yesterday (although that was the right thing for me to do - every blog post represents a segment of learning and so I have to limit them at a certain point and start a new one) I am going to try and keep this the second and last blog post for this task. Also because I just think that the rest of this article is on one topic. So let's go. First of all - the biggest takeaway from the article seems to be value and cherish your code reviewer's time. You will learn more if your PR is better. Your reviewer will put more effort in to your review when they know you value their time.

Techniques

This section looks familiar but THERE IS ALWAYS MORE TO LEARN. SO let's go.

Review Your Own Code First

"BEFORE SENDING CODE TO YOUR TEAMMATE, READ IT YOURSELF FIRST. IMAGINE READING THE CODE FOR THE FIRST TIME. WHAT MIGHT CONFUSE YOU?" Wow. Yes I used to get into trouble with my boss for not reading my code back - rightly so. 

The first thing is to check for typos and errors and silly line deletions. But it's important to check - is the code understandable? But I feel like the author might be saying more here - so let's find out more. 

TAKE A BREAK BETWEEN WRITING YOUR CODE AND REVIEWING IT

Always. Always always always.

WAIT UNTIL THE MORNING TO LOOK OVER IT WITH FRESH EYES. 

ALWAYS. ALWAYS. ALWAYS ALWAYS ALWAYS.

- USE A DIFF VIEW!!!
- DON'T EXPECT YOURSELF TO BE PERFECT

- READ THE CODE AS YOU WOULD FOR THE FIRST TIME - WHAT MIGHT CONFUSE YOU?

Write A Clear Changelist Description

I don't entirely know what a changelist is. 

But this author has a really call other article, "How To Write Useful Commit Messages". But the point is

- WHAT the change achieves, at a high level

- WHY you're making this change

- SUMMARIZE any BACKGROUND that the reader needs to know

Answer Questions With The Code Itself

Code that documents itself naturally IS THE BEST CODE. 

If it's not clear can you rename or restructure logic? Code comments can help too but they're not as good as code that documents itself naturally.

Narrowly Scope Changes

Okay mental fatigue has kicked in.

DO SEPARATE PRS FOR DIFFERENT THINGS.

THIS IS TOTALLY OBVIOUS TO ME.

DO JUST ONE THING.

THE SMALLER AND SIMPLER THE BETTER. FOCUS ON ONE THING AT A TIME.

KEEP FUNCTIONAL AND NON FUNCTIONAL CODE CHANGES SEPARATE

'nuff said

IF IT IS TOO BIG, BREAK IT UP BEFORE REQUESTING A REVIEW. 

THE author recommends 400 lines of code as a point for when a review request becomes too long. Can you break things up and do things apart? "It puts less strain on the reviewer." Can one bit of the new code be implemented before the other is?

NEVER TAKE FEEDBACK PERSONALLY!

I love feedback on my code. "AS THE AUTHOR, YOU ULTIMATELY CONTROL YOUR REACTION TO FEEDBACK."

"I TRY TO INTERPRET ALL NOTES AS HELPFUL LESSONS."

IF YOUR REVIEWER IS WRONG...

... Be patient. If there are ways to refactor the code then do that. Or add comments to make the fact that your code is correct more obvious. 

If the coding is too much of a flex but too hard to understand - make it more readable.

Make It Clear Who Is Holding The Baton

Mark comments as resolved. Or send messages. Or write "done." I like it when someone slacks me when my PR comments are ready for me to read. I like to slack the person when my changes are done.

We have built in emojibot tools too. I will speak to my new colleagues. To discuss, how do we make it really clear who the person holding the baton is?

If someone puts in effort with their comment put in effort with your response too - but I do that anyway!! <3 <3 

If something is missing, ask for it "artfully"...

A great example that the author gives is

"What changes would be helpful?"

Give Your Reviewer The Benefit of The Doubt

If two of you are in disagreement about something subject, let them win xxx

Keep The Ball Rolling As Quickly As Possible

The quicker you get back to. your reviewer on their comments, the less they have to remind themselves 

• What your code was 
• What the context was
• What the comments they wrote were

"ONCE YOU SEND YOUR CODE OUT, DRIVING THE REVIEW TO COMPLETION SHOULD BE YOUR HIGHEST PRIORITY."

Conclusion

I STILL DON'T EVEN KNOW WHAT A CHANGELIST IS