Introducing…. Mike’s Axioms for Computing Instruction.
As I do more and more teaching and lesson writing, I’ve started collecting the gemmiest of my design principles.
Little by little I’ll record them here in the blog with some examples and the reasoning behind them, and hopefully they’ll be a useful reference for me and others. As I deepen my formal knowledge and gain more hours of practical experience, I’ll come back and elaborate or revisit.
Here are some to get started, just placeholders for now:
- Remove artifice. Make exercises as close to “real code” in a “real building scenario” as you can.
- Teach only what’s necessary for students to know *right now*. (this might be the teaching equivalent of the YAGNI principle in agile software development)
- Minimize overhead. (Where possible, pick languages that lend themselves to this)
- Maximize time spent on hands-on tinkering, sometimes at the expense of lecturing.
- Teach *what it’s like to be a coder* or creator, not just how to complete the exercises. The process and self-conception are as important as the acquired skill.
- Demonstrate mistakes and other kinds of everyday programmer fallibility. Be open about acknowledging your limitations, copying and learning from others, and reliance on references. Do these unintentionally and ad-libbed, where possible.
- Have students do the next smallest thing that will work. Test, debug, move on. (Another concept that crosses over nicely from agile software development.)
- Use pseudocode & comments liberally for teaching.
- Follow the model: Read > Write > Create. Start with reading or watching to understand. Move on to editing or tinkering with or tweaking existing code to see what effect that has. Finally let students master the given command or technique by building their own.
I’ll leave it at that for now… Got any of your own to share? Leave a Comment!