Wanted: Advice from CS teachers
-
Example of the problem:
Me: "OK everyone. Next we'll make this into a function so we can simply call it each time-"
Student 1: "It won't work." (student who wouldn't interrupt like this normally)
Student 2: "Mine's broken too!"
Student 3: "It says error. I have the EXACT same thing as you but it's not working."
This makes me feel overloaded and grouchy. Too many questions at once. What I want them to do is wait until the explanation is done and ask when I'm walking around. #CSEdu
@futurebird I’m not in the education loop. But I saw this with some of the new hires for the last 5-10 years. Rightly or wrongly, I attributed this to the teaching to test mentality. The kids are taught that there are always “right” answers, you cannot figure them out yourself you just have to ask the teacher and they will give it to you. There isn’t time to teach creative problem solving.
-
I think they become anxious when their code isn't working the same as what I have up on the projector and they want to get it fixed RIGHT AWAY so they won't fall behind.
Then when one of them starts calling out they all do it.
I may take some time to explain this.
This never happens when I'm teaching math. Something about coding makes them forget some of their manners, and become less self-sufficient. "It's broke! I'm helpless!"
What is that about?
@futurebird a bit late to the thread but this sounds a lot like the phenomenon of livestreamers when they play a new video game for the first time - they make a lot of noise in the first few minutes about settings and controls and how they like this or don't like that. When the barrier to playing feels high and their energy level is low they may quit before feeling involved in the game and leave a remark about some aspect of polish that they weren't happy with. I've worked on games like that and addressed literally every polish item. Then they find an excuse like "uh, it looks really promising but not for me". I did a lot of browbeating at demo nights to get a sense of what player feedback's limits were, because beyond a certain point they just don't know what they want and don't have answers for why it feels bad or they got overwhelmed or intimidated by the experience.
If the game is well-constructed it doesn't rely on explicit hand-holding to march them through - it rapidly involves them in a puzzle or process that warms up some plan or mental model of what is going on. It lets them build up their energy investment as they do this, and then their rate of utterances slows down dramatically and becomes less "i don't get it, i need help, this sucks" and more "hmm. That's interesting. I wonder what happens if" and before you know it hours have passed.
But players who burn out on games return right back to citing minor polish issues. 1000 hours in and now you're suddenly complaining about the controls being unresponsive and leaving a negative review on Steam.
When the computer displays messages, it does something similar to set expectations by involving the student in conversation. The student, being human, reacts to being spoken to by saying something back, out loud. Once the first person normalizes that response the whole room lights up.
For the same reason that the livestreamer's first complaints aren't really an issue, the students aren't *actually* in need of help - that's a displacement of their reaction into words that resemble their feelings. And error messages with misleading qualities compound this. The industrial standard of tooling is guided around having the compiler act as a tiny bureaucrat that rubber-stamps things and makes you fill out forms, but it's a bureaucrat with the savvy of cost-optimized customer support - terse, formulaic, mostly addressing the surface issues.
There's a type of programmer that, when they get errors and warnings, goes looking for the settings to turn them off. I think that is a related thing - the compiler frustrates them on a base emotive level. This type of programmer is probably very satisfied with LLM coding because of the sycophancy.
On your end, you know that the student copying off a lecture slide probably has it 95% right, but they need models preparing them to react to these messages, otherwise they spiral out and quit.
-
@EricLawton @unlambda @maco @futurebird @david_chisnall i disagree with some strong asterisks. But I do think that making something you can really be proud of in detail is a bit uphill.
But also this enables a lot of time to spend on the planning and documenting side of things, which are absolutely things that programmers have wanted more time to do well, and processes that support. This might be providing them.
@aredridel unfortunately, in corporate environments none of the gains that might show up are invested in those tasks* because allocation of resources is generally not in the hands of those who would see that as important.
*) at least I haven’t seen it
-
Tangentially related:
"AI can write code so why teach how to code?"
"Great point! It can write an essay too, so why teach how to read."
Like. We've had calculators for decades and still teach arithmetic. And functionally the average person needs to know probably more about mathematics and needs to read more than they did a century ago. The same will apply for code.
I would make a slightly different point, I think.
When I was at university, doing a degree in computer science, the first language they taught us was Pascal. The second was Prolog. I can’t remember which order the third and fourth were taught in, but they were Java and Haskell.
Of these, Java was the only one widely used in industry. In my subsequent career, I have rarely used any of these. But I have used the concepts I learned repeatedly.
The tools change. Eventually, modern IDEs will catch up with 1980’s Smalltalk in functionality. But the core concepts change far more slowly.
And this matters even more for school children, because they’re not doing a degree to take them on a path where the majority will end up as programmers, they’re learning a skill that they can use in any context.
I spent a little bit of time attached to the Swansea History of Computing Collection working to collect oral histories of early computing in Wales. Glamorgan university was the first to offer a vocational programming qualification. They had one day of access to a computer at the Port Talbot steelworks (at the time, the only computer in Wales) each week. Every week, the class would take a minibus to visit the computer. They would each take it in turns to run their program (on punch cards). If it didn’t work, they would try to patch to code (manually punching holes or taping over them) and would get to have another go at the end.
Modern programming isn’t really like that (though it feels like it sometimes). The compile-test cycle has shortened from a week to a few seconds. Debuggers let you inspect the state of running programs in the middle. Things like time-travel debugging let you see an invalid value in memory and then run the program backwards to see where the value was written!
But the concepts of decomposing problems into small steps, and creating solutions by composing small testable building blocks remain the same.
The hard part of programming hasn’t been writing the code since we moved away from machine code in punched tape. It’s always been working out what the real problem is and expressing it unambiguously.
In many ways, LLMs make this worse. They let you start with an imprecise definition of the problem and will then fill in the gaps based on priors from their training data. In a classroom setting, those priors will likely align with the requirements of the task. The same may be true if you’re writing a CRUD application that is almost the same as 10,000 others with a small tweak that you put in the prompt. But once it has generated the code then you need to understand that it’s correct. LLMs can generate tests, but unless you’re careful they won’t generate the right tests.
The goal isn’t to produce children who can write code. It’s to empower the children with the ability to turn a computer into a machine that solves their problems whatever those problems are and to use the kind of systematic thinking in non-computing contexts.
The latter of these is also important. I’ve done workflow consulting where the fact that the company was operating inefficiently would be obvious to anyone with a programming background. It isn’t just mechanical systems that have these bottlenecks.
And this should feed into curriculum design (the Computer Science Unplugged curriculum took this to an extreme and produced some great material). There’s no point teaching skills that will be obsolete by the time that the children are adults, except as a solvent for getting useful transferable skills into their systems. A curriculum should be able to identify and explain to students which skills are in which category.
(And, yes, I am still bitter my schools wasted so much time on handwriting, a skill I basically never use as an adult. If I hand write 500 words in a year, it’s unusual, but I type more than that most days)
-
Tangentially related:
"AI can write code so why teach how to code?"
"Great point! It can write an essay too, so why teach how to read."
Like. We've had calculators for decades and still teach arithmetic. And functionally the average person needs to know probably more about mathematics and needs to read more than they did a century ago. The same will apply for code.
@futurebird @david_chisnall When I was at school, back in the 1960s, the careers advisors told us "don't learn programming, within four years computers will be intelligent enough to program themselves."
I suspect school careers advisors will still be saying the same thing in the 2060s.
-
I would make a slightly different point, I think.
When I was at university, doing a degree in computer science, the first language they taught us was Pascal. The second was Prolog. I can’t remember which order the third and fourth were taught in, but they were Java and Haskell.
Of these, Java was the only one widely used in industry. In my subsequent career, I have rarely used any of these. But I have used the concepts I learned repeatedly.
The tools change. Eventually, modern IDEs will catch up with 1980’s Smalltalk in functionality. But the core concepts change far more slowly.
And this matters even more for school children, because they’re not doing a degree to take them on a path where the majority will end up as programmers, they’re learning a skill that they can use in any context.
I spent a little bit of time attached to the Swansea History of Computing Collection working to collect oral histories of early computing in Wales. Glamorgan university was the first to offer a vocational programming qualification. They had one day of access to a computer at the Port Talbot steelworks (at the time, the only computer in Wales) each week. Every week, the class would take a minibus to visit the computer. They would each take it in turns to run their program (on punch cards). If it didn’t work, they would try to patch to code (manually punching holes or taping over them) and would get to have another go at the end.
Modern programming isn’t really like that (though it feels like it sometimes). The compile-test cycle has shortened from a week to a few seconds. Debuggers let you inspect the state of running programs in the middle. Things like time-travel debugging let you see an invalid value in memory and then run the program backwards to see where the value was written!
But the concepts of decomposing problems into small steps, and creating solutions by composing small testable building blocks remain the same.
The hard part of programming hasn’t been writing the code since we moved away from machine code in punched tape. It’s always been working out what the real problem is and expressing it unambiguously.
In many ways, LLMs make this worse. They let you start with an imprecise definition of the problem and will then fill in the gaps based on priors from their training data. In a classroom setting, those priors will likely align with the requirements of the task. The same may be true if you’re writing a CRUD application that is almost the same as 10,000 others with a small tweak that you put in the prompt. But once it has generated the code then you need to understand that it’s correct. LLMs can generate tests, but unless you’re careful they won’t generate the right tests.
The goal isn’t to produce children who can write code. It’s to empower the children with the ability to turn a computer into a machine that solves their problems whatever those problems are and to use the kind of systematic thinking in non-computing contexts.
The latter of these is also important. I’ve done workflow consulting where the fact that the company was operating inefficiently would be obvious to anyone with a programming background. It isn’t just mechanical systems that have these bottlenecks.
And this should feed into curriculum design (the Computer Science Unplugged curriculum took this to an extreme and produced some great material). There’s no point teaching skills that will be obsolete by the time that the children are adults, except as a solvent for getting useful transferable skills into their systems. A curriculum should be able to identify and explain to students which skills are in which category.
(And, yes, I am still bitter my schools wasted so much time on handwriting, a skill I basically never use as an adult. If I hand write 500 words in a year, it’s unusual, but I type more than that most days)
@david_chisnall @futurebird This is a tangent, but...
As a schoolkid, I *hated* handwriting - and especially that we got graded for it. I have joint hypermobility and holding a pencil was fatiguing and often painful. If I used any of the specialized grip aids, I needed to move my wrist much more than my fingers, and that made it *even worse*. My handwriting looked like a 5-year-old's well into my teens - at which point I got a special dispensation and was allowed to use an electric typewriter (wait, am I *that* old? No, it must be my school that used archaic equipment.
)Now I'm middle-aged, and I use a handwritten notebook just because I like it. I've even learned some basic calligraphy just for fun, and if I put in a little effort I can write in a pretty nice cursive; I even came up with my own partially-looped script. I'm sure that *part* of this is that it took me a longer time to develop better muscle tone in my hands (infamously underdeveloped in hypermobile kids) - but, really, I think it's *much* more about finding some intrinsic motivation for it and not being forced to do it when I simply couldn't see any point in it.
-
(Certainly not all programmers, but people proud of the craft and of doing a good job.)
@aredridel I have been frustrated all my working life by otherwise good programmers who will not document. I've only ever worked with one programmer who in my opinion documented enough (and I've ever since striven to emulate him). But in general I've seen no evidence that the majority of software people 'want to do documentation well'.
On the contrary, a majority see it as menial labour and a waste of their time.
-
I would make a slightly different point, I think.
When I was at university, doing a degree in computer science, the first language they taught us was Pascal. The second was Prolog. I can’t remember which order the third and fourth were taught in, but they were Java and Haskell.
Of these, Java was the only one widely used in industry. In my subsequent career, I have rarely used any of these. But I have used the concepts I learned repeatedly.
The tools change. Eventually, modern IDEs will catch up with 1980’s Smalltalk in functionality. But the core concepts change far more slowly.
And this matters even more for school children, because they’re not doing a degree to take them on a path where the majority will end up as programmers, they’re learning a skill that they can use in any context.
I spent a little bit of time attached to the Swansea History of Computing Collection working to collect oral histories of early computing in Wales. Glamorgan university was the first to offer a vocational programming qualification. They had one day of access to a computer at the Port Talbot steelworks (at the time, the only computer in Wales) each week. Every week, the class would take a minibus to visit the computer. They would each take it in turns to run their program (on punch cards). If it didn’t work, they would try to patch to code (manually punching holes or taping over them) and would get to have another go at the end.
Modern programming isn’t really like that (though it feels like it sometimes). The compile-test cycle has shortened from a week to a few seconds. Debuggers let you inspect the state of running programs in the middle. Things like time-travel debugging let you see an invalid value in memory and then run the program backwards to see where the value was written!
But the concepts of decomposing problems into small steps, and creating solutions by composing small testable building blocks remain the same.
The hard part of programming hasn’t been writing the code since we moved away from machine code in punched tape. It’s always been working out what the real problem is and expressing it unambiguously.
In many ways, LLMs make this worse. They let you start with an imprecise definition of the problem and will then fill in the gaps based on priors from their training data. In a classroom setting, those priors will likely align with the requirements of the task. The same may be true if you’re writing a CRUD application that is almost the same as 10,000 others with a small tweak that you put in the prompt. But once it has generated the code then you need to understand that it’s correct. LLMs can generate tests, but unless you’re careful they won’t generate the right tests.
The goal isn’t to produce children who can write code. It’s to empower the children with the ability to turn a computer into a machine that solves their problems whatever those problems are and to use the kind of systematic thinking in non-computing contexts.
The latter of these is also important. I’ve done workflow consulting where the fact that the company was operating inefficiently would be obvious to anyone with a programming background. It isn’t just mechanical systems that have these bottlenecks.
And this should feed into curriculum design (the Computer Science Unplugged curriculum took this to an extreme and produced some great material). There’s no point teaching skills that will be obsolete by the time that the children are adults, except as a solvent for getting useful transferable skills into their systems. A curriculum should be able to identify and explain to students which skills are in which category.
(And, yes, I am still bitter my schools wasted so much time on handwriting, a skill I basically never use as an adult. If I hand write 500 words in a year, it’s unusual, but I type more than that most days)
Second that – Clojure and Haskell taught me so much, completely changed the way I write Java, Javascript or Python code, the three main programming languages for work. While I can still write in them, I most often don't, but the concepts learned perdure, as do the expectations (managed memory, seamless concurrency, immutable data structures with structural sharing, functions without side effects, first-class functions, ...).
-
@david_chisnall @futurebird This is a tangent, but...
As a schoolkid, I *hated* handwriting - and especially that we got graded for it. I have joint hypermobility and holding a pencil was fatiguing and often painful. If I used any of the specialized grip aids, I needed to move my wrist much more than my fingers, and that made it *even worse*. My handwriting looked like a 5-year-old's well into my teens - at which point I got a special dispensation and was allowed to use an electric typewriter (wait, am I *that* old? No, it must be my school that used archaic equipment.
)Now I'm middle-aged, and I use a handwritten notebook just because I like it. I've even learned some basic calligraphy just for fun, and if I put in a little effort I can write in a pretty nice cursive; I even came up with my own partially-looped script. I'm sure that *part* of this is that it took me a longer time to develop better muscle tone in my hands (infamously underdeveloped in hypermobile kids) - but, really, I think it's *much* more about finding some intrinsic motivation for it and not being forced to do it when I simply couldn't see any point in it.
I can type about as fast as write by hand, and far more legibly (and I then get something searchable and editable). I was kept in at break times to practice handwriting. When I was 14, I was allowed to type essays in English and my average grade jumped from C to A. My first book was published when I was 25 and I was paid to write from about age 21. It turned out I had no problem with the ‘framing thoughts’ bit of English, just with using a pen.
So much schooling treated penmanship as a prerequisite for the skill that they were trying to teach. I have no objection to people enjoying calligraphy or shorthand note taking. Just don’t judge unrelated skills based on this.
-
Second that – Clojure and Haskell taught me so much, completely changed the way I write Java, Javascript or Python code, the three main programming languages for work. While I can still write in them, I most often don't, but the concepts learned perdure, as do the expectations (managed memory, seamless concurrency, immutable data structures with structural sharing, functions without side effects, first-class functions, ...).
In my experience, the people who write the best C++ are people who are proficient in Haskell. The worst are ones who are most proficient in C.
-
In my experience, the people who write the best C++ are people who are proficient in Haskell. The worst are ones who are most proficient in C.
@david_chisnall @futurebird I count myself fortunate to never have to write C or C++ code, or worse, read and debug someone else's C or C++ code, even though I can.
-
I can type about as fast as write by hand, and far more legibly (and I then get something searchable and editable). I was kept in at break times to practice handwriting. When I was 14, I was allowed to type essays in English and my average grade jumped from C to A. My first book was published when I was 25 and I was paid to write from about age 21. It turned out I had no problem with the ‘framing thoughts’ bit of English, just with using a pen.
So much schooling treated penmanship as a prerequisite for the skill that they were trying to teach. I have no objection to people enjoying calligraphy or shorthand note taking. Just don’t judge unrelated skills based on this.
@david_chisnall @futurebird Here, we got two separate grades for written work: One for content and one for presentation (which basically meant penmanship). I consistently got great grades in the former, and terrible ones in the latter. After said dispensation I no longer got presentation grades and all my earlier ones were annulled, so my average took a *huge* leap. AFAIK schoolchildren here now just write on computers - though some schools want to bring back analogue tools because of AI.
I can type much faster than I write by hand. I just find handwriting pleasant, and the slower pace (and the fact that I can't easily erase or cut and paste) means I "gather my thoughts" (for lack of a better term) in another way than when I'm typing. I've come to enjoy that bit of friction - but that only happened long after anyone stopped trying to force me to do it. But it's really not an "essential" skill, and I'd say that it already wasn't when I was a kid.
-
@david_chisnall @futurebird Here, we got two separate grades for written work: One for content and one for presentation (which basically meant penmanship). I consistently got great grades in the former, and terrible ones in the latter. After said dispensation I no longer got presentation grades and all my earlier ones were annulled, so my average took a *huge* leap. AFAIK schoolchildren here now just write on computers - though some schools want to bring back analogue tools because of AI.
I can type much faster than I write by hand. I just find handwriting pleasant, and the slower pace (and the fact that I can't easily erase or cut and paste) means I "gather my thoughts" (for lack of a better term) in another way than when I'm typing. I've come to enjoy that bit of friction - but that only happened long after anyone stopped trying to force me to do it. But it's really not an "essential" skill, and I'd say that it already wasn't when I was a kid.
Here, we got two separate grades for written work: One for content and one for presentation (which basically meant penmanship)
The thing is, these are not separable concerns. People who struggle to type tend to write code that’s hard to read because typing comments and using meaningful function and variable names is a struggle. So you’re implicitly measuring input-device proficiency when you judge code (this is slightly different with autocomplete because using a meaningful name ones is effort but then autocompleting it may be easier than autocompleting or typing a shorter one).
Exactly the same applies with essay writing. Writing with a pen has (for me) a much higher cognitive load. When I type, I frame a sentence in my head, edit it a bit, then flush the buffer asynchronously through my fingers without any involvement of my conscious mind. When I write with a pen, I have to think about forming the shapes. For my mother, it’s the exact opposite. We both have a thing where we can’t spell a word if you ask us, but get her to write it or me to type it and it will be correct.
If you had to type an essay using my nose, no amount of separation of presentation and content marks would save you from a low grade. For me, using a pen is different in degree but similar in kind.
-
Here, we got two separate grades for written work: One for content and one for presentation (which basically meant penmanship)
The thing is, these are not separable concerns. People who struggle to type tend to write code that’s hard to read because typing comments and using meaningful function and variable names is a struggle. So you’re implicitly measuring input-device proficiency when you judge code (this is slightly different with autocomplete because using a meaningful name ones is effort but then autocompleting it may be easier than autocompleting or typing a shorter one).
Exactly the same applies with essay writing. Writing with a pen has (for me) a much higher cognitive load. When I type, I frame a sentence in my head, edit it a bit, then flush the buffer asynchronously through my fingers without any involvement of my conscious mind. When I write with a pen, I have to think about forming the shapes. For my mother, it’s the exact opposite. We both have a thing where we can’t spell a word if you ask us, but get her to write it or me to type it and it will be correct.
If you had to type an essay using my nose, no amount of separation of presentation and content marks would save you from a low grade. For me, using a pen is different in degree but similar in kind.
@david_chisnall @futurebird I mean, I agree. I'm describing the writing assessments of the dysfunctional Danish school system of the 1980s, not praising them. Having been a teacher myself, I also figure it would probably be very hard for a *reader* to separate those two concerns - if you're distracted by illegible writing (or impressed by wonderful penmanship), then it's going to be hard to completely separate your impression of the content from that.
Back then, for home assignments, I would actually often type my essay into Geowrite on my Commodore 64 first and *then* copy it to paper by writing it down with a pen - which really perfectly illustrates how ridiculous that part of the exercise was.
-
Sometimes I have them write the code on paper with the computers closed. And this is fine, but I'd rather have them using the IDE or textedit and there is a limit to how much fun you can have with code on paper.
And it does tend to be the weaker students who are almost happy to find something to stop the onslaught of information "see it doesn't work! we can't go on!" and that obviously makes me very grouchy.
I need them to see this is like saying "Teacher my pencil broke! Stop the lesson!"
@futurebird my first thought is pair them up and give them problems/coding puzzles to work through? Get them used to banging their head against the problem.
-
Sometimes I have them write the code on paper with the computers closed. And this is fine, but I'd rather have them using the IDE or textedit and there is a limit to how much fun you can have with code on paper.
And it does tend to be the weaker students who are almost happy to find something to stop the onslaught of information "see it doesn't work! we can't go on!" and that obviously makes me very grouchy.
I need them to see this is like saying "Teacher my pencil broke! Stop the lesson!"
That's an interesting question, and I've seen similar. I skimmed the other answers, yet couldn't find my points, so here's my two cents:
1) The immediacy of feedback is different to solving a math or physics problem.
In math or physics, there's an explanation. Then students get a task. Then students calculate stuff. And then the correct resolution is revealed. Pretty much like a quiz.
And it's a flow that gives a teacher the time to look at individual problems afterwards.
-
That's an interesting question, and I've seen similar. I skimmed the other answers, yet couldn't find my points, so here's my two cents:
1) The immediacy of feedback is different to solving a math or physics problem.
In math or physics, there's an explanation. Then students get a task. Then students calculate stuff. And then the correct resolution is revealed. Pretty much like a quiz.
And it's a flow that gives a teacher the time to look at individual problems afterwards.
Enforcing a similar flow when teaching programming might help. Give folks more time to think about their code. Press "run" at the same time.
Having seperate time slots for explaining and debugging might be less overwhelming for everybody.
-
Enforcing a similar flow when teaching programming might help. Give folks more time to think about their code. Press "run" at the same time.
Having seperate time slots for explaining and debugging might be less overwhelming for everybody.
2) a) Another thing is, that syntax doesn't matter in math or physics.
When students do math or physics, the notation doesn't matter in solving the problem. Sure, they might use a wrong notation, and sometimes that gets them confused. But the solving is in their head, the notation is an afterthought.
If in physics they forget to put the units onto their result, they still feel like they solved the task.
-
2) a) Another thing is, that syntax doesn't matter in math or physics.
When students do math or physics, the notation doesn't matter in solving the problem. Sure, they might use a wrong notation, and sometimes that gets them confused. But the solving is in their head, the notation is an afterthought.
If in physics they forget to put the units onto their result, they still feel like they solved the task.
b) Nor do young students debug their formulas. They get told by the teacher what and where they did wrong when they hand in their solution.
Aren't the programming students doing the same thing?
c) I think a lot of the being overwhelmed aspects comes from students learning three things at once:
- Syntax
- Programming
- DebuggingProgramming is not the only instance where students learn syntax. Language classes exist. But it's more strict than anywhere else.
-
b) Nor do young students debug their formulas. They get told by the teacher what and where they did wrong when they hand in their solution.
Aren't the programming students doing the same thing?
c) I think a lot of the being overwhelmed aspects comes from students learning three things at once:
- Syntax
- Programming
- DebuggingProgramming is not the only instance where students learn syntax. Language classes exist. But it's more strict than anywhere else.
Just think of a beginner level language student trying to speak. And after the first sentence, they get interrupted with "Nope. Wrong, fix your sentence." "Nope, still wrong" "Nope". It would be quite a frustrating experience, wouldn't it?
