Sharing context outside pair and mob programming
Approaches to avoid the pain of Async Code Reviews.

Just a guy who loves to write code and watch anime.
Search for a command to run...
Approaches to avoid the pain of Async Code Reviews.

Just a guy who loves to write code and watch anime.
No comments yet. Be the first to comment.
Qualities that make outstanding builders.

Bipedal vs quadrupedal: how many legs This is about the number of legs the creature walks on. Bipedal. Two legs. Humans, ostriches, T-rex, kangaroos, most fantasy humanoids. Quadrupedal. Four legs. Do

Intro You hear "lerp" and "smoothstep" everywhere in game dev. They sound like math jargon. They're not. Both are small tools that do the same job: smoothly move from one value to another. The problem

What is Kinematics Kinematics is the math field. It's the study of how things move without worrying about forces (which would be dynamics). FK and IK are the two branches: forward kinematics and inver

Intro Textures are usually the biggest cost in a 3D scene. Memory, bandwidth, and load time all get eaten by them. Resizing them is the obvious lever. There's more. This post is about the less obvious

I dislike Async Code Reviews. They are time-consuming, and numerous times have I found myself being confused because I don't fully understand the entire context. I don't like them, they are a pain, and really slow down the team.
This was one of the greatest write-ups I have read about Async Code Reviews: From Async Code Reviews to Co-Creation Patterns. It also goes in-depth about the pros and cons of both big and small pull requests.
In this article, I want to share ways to reduce the pain of Async Code Reviews, but not directly doing pair or mob programming.
Before a task gets implemented, the engineer that will be implementing it chats about it with a teammate. This way they can come to an agreement on how it will be implemented.
Once it is done the two persons come back and do a pair review if possible.
If that isn't possible, the reviewer can review the code asynchronously, and if any changes are necessary, they can also take over the pull request (collective ownership). Most of the time from my experience this results in an immediate merge.
I said changes necessary because a pull request shouldn't be blocked over minor things.
If things are working, the requirements have been fulfilled, no risks are involved (performance, security...), and the code is well-tested, then get the pull request merged! Refactorings can be done in follow-up pull requests.
If doing a pre-review isn't possible, I recommend scheduling a time to do a pair review.
A focused session where the two persons involved (author and reviewer) review the PR together and any changes that should be made, they do it together, and get the PR merged, no ping-pong and annoying cycles which often happen in Async Code Reviews!
I like this approach. The only con here is that the reviewer still needs to learn the context involved and if major changes need to happen to the code for whatever reasons, then the pair will get it done together, although that could have been avoided with a pre-review.
Async Code Reviews are painful. Pair and mob programming aren't the only alternatives to avoid the pain of pure/traditional Async Code Reviews. There are other ways to avoid doing them and become more productive as a team!