I'm at Hack Reactor for a free one-day mini bootcamp, and I'm trying to think about what makes teaching effective or ineffective. The guy teaching is probably fairly inexperienced, so I don't blame him, but I've been needing something a little... better. There's an initial, crucial jump from 0 to a level where you're able to start really growing on your own, and this isn't it.

It's easy to get caught up in the details when you're teaching something new to someone. One way to combat this is to stick to a clear gameplan in terms of what you want someone to get from your lesson, and what you want them to be able to do. In particular, we went over typing in terms of strings and numbers, but got sidetracked with edge cases. I know that being very vigilant about your spelling and typing is important, but it seems like a bit of a mess to start talking about how to escape characters when your student hasn't built a stable mental model of how to create or manipulate a string to begin with.

While the guy was probably a reasonably competent developer, he wasn't especially good at teaching. I ran into a few problems with his style of communication and the ways that he tried to contextualize and explain the lecture's concepts. It's something that I often run into with experienced devs- they can often communicate very effectively and rapidly with other devs, but end up stumbling when it comes to teaching foundational concepts to a newbie.

This got me thinking about pedagogical strategies and design patterns. Thanks to the Youtube algorithm, I ended up being reminded of a video by Mark Brown, the mind behind GameMaker's Toolkit.

https://schoolofgamedesign.com/project/super-mario-4-step-level-design/

Honestly, I think that the time that I've spent playing games and following speedruns has really helped me learn to create robust mental models for the problems I'm trying to solve. What this episode of GMTK reveals to me is one of the ways that the learning/teaching is very intentionally implemented by game developers. I'm thinking that it's a strategy that could be applied to learning/teaching any sort of technical skills.

It basically boils down to 4 steps:

1. Introduce the new mechanic. This is usually done in a very simple environment, where the new mechanic is the only thing you have to worry about, and there are only minor consequences for failure. In the context of CS, this would mean introducing only one concept at a time, and having people use it in its most generalized, obvious forms. If we were talking about how to handle objects, I'd probably start with declaring an object and accessing its properties. Assuming that we'd already had lessons on functions and variables, it'd be pretty easy to introduce an object as a thing that you could use like a collection of variables.

2. Develop the new mechanic. This is an opportunity to go more in depth with a concept, and to work through some of the secondary effects it might have, or to apply it to a variety of problems. Here, I'd think about introducing problems like reassigning the values stored in it, storing methods in them, and so on.

3. add a twist. I think this is probably where you'd start to introduce edge cases and play with more of the unintuitive parts of it. Maybe here you start to introduce the problems with comparison operators in objects, or how to iterate through them, what happens when you start nesting them, or some of their interactions with recursion and loops, since you'd handle looping through an object significantly differently than you would an array.

4. the conclusion. Now, you'd want to bring everything together, using both intuitive and nonituitive strategies in order to solve an interesting problem. In the Mario model, this serves as a victory lap, but in the context of learning CS, this can also be a strategy to cement your knowledge.

It feels like a fairly intuitive strategy for teaching a concept, and, if it's anything like its implementation in Mario, I'm optimistic about its efficacy and the potential for... fun?