How can a TA help a student who is certain she sucks at programming?

Question

I am a TA for an undergraduate Signals and Systems class (Electrical Engineering). As part of this, I lead a lab session, where we teach students how to code up various signal transforming operations in MATLAB, and visualize the transformed signals (for example, time-scaling, time-shifting, etc). So far it has been just basic stuff (it's only week 3), but the complexity will scale up quite a bit.

One of my students has some kind of "code-fright". She understands the theory (because there's a pre-lab in which you write down the theory of what you will be coding in the lab, and she does well here), but when it comes to coding, she just can't get started; her editor is blank till the very end, and she doesn't ask for help when I go to her; eventually, she's on the verge of tears, and is clearly very, very upset.

When I try to talk to her about what the code should look like, asking questions, and trying to get her to answer, she just remains stuck on the line, "I'm not good at programming". I repeatedly tell her that she has the theory down, and she simply needs to write it up in MATLAB, and reassure her gently that she can do this. But it doesn't help at all.

How do I help her out? The lab has 20 students, so as much as I wish, I can't spend more time with her. But I don't want her to forever think that "she sucks at programming".

EDIT - I forgot to add, this lab has teams. But she refuses to work with her partner (presumably because she wants to be able to do it on her own?). The partner does manage to get her code to work on her own.

Answer 1

When you tell her that she doesn't suck at programming, all she hears is that you don't understand how bad she sucks. The psychology is the important thing here, not pedagogy. If I were in your situation, I would say something like, "Yes, you do suck at programming. In fact, most of us suck at programming. (Heck, have you ever noticed that Windows doesn't work???) But by doing some of these exercises, we get a bit better at programming. Likely, you'll never be World's Greatest Programmer, or even a programmer, but by struggling, even unsuccessfully, with some of these exercises, you'll make yourself a stronger thinker. And therefore a better person."

I've gotten a lot more mileage out of "We all suck, so let's do what we can" than pretending that everyone's a genius.

Answer 2

About her not wanting to work with her team mate -- she may have some fears such as:

• that she'll feel embarrassed in front of her team mate
• that she'll rely too much on the team mate's competence
• that her phobia and/or incompetence will be contagious

Here's what I think would help:

• She needs a tutor to work with her outside the lab, one on one, several hours per week, ideally for 30 - 40 minutes per day.
• The professor should be brought on board and she should be allowed to turn in pseudocode on a temporary basis.
• In each tutoring session, the tutor should pose a programming exercise and ask her to write pseudocode, since (if I understood right) she's comfortable doing that.
• Next, to produce Matlab code, the tutor should scribe for her (write from her dictation), using pencil and paper, away from the computer -- ideally not in a computer lab.
• When she gets stuck on syntax, the tutor should allow her to look at an easy-to-use syntax cheat sheet (if one doesn't exist, the tutor should create one).
• As much as possible, the tutor should help her fix errors before they get to the computer.
• Once the program has been written completely with pencil and paper, they should sit in front of the computer together, but with the tutor in the driver's seat. Initially, the tutor should do all the typing and clicking.
• She may continue to be tearful and she may continue to say she's not good at programming. The tutor should not waste any time with pep talks and should not argue with her. At the end of each session, the tutor should give brief positive feedback, with eye contact, but without gushing.
• After several sessions, the tutor should say, at the end of the session, "Next time, you're going to type the second half of the program."
• At the next session, when they're moving to the computer, the tutor reminds the student, "Today, you're going to type the second half of the program." Next, the tutor types the first half and then hands over the keyboard and mouse. Now, the tutor needs to be as cool as a cucumber and just wait. The tutor may solve a Sudoku while waiting if desired.
• The next session, the same, but at the end, the tutor informs the student that next time, she will type the whole program.
• The next challenge might be to move toward composing at the computer -- but this stage might not be needed.

This is a bit like exposure therapy. The tutor should provide occasional positive feedback, but very businesslike. You know, and I know, and the tutor will know, that the student will be going through hell. But it is most respectful to just let her go through it, without making a big deal about it.

If she takes the initiative to speak about her feelings, the tutor should not interrupt -- but the tutor should keep the focus on programming (not talk therapy).

It might be helpful for the student to see a medical doctor to discuss possible pharmaceutical support for this project before beginning. That part is optional and the decision is very individual.

I don't know how you could help arrange for this. One obvious option is to find a private tutor who could do a good job with this type of tutoring, and propose that she pay the tutor out of pocket. You could ask in your department to see if there are any other options.

---

Edit: I glanced at the Wikipedia article's Solutions section that Daniel linked to, and it made me realize I should have explained where my outlined intervention came from.

It came from my experience with my son, who has Tourette Syndrome, OCD and anxiety. Specifically, from tutoring him during several key difficult periods, and from assisting with home exercises in his treatment for OCD.

Scribing during high-symptom periods has allowed him to progress academically. We were able to move from a place of high emotion and a lot of homework refusal to a place where I would start the homework session by scribing, until he would grab the pencil and the clipboard from me, and eventually to a place of independence.

Exposure treatments work on the principle of exposing the person to the thing that's very distressing, but in a controlled way, with increases given in small baby steps. It takes patience. The body can't maintain its alarmed state forever, so in each session you apply the stressor in a small amount and wait it out. Eventually the fight-flight-freeze response goes away. You do the exercise repeatedly. That's a very simplified explanation but I hope it helps.

This student's problem is a bit like the classic phobias, e.g. fear of flying, fear of spiders, etc., but it's a bit different, and that's why I used my experience scribing for my son as a model.

Answer 3

I've had some of these cases over the years, and they always end badly. To me, the "she doesn't ask for help when I go to her" is the worst signal here. A student in that situation cannot get better, in my experience.

This sounds a lot like math anxiety, which is an incredibly deep problem, and likely beyond your ability to fix as a TA. My understanding of the literature is that classroom-based interventions do not work; the student needs one-on-one treatment; so perhaps you should direct them to a school counselor, if available. You could also peruse the suggested solutions here, but they are mostly aimed at school-aged children, and frankly even the top few items run counter to research as I understand it.

In the long run, you'll find that if a student doesn't want you to assist them, then you simply cannot be of use to them as a teaching assistant.

Answer 4

I wasn't familiar with MATLAB, so I looked at some code samples on a page called Getting Started with MATLAB. If your own introduction to MATLAB looks like this, that may be the problem. Even those extremely basic operations assume a lot of knowledge that programmers take for granted, like what variables and functions are, first conceptually, and then in their general appearance in code. The thought underlying "I suck at programming" may be, "What the hell is programming, anyway?"

Answer 5

Programming is a complex skill that you can't pick up that quickly. So telling her she can do it when she may have an accurate assessment of her abilities won't help in any way. If I would attend a class and find out it is given in Chinese, then no amount of telling me "no you can actually understand Chinese, just try it" will help. There is this mindset of "We can do whatever we want if you just want it enough" but what gets forgotten is that some things need years of training.

What she needs is to attend an introductory programming course, where she learns basic concepts and assumptions, for example that there is a CPU and it executes instructions in sequential order and there are variables and so on.

Answer 6

Since no one suggested this before, simply ask her why. 3 minutes after you give out the exercise for everyone to do, go to her and check her screen.

If she keeps repeating the same phrase, break the "brain freeze" pattern by asking a sequence of questions similar to:

1. "why can you not start?" (nod and ignore if she repeats the same phrase)
2. "did you study the last classes exercises code?" Or simply, "did you study the basic syntax of a MATLAB program?"
   • if not and if the reason is because she did not have the code, ask her why she did not study from her partner's code?
   • if she did study, why can't she start by trying out a similar structure to the code in X class or from what she has seen in Y book/tutorial?
3. More importantly, remind her that this is a group exercise, that both of them seem to understand the logic behind the exercises, so she needs to work with her partner. Then ask her: "why are you not cooperating with your partner?"
   • if she replies that "her 'programming level' (whatever that is) is too advanced for me", then say to her: "what matters here is that the group implements the logic, if you both understand parts of it you can ask each other about certain issues, like which set of conditions would be better in this case, what expression would satisfy them better, etc."
   • if she comes up again with the "I want to do it on my own" line, be blunt, tell her that this is a group exercise for a reason and that the group (not her) needs to deliver the code at the end. You may suggest to her that she can try to do the exercise by herself after the class, but if she still decides not to contribute, consider that dismembering the team and evaluating each one individually is an option. Ask her partner first how would she feel about it.

From this sequence at least you'll be able to address the real problem, which some here have speculated about (freeloading may be implicit), but if you ever discover the true reason, adapt your strategy in order for her to either start writing something down (even if the interpreter does not run, at least there will be a debugging process to do) or to start working with her partner.

Answer 7

Emphasize bravery for new programmers

When I was preparing to tutor a 13-year-old girl in programming, having only helped undergrads before, I did some light research to see what tone I should set. I came across this TED Talk:

Teach girls bravery, not perfection | Reshma Saujani
_{(Reshma Saujani is the founder of Girls Who Code.)}

Saujani's thesis is that girls are socialized to be perfect, whereas boys are socialized to "play rough and climb to the top of the monkey bars". One study she cites found that grade 5 girls encountering material that was too difficult gave up whereas boys redoubled their efforts, despite the girls' overall superior academic performance. (In fact, the smarter the girl, the higher the chance she gave up.)

Now consider that programming requires a huge amount of trial and error both in writing and debugging, not only for learners but even for most professionals.

A scenario she describes at Girls Who Code sounds very much like your own student's:

We immediately see in our program our girls' fear of not getting it right, of not being perfect. Every Girls Who Code teacher tells me the same story: during the first week when the girls are learning how to code, a student will call her over and she'll say, "I don't know what code to write." The teacher will look at her screen and she'll see a blank text editor. If she didn't know any better, she'll think that her student spent the past 20 minutes just staring at the screen. But if she presses Undo a few times, she'll see that her student wrote code and then deleted it. She tried, she came close, but she didn't get it exactly right. Instead of showing the progress that she made, she'd rather show nothing at all.

She also mentions a pattern that reminds me of your student's "I suck at programming" comments:

When the guys are struggling with the assignment, they'll come in and they'll say, "Professor, there's something wrong with my code." The girls will come in and say, "Professor, there's something wrong with me."

Not everyone may agree with this assessment (the disheartening YouTube comments are evidence enough), and generalizations have exceptions. There's no guarantee that these observations apply to your student's case. But at a minimum, I think it would be a promising track to follow.

Applying this

Let her know that mistakes are necessary steps to mastery and that progress is only made in this field by trial and error. The mistakes she'll make won't do any harm or damage the computer. But showing them to you will allow her to get past them.

Focus on the process, not the result. Praise growth, not (perceived) ability.

Throw in stories of your own history getting over these humps. Many students love to hear that their teacher wasn't always "all-knowing". They see that you're human and had the same problems as them. Ergo, they too can surmount them.

You can also do something like "My Favourite No", where you invite attempts from the students. You then identify the mistake whose correction is most likely to help everyone and go through it with the students. These days apps like Padlet would make it easy to do that anonymously.

Theoretical connections

As Kevin comments below, there are connections with growth vs. fixed mindsets and mastery vs. performance outlooks. There are also connections with attribution theory ("Whose fault is it when I fail? Who gets the credit when I succeed? Why did I fail or succeed?"). We know, for example, that helping students attribute success to effort rather than innate intelligence is a good predictor of willingness to take on new, harder tasks (itself a prerequisite for succeeding at them).

---

Appendix: filling in the air pockets

This doesn't mean a diminution of rigour. You don't need to say that mistakes are fine or can be ignored. Quite the contrary: Students have to make them because it's important to identify them. The mistakes aren't good; making them is.

I'll illustrate. I have another student, a 10-year-old boy* I'm teaching French. For a long time, he seemed to hate reading, even though he was pretty good at it. During one lesson he happened to make a remark that revealed the problem: "I'm not gonna read. I'll just make mistakes."

"So?" I said. "That's what I'm here for! I'm not here to listen to you already reading perfectly!"

I then made this impromptu drawing:

"This box is your understanding of how to read French," I said. "When we completely fill it in, you understand everything. But right now there are little bubbles — air pockets. Those are the gaps in your knowledge."

"Whenever you read, we're scanning this box. Every time we find a bubble, we 'pop' it. We talk about the mistake and practice till you get it. By the end, this is what we have."

I don't know if it would work with everyone, but it worked with him. He got over his fear of reading.

_{* Those who read this episode as proof that boys have the problem too can feel free. The pedagogical point is the same.}

Answer 8

I think their problem is the initial barrier to "programming". They think a "programmer" is genius that thinks in code, loves in code, breathes in code and knows always everything.

If they can do it manually on a paper switch the computer down and ask them to instruct you to do all the steps on the paper.

Start with a blank page and ask them to feed you with the signal draw the signal input or ask them how to draw the graph. Then ask what to do next and why. "Apply fourier transformation" is good instruction here. in the end you should be instructed to draw the output graph. Assure them that it is That Simple.

Then start again with a blank page. Explain them, that now you are more dull than earlier and that you understand simpler tasks only. Explain them that one instruction from previous example must be divided in several steps following each other. The instructions here should be complex as well, but a bit simpler. Assure them that it is Still That Simple.

Repeat untill the instructions you are asked to do are exactly the instructions written on one line in the computer code.

Now they wrote the actual program in language they understands. Assure them it is That Simple and that you were dull enough to be considered a computer and they can get results from you anyway.

Then start the computer and write "Hello World" function. Assure them it is that simple.

Show them how to translate short part of the instruction they fed to you to the code MATLAB understands. Something like "go through X and append every value greater than Y to Z" translates to:

Z=zeros(0,1);
for ii=1:length(X)
  if X(ii)>Y
    Z=[Z;X(ii)];
  end
end

Explain them every single command and assure them they actually used that command, but with slightly different name.

Let them write slightly longer code based on the simple example you have just explained.

I think there is only one lesson they need to learn: Everything is build up from simple parts. All they need is to know about those simple parts and how to connect them to build something more complex.

Also do not hide help and doc functions from them.

Avoid something like "It is simple, all you need to do is [write advanced code]". This will prevent a lot of people from even thinking about whatever you do.

Answer 9

Have you ever heard of Imposter Syndrome? My coding bootcamp introduced it to us at the start of our development training. It essentially sums up the feelings of inadequacy, especially in the face of peers. Learning code can feel like an insurmountable task. This video helped myself and my fellow students when we felt like we were in the wrong place:

https://www.youtube.com/watch?v=eqhUHyVpAwE

It may seem a bit silly but for the mind of a student, I think it is suitable.

Answer 10

I teach math and programming to life science students, so I've seen students like this, although maybe not this extreme. Here's what I would try.

1. Start interacting with her in your usual way. Wait until she says, "I suck at programming".

2. Don't contradict her. Instead, say "OK, let's suppose, just for the sake of argument, that you suck at programming." If you feel you can pull it off, ham it up and see if you can get a laugh. "In fact, you might just be the worst programmer who ever lived!" If this doesn't fit you, just do the first line.

3. Turn it around. "I bet that even if you really are the worst programmer in the history of humankind, you can code this line." Point to something very simple from her pseudocode. Provide support if necessary and be enthusiastic when she gets it. If she freezes, type an answer with an obvious mistake into her editor. Let her fix the mistake.

4. Go to the next simplest line. At this point, you're not going for a fully working program, just incremental development.

5. At this point, tell her to work with her partner for a few minutes and say you'll check back soon. (Repeat a few times.) It's also good to make an announcement to the whole class about how much time professional programmers spend debugging.

Also, encourage her to come to office hours. That can be a good way to work with a student individually without spending extra time.

Answer 11

I would like to add that some starter code / basic infrastructure can go a long way in helping a person who isn't very familiar with programming start typing stuff into the editor.

For example, in c++, a blank fourier_transform.cpp may look terrifying, but one with

... doFourierTransform(...)
{
    /*
        Input : This function takes as input ...
        Output : This function should return ...
    */
    //==== PUT YOUR CODE HERE ====


    //============================
}

suddenly makes it much easier to start with.

Forgive this slight piece of personal opinion... but Python might be an easier language for beginners than MATLAB

Answer 12

I don't work exactly as a programmer, actually I am a professional software developer, hence my perspective might be a bit different. Moreover, I studied computer science so I really don't know much of the engineering side of academia (I just know it is different).

However, I did study a lot of programming (it is just a small part of software development after all) and from what you wrote I think there is something that can and should be fixed or at least can help this student a lot.

In particular, you mentioned that:

She understands the theory (because there's a pre-lab in which you write down the theory of what you will be coding in the lab, and she does well here), but when it comes to coding, she just can't get started

I might be wrong, but it seems to me you are first doing a pre-lab when they write something and then you get them right in front of a screen with MATLAB opened.

This is dangerous (and not productive) for professionals, let alone for novices.

Starting to write code without having figured exactly what your goal is and what structure it will have is like leaving for a 2-year long journey with no luggage, no money, no means of transportation and no idea of where you are going. You can probably do it but you rather wouldn't.

I can't recall how many times we were taught this when I studied programming in high school and in my BSc. Actually, they even forced us to do so. Not much during the MSc, probably they figured we wouldn't be there if we didn't already know it.

By starting directly in front of a screen one:

• spends a lot of time fixing syntax while still thinking about how the solution will work
• writes messy code which lacks a clear vision
• feels the frustration and the pain of not having precise ideas

This can be fixed by applying the Correct Way (:P) of:

• starting with a list of: provided input, output we want to get / effect we desire
• writing down a step by step process detailing how the problem will be solved, or how the main function will behave, etcetera (plain English, then pseudocode as a second step)
• (if it is a larger program) designing a list of different functions and or data structures, thinking firstly just what they will do, then how
• finally copying the things written on paper into actual code, step by step and only at this point thinking about syntax/bugs

For small programs or scripts, professionals can usually handle designing all the code structure in their minds before starting, however it is quite hard (if not impossible) for novices or people who think they "suck at programming". I usually write down stuff for anything that will take more than 2 hours of work.

Pen and paper are the first tools that should be used for programming and also for software development especially by beginners. This approach should be pursued instead of having the students write code directly.

---

Side note

A different approach is usually good for becoming familiar with the syntax of a language, especially in a REPL environment. That is starting from code provided by someone else (small chunks) and trying to change the values of parameters to see what happens.

But this approach should not be confused with learning how to program. This method makes sense only in an "exploratory mode" not aimed at writing a particular piece of code.

Answer 13

Your student will probably not be able to pass the course this time - she is already far behind, and will be unlikely to catch up. So she may prepare for passing next time.

The problem isn't anything intellectually, it is plain and simple fear. She absolutely knows she can't program, so she needs to start without programming, or without thinking she does programming. In the end, "programming" means you type a program, the computer does what the program says, and if you type the right things, the computer does what you actually wanted.

So to try her to do this in the simplest possible way, ask her to go to https://www.w3schools.com which teaches html. It starts really easy. They show a program, you change it a bit, you click on a button and it shows the result of your changes. It doesn't look like programming ("real" programmers will say it isn't programming, but it's close enough), so the hope is that she can do this without being overcome by fear, see little successes, and improve from there.

And at some point, MatLab will not induce fear in her anymore. I hope it is possible for her to get the course materials, so she should be able to get started on her own, and then do the course next year.

Answer 14

I'm getting here late but I want to contribute a different angle. Most people are saying "tell her something and she will change" or "change her": this will not work. Think what if they were your family. What would you do then? Like if your son refused to fold his laundry? I think there we would just have to fold the laundry together until he got the hang of it. I could do it for him every once in a while so they don't get frustrated but eventually they will have to learn to do it by themselves or it doesn't get done. Some people just don't fold their clothes, like some people just don't like computers.

It's hard to understand from our perspective but it's no less unique or special. Certainly a tough lesson for any teacher and shows the importance of a positive attitude. Even if they don't learn if you can keep a positive attitude it was still a success for the student. Hope my perspective sheds light on the situation and best of luck.