# Student not understanding explanation the 1st, 2nd... and 8th time

I am working for a company, and a target for this year is to increase the level of CS knowledge among the staff.

The company does mostly engineering stuff so the people come from an engineering background, they might have some knowledge of programming, such as what is a variable, control flow, etc. but classes are virgin territory. That is kind of the average level there.

Me and a few others with knowledge (formal CS background, working in the AI team of the company) were assigned to increase the level of knowledge in the office. Basically each mentor was assigned a handful of mentees and the mentor decided what to teach and what exercises to give etc. to improve the algorithmic thinking and C++ competency.

I paired up with a colleague and we pooled our mentees. For some people it worked great. People went from variable names like a, b, ok, x and thousands of lines of copy-pasted code in main() to actually nice variable names, class hierarchies with abstract classes/interfaces, clean code to the point where (almost) no comments were needed, etc.

I tend to think that we are doing something right, especially since my colleague and I also teach at our university (which is among the top3 in the country), create training materials, held multiple training sessions on different subjects, regularly mentor interns with great success and also did volunteer work tutoring middle school children in introductory programming, with parents at the end asking us to continue the tutoring for money. So we are not exactly new to teaching, and our experiences seem to indicate that we are not bad at it either.

However I have a student that doesn't seem to grasp some concepts at all even after multiple (>5) explanations using different methods and analogies. Will also forget basic techniques in the span of hours.

For example he needs a copy of a vector<int> (C++). He will do the old song and dance:

vector<int> copy;
for (int i = 0; i < my_vec.size(); i++)
copy.push_back(my_vec[i]);


We told him several times and explained why it was better, faster, prettier to just do:

vector<int> copy = my_vec;


He always forgot to do this for his homework until we made his homework to clean up his code and implement a single utility function.

He cleaned up the code, then in that utility function went right back to the for method. And when we pointed this out it took a couple of minutes and helping questions for him to realize what he did wrong.

Another example is that as a first project the mentees have to implement a basic Hill Climbing algorithm. This project has been given in June. We have people who will begin implementing Genetic Algorithms this week and it won't even be hard for them. People who have started from variable names like a, b, ok, x and thousands of lines of copy-pasted code in main().

Without precise instructions he's barely able to create functions like with 1-2 rounds of review "you get a vector of vectors as an argument. compute f on each of the vectors and return the index of the first vector where the value of f is above some threshold x".

The hill climbing algorithm was explained exactly 7 times to him in different ways, with both me and my colleague actually spending time to come up with new analogies. Every time this mentee will enthusiastically say that this time he understood better than all the other times and then do something like just compute the best neighbor of the starting point and return that neighbor, and then name the function firstImprovement.

The problem is that this person does not appear disinterested. When we explain things he nods and looks like he is concentrating and that makes us try again and again because it looks like he's trying too, but the issues above have been a thing for months. On a problem as simple as Hill Climbing.

Has anyone ever had such experiences? Any advice? Or any other site where this question would be appropriate?

• Not a duplicate, but your question reminds me of this question.
– Ben I.
Sep 17 '20 at 11:31
• We had a guy just like this. Tried super hard, but just could not recall stuff. Turned out he had gotten part of his brain removed (labotomy). In the end we had to let him go. Sep 18 '20 at 8:02
• Not everybody is talented equally. Maybe he'll never become a top software engineer, but is an outstanding electronics hardware expert. So, at some time, he, you and the company should decide if and how to go on. Sep 21 '20 at 12:24
• How relevant are the two topics you mentioned (vector copying and hill climbing) to their jobs' everyday tasks? Sep 21 '20 at 12:29
• It sounds like you are doing very well at teaching, keep up the great work! Yes, I have seen students who reached a high-water mark early on and were never able to move past it, despite two instructors pouring out great effort. The interesting thing was that in one or two cases, these students did as you said: repeatedly assert that they have finally got it. It started to seem a bit like H.M., and we had to say that we felt it was not a good use of their time to stay in the program of study (a vocational training program). I was a T.A. for a Basic course long ago and saw something similar. Sep 23 '20 at 23:59

Maybe you are stressing things of minor importance. You gave us two examples.

vector<int> copy;
for (int i = 0; i < my_vec.size(); i++)
copy.push_back(my_vec[i]);


sure is lengthy, and probably also a bit slower than the C++ expert version of

vector<int> copy = my_vec;


But it does its job and is readable (while e.g. to me as a Java guy, I'd struggle to remember that the assignment operator here does a copy of the data structure). And, regarding performance, we all know that in at least 90% of all cases, it doesn't matter. And if it matters, I'd search for a solution where the vector doesn't have to be copied at all.

Regarding Hill Climbing: During 40 years of software development, I rarely ever needed hill climbing, and I've been working in algorithm-sensitive areas. So, unless your students' jobs need things like hill climbing regularly, think of exercises better matching their everyday needs.

To summarize it: You're not preparing that guy for a PhD in computer science (which most probably isn't needed for his job and out of scope for him as well), but giving him some tools to improve the software engineering aspects of his work.

With this guy, I'd switch from a fixed curriculum to practical reviews of production code, concentrating on readability, robustness and structure, looking at code written by different developers. If he struggles there as well, then have a nice, deep talk with him.

EDIT, as requested by OP

Regarding the "nice, deep talk": If that guy really struggles hard with basic concepts of software engineering, then he'll probably never catch up with the others. That mindset of specifically-structured thinking is not given to everybody. So, he should understand that his talents might be somewhere else.

He can choose whether he wants to pursue his career as a software engineer, with the risk of always staying behind all the others. Or he can find a different role in the team where his talents shine. It might be he is good at understanding the customers' way of thinking, or at hardware development and interfacing, or UI design, or management, or quality assurance, or whatever. Software development teams need so many roles besides coding, there might well be tasks where he can shine.

That's what I'd talk about with him. You should try to make this a positive experience for him. Maybe you already observed some of his talents, so you can suggest some migration path. For that talk, interpersonal skills are most important.

• We are already working with every single person on a case-by-case basis. We switched to this method from the moment it was clear that there were large skill gaps. Fortunately there is 2 of us and 6 of them so it is possible to give everyone ample time for code reviews but even this has had limited to minimal effect. Sep 22 '20 at 6:08
• As for Hill Climbing. In much less than 40 years of software development one of the largest projects I spearheaded used Hill Climbing as one of its integral parts. This project gave me at least 2 salary increases and a sizeable promotion. But aside from that, HillClimbing is an insanely simple algorithm. It's not much harder than sorting a bunch of numbers. And in engineering... complicated control flow is an everyday occurrence so a small degree of algorithmic thinking is required for the job. A degree that is a bit above HillClimbing. Sep 22 '20 at 6:12
• All in all, thank you for the reply! 1st: After noticing skill differences we have moved to personal tutoring pretty fast. 2nd: Also we have focused more on clean code and only rudimentary functions so there is almost no algorithmic thinking to be done. 3rd: The everyday tasks are engineering-related and unlike most jobs there is a bit of physics and math involved for everyone, so a HillClimbing seems a reasonable standard. I am however open to other ideas of "projects". 4th: Can you elaborate the deep talk please? Sep 22 '20 at 6:18

Ah, this is a tricky one and you’re clearly dedicated to helping this person so I imagine you’re finding this hard.

I read the core issue as being that the person you’re trying to help is not giving you honest feedback. I.e. they repeatedly indicate that they understand some thing or some explanation when in fact they do not.

If this is true, there’s likely to be some quite fundamental stuff which they’re yet to grasp that is blocking them from making progress on the task/s in hand but, because they’re not open about (or aware of?) what that is, you’re focussed on the wrong things.

I’d start by trying to reveal their current mental model of something simple - by that I mean simple to them, not simple to you. They may feel quite vulnerable during this exercise and it’s important that they do not fear reprisal. You could consider asking another member of staff, who is just a few steps ahead of this person, to be a mentor. This might create a space where the latter feels safe.

• There is some material available on the concept of "Notional Machine", which is the idea that someone has of how the machine works. When you say "some fundamental stuff they have yet to grasp", it seems similar. This is why I like to stress teaching how computers actually work, rather than starting at a more abstract level. But then I get a storm about transistors and electrons from people. Good luck. Feb 12 at 16:10

It's rather easy to observe that there is a pretty significant proportion of people who simply cannot ever program, do algebra-level math, etc. See also the following SE questions:

Trying for a zero-tolerance "no one can fail to do this" is counter-productive and a waste of resources. Some of us (e.g., U.S. community college) teach in a situation where that describes the majority of our students. After 3 tries in your case you're basically wasting your company's time.

Lay out the situation to you manager, with time spent on the task, and see if they want you to continue pursuing this.

• Equality of Opportunity good, Equality of Outcome ungood. Wrong Expectations doubleplusungood. Feb 12 at 16:07

# Some ideas

Order of teaching may be a problem. Teach the specialised easy to use method before the general hard to use one.

Re-consider the choice language, you are trying to teach programming at the same time as teaching a very hard language, this puts a very high cognitive load on the student.

Teach test-driven programming. See PRIMM for how to do this in teaching.

• Everything you said we have already done in several ways. Sep 20 '20 at 20:51
• @raresdima: What language-change did you try? I can tell you (a) You can teach C++ (b) You can teach programming (c)... Or even CS. But I've never known teaching/learning of programming still less CS via C++. People's brains come in a vast variety. If it really matters to you/your employer to pick up this person I'd try Excel, or vba for the Office-app he's good at or... Millions of possibilities
– Rusi
Sep 25 '20 at 8:11
• @Rusi you comment seems to be part a comment about the question (not this answer), and part an answer. If you move the answer part to an answer, then you may get some reputation. Sep 25 '20 at 8:16
• All true! I was just latching onto the snippet: «You: .... re-consider the choice language, — a very hard language, with very high cognitive load.. @RaresDima: We've tried...» I recognize that you've (probably!) +1ed my comment and are saying you'll +1 my answer — thanks for that. As some general rules: If I answer I try to do it so the questioner is helped. I try to avoid polemics! My views on this are extreme : Imperative prog is a mistake; OOP is a scam; C++ is among the worst — if this view would help the OP can do... But until then I'd not like to heat up. (this is a nice SE!)
– Rusi
Sep 27 '20 at 4:21
• Other eg this question : I'd say «recursion is easy; it's assignment (as the atomic unit) that makes it hard; mutable data structures even worse.» I could answer along the lines: «Switch to a language not usually needing assignment/mutation — scheme — or even better a language that doesnt have these — haskell — and see your problem vanish.» However the last line of the question — C a given — strongly suggests that this answer would be a non-answer... So I refrain 😀.
– Rusi
Sep 27 '20 at 4:41