Wanted: Advice from CS teachers

Wanted: Advice from CS teachers

When #teaching a group of students new to coding I've noticed that my students who are normally very good about not calling out during class will shout "it's not working!" the moment their code hits an error and fails to run. They want me to fix it right away. This makes for too many interruptions since I'm easy to nerd snipe in this way.

I think I need to let them know that fixing errors that keep the code from running is literally what I'm trying to teach.

Wanted: Advice from CS teachers

When #teaching a group of students new to coding I've noticed that my students who are normally very good about not calling out during class will shout "it's not working!" the moment their code hits an error and fails to run. They want me to fix it right away. This makes for too many interruptions since I'm easy to nerd snipe in this way.

I think I need to let them know that fixing errors that keep the code from running is literally what I'm trying to teach.

@futurebird

I’ve taught programming like this, but I’m an increasingly huge fan of the debugging-first approach that a few people have been trying more recently. In this model, you don’t teach people to write code first, you teach them to fix code first.

I’ve seen a bunch of variations of this. If you have some kind of IDE (Smalltalk is beautiful for this, but other languages usually have the minimum requirements) then you can start with some working code and have them single-step through it and inspect variables to see if the behaviour reflects their intuition. Then you can give them nearly correct code and have them use that tool to fix the issues.

Only once they’re comfortable with that do you have them start writing code.

Otherwise it’s like teaching them to write an essay without first teaching them how to erase and redraft. If you teach people to get stuck before teaching them how to unstick themselves, it’s not surprising that they stop and give up at that point.

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?

Wanted: Advice from CS teachers

When #teaching a group of students new to coding I've noticed that my students who are normally very good about not calling out during class will shout "it's not working!" the moment their code hits an error and fails to run. They want me to fix it right away. This makes for too many interruptions since I'm easy to nerd snipe in this way.

I think I need to let them know that fixing errors that keep the code from running is literally what I'm trying to teach.

Things to Try:
* look for typos
* look at what the error message indicates.

If these don't work consider reverting your last changes to the last working version of your code. Then try making the changes again, but be more careful.

If you can't revert the changes, start removing bits of the code systematically. Remove the things you think might cause the error and run the code again. Isolate the change or code that causes the problem.

You can be a great programmer.

2/2

Wanted: Advice from CS teachers

When #teaching a group of students new to coding I've noticed that my students who are normally very good about not calling out during class will shout "it's not working!" the moment their code hits an error and fails to run. They want me to fix it right away. This makes for too many interruptions since I'm easy to nerd snipe in this way.

I think I need to let them know that fixing errors that keep the code from running is literally what I'm trying to teach.

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

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?

@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.

@david_chisnall

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.

@david_chisnall

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

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)

(Certainly not all programmers, but people proud of the craft and of doing a good job.)

@futurebird

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.

@david_chisnall @futurebird

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, ...).

@albertcardona @futurebird

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.

@datarama @futurebird

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.