> To some degree, having spaghetti code and all globals is useful for teaching because it 1) gets people excited to program and see something working and 2) demonstrates why you don't want to do those things. I remember when trying to write my first text based CYOA game, I was so excited to add content to it and see it on screen, but also learned very quickly that having to scroll through 20 pages of if statements was not fun, and why functions would help. I'm not sure if someone explaining "encapsulation" to me would have really taken root.

While I'm certainly no fan of spaghetti code, I think this is an important kind of experience for novices. I, for example, let mentees at work go down a wrong/weird path with their code for a couple weeks when I see bad code patterns or poor choices in algorithms/data structures in order to give us something to discuss and correct later when they start to hit pain points that I, usually correctly, predict they'll hit. I let them know that they're making their life harder, but I don't direct them to change course (some do on their own, others don't). Telling someone who's just learning how to do things the "correct" way (to the extent that there is a singular correct or a small set of correct options) doesn't give them sufficient motivation and experience to actually learn and internalize it. Often you get a kind of cargo cult mentality around the things you teach them since they lack comprehension of why those are good ideas or better ways of organizing code or whatever, or a later rejection of what they're taught because they don't understand the motivation behind it.

Also, letting them go down the path of spaghetti code or confused structures gives an opportunity to teach them refactoring techniques, which even expert programmers still have to apply to systems they develop (most people don't write perfect code on the first pass, and most systems having changing requirements which would render the perfect code imperfect if they did).