hey mastodon, throw all your programming pedagogy links at me. I teach a lot of beginner programmers and I want to get better at it!
specifically the trouble I have is getting beginners from the "I understand the syntax and can modify examples" stage to the "I can model problems as programs and apply my knowledge of the language to build these programs" stage. the first stage is pretty easy and most tutorials for beginners are oriented toward that kind of literacy... the second is harder to achieve and harder to teach, and it seems like most people only reach that stage with self-directed practice
@aparrish Hmm, I should do a reflection on "how did I get to this point?" It's a pity I only remember bits and pieces of what I've learned before a specific "catalyst" event.
@aparrish (That event being "building a toy CPU in Verilog for a class". That was the first time I really felt like "I could do anything with computers".)
@aparrish
Some resources that support the idea that grokking takes time and self-directed practice:
http://norvig.com/21-days.html
http://abstrusegoose.com/249
@aparrish Maybe what you might teach for this step is more about methods to cut a "problem" in small chunks and how to draw flow charts and system design?
Like, less on code, but more around the actual thinking that bring one from "I want to do this" to "I'll do it that way".
Focusing the thinking more on "how to explain my problem to the computer" and less on "write code"
I'm not sure there's a way to teach that. If there is I never found it nor saw it used.
@aparrish @StreetWanderer you're speaking of the distinction between computer programming and software architecture
The traditional way to teach that involves design patterns, which last I checked, have a bad reputation among people who have to work with green CS grads.
@aparrish I've been fighting with a lot of "engineers" over the years about the way programming is taught to beginners.
I even wrote a bad Medium article on the subject.
Programming is taught as maths when it needs to be taught like a foreign language.
Learn to speak and formulate though in the "computer language", the specifics of syntax, vocabulary and grammar can be learned as you go.
Like with a language, your accent and grammar will be off at first but that's part of the learning.
@aparrish the problems at Project Euler (projecteuler.net/archives) seem to mostly exist between the two stages you mention, so it's a good resource for practice material.
@aparrish I think second is actually pretty much orthogonal to the first, and don't derive from it at all. Learning to break up and model problems abstractly can be learned with not programming at all. And perhaps it should? I learned in parallel, but recalling it, the classes in college where almost always independent. I learned basic programming and languages in some (like intro to programming) and modeling in others (like db, software engineering, algorithm analysis)
@tonnydourado that's a really good point! unfortunately the two tasks get conflated in curricula all the time. :/
@aparrish yeah. Lots of discussion about which language to teach first. It is relevant, I think, but before any languages, understanding the computer should come first.
@aparrish the one thing I feel helped me throughout the whole thing is forming a mental model of the computer very early on. There was no programming involved, but the professor explained, in high level, but precisely enough, how CPU and memory interact and how this leads to breaking things into smaller steps. I feel like if you get that, a lot of the apparent magic in even higher level languages becomes less opaque.
@aparrish when I ta'd initial courses, that was the hard jump. tbh my advice to early cause students is "time and loc". experience the craft as you fumble towards comfort.
love to hear of better methods
@aparrish We had a whole class in my electrical engineering undergrad that tried to teach that, but mostly failed at it. I think project-based work, where you give people progressively larger and larger problems to solve, is pretty much the way to do it.
The principle from the class I alluded to still applies: abstraction and synthesis. Students must abstract a problem and then synthesize that into the relevant language concepts
@aparrish One thing that I'd be interested to try is a daily whiteboarding excercise. So students only do the abstraction part and you do it as a group for like the first ten minutes of class every single day.
If you look at it at two skills it's the abstraction that's usually the harder part than the synthesis, so I think just working those abstraction muscles through daily calisthenics is the way to go.
@aparrish So like the input of the exercise would be some problem. The output would be a HYPOTHESIS as to how you MIGHT model it in code. But don't bother digging in and falsifying. Just move on. One hypothesis a day. Maybe at the end of the class review them all and self-critique?
@tinysubversions I've been trying to incorporate material like that. also when I introduce a new bit of syntax, I try to start with the kinds of problems that require the new syntax to solve, and ask students to "design" the relevant syntax for solving those problems. I guess I need to write those exercises down and be a bit more consistent/directed with them
@aparrish Yeah that sounds pretty good!
@aparrish @tinysubversions this is the method by which I was taught theoretical-linguistics Syntax, and it was so great and empowering! Now I want to see how many other things can be taught this way, instead of by rote. (And programming is clearly one of them).
@tinysubversions @aparrish I agree with Darius. I teach a class that is almost purely project based and my model is basically, give them a bunch of building blocks during class, then ask them to put it all together in an assignment, then build on top of that with more complex building blocks.
@aparrish sorry, this is not an answer, but I want to say that this totally mirrors my experience and I hadn't seen it described before. For a decade I kept re-learning that first stage and it took forever (and a project-based book, and a project I cared about) to make the leap to the second step
@cfbolz @xor I teach mostly artists in a self-directed setting (masters degree art program). my experience is that even motivated people with a project they care about will often fail to make the leap (usually finding a solution with a perceived lower effort gradient, e.g., using pre-built code examples with little modification or collaborating with a more experienced peer)
@cwm I'm familiar with openframeworks—some of the faculty here at ITP use it as well. my problem is that I just really don't like C++ :)
@aparrish I find that I can read something, and not understand it but when I do something that involves what's being learned and can see an example I learn very well.
@aparrish I'm not an educator but I'm really interested in this problem
@aparrish the only textbook I know that tries to address the second stage is 'How to Design Programs'. It's Scheme based, however:
@cfbolz this actually looks really promising, just from the TOC alone
@aparrish it's very principled in its approach. I'd love to have a python equivalent!
@aparrish Do you think the hurdle is related to algorithmic thinking?
This paper looks interesting with regard to the pedagogy of algorithmic thinking.
https://publik.tuwien.ac.at/files/PubDat_140308.pdf
I've also found the book "How to Solve It" useful for thinking about and teaching problem solving, though it's not directly related to programming.
@aparrish Agreed. I got to the first stage, but have no chance of ever writing something from scratch. Brain no worky that way.
@aparrish this is not what you sought but: I am curious to play T Cavanagh's forthcoming work. A (non-coding) pal said past programming tasks just built chaotic knots - but with this, form was distinct, simplifications logical. shows abstraction mapping, i think? idk! but i'm curious.
@aparrish My current theory, after years of trying to figure this out, is that people generally learn the second through a programming apprenticeship. This is slightly gloomy, I know, and I would love to find out about books that teach this.
@aparrish This is the toughest. I try to make frustration and confusion more acceptable to students. Lower expectations of fancy results and appreciate that hair-tearing is part of the process. And I do a lot of iterative, code-along-with-me exercises to show how I start with something simple and slowly add to a program rather than pointing to finished examples.
@aparrish Our brains are pattern machines, so that is how we learn at first. Finding patterns, adjusting them, etc. Modeling problems as programs in your head takes time, but I bet it could take less time if we pointed out that that was the goal. Some people like thinking of codes as layers, and that can help, but it's a middle step.
@aparrish For the second one you also need a lot of creativity. For some people that's very hard.