Did you find that this method resulted in less, more or the same number of students that just couldn't follow? I've been thinking about this a lot as in France we have a few "alternative software school" that use the "basically figure it our yourself" method a lot, and while it's sometimes frustrating as an experience, it really prepares you well for what you're going to face.
I intuitively think one flaw would be that less student would be able to finish the studies, but on the other hand these students wouldn't probably make it in the professional world either.
I can’t speak for the person you’re replying to, but I suspect the idea may be that the students are able to “make it” in the sense of holding down a job, but not in the sense of being particularly competent / productive.
That's a good talk, and people should watch it. But as I recall (it has been a bit since I watched it, probably 6 months) she doesn't argue that we should only give answers to students, but that we should give more answers to students than many (especially self-taught programmers) might think necessary (or desirable).
The research basically showed that rote learning (the thing so strongly objected to here on HN in many education discussions) is actually effective. But that doesn't contradict the idea that self-guided exploration is bad (paired with an instructor answering questions, even questions with questions), it just shouldn't be where we start or the sole way we teach.
In particular, a common objection to rote teaching programming is often along the lines of, "I taught myself assembly on a Commodore 64, anyone can do it [and I'll imply that it's the best way to learn]." Which can work, and can work for many students. But it's not effective for every student, and creates an artificial barrier (for the majority of students who will learn better, faster, or even at all with a more traditional presentation of the material).
I made it a point that "if it is on an assessment, then they will have seen it in class"
No tricks, no novel algorithms. Just show me that you learned the things that I tried to teach you.
If a lab asks you to write a for loop that prints all the strings in an array, then I've taught the syntax for strings, printing,accessing elements from arrays, getting the length of an array, writing a for loop, etc... There have been hands on activities and/or funsheets for each of those ideas that include fill-in the blank questions where they get the framework of for loops with arrays.
And they get handouts with the syntax / code structures / algorithms.
And they get those worksheets/handouts/etc to reference while working on the lab.
In a classroom environment, it's important to teach and build the foundation to solve problems. But then it's important to make the student do the work to build the connections so they actually learn something. Even if the something they learn is where they can look to find the answer to a question like "does an array start at 0 or 1?"
In my eyes learning to programm is on of those things that is a out a stract connotations or ideas how we think something functions much more than actual experience.
When you learn gravity, of course you can watch an apple falling from a tree and fogure it out yourself. But you could also watch an apple falling from an tree, try to figure it out for a while and then get a fascinating deep dive in the physics behind it, and then take another dive at the issue.
Just by presenting the issue in the right way instructors can make the difference between people who struggle to grasp something and people who already have the right abstractions in their head but only need to figure out what it means in practise.
The worst peogramming instructors are those who are like: "It was nearly impossible for me to learn this, why do you think it would be easy?"
I intuitively think one flaw would be that less student would be able to finish the studies, but on the other hand these students wouldn't probably make it in the professional world either.