Together with Andy Milenius I have the opportunity to engage with some folks at a local middle school to help some people learn about computers.
Specifically our goal is to recast relationships between learners and computers, such that they are tools to be used for anything rather than things that use you and limit what you can do.
For the first two sessions we've followed a pretty standard classroom format. Either myself or Andy gave a lecture, paired with a demonstration (using glitch), and then the learners tried to implement the same thing.
The main advantage here is it gave us time to give proper flavor to the whole experience, and talk about why the ideas we were telling them about were important. However, the technical information we were also trying to communicate was often lost. Those who were going to understand it, regardless of what we did, got it, and others either got it by playing around with it, or with 1:1 interactions.
To be honest, I'm dissapointed with myself. I think we defaulted to a traditional learning structure because it was the easiest to set up.
One way to do more complex work, and be more robust to different skill levels would be to put the kids into groups with a clearly specced out task they have to work towards. This way those that work faster are naturally incentivized to help those in their group (if they responsibilities are clear and the fast learner doesn't just dominate the project). Of course, groups introduce a bunch of organizational and interpersonal challenges.
Instead of delivering the the specific things we want students to learn as a lecture we could write out a tutorial, publish it to the hackers-club website, and have them work from there. This could be paired with an opening tone setting lecture, but we would keep it much shorter than previous ones.
This has a side-effect of introducing the kids to websites as learning tools. We could have them write their own tutorials in the future, or do more complicated things online.
To edit and host their websites, we introduced the learners to glitch. We considered Repl.it as well as some other options, but glitch won out for it's approachability and simlplicity.
The structure of development shouldn't be on individual projects but on collaborative ones following the FOSS software development methodology.
Code review, working with issues, writing readmes and docs, all allow for deeper thinking about programming and allow for more responsibility for the learners.
Definitely trendy at the moment in the professional field, pair programming is where two people code together, one person "driving", typing and interacting with the code, and the other "navigating", thinking about what comes next, keeping an eye out for bugs.
The biggest difficulty is that it requires coincidence of projects and skill levels. It also requires a certain baseline of interpersonal skills.