I can see the point on being a bottleneck. I'd still argue that's probably a good bottleneck to have though, and certainly better than letting the code quality

I can see the point on being a bottleneck. I'd still argue that's probably a good bottleneck to have though, and certainly better than letting the code quality slip. It depends on the timelines and priorities, but I'd rather work somewhere that invests time up front to save time later. I strongly disagree that the co-workers would not learn from said refactoring. That's very pessimistic on either the coworkers reading comprehension, or pessimistic on their attitude or willingness to engage with the changes without being forced to do so? I don't know I find it amazing when someone offers a refactor suggestion, whatever amount of "doing it" they do for me, I find I learn a lot from learning what the changes actually are. If they do it themselves I get a really good feel for their style and what I can learn from it. edit: And on the flip side, I find it's sometimes faster to just make a small refactor change than to explain it in person --- but this depends on the physical locality of teammates and schedule conflicts. In other cases it's easier to swivel the chair around and poke them on the shoulder and explain the refactor than to make it. Which is easier depends on priorities, chain of command, schedules and all that.