Wanted: Advice from CS teachers

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

@grant_h @futurebird @MrBerard I haven't tried pair programming because I don't know how to create accountability for both parties

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!"

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.

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.

@Catfish_Man @futurebird

"If debugging is the process of removing bugs, then programming must be the process of putting them in." - Dijkstra

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

@EricLawton @maco @aredridel @futurebird @david_chisnall we don't know exactly how much it costs for the closed models; they may be selling at a loss, break even, or a slight profit on interference. But you can tell exactly how much inference costs with open weights models, you can run them on your own hardware and measure the cost of the hardware and power. And there's a competitive landscape of providers offering to run them. And open weights models are only lagging behind the closed models by a few months by now.

If the market consolidates down to only one or two leading players, then yes, it's possible for them to put a squeeze on the market and jack up prices. But right now, it's a highly competitive market, with very little stickiness, it's very easy to move to a different provider if the one you're using jacks up prices. Right now each of OpenAI, Anthropic, Google, and xAI are releasing frontier models regularly which leapfrog each other on various benchmarks, and the Chinese labs are only a few months behind, and generally release open weight models which are much easier to measure and build on top of. There's very little moat right now other than sheer capacity for training and inference.

And I would expect, if we do get a consolidation and squeeze, it would just be by jacking up prices, not by generating too many tokens. Right now inference is highly constrained; those people I work with who use these models regularly hit capacity limitations all the time. These companies can't build out capacity fast enough to meet demand, so if anything they're motivated to make things more efficient right now.

I have a lot of problems with the whole LLM industry, and I feel like in many ways it's being rushed out before we're truly ready for all of the consequences, but it is actually quite in demand right now.

@stilescrisis

If you haven't been coding for a few years, you won't be a skilled programmer. It won't take a lifetime to run out of them.

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?

@unlambda @EricLawton @maco @futurebird @david_chisnall All of this. I remain with a position of "this is a net negative for society”. However the utility to a programmer is pretty hard to deny.

@aredridel

The utility to employers of programmers, yes.

I'm not clear how individual programmers benefit. Obviously not those who are laid off.
Not for those who take pride in their work.

@unlambda @maco @futurebird @david_chisnall

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

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

@futurebird @maco @EricLawton @david_chisnall Oof. A sales pitch embedded in it sounds miiiiiserable.

As far as pricing ... man it's hard to tell. The training of models is very expensive, and energy-consuming. That has to be amortized somehow. But the actual running takes only a little more than 'home computer' level. (and cruddier models do run on home computer scale things)

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/

@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

Also IndentError, KeyError, and IndexError.

(Optional: 'hunt the Big Five': can they deliberately make code that has this error? and then fix it?)

Finally TypeError, for which more than the previous errors the fix depends on what you were doing. New phrase: 'I THOUGHT I had a number, but I HAVE a string. Can I change what I HAVE, or should I change what I THINK?"

Change what I have: int(my_string)

Change what I think: Ah, x can also be a string. `if type(my_x) is str: ...`
3/

@mensrea @futurebird

That is something I should definitely try sometime.

When the broken code comes from another person, it is more "improving something" and less "getting your work dissected".