Publish first, review later
Code that is waiting for review is useless to the customer. It also risks growing old, or blocking other work that needs to be done. On top of that, it is demotivating for developers to see their code collect dust.
If the code is created by an open source community, or something else that is done outside of the ordinary work, things are different. For a team working with the code in a professional setting, asynchronous code reviews should be something to avoid.
The purpose of a code review
A traditional code review has two major purposes. The first is to make sure that the code behave as intended. There are alternative ways to achieve this. You can work in pairs or an ensemble. A test first approach, with a good knowledge in test coverage design, might also help with this.
The second purpose is to maintain code quality over time. This is impossible for a team that lack refactoring skills, regardless of how well code is reviewed. Perhaps it works for a product in an environment that never changes, but then code quality will also be less important. So the team will need to know how to change production code in a safe and effective way. With that knowledge, you can review code that is important, instead of code that is new.
The important code is the areas in the production code where a lot of changes happen. You can then, as a team, look at the code and find ways to change it, so that it is easier to work with. That will improve the software design skills of the entire team.
Ease them out
To become a high achieving software team you will need the same skills that make asynchronous code reviews unnecessary. So try to ease them out if you can. If you don’t feel safe to let code go into production without a review step, make sure to only focus on functionality (or what regulations demand). Have a linter in place that checks things like formatting as a pre-commit hook. If the code quality is so low that it hurts to put the code in production, that developer should not work alone. It is harder to teach software skills through a written review than in person.
Save the review energy for the high stake parts of the system, and go through it as a team. Then you make sure that the knowledge from the entire team is used, and shared, and that everyone is onboard with the results.
When the code never has to wait for someone else to get into production, then you can create value really fast.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about maintainable code, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.