I struggled with this a few times: “When a person signed up to do a job for him, he would in turn trust that person to accomplish it; he wouldn’t break it down into little pieces and make the task small, easy and dull.”

I’m not particularly talented, far from it actually, but many times I’ve worked in teams with non-junior people who were tasked to do some portion of a project, and simply delivered garbage: a terribly over engineered solution in a component where over engineering was actually very dangerous (e.g. doing distributed systems using several small bespoke moving parts rather than a single solid leader election mechanism, or even better getting away with something leaderless and more elegantly stateless, to give a recent example).

In those occurrences, I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, until the other person really had to finally move to a solution much more similar to the one I had in mind (much much simpler). Sometimes this required an embarrassing feedback loop of 10+ round trips, where every time I’d just look at the newly delivered code say “this doesn’t work in a X scenario”. And I was not in a better position from a knowledge perspective, we were essentially peers.

I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public), but at the same time, how could I have acted differently? The end result was really orders of magnitude better, more robust and smaller.