I'm increasingly forgiving of that kind of "primitive" code with giant, heavily nested functions, because the worst that can go _wrong_ with it from a maintenan

I'm increasingly forgiving of that kind of "primitive" code with giant, heavily nested functions, because the worst that can go _wrong_ with it from a maintenance standpoint is heavy duplication and overreliance on mutable state. Those are knowable quantities, and you can attack them systematically. Otherwise, everything is laid out for you in straight-line order. You can just read it and see "this happens before that" without having to run the program or a debugger, and nobody even has to burden themselves with giving "this" and "that" an explicit name(although a comment can be a real boost to finding what you want). Codebases that are cleverly factored to within an inch of their life are much, much worse. There's no guarantee that the original factoring successfully decoupled anything, and all the additional content allows for new bugs to slip in "between the cracks" - parameters left accidentally unset, a hierarchy of functions getting called in the wrong order, etc. The original programmer has to spend more time coming up with ways to name and enumerate these details, allowing their eyes and thoughts to be taken off of the domain problem. Because more powerful programming tools are used, more powerful debugging techniques become necessary. And when the architecture breaks, the call stacks just get deeper as the heavy metaprogramming guns are brought out to make increasingly clever workarounds to the resulting issues - after all, nobody really wants to try to disentangle the code after it hits the point of architectural meltdown. Of the two, copy-paste coding is definitely the lesser evil. So I allow some of that first and then clean up the low-hanging fruit.