Code Review Doesn't Have to Suck

Why do it?

Your team will get better. Your product will get better. The community will get better.

Have a secondary or rotation location.

Don’t fight over semicolons; come ready with a style guide.

Let the initiator drive the discussion.

Present even if you are the only one working on the app or in the language or even knows it.

Share a call; share the screen.

Otherwise, just write it out.

We all know Skype sucks, but there are others. Meetspace?

Have others review your code!

Explain your thoughts and be accountable for them.

Have someone challenge your assumptions and decisions.

Make pull requests to single-person code bases.

Team: Meeting daily at 1:30pm at a rotating desk, limit to 30 min

Individual Projects: Asking friends to review remotely

Use ghi for GitHub

Use review/discussions & templates/templates features on GitHub/GitLab.

Do code review in interviews.

You can use code review to review candidate samples.

Choose a time that works for the team.

Have a rule set for assignment, cut down on repeated reviews.

If the team is large enough, have a Code of Construction.

Start by meeting as a group. One person will probably have to own it.

Stop wasting code review just on senior engineers.

Do it even when in person.

Leave notes for the future. Assume a bad reading of your comments.

Whenever possible, put example code in the comment.

What to do if your distributed team is across incomparable timezones.

Don’t let pull requests hang around after being reviewed.

If they hang around too long, it’s a sign of mis-alignment within the team.

Have a canonical representation of a pull request that is ready for review.

Make more pull requests and smaller ones.