Seems to me like "the unsupervised junior" isn't participating in the "Socratic method" the article discusses, but your experience does impugn the author's hypothesis that the burden of Junior Developers will drive out a better process ( as a forcing function) eg your "real code review" and "good process of defining tasks".
It might in a lot of places - if anybody even notices that there's a problem and if they then have the political capital to change it.
In this case, nobody really kept an eye on how things were being built, and the person was actually remarkably productive. I really don't have a bad word to say about them: they were given vague tasks and came back, for most of them, with working implementations. We're only a handful of people and everybody was busy elsewhere, but what little guidance and review we could offer was always accepted with much gratitude. They lasted about 18 months before moving to somewhere that offered more support, and I can't blame them at all.
What happened is predictable: things that ought to be in one place end up distributed in little pieces, and existing features got invasively modified to add new features even when that wasn't necessary. Poor separation of concerns, design patterns applied wrong, all of the stuff that over time adds up to a codebase that's hard to work with.
I think a lot of the refactoring we do would make a good book, actually, if any of us were the type to write about programming.
> I really don't have a bad word to say about them
...doesn't quite square with:
> I'm still cleaning up after the unsupervised junior two years later.
I can appreciate that misfactored code now helps "flatten the curve" and skirt under whatever deadlines you were respecting——even at the cost of a long tail of reactors——but its a shame that junior dev isn't around to learn from their mistakes, and also that they weren't paired with a more senior dev who could've coached them through those reactors at the time, enriching both the codebase and the human capital.
