This is the worst time to try to fix anything. The author has just finished (or thinks he finished) the work and any attempt to change anything by the reviewer is going to elicit resentment in most people. Try to tell the person the change cannot pass and you can make an enemy. Or you let the change in because you like the person. Either way, it is bad.
And all this for naught because in my experience the law of sunken cost comes into action and people will try to push it as much as possible unless it really has a critical flaw.
For this and other reasons I prefer pair programming as an alternative to code reviews. Work progresses faster when two people do it (vs slower when one has to finish it and then another review it). You actually have two people understanding what happened. And you can avoid all of the drama because problems get fixed as the solution is being designed and written.
And yes, this is a good (or at least better) time to teach. Though I try to not be preachy and instead prefer to demonstrate how I solve problems and comment on why.
Anyone who resents code review isn't fit for this business. This is exactly why information given by interviewers to hiring committees focuses on the nature of the back-and-forth exchange during the interview, and decidedly not on whether the candidate completed the exercise. The most important feature of a software engineer is how well they fit into organizations.
Same above goes for anyone who believes they have "finished the work" before getting any reviews.
Ever joined a team and needed to get results from them? Usually firing every single person and starting to hire for your high standards is not an option.
There is your idealised view of how software development should work and then there is the real world. I prefer to stay grounded in the real world and figure out actual ways to help people succeed rather than telling them how they should be performing and firing if they can't meet my standard.
Whatever you think about what people "should be feeling", the truth is when they made their last commit almost everybody feels they finished their work and when it is thrown back to them they do not welcome it. I have never seen a hiring process able to only pass people who are happy to get review comments requiring them to review large part of their work.
After quarter of century as a developer with 1/3rd of this time in pair programming teams I can say that's not true.
Works goes faster when you work with another person even if for the fact it is harder to procrastinate.
And problems are always easier and cheaper to solve the earlier in the process they are caught.
Then there is the simple fact that a well executed coding review will take significant portion of the time it took to make the change. Most coding reviews are really only cheaper because the reviewer is just skimming the code to see for obvious faults. So it is not really apples to apples comparison.
This is the worst time to try to fix anything. The author has just finished (or thinks he finished) the work and any attempt to change anything by the reviewer is going to elicit resentment in most people. Try to tell the person the change cannot pass and you can make an enemy. Or you let the change in because you like the person. Either way, it is bad.
And all this for naught because in my experience the law of sunken cost comes into action and people will try to push it as much as possible unless it really has a critical flaw.
For this and other reasons I prefer pair programming as an alternative to code reviews. Work progresses faster when two people do it (vs slower when one has to finish it and then another review it). You actually have two people understanding what happened. And you can avoid all of the drama because problems get fixed as the solution is being designed and written.
And yes, this is a good (or at least better) time to teach. Though I try to not be preachy and instead prefer to demonstrate how I solve problems and comment on why.