views:

388

answers:

12

I'm a computer science student finishing up my second semester of programming classes. I've enjoyed them quite a bit, and learned a lot, but it seems other students are struggling with the concepts and assignments more than I am. When an assignment is due, the inevitable group email comes out the day or two before with people needing some help either with a specific part of the problem, or sometimes people just seem to have a hard time knowing where to start.

I'd really like to be able to help out, but I have a hard time thinking of the right way to give them help without giving them the answer. When I'm having trouble understanding a concept, a code snippet can go along way to helping me, but at the same time if it makes a lot of sense, it can be difficult to think of another way to go about it. Plus the Academic Integrity section of each assignment is always looming overhead warning against sharing code with others. I've tried using pseudo code to help give others an idea on program flow, leaving them to figure out how to implement certain aspects of it, but I didn't get too much feedback and don't know how much it actually helped them out, or if it just confused them further.

So I'm basically looking to see if anyone has experience with this, or good ways that I can help out other students to nudge them in the right direction or help them think about the problem in the right way.

A: 

One of the most common problems in teaching is determining whether the student understood you. An easy and effective way to determine if you should continue or rephrase is to have the student demonstrate their understanding by doing something closely related but not identical.

Also, since programming is essentially word problems, it's important that the student break things down into steps. I'd be asking to see their highlevel step-through before I showed them anything. Too many people get hung up in syntax and never really nail down what they're trying to do before diving in.

dnagirl
+3  A: 

Some thoughts:

  1. Do pair programming

    Have the student (the person you are helping) sit in the chair and code something. Could be a code snippet, could be a portion of a project, anything, as long as it represents something they have trouble on. As they go, point out (not rudely) places where they may have done something incorrectly, or something that could be improved upon.

  2. Review work done

    One of the things that helped me the most was to have a peer (as opposed to a teacher or student aide) review my code. Most of the time the peer could point out places where they might have done something differently.

  3. Make them repeat you.

    I often make people I'm helping learn repeat what I just said to see if they understand it or have any questions. You would be surprised how often people don't speak up when they don't understand something.

  4. Offer help before the project is due.

    Trying to get the project done the night before it is due is a surefire way to, at the very least, not learn the concepts as thoroughly as you might have otherwise.

  5. Don't code it yourself

    Your peers will learn nothing if you do it for them.

  6. Find other resources

    An aide, a friendly professor, another one of your peers can be invaluable resources. If you find that your style of teaching doesn't mesh well with one of your peers' style of learning, point them toward someone else who might be able to help them more.

  7. Hope for the best

    You can only go so far when teaching someone; they have to want to learn.

Matthew Jones
Oh, and 8: Don't offer help unless you are sure you know what you are doing. Bad advice is often worse than no advice.
Matthew Jones
+8  A: 

I've worked as a TA and at a CS department help desk (and helped buddies). This is what I do...

Abstract out the issue, find a related problem, then work through the related problem with them. If they can't make the connection, you can't really help them.

Edit: and refuse to help with more than the bare basic syntax if they are looking for help the day of or day before. Things should have been dealt with long before deadline. Crutching people on the day-of is not a good practice for you.

Paul Nathan
Definitely a good way to go.
justkt
+2  A: 

One thing that might be helpful to your fellow students is to point to similar code in the lecture notes (or if you don't get lecture notes handed out, in your own notes). That way you're only showing them what the professor said, but doing it in a helpful way.

If another student is open to it, asking them questions about everything they've tried and why would be helpful.

Finally, consider going to your professor and asking for his or her input on what you are allowed to do and how they might suggest you help others. After all, professors have years of experience in teaching students. Even more, will you have an opportunity as an undergraduate to be a TA in future years? I got to TA as an undergraduate, and that helped me to productively use my impulses to assist others without breaking any honor codes. If you have such undergraduate employment opportunities, letting professors see you now as the helpful type will help you acquire them.

justkt
A: 

First off I hope you a primarily concentrating on getting a good degree. Lecturers are there to help weaker students.

Having said that it is good that you are taking in interest in helping those around you. Sounds like you are on the right track with not giving them the code directly.

Your pseudo code idea sounds good and in addition to that you could spend some time discussing the issue with them to help clear their minds on the problem. (only if you have the time)

If they are having a lot of issues with many assignments it probably means they should be considering switching degrees. Programming is not for everyone.

Good luck!

AJ Dhaliwal
+15  A: 

Have them explain their code to you.

This accomplishes several things:

  • First, it demonstrates that they actually have code to show you. How can they not understand something if they haven't even opened up a text editor yet?
  • Next, it demonstrates that they understand the code at a basic level. They could have copied it from somewhere. If they don't know the first thing about the code they have, that's a flag. (If they did copy the code, but still took the time to understand the code, then that's still academically dishonest but it's a valuable skill to use after college.)
  • Finally, now we're at the place where they might actually get it, with your help (or possibly even without!) If they get to the place where the hole in their understanding is (as they're explaining their code to you) and it jumps out at them, then they've solved their own problem. If they don't recognize the hole, then this is where you can give them targeted hints.
John at CashCommons
Good advice, I really like having them explain their code. Sounds like a really good way to get started and figure out what they really do and don't get.Good advice all around, I appreciate all the input.
David Barry
Agree, a good approach. Basically rubber ducking where you are their rubber duck.
derivation
@derivation, I think that was from Pragmatic Programmers or Code Complete but I can't remember which.
John at CashCommons
I agree it's good to help and if someone is keen and willing to learn, but doesn't quite get something then definitely offer help.Equally, there are some people who probably aren't interested because they haven't quite grasped it. They could probably just do with a bit of encouragement.I'd steer clear of people that aren't willing to learn though - I remember some of the idiots on my degree who would be starting their assignments on the day they were due in, rather than myself and close peers who would start as soon as possible after being given it.
Michael
This is definitely the easiest way to help someone out. Explaining their error almost never conveys learning, but letting them work through their reasoning out loud, formally, generally gets the job done.
Stefan Kendall
A: 

A general experience in explaining stuff to others is to find out where they stand first. Try to refrain from giving them solutions to problems they don't even have yet (even if you are sure that they will come across them later). In other words, don't go two steps ahead of them. If they have problems understanding call-by-value, don't explain them recursion.

Space_C0wb0y
A: 

PSYCHOLOGICAL APPROACH

show them some popular real world APPLICATIONS (as an example) which they use day to day...written in same programming language you are trying to teach.....

  1. explain every thing with background
  2. give every student, considerable importance
  3. alwaysss use colour coded syntax
mujahid ali
People are not pokemon.
Stefan Kendall
A: 

As far as helping fellow students in general, I generally use the "play stupid" approach. I pretend that I know nothing about their particular assignment, and I ask them to get me up to speed on what they are supposed to be doing. I also ask them to give me a quick run-down of what they learned in class about whatever concept the assignment is about. This usually takes about 5 minutes and about 95% of the time, the other student has answered their own question by the time they finish explaining it to me. If they haven't solved it by this point, I ask them to walk me through their solution to the assignment. In doing this, they usually catch where their solution deviates from what they just said they learned in class.

As far as programming-specific help goes, I sometimes ask the other student to send me their code and I run it through a simple shell script I wrote. That script blanks out everything in the code file that is not a comment, and I give the result to the other student to read. The resulting file usually reads like an outline of their code, and a lot of times they can see where their code went wrong simply by getting the code out of the way. If their approach is completely wrong, I tell them to write an outline of what the code is supposed to do (in high-level terms) using comments; after completing this, they fill in each section of the outline with code that implements that outline step (testing each "chunk" as they go). This helps a lot of people separate the code from the algorithm (many common problems I see stem from the lack of a systematic or disciplined approach to problem solving, and this exercise helps get them on the right path).

Another method is to answer questions using a different programming language. For example, I helped several of my fellow students on Matlab projects by explaining the concepts using C, Ruby, or even pseudo-code (that read more like plain English than code). I knew that they had far more experience with other languages, so I used what they knew best to illustrate the concepts and encouraged them to try solving the problem in their "native language" first. Once they were confident that they understood the concepts, they could work on figuring out how to implement them in the target language. Having to learn new concepts while you are still learning a language makes both more difficult. This approach also helps determine whether they are having trouble understanding how to solve the problem or how to code the solution.

bta
+2  A: 

I don't think you should be helping them. I think it's academically dishonest. Also, it does them no help to have you give them answers, or even to have you be around to answer questions, since once they get to the exam (or the real world), you won't be there for them. They need to not only learn how to program on their own (which presumably you're helping them do), but also get their questions answered on their own. That means posting on places like StackOverflow. You might want to recommend that they formulate a specific question (always a good exercise) and post it on here with the "homework" tag.

When I was taking CS classes in college, there were a number of students who just couldn't code or design at all (and I'm thinking of a senior level software engineering class in particular). They also had no idea how to go about solving problems, or where to look things up, where to get questions answered, or what questions to ask. They were totally helpless because they had spent most of their undergraduate time working on their homework/projects in groups and having the more talented group members hand-hold them. Don't perpetuate this. The last thing the industry needs is more incompetent programmers who graduate with good grades to put on their resume.

rmeador
You make a very good point. Helping them write the programs is what I want to try to avoid, If I'm going to be giving help to another student I want to make sure that my assistance would help them realize how to tackle the problem themselves. One of the things I see is people seeming to not get modularization. I feel there are some areas like this some people could use a guidance to help make the idea click. Very good response though, If I give help in the future I need to make sure it's someone looking to learn, not looking for the answer.
David Barry
I disagree. Helping them is not the same as giving them answers. Helping them is more akin to re-teaching a concept they may not have learned the way it was taught in class. Using that to solve their problem is still up to them. You said they need to learn how to "get their questions answered on their own", but isn't that what they're doing by asking you for help? I agree that dragging someone else's dead weight around is a bad idea for all involved, but I wouldn't say that is a reason to avoid helping fellow students entirely.
bta
+1  A: 

Whenever I tried to teach my girlfriend how to program I did almost nothing but ask questions. (she got to the .each statement before getting bored)

Ask them question how their code works and how they think they could accomplish the task. Give them small nudges in the right direction. And never EVER type something for them. If you have another computer and type code on it to show them and show them the results, that is fine but don't over do that.

Earlz
+1  A: 

Here's the advice I give my student teachers: avoid giving answers to students. Instead, ask them questions. And make sure to ask questions that they can ask themselves in the future. For the material I teach, here are some of the questions I want all students asking themselves:

  • What is your abstraction?

  • What is an example of how your abstraction is supposed to behave? Can you show me another example?

  • Are there any examples of where you abstraction is allowed to fail? How should it fail on that example?

  • Have you tested these examples?

  • What is the representation of your abstraction?

  • How does the representation relate to the abstraction? Can you show me a picture? Can you show me in math?

  • What functions are allowed to see the representation? What is the contract of each function? Does the representation satisfy an invariant that the function can assume? Does each function make sure the invariant is preserved?

  • What does valgrind say?

Norman Ramsey