I agree. But over the years I've come to understand there are two kinds of learners;
a) "I learn what I need to accomplish this task". This is observed as question/answer and only the simplest version of the answer is needed. So something like "how do I create a variable x and assign 10 into it. All he's looking for is
x = 10
b) The second kind wants to understand the nuance of what's happening, so they can apply that nuance to future code. They are looking for an answer, but the are interested in the working that leads to the answer. So in the above example they want
x = 10
var x = 10
let x = 10
options{x:10}
and so on. They digest when to use one and when to use another, and they delight in using the correct form in the correct place.
In my experience (a) programmers will get through tasks quickly, but with shallow understanding. They will eventually have all the tools, but lack the ability to see the big picture. They struggle to read other people's code.
On the other hand (b) programmers learn much more slowly, they take a lot of time to accomplish tasks because they are being distracted by their curiosity. But after that investment they easily outstrip their peers in productivity, and more importantly can do things that an (a) type programmer can never do.
What I've come to accept though is that giving a (b) answer to an (a) questioner just leaves them confused. They asked about assignment, and a discussion of scope just leaves them befuddled (since they don't know what scope is anyway). Which can be frustrating to the answerer who is a type (b).
Type (a) should not be doing a Masters program in the first place, so I feel your pain in that regard. Google is great when you're out in the world, but it's a terrible way to "big picture" learn.
Great explanation! I wish I could influence the student intake but as a faculty I find it difficult to negotiate with the administrators whose objective function is to maximize the program enrollment! So I have accepted the status quo. Nonetheless I show them how I would solve a specific problem without going to Google at all.
Alas most post-graduate programs are under subscribed, and it is important for reasons of prestige etc to maximize enrollment. There is no point in trying to convince others to reduce numbers - those are the very metrics _they_ are judged by.
I've [1] adopted the approach of meeting the student where they are answering their question, then trying to take them one step further. I try to encourage good habits, and at the same time ceasely mock bad habits (in a gentle, running-joke, kind of way.)
That said I also demonstrate the use of Google in answering a bunch of questions, for which the internet is overflowing with answers. Google is a fantastic resource and there's a lot of great stuff out there.
[1] I am not an academic, and my "students" are not in school. They are typically professionals, trained in another discipline, who were around when computers started, and there was no software so they had to write their own. They have 40 odd years of programming experience, but usually with zero formal training. Seeing individuals in this age-group make breakthroughs though is immensely rewarding.
a) "I learn what I need to accomplish this task". This is observed as question/answer and only the simplest version of the answer is needed. So something like "how do I create a variable x and assign 10 into it. All he's looking for is x = 10
b) The second kind wants to understand the nuance of what's happening, so they can apply that nuance to future code. They are looking for an answer, but the are interested in the working that leads to the answer. So in the above example they want x = 10 var x = 10 let x = 10 options{x:10}
and so on. They digest when to use one and when to use another, and they delight in using the correct form in the correct place.
In my experience (a) programmers will get through tasks quickly, but with shallow understanding. They will eventually have all the tools, but lack the ability to see the big picture. They struggle to read other people's code.
On the other hand (b) programmers learn much more slowly, they take a lot of time to accomplish tasks because they are being distracted by their curiosity. But after that investment they easily outstrip their peers in productivity, and more importantly can do things that an (a) type programmer can never do.
What I've come to accept though is that giving a (b) answer to an (a) questioner just leaves them confused. They asked about assignment, and a discussion of scope just leaves them befuddled (since they don't know what scope is anyway). Which can be frustrating to the answerer who is a type (b).
Type (a) should not be doing a Masters program in the first place, so I feel your pain in that regard. Google is great when you're out in the world, but it's a terrible way to "big picture" learn.