Wanted: Advice from CS teachers
-
@raganwald
The best, most succinct, explanation of the difference here came from @pluralistic:
Coding makes things run well, software engineering makes things fail well.
All meaningful software fails over time as it interacts with the real world and the real world changes., so handling failure cases well is important.
Handling these cases involves expanding one's context window to take into account a lot of different factors.
For LLMs, a linear increase in the context window results in a quadratic increase in processing. And the unit economics of LLMs sucks already without squaring the costs.
Which is why AI, in its current incarnation, is fundamentally not capable of creating good software.(I've heavily paraphrased, so apologies if he reads this).
@flipper @raganwald @pluralistic @futurebird @EricLawton @david_chisnall I really hope it's a) true and b) stays like that
-
@wakame @futurebird my immediate instinct is to object that these error messages are about the input, not the person sending the input, but making it not personal / not making it personal is also one of those important skills that everyone used to assume everyone had and no one taught and now no one has@wakame @futurebird so far this thread it seems to teach someone how to program a computer they must first learn
- conflict management and de-escalation skills
- theory of mind
- rationalist epistemiology
- emotional self-discipline
- scientific method (controlled testing)
- the art of doing things one thing at a time (and figuring out what "one" "thing" is when it might not be self-evident)
... -
@wakame @futurebird so far this thread it seems to teach someone how to program a computer they must first learn
- conflict management and de-escalation skills
- theory of mind
- rationalist epistemiology
- emotional self-discipline
- scientific method (controlled testing)
- the art of doing things one thing at a time (and figuring out what "one" "thing" is when it might not be self-evident)
...@futurebird @wakame conclusion: programming is a martial art -
"I have the exact same thing as you but it's not working"
99 times out of 100 no, no you do not have the "exact same thing" you've made a typo.
Because the whole point of it being a computer is that if you have the exact same code it always does the exact same things.
@futurebird @freequaybuoy though sometimes the problem is that a language requires spaces rather than tabs, or prohibits a mix of them... or the student was trained for decades on languages where whitespace didn't matter... -
@wakame @futurebird (not that i don't make the mistake of checking everything from lines 8 through 64 after an error on line 32 without looking up to line 4, but that's more just lazily assuming that past me must've gotten "the basic stuff" right and any error must've been further down)
I intended to capture that doing computer stuff doesn't happen in a social vacuum.
But this is an interesting topic. I think it might also be a question of personality.
If a world-renowned professor for mathematics comes into a classroom, points at kid and says: "What you are writing there is wrong.", I can imagine three types of reactions:
a) The kid might see this as "neutral" input, looking for a mistake in what it just wrote.
b) They might see it as a personal attack or even invalidation and might consider themselves a failure.
c) They might question that figure of prestige and authority.I am more of a "category c)", but I would assume that most people are "category b)".
-
I intended to capture that doing computer stuff doesn't happen in a social vacuum.
But this is an interesting topic. I think it might also be a question of personality.
If a world-renowned professor for mathematics comes into a classroom, points at kid and says: "What you are writing there is wrong.", I can imagine three types of reactions:
a) The kid might see this as "neutral" input, looking for a mistake in what it just wrote.
b) They might see it as a personal attack or even invalidation and might consider themselves a failure.
c) They might question that figure of prestige and authority.I am more of a "category c)", but I would assume that most people are "category b)".
@wakame @futurebird (b) in response to my grade 10 science teacher's response to a fundamental misunderstanding of how salt solutions work is why i have a BA and work in a notoriously innumerate-liberal-arts-major-infested profession today... -
My students aren't lazy, but they *can* be a little perfectionist: scared to take risks or sit with not having the answer right away.
They are really upset when their code won't run... but staying calm and *systematically* looking for the cause of the problem, knowing that if you just work through the tree of possible causes you will find it is not something they are good at.
I think I need to teach this.
Maybe I will give them some broken code and we will find the errors together.
@futurebird yes, do that. i'm not a coder, nor a CS teacher, but teaching debugging is crucial to learning how to program. it's necessary to understand why anything works at all, instead of just copying code and not understanding why it doesn't work.
-
@cubeofcheese @futurebird all of the above, but particularly #4. Model the behaviour you want. Cold call what the error that you just made is. Let it become a thing to audit your code.
Another thing that works is pair programming. Building that culture and trust can take a little while, but both parties learn a lot.
@MrBerard mihjt have ideas?
@grant_h @futurebird @MrBerard I haven't tried pair programming because I don't know how to create accountability for both parties
-
@futurebird @wakame conclusion: programming is a martial art
Sosuko-do: The way of the source code
-
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
@futurebird Just sitting in an interactive debugger can be a very calming activity, IME.
Stepping through it slowly, one statement at a time, looking at the variables in scope, poking at things.
Figuring it out at your own pace instead of the computer's, taking all the time you need. -
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 in trade school, we always wrote pseudocode before writing actual code, which is like a kind of outline of how the program will work. it's not always easy to translate between pseudo and real code, but it helps to understand the process of what you're doing.
-
So Your Code Won't Run
1. There *is* an error in your code. It's probably just a typo. You can find it by looking for it in a calm, systematic way.
2. The error will make sense. It's not random. The computer does not "just hate you"
3. Read the error message. The error message *tries* to help you, but it's just a computer so YOUR HUMAN INTELLIGENCE may be needed to find the real source of error.
4. Every programmer makes errors. Great programmers can find and fix them.
1/
@futurebird Yes, when I taught young adults I had an explicit section, right after the first ones that gave them a taste of success, on reading error messages.
Showed an error -- intimidating, eh? But we can pick out parts. Line number, file, error type, message, and a traceback. Highlight those as I pointed them out. New raw error message: hey, same structure! Can we pick out the line number? etc.
1/
-
@wakame @futurebird (b) in response to my grade 10 science teacher's response to a fundamental misunderstanding of how salt solutions work is why i have a BA and work in a notoriously innumerate-liberal-arts-major-infested profession today...
I had a horrible math teacher in first grade who accidentally showed me that being an adult with authority doesn't mean a thing.
Might also explain my ongoing war with "authority".
-
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.
@david_chisnall @futurebird
I wonder if many of us who grew up coding learned?
There was something we wanted to fix, or edit, and read the code and poked at it until it did what we wanted, only later having the resources and tools to learn 'properly'.Maybe properly should include the poking stages!
-
@grant_h @futurebird @MrBerard I haven't tried pair programming because I don't know how to create accountability for both parties
@cubeofcheese @futurebird @MrBerard I have only done it informally, but encourage it. Typically, it's during class, so I can see who's engaged. It depends very much on the individuals, and how they gel as a class. I have one cohort who are amazing at it, another who are just getting there.
I generally have pretty engaged students, and I try to push accountability onto them: they have to write the exam at the end of the course, and you can't cram coding. I just predict the grade
-
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!"
Honestly, I was going to suggest exactly this (more work on paper before the computer comes into it), the keyboard can be a distraction.
The hardest stuff I have written, where I needed it to be actually right, was all done by hand in a notebook, and the coding was basically transcription.
-
My students aren't lazy, but they *can* be a little perfectionist: scared to take risks or sit with not having the answer right away.
They are really upset when their code won't run... but staying calm and *systematically* looking for the cause of the problem, knowing that if you just work through the tree of possible causes you will find it is not something they are good at.
I think I need to teach this.
Maybe I will give them some broken code and we will find the errors together.
@futurebird i think the institutional guidance is the thing itself which removes self sufficiency, it punishes own goals and forces alignment with a program
-
My students aren't lazy, but they *can* be a little perfectionist: scared to take risks or sit with not having the answer right away.
They are really upset when their code won't run... but staying calm and *systematically* looking for the cause of the problem, knowing that if you just work through the tree of possible causes you will find it is not something they are good at.
I think I need to teach this.
Maybe I will give them some broken code and we will find the errors together.
@futurebird @tito
Yes, I started to teach how to fix broken code in some classes: read and understand errors, where to look, etc. These are skills they really need but we let them figure them out by themselves. By teaching them how a code can be broken and how to fix it they figure out what is correct code.
It's much better this way than the other way around IMHO.
And yes they are scared to do mistakes, it's even worse in electronics classes! -
"If debugging is the process of removing bugs, then programming must be the process of putting them in." - Dijkstra
@wakame @Catfish_Man @futurebird ha, I like "no one is dumber than yourself yesterday" because you know that person's flawed thought process.
-
@futurebird Yes, when I taught young adults I had an explicit section, right after the first ones that gave them a taste of success, on reading error messages.
Showed an error -- intimidating, eh? But we can pick out parts. Line number, file, error type, message, and a traceback. Highlight those as I pointed them out. New raw error message: hey, same structure! Can we pick out the line number? etc.
1/
@futurebird
So that was step one, teach their eyes to pick info from the error text, instead of sliding off it. Next step teach them to see error as a call for their action. I did this by running through 2-3 common errors and the action, repeating 'WHEN I see an X error, THEN I do Y' language.WHEN I see a NameError, THEN I read the error, look up the line, and look for a mistyped name.
WHEN I see a SyntaxError, THEN I double-check my quote marks / parentheses / colons.
2/
