Shared Project Space What I think works well is when the students in the class have their own shared virtual classroom in which to share Python projects. These need not be accessible to the public (people not in the class), but having real time access to each others' projects -- those voluntarily shared -- creates community and a sense of shared work. In the meantime, every student gets a private area in which to work on projects that aren't shared. These may be stored in the cloud, with no software locally installed other than a capable browser. Or not (local installation of software may be a selling feature). When it's BYOD, remind students that they get to upgrade own computer, versus leaving the cloud-based workshop with nothing installed. Integrated Graphics Turtle graphics were a breakthrough in the sense that something graphical was brought into the projects. Pythonic turtles, as objects, controlled by code, don't become irrelevant when the math becomes more complex.[0] If you're able to go from 2D to 3D, so much the better. Vpython anyone? Save Branches, Explore... At one end of the spectrum, we have "march them through" drills wherein all students are expected to enter the same code and reap the same rewards, a working something. Another approach, somewhat similar, is to hand them the working something, and then dissect the code. Work from both directions? At the other end of the spectrum, one shows them "new tricks" (e.g. event listening) and then "turns them loose" to explore. This is where the shared project space comes in. Look over the shoulders of your peers, at what they willingly share. Remix. Comment. In testing new features one creates "exhibits" (like museum exhibits) that "show off" said features. Save these as such and then reuse them by copying forward, to make more elaborate exhibits, up to (including) games. Games may be shared in completed or part-way form in the classroom pool (back to the other end of the spectrum). Rather than insist on always frequenting one place on this spectrum, feel free to vary the diet. March through code a little bit. Then show a feature with completed shared code. Then turn them loose to experiment (that could mean the teacher stops talking, but keeps using the shared chat stream). Hands On Given students opportunities to share code means giving them time to ponder and write code. The lecture format assumes students will work offline later. The tutorial or workshop approach assumes the students have time to workout (practice) during the session. Most of my suggestions above imply time during class in which to create and share work. I'm recommending the hands-on workshop mode over the lecture mode in this case. In my four hour twice a week format, we have three 20 minute labs per meetup. In my summer school for kids format, we would often have 20-30 minute intervals for discovery and exploration. We had 2.25 hour meetups. [1] Shared Chat Stream Even when my students are all in the same room, physically, I encourage using the chat window, a scrolling record I might study in more depth later, alluding back to it the next time we meet. In the stereotypical historical classroom "note passing" is discouraged by the teacher, but in this case the convention is flipped and the teacher participates in the chatter, a way to have synchronous commentary that's not disruptive of the audio track. Students may share URLs. I encourage them to log the chat. Recent examples (School of Tomorrow playlist): https://youtu.be/kBjZb-RrgLY (re phasors...) https://youtu.be/n57W4BSdx1k (exercising a "fire at intervals" feature) These specific examples are Codesters-centric (codesters.com), however my above summary is not premised on using any specific platform, nor even language (though I specify Python, this being edu-sig after all). Codesters is modeled on MIT Scratch in many ways. Platforms such as REPL.it have a classroom feature (with which I'm presently less familiar). Note: if a coder is making the transition from block-based Scratch to Python or other lexical (as in non-graphical) language, and finding it painful, I will sometimes recommend doodling in Scratch while auditing the Python part. My emphasis on integrated graphics (above) is against the current backdrop of many coming to Python by way of MIT Scratch as a first development environment. I can well imagine a scenario wherein a teleteacher encourages a virtual classroom of students to establish their own REPL.it accounts and then share with one another by pasting URLs to the Zoom chat window (Zoom being video-audio meetup software). I may try doing this myself. These Youtubes are similar to what I'd be sharing during a live teleteaching gig, such as we did this summer, me in Portland, the middle school students in Illinois in their own classroom (Carl Sandburg College computer lab). [2] I also pick student projects out of the shared pool and talk about them "in front of" the class (shared monitors), something I'm not doing in either example. Kirby Notes: [0] If adults have a problem with "turtles" call them "tractors" (a joke I make in Pythonic Andragogy). Seriously, I'm looking at adult topics such as AC current and Steinmetz phasors using complex numbers, with nothing more than turtles er tractors in Codesters. [1] My next such Codesters-based middle schooler teleteaching gig is in Nevada I believe. I'll be doing Spyder and Jupyter Notebooks with adults in California. However I often show Codesters to adult Python learners, which connects me back to the more "grown up" topics of AC current and related "grid talk" (a common feature in my several playlists). [2] As a Youtube character, I adopt many of the conventions of the genre (dress code etc.), helping to carve out a mnemonic niche, as one more educational video clown (memorable teacher). I've been influenced by Coding Train among others. Lots of great Python teaching going on. Shout out to Socratica.