This is pretty much how I taught my High School Computer Science classes.
The biggest step for me was to never touch the student keyboards. And then I basically only answered their questions with more questions.
Sometimes I would hear students grumble "He never answers my questions...", But in the long run, they would start asking themselves the same questions they knew I would ask (what did you expect it to do?, what did it do?, Why did it do that?)... Then they would usually solve their problem without me!
Or, when they called me over they would start with "I tried a, b, and c" and got results x, y, and z" which is a way better start to a learning experience for everyone than the old "it doesn't work, fix it, please"
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.
When I tutored computer science at the community college, I often felt like some of our students were constantly trying to trick me into writing code for them. Idk if other tutors often did that for them or what, but it was frustrating for me.
Avoiding getting sucked into touching their keyboards was what I had to do, too.
I don’t mean to sound cynical, but it’s possible that these students simply got away with this strategy for their entire academic “career” up to that point. I.e. complain about the difficulty of the task, throw your hands up, ask for “help” enough times until the teacher basically solves/explains the entire problem for you and then just copy their exact solution.
The idea that a teacher should ever touch a student keyboard in a computer science or programming class to me is absurd.
> The idea that a teacher should ever touch a student keyboard in a computer science or programming class to me is absurd.
I agree.
In this case, the students who seemed to work this way were mostly (all?) ESL students, and none of the tutors spoke the native language of the students. So it could be difficult even to indicate what you wanted them to look at, and it was especially frustrating when the errors they were dealing with were trivial syntax errors.
I would see this a lot, too. I think in many cases it is a coping mechanism that they develop and may not even realize they are doing it.
You see articles about not praising kids for being "smart" because that praises something innate about them, but instead praise them for working hard or growing or learning. Sometimes kids that are "smart" in middle school don't have to work/learn/study because everything just makes sense. But then they get to high school and their grades start to dip because their "middle school smarts" don't apply to high school material and they didn't develop the skills to study/learn effectively. But they are known as "smart kids" and smart kids get good grades... So they need to find ways to get good grades... because they are "smart kids"
I hope I was able to help some of those students unlearn some of those habits and develop more educational ways to "get good grades"
> Sometimes I would hear students grumble "He never answers my questions..."
Did you ever explain why you are doing this? After walking a student through their problem I would praise them and point out they solved the problem themselves. Some people may perceive your style as you being annoyed or unwilling to fully help, so explaining explicitly why you're helping that way would be good.
Yeah, I don’t see the point in just stubbornly only responding with more questions. As an instructor you could actually instruct. Why not say “a good technique when you get stuck is to ask yourself these 3 questions…” instead of just cryptically asking the questions and hoping they come to this amazing epiphany that wow my instructor wasn’t just being cryptic because they’re a jerk, they were doing it to teach me!
I absolutely hated primary/secondary school until I realized all these "difficult" methods were designed to help ME learn.
Naturally the attitude at that age is "Oh my gosh the teachers love torturing us >:( they hate us >:( school bad >:(". I'm forever grateful for the gifted program at my district for teaching me otherwise. Writing this comment gave me a rush of nostalgia, I think I'm gonna go visit again
Yes, it took me too long to realize this too... so I immediately told my kids this is the reason for all of the exercises they have to do. When they approach it from the perspective of its purpose, then they take the time to learn it rather than just trying to finish it.
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 still think there are also questions which are best answered straight, like 'how many bytes does a float have? Do arrays start with 0 or 1 in this language? Is printf of %s with null argument, undefined behaviour, implementation defined or actually standard conforming'.
You've been down-voted, but you're absolutely correct in some situations.
Sure, answering those questions with "this is a great opportunity to learn how to read the documentation" is the "right" response.
But I think we've all experienced the frustration of trying to write something in a language we don't use every day, and 'wasting' our time looking up simple things ("okay, what's the exact syntax of a for-loop in this language again?") that just adds friction when we're trying to solve a problem. There's a reason programmers complain so much about being interrupted.
Part of being a good teacher is being able to make those points of friction disappear and enable your students to "get it" and experience the joy of solving a problem.
Don't let perfect be the enemy of good. How many kids would play football/soccer if you were only allowed to play a match with regulation numbers of players on each side, and stopping play every time someone didn't have 'perfect' form?
I suspect they were downvoted because the initial commenter didn't say they only answered questions with questions or that they never provided more traditional instruction. GP is arguing against something that wasn't even said.
Those kind of questions are a great opportunity to show a student where to find documentation and how to read it, because that is a daily journey that will never end.
"How many bytes does a float have?" is a bad question to ask. Languages may implement floats differently. If someone asks "how many bytes does an ieee 754 double-precision floating-point have?" then sure, answer 8 bytes. But "how many bytes does a float have?" is precisely a question that should be further defined.
I think this method of teaching works well if this lines up with how the students are evaluated. The students willingness to accept this form of teaching is entirely reliant on how they feel this will impact their final grade. That's why it's important to align your grading and evaluation style with your teaching style if this is what you expect from students. That way, they'll be more inclined to go with the flow knowing that it won't bite them on the other end when it's time to take a test.
That's an excellent point. I actually stopped grading lab assignments. I found students were more interesting in getting "the answer" than learning the material. This would lead to students making decisions that optimized for"having the answer" but were detrimental to "learning the material".
Once I stopped grading the labs, it freed students to experiment and learn rather than rush and stress about the due date. It didn't really matter if they finished the lab, as long as they learned something along the way.
There was, of course, much more to my classes than the labs. Lectures, group activities, "kahoots", discussions, prelabs, funsheets, etc... Lots of ways to assess a students understanding and help catch the ones that are falling behind.
As a CS teacher, I think there is a time for touching a student's keyboard and a time for leading them with questions or some other method. You have to read the student. With weaker student's I will sometimes set them up with a partial answer and get them to complete it, or show them multiple solutions for a similar problem, hoping one will spur on insight.
Some people learn better by doing and discovering, others better by initially imitating and still others in different ways at different times.
For me there are no preferred methods, just a toolkit I build on and pull from as I learn more about teaching.
This works if the student already has a grasp of how to write software. The new teacher here does your method with new students just learning the syntax, and it's a failure. Treat them like they're learning french. First comes meaning of words, then how they're applied. Examples of it, what it means, and then how you change what it means to mean something else. Practice and Exposure is the only way to effectively learn any language. These students are going to entirely forget what a for loop is after their class and switch majors when the next classes depend upon fluent understanding.
this is so true! my brother started learning to code later on in life, i knew he looked up to me but also, he knew he could ask me for help whenever and i helped him as best as i could, but i get busy working on projects and cannot always answer a text message or phone call. i would see his message later on in the day and listen/read his messages and it would start out asking for help and about the 2nd or 3rd and sometimes 4th message he would have it figured out and i was happy about that because he did what i think is the most important thing when it comes to long term mastery of any skill
he figured it out on his own or was at least was able to recall the knowledge from within. if i would have took over his keyboard he wouldn’t have imprinted that as fast, i heard this saying once and it’s encouraging for others to hear/read as well so i’ll say it
“when you are confused, don’t be upset at yourself, it is a good sign. confusion means you thinking about something new or from a different perspective, and that means you are learning”
it’s a humbling experience, i get it, but not a sign you will never understand something, in fact, confusion is the first sign that you are getting it. be encouraged
The biggest step for me was to never touch the student keyboards. And then I basically only answered their questions with more questions.
Sometimes I would hear students grumble "He never answers my questions...", But in the long run, they would start asking themselves the same questions they knew I would ask (what did you expect it to do?, what did it do?, Why did it do that?)... Then they would usually solve their problem without me!
Or, when they called me over they would start with "I tried a, b, and c" and got results x, y, and z" which is a way better start to a learning experience for everyone than the old "it doesn't work, fix it, please"