Comment by primitivesuave
6 days ago
I taught kids how to code for several years, both in person and through a website that taught Python to ~500k kids. My eternal advice with teaching CS is to delay abstractions as long as possible. Teach them how to draw a circle on a canvas, then get them to move the circle to different parts of the canvas, then get them to draw multiple overlapping circles/rectangles/etc. Once you've got that down, make a bouncing ball animation, simple games, and so on. Most kids don't really care for leetcode problems these days, so it's best to stick to things that are visual, creative, and instant-feedback (i.e. games).
This was a really useful realization when I was teaching kids to code in person for ~5 years. I started off teaching Java with an abstraction layer (https://www.bluej.org/), but I found that many students would be intimidated by anything that ventured outside of the abstraction (e.g. just run `javac` on your computer with a `.java` file). My most successful students intuitively understood how to turn a text file on their computer into a useful piece of compiled code, or into a JAR bundle that they could share with others. They also used the various abstractions that were thoughtfully introduced over time - e.g. an IDE that gives you a run button, libraries like Firebase which enable some exciting multiplayer game options, and so on.
My experience also shown that Python, being considered "simple", is actually harder for students to learn. Things I took as obvious are not for first time coders:
Ok, so spaces and indentation matter. How many spaces exactly there should be around `=`?
`a[1]` -- does it fetch something or does it modify something?
`for k, v in a.items():` or `for i in range(10):` -- waaa? How many spaces there should be?
What do you mean my Python script doesn't run, you see I clicked it and it runs. What do you mean "interpreter"?
And the main issue -- types. I'm 100% convinced now that the first language must be strictly-typed, like Java, and don't use `var`, always use explicit types. Otherwise students don't think in terms of types, but "what I put there" like it can hold anything.
I've been increasingly concerned by packaged CS curricula that includes an overabundance of guidance and tooling. I've seen too many students complete a course (successfully!) and leave without any ability to start building projects of their own.
I don't want to end up as a curmudgeon griping about how "back in my day we didn't have an IDE!", as I'm in favor of giving students real world tools early, but I'm worried that we're filtering out some level of independence by sandboxing their learning so strictly.
Yeah, I'm an adult and half the time I find that abstractions just muddy the water. The correct amount of abstraction is not zero (possibility excepting the poor engineers who have to actually design microchips), but IMHO it's usually lower than people think it is.
As a heads up, I fell in love with abstractions as soon as I could understand them (at some point in age 12 or 13 I "invented" function calls in rpg maker events)