I personally think this is bad advice. I've experienced this kind of method through a friend of mine; it was always more frustrating than it was worth. I knew he has good intentions, but the truth is, different people learn differently*. When I ask questions, its often to try to build context or a mental map before I tackle a problem. I think that, while being cryptic and only answering questions with more questions can help nudge certain students in the right direction, it will just frustrate and confuse others. My guess is that for every student you've found this method successful with, there were 3 students who just gave up on asking you for advice because they'd just assume you'd elude them again -- and these are invisible failures.
Personally, I stopped asking that certain friend for advice after one too many frustrating sessions.
That really depends on what you want this certain friend to do. Usually, when the context is not learning, you want to hear answer with the nuts and this is universally true.
We don't comment on code review with "What do you think this does", we say "Here this is wrong because it will do X and to fix you need Y".
But when it comes to learning, I can't fault the other approach because that is clearly the better way to drill the programming mentality over to the learner. Almost all good engineer knows where to look, and syntactic or logical problems in any context are solved in a very similar way. People who don't have this structured method to approach a bug are going to find trouble in software engineering.
If the change is simple, i.e. obvious with an visual examination, or if the bug is straightforwardly presented in the stack trace, in a learning context it's imo more helpful to have you go over the problem and arrive at that conclusion yourself.
I've had multiple instances with multiple different people that come to me with problems that are pretty much repeats - I've since adapted to "I'll give you hints but you'll need to figure out yourself" in the context of learning.
Yes, I don't disagree that sometimes toiling over a problem yourself is the most rewarding. I think most people have experienced this. This is the purpose of exercises in textbooks. But most textbooks don't solely consists of exercises. I was responding to this idea of never giving direct answers, only always posing more questions, which I think has a high potential of backfiring. As another user pointed out in this comments thread, I believe the best approach to take is first get an understanding of what the student already knows and understands, how best they learn, and form your instruction around that.
When it comes to working with people, it’s usually clear who learned programming by rote memorization and who actually noodled their way through a formal education. I’ll do almost anything to avoid working with the former. They just can’t carry their weight, most of the time.
> the truth is, different people learn differently
This is the same conclusion I came to as a computer science TA in college. At first, I was naive and tried to teach people the way that I would find it effective to be taught, and I was a bit stymied by this. I slowly started trying different strategies for teaching things, and once I made the (somewhat obvious in hindsight) realization that different students learn in different ways, it became a fun challenge to find a method that worked for a given student.
I'm not a teacher, but a parent of young children. Echoing an educational scientist from my country: the key point for effective teaching is to realize how or what does the student or child understand right now. This should be the baseline of your explanations.
Personally, I stopped asking that certain friend for advice after one too many frustrating sessions.