Then you are a bad instructor, obviously.
Because it’s often not like this and the difference is usually in the instructor.
That’s what I take from that.
(Other than common sense about meaningless mimicking versus gradual understanding from small steps, confirmed by plenty of research about didactics.)
People are different. For me personally “trusting the process” doesn’t work at all. Fortunately no, you don’t have to, generally.
Seem to be 2 problems. One is obvious, the other is that such tedious boilerplate exists.
I mean, all engineering is divide and conquer. Doing the same thing over and over for very different projects seems to be a fault in paradigm. Like when making a GUI with tcl/tk you don’t really need that, but with qt you do.
I’m biased as an ASD+ADHD person that hasn’t become a programmer despite a lot of trying, because there are a lot of things which don’t seem necessary, but huge, turning off my brain via both overthinking and boredom.
But still - students don’t know which work of what they must do for an assignment is absolutely necessary and important for the core task and which is maybe not, but practically required. So they can’t even correctly interpret the help that an “AI” (or some anonymous helper) is giving them. And thus, ahem, prepare for labs …
Not sure which particular parts are confusing, so I’m going to guess and rephrase like this:
People are obviously different, it’s obvious that a certain process can’t fit all sizes, so if there’s a kind of “attitude” with which that process fails, then the problem can be both with the process and with the attitude.
And in my personal experience there are processes which work just fine with that attitude.
Processes are built for human needs. Not humans are built for processes.
So the problem is with the process, which includes the instructor who seems to think that it’s not.