Wanted: Advice from CS teachers
-
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?
-
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 maybe include exercises with intentionally broken code and the task to fix it on their own? Maybe they then see that there are typical problems exactly like the ones they complain about that are part of programming and not problems of the teaching format.
-
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?
The other aspect is that hardly anything at school teaches debugging. It's a skill folks pick up later in life when they build and repair things.
Techniques like cross testing where you replace parts of your system and see if the error still occurs are just craftsmanship.
But for a lot of students, it's probably something new that they have to get some experience with.
Which is probably hard when they also have to focus on other stuff at the same time.
-
The other aspect is that hardly anything at school teaches debugging. It's a skill folks pick up later in life when they build and repair things.
Techniques like cross testing where you replace parts of your system and see if the error still occurs are just craftsmanship.
But for a lot of students, it's probably something new that they have to get some experience with.
Which is probably hard when they also have to focus on other stuff at the same time.
I'm no educator.
I don't know how to split this into packages that allow students to build confidence and competence while not getting bored and losing interest at the same time.
But when students fail at a message that basically says "add ; to the end of the line 42", then they imho either lost confidence that they can resolve this. Or the message is not as easy to decipher as somebody who done that often thinks. Or both.
-
@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.
@simon_brooke tbh what lots of environments allow is menial. But if people use coding tools they’re going to need to fix it for the tools at least.
-
@futurebird To be fair there are a lot of professional software engineers I know who have essentially this same problem. The second anything is wrong they go on slack and start asking for help immediately and go straight to helplessness.
@wesley @futurebird I see this too. I tend to deal with this by giving them the benefit of the doubt and asking them what they've already tried. If they've tried something, then they reply with useful context. If they have not yet tried anything, then they quietly go away.
