Master Chef in Coding Kitchen

5 proven techniques to close code reviews faster

In my 10 years of software engineering, working with more than 7 teams from diverse geographies, closing code reviews faster was a problem that transcended cultures. I have seen cases where devs waited for weeks to months for approvals.

Code reviews should feel like a virtual hangout spot for nerds, a place for chatting about code philosophy, cracking jokes, and sharing memes. Sadly, it's often a bit dull – less love, more ego.

But the good news is that there are ways to overcome this.

The techniques used to close code reviews are pretty much similar to cooking a master chef dish. Today, I am listing 5 proven techniques that helped me to close code reviews faster or you could say, turned me into a better chef in the coding kitchen.

Here on, I am going to use "PR" to refer to code review/pull request/merge request.

1. Taste your food first

Once you've pushed your code, start with a draft PR. Review it as if you're checking someone else's work, make any needed code tweaks, and then open it up for others to see.

I admit, I sometimes forget to tidy up consoles, debuggers, or those temporary variables I create. But believe it or not, this habit pushes me to present cleaner and more readable code in the end.

2. Focus on one dish, not two

One PR → One Feature.

Every PR has a scope of the user story or the bug associated with it. Please don’t go beyond it. During review, if a colleague asks for a change beyond the scope, tell them to create a separate backlog task for it.

Also bundling multiple features in one PR confuses reviewers, causing delays in approvals. Separate PRs for each feature simplifies understanding and speeds up the process. Keep it clear and get the green light faster.

3. Dish's appearance hints at taste

Include visuals like screenshots or screen recordings for UI changes and flow diagrams for data or backend design. It helps reviewers get a clear picture before diving into the review process.

Reviewers often skip reading the user story or bug details, and end up asking about the code changes. However, when I provide a clear description with snapshots or diagrams, they don't need to bother me. It's a time-saver.

4. Judges should celebrate the dish

After you've taken care of all the feedback, go ahead and ask for approval. Don't be afraid to do it. If there's a deadline for the PR, don't hesitate to let the reviewer know. It's totally okay to follow up.

The job of a reviewer is not only to provide feedback but also to celebrate the code at the end.

5. Great chefs draw inspiration from others' dishes

I became a better developer by checking out other people's PRs. I'm usually the first to dive into a PR when someone opens it. I would appreciate and clap whenever I see some amazing piece of code. It's all about understanding and celebrating each other's creativity.

In the world of PRs, there's no "junior" or "senior." Treat every PR as a chance to learn. Forget hierarchy, dive in, read, appreciate, comment, and ask simple questions. That's the path to becoming a great dev.

I would love to hear ideas that helped you close your code review faster. Don’t hesitate to share them in the comments. Maybe your team or another team implements it.

Experiments and Experiences

I've been starting my days during Brahma Muhurat for the last 8 days. It's a 48-minute slot, beginning 1 hour and 36 minutes before sunrise, also known as 'The Creator's Time.' Starting your day then is believed to have both physical and mental benefits.

What I do?

I kickstart my routine with a cold bath, followed by meditation and a run. When I get back, I jot down whatever comes to mind in my journal. I intentionally avoid using my phone or checking the clock during this time.

To stay accountable, I posted a few selfies after taking the cold bath.

Selfies post cold bath

I tried something new, and it turned out to match my body's natural rhythm. Feeling super energetic, I aim to stick with this routine and make it a habit throughout 2024.

---

If you enjoyed what you read and believe that code reviews should be more fun, share this with your colleagues. Let's spread the word and bring a new, playful review culture.