2019-05-03
These are the design principles that I try to use to guide decisions at Rovercode
- We are not gamifying an otherwise dull activity. We are not wrapping a shiny layer of “fun” around a chore. We are creating a playground in which students learn about code by exploring and embracing its constraints and peculiarities. We can’t and shouldn’t try to make writing a reflection journal a delight, but we should make sure that it’s a safe, purposeful, and rewarding experience. Further reading: Ian Bogost’s Play Anything.
- We design for great teachers. While we hope that Rovercode will be effective for solo learners and students in understaffed schools, we are not afraid to design experiences that require a skilled and active teacher. We do not shy away from activities that require the adult to devise student groups or find open gym space. We recognize that the most authentic positive feedback comes within the real-life learning environment the teacher has already established. A positive call home is usually more powerful than a fake badge in a web app.
- Remix culture does not preclude authentic assessment. We take a step back and assess the student’s entire process and their ability to communicate their own unique ideas using code. Further reading: Boud, Cohen & Sampson and Carter.
- Learning coding is not fundamentally different than learning other things. Many strategies that work for teaching other subjects (especially other languages) also work well for teaching programming. While we’ll also provide opportunities for higher-level problem solving, we are not afraid of quizzing on basic syntax or doing code read-aloud exercises. Further reading: anything by Felienne.