[karolinepauls]

Good riddance indeed. The last 30 years of software teaching basically trained developers to produce complexity for its own sake, while calling it engineering. I'm not sufficiently full of myself to link to my own writing (yet) but I'm full of myself enough to self-paraphrase:

1. Programmer A creates a class because they need to do create an entry point, a callback, an interface... basically anything since everything requires a class. Result: we have an class.

2. Programmer B sees a class and carelessly adds instance variables, turning the whole thing mutable. Result: we have an imperative ball of mud.

3. Another programmer adds implementation inheritance for code reuse (because instance variables made factoring out common code into a function impossible without refactoring to turn instance variables from step 2 into arguments). Result: we have an imperative ball of mud and a nightmare of arbitrary dynamic dispatch.

At some point reference cycles arise and grandchild objects hold references to their grandparents in order to produce... some flat dictionary later sent over the wire.

4. As more work is done over that bit of code, the situation only worsens. Refactoring is costly and tedious, so it doesn’t happen. Misery continues until code is removed, typically because it tends to accumulate inefficiencies around itself, forcing a rewrite.

[chii]

All of these things you've described are actions taken by someone that has not had a deep think about their code and organization, architecture and patterns. It reeks of inexperience, and/or pressure to get shit done without needing any time/deep thinking on how best to do it.

While the teaching is partially to blame, i say it is more that most people are sloppy and undisciplined thinkers. When they dont have any incentive to produce disciplined code, they wont.