Wanted: Advice from CS teachers
-
At the university we had this maybe once.
But then, to quote a professor: "You are learning 'computer science' here. 'Programming' is something that you should either already know or learn in your free time."
@wakame @voltagex @itgrrl @futurebird [vague memory of a passage in solzhenitsyn about "engineers" and people who've never had to lay a brick] -
@futurebird
I know this from people I taught programming.And I think the main problem is that the computer is judging you. In a way.
This can come in two forms:
a) The program fails to run, shows you an error, etc.
b) The IDE adds an error or warning to a line saying: This is wrong.So there is "objective proof" right there on the screen that you "are a failure". This is not some other person saying it, this is a piece of technology.
This is also something I hate from a usability/user experience perspective.
The computer doesn't say: "Sorry, I don't understand what you mean with that line."
It says: "This line can not be processed because the user is dumb."(Not quite, overemphasizing.)
When taking about critique or blame, there is this typical antipattern: "Everybody uses a fork."
No, they don't. I use a fork, I want you to use a fork, but instead of saying that, I invoke a mystical "everybody".
@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 -
@futurebird
I totally cried when I was 14 and I tought in my naivety that I knew almost everything and then a simple program failed.
[Edit: And seriously: I think it is hard to understand if the voice from god tells your that there is an error line 32, that this could be somehow wrong.
I mean, this is a computer, right? It doesn't make mistakes.
Maybe emphasizing that the IDE and the compiler and everything else was written by humans and that they discover bugs in those programs all the time could help.]
@wakame @futurebird
> the voice from god
i rarely had this problem and i also could never understand what people at church and elsewhere were talking about when they talked about feeling the presence of god or whatever
i just thought of it as pure cause and effect, like
you're rolling a toy car down a track
the track has a snag in it you can't see
the toy gets derailed and hits the floor
you don't look at the floor for the snag -
@wakame @futurebird
> the voice from god
i rarely had this problem and i also could never understand what people at church and elsewhere were talking about when they talked about feeling the presence of god or whatever
i just thought of it as pure cause and effect, like
you're rolling a toy car down a track
the track has a snag in it you can't see
the toy gets derailed and hits the floor
you don't look at the floor for the snag@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) -
@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.
