Re:Don’t Teach During Code Reviews
by strix_varius on Sunday February 05, 2023 @05:59PM
(#34670702)
> There are better places, and ways, to teach junior developers than long, painful code review processes.
If I had to choose the best single way to grow as a software engineer, it would be through code reviews: both giving and receiving.
That said, "long, painful" code reviews is a red flag for your team. A code review should have one of four outcomes:
1. Lgtm.
2. Approved. Left some suggestions for your consideration.
3. Specific changes requested.
4. This whole approach needs to be re-evaluated, let's talk.
_None_ of those should be long or painful. It sounds like your team might be doing #4 in the PR itself when really that's an exceptional case that should make it to a usually-synchronous discussion.
If I had to choose the best single way to grow as a software engineer, it would be through code reviews: both giving and receiving.
That said, "long, painful" code reviews is a red flag for your team. A code review should have one of four outcomes:
1. Lgtm.
2. Approved. Left some suggestions for your consideration.
3. Specific changes requested.
4. This whole approach needs to be re-evaluated, let's talk.
_None_ of those should be long or painful. It sounds like your team might be doing #4 in the PR itself when really that's an exceptional case that should make it to a usually-synchronous discussion.