Wanted: Advice from CS teachers

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

@aredridel @futurebird @maco @EricLawton @david_chisnall but the actual running of all these popular LLMs has long ago outgrown the training? With vast majority of e.g. OpenAI expenses being on inference and not on training.

@futurebird
Wonderful. I would suggest a small change to 4. Even though the rest of your message explains how to become a great programmer, students may get hyper-fixated on #4. They may think "oh I'm just not a great programmer" before even reading ahead, or even after. So may I suggest something like: "Finding and fixing the errors is an essential step towards becoming a great programmer." This frames it as a process from the get-go, rather than a binary.

@IngaLovinde @futurebird @maco @EricLawton @david_chisnall Yup. Not mostly for coding, where the demand is pretty direct, but ChatGPT is wildly popular itself _and_ wildly integrated even in the most ridiculous places. So even in the places it's hated, someone's inducing demand.

@futurebird

Okay, last bits, sorry for going on so long!

1. My inspiration was Software Carpentry's module on reading errors. https://swcarpentry.github.io/python-novice-inflammation-2.7/07-errors.html
2. I also taught them about 'rubber ducking'. Made it all conspiratorial, let them in on the secret, tell them the pros do this. (We do!) The secret is: draw a little duck, and when you get errors explain your problem to the duck. Duck is simple duck, so explain every detail. Often, because you explain it, you'll realise how to fix it! 4/4

@wakame @futurebird and i do need to brag about one of them. one day one of the interns told me of how she started getting answer to problems she couldn't figure out. she created 2 stack overflow accounts, with her main she asked her question. with her alt, she'd confidently give herself a wring answer. and then sit back and wait for the well actuallies. i was so proud

@futurebird I mean, the computer *does* just hate you, but that's not why your code isn't running. Completely separate issue.

@mansr @futurebird *cries in PHP*

@futurebird random : don't do big changes. Do small changes and validate with compiler or tests. That usually solves 90% of problems.

@futurebird I'm gonna be brief because I'm a parent, not a teacher, but this experience rhymes with mine.

what I tend to do is respond in a way that addresses the existence of a good question without answering it. even if the response equates to "I'm doing something so I'm not ready to help with that yet", I try to encourage the aspect of wondering. so for example "you've stumbled on a surprise part of the lesson! it's ok, keep following along while i get everyone there."

or something. I'm just a guy.

@david_chisnall @futurebird I remember being excited when I learned Ruby was supposed to be a test-first language (you design the tests then code to them)

Unfortunately, the language was Ruby and few if any of its users even tried to adopt such an ideology.

But I agree with you! On that, have any reading materials with tips for modern practices, I'm still clinging to a worn copy of 'Working Effectively With Legacy Code'

@futurebird I think it’s because code is supposed to do something. So when it doesn’t they get anxious. I still have this whenever I do a training and for some reason my code doesn’t work. It’s a fear of falling behind and a feeling of inadequacy

@futurebird ive been having the exact same problem haha. i think maybe it helps to have moments where, if everything goes right, the program will crash in a particular way, and we can look at what the error is saying and then at what that actually means. perhaps?

@futurebird reminds me of the helpful guides in the Usborne books I learnt programming from.

@futurebird I address this issue by giving students a working program and have them purposely make mistakes to see what happens: https://langintro.com/comsc020/lets-think-python.pdf (page 22) You might even want to make a contest for “who can get the most error messages/ weirdest error message with a mistake in one line?”

As for looking at the wrong line for the error, I use the analogy of buttoning your shirt wrong. You find out it’s wrong when you run out of buttons at the bottom of the shirt, but that’s not where the error really started. (https://youtu.be/kJ4FGD2sQzE)

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

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

@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

@EricLawton @unlambda @maco @futurebird @david_chisnall

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

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