For the most part this article makes sense and is interesting. The conclusion of what to do about it in his particular case isn't the best solution though IMO. This idea of leaving a short review on code that has fundamental problems, and then rewriting it later on yourself, is not sustainable and not helpful to the junior developer. Now you have the problem of the developer not gaining any new insight into how the solution could be improved, and they'll continue to make those same mistakes in the future. Along with the practicality that you're going to have an increasingly unmaintainable codebase. I definitely wouldn't want that as the person submitting code that needs improvement personally.
The approach IMO should be to leave reviews that are constructive and help the developer understand the issues in their code, so they can continue to improve (or show you why their approach is a good one) and over time the reviews will be less problematic because the team is on the same page. The fact that in the first example that instead of this, the developer continued to have problems and was let go, tells me the reviews must have really not been very constructive at all.
The idea of not being mean spirited or tearing people down is a good thing to share and think about, but don't go too far in the other direction.
For the most part this article makes sense and is interesting. The conclusion of what to do about it in his particular case isn't the best solution though IMO. This idea of leaving a short review on code that has fundamental problems, and then rewriting it later on yourself, is not sustainable and not helpful to the junior developer. Now you have the problem of the developer not gaining any new insight into how the solution could be improved, and they'll continue to make those same mistakes in the future. Along with the practicality that you're going to have an increasingly unmaintainable codebase. I definitely wouldn't want that as the person submitting code that needs improvement personally.
The approach IMO should be to leave reviews that are constructive and help the developer understand the issues in their code, so they can continue to improve (or show you why their approach is a good one) and over time the reviews will be less problematic because the team is on the same page. The fact that in the first example that instead of this, the developer continued to have problems and was let go, tells me the reviews must have really not been very constructive at all.
The idea of not being mean spirited or tearing people down is a good thing to share and think about, but don't go too far in the other direction.