How can you ensure timely code reviews?

Moving targets are the death of success. The expected functionality must be clearly defined before the team begins at all to think about code. Once defined, deadlines must be understood, and; milestones defined along a given timeline. Management and Client and Developers - all - must agree on these expectations before coding ever begins. Code reviews, come in different flavors, but; the ones that truly matter, happen daily, and sometimes even hourly, by the engineers involved. The most important time to review code, is when you are correcting an issue, when you are resolving a problem. Peer review is a good habit, and; Management and Client should always be kept in the loop.

To ensure timely code reviews, it's important to make them a regular part of the team's routine. This means setting aside specific time each day for reviews. It could be defined as section in team's ways of working document. Keep track of how long reviews take and use that info to spot any slowdowns. You can also add a fun element like rewards for team members who do a great job with reviews. This helps keep everyone motivated and involved.

Code reviews an essential part of the whole development lifecycle. Having a team actively contributing and engaging in code reviews could result in producing very high quality code. But review code can be a tedious process itself if the reviewer has no context of the code itself. Few of the things I've always found helpful while putting down my PR's for review are, 1. Have one PR/Branch (if possible) solve one and only one issue. Makes it easier for the reviewer to understand what you are trying to solve. 2. Have a clear description about what the PR does, Including all the necessary details possible such as, description, issue resolved, flags (like is it a bug, feature, etc), screenshots, outcomes and issue tracking ID (if applicable).

In order to set clear expectations during the code review process, - Consider using pull request templates with a check list of the most important tasks that you expect the author to complete before submitting the request for review - Encourage small pull requests which do not contain a lot of code, the pull request should not become too big to be reviewed in a single sitting. - Add documentation inside and outside the code, such that if somebody wants to later understand why you wrote a piece of code, they need not look any further than the codebase itself - If the review is not possible in a reasonable period of time, communicate that clearly to all stakeholders, if possible delegate the review to someone else.

One thing I've found helpful in ensuring timely code reviews is adopting a "selective and concise" approach. This involves carefully choosing which parts of the code need thorough review. Not every line or change requires equal attention. Prioritize key areas like new features, complex logic, or parts of code that are prone to errors. Being concise is equally important. Provide clear, focused feedback. Avoid overly long comments and instead, aim for brevity and relevance. This approach respects the reviewer's time and encourages quicker, yet still effective, reviews. Remember, the goal is to maintain code quality efficiently, not to scrutinize every minor detail.

Code reviews should focus on the GOAL. In reality, very often, the code you're developing is NOT the code you will DEPLOY. I teach developers a simple philosophy: Make it work. Make it right. Make it better. Goal #1, Make it work as expected. Goal #2, clean up the MESS that works so that the code is "right". Goal #3, make it better - but with care. Better often means, "extras". Or improvements in performance. Never lose sight of the working copies. And when TIME and RESOURCE allow - make it better. Thus, this little mantra: Make it work. Make it right. Make it better.

Automation tools help a lot when it comes to code reviews. The available open source solutions solve a huge percentage of the code reviews, and a lot of remaining percentage can be appended into rulebook as an extension of the available solutions. Once the generic things are resolved without a reviewer involved, the actual code review can be very minimalistic, and very "business problem" oriented.

Automation tools such as linters, formatters, SonarQ, Veracode, test automations, CI... can cover a whole lot of review areas and provide the submitter with quick, concise, and consistent feedback. It also freed up the reviewer's time and effort to focus on areas where critical thinking and creativity are needed.

A good code reviewer isn’t just someone who is good at finding flaws in the code, or knows best how to optimise it, but a good code reviewer, - Builds trust with their team members during the code review process - Instead of directing people, use a collaborative approach. “Rename this variable to isEphemeral” versus “How about we rename this variable to isEphemeral?”, the tone matters. - If you find certain practices being used that can benefit others, tag your teammates to let them know, this will also bring recognition for the original author.

Following-up is an important and often neglected part of the code review process. Your job simply doesn’t end with reviewing your peers’ code. - What if they didn’t understand the comments and feel hesitant to reach out? - What if they are too scared and anxious to try out an approach you suggested? Sometimes, it’s nice to reach out directly and find out what’s going on if the progress on the review is stalling.

To ensure timely code reviews, set clear deadlines and follow a consistent schedule. Use automated reminders to keep on track. Prioritize reviews based on project urgency. If you're behind, consider reallocating resources to catch up. Emphasize the importance of prompt reviews in your team culture. Regularly check for bottlenecks and address them. Keep the review process efficient. Additionally, learn to lean on project managers or scrum masters for support in managing the review workload and maintaining the flow of the process.