Debugging as Literacy
Debugging isn't just fixing code. It's a mode of thinking - a literacy in the root sense: the ability to read, understand, and respond to systems. Treating debugging as literacy changes how we teach code in videogame design.
The Conventional View
In CS education, debugging is remediation. You wrote a bug; now fix it. Debugging is failure recovery.
This framing makes debugging shameful. Students hide their bugs. They feel dumb when code doesn't work.
The Literacy View
Debugging is reading. When code breaks, you read what it's actually doing (vs. what you intended). That reading skill transfers: you can read code you didn't write, read systems you didn't design, read behavior you didn't expect.
Debugging is inquiry. "Why doesn't this work?" is a research question. You form hypotheses, test them, revise. This is scientific thinking applied to systems.
Debugging is craft. Every craft has failure. Potters have collapsed pots. Writers have bad drafts. Debugging is normal, not shameful.
Why This Matters for Videogame Design
Videogame designers who can't debug are dependent on engineers. They can't prototype. They can't tweak feel. They can't understand why their design isn't working.
Videogame designers who can debug have:
- Prototyping independence: Build rough versions without waiting for engineers
- Feel intuition: Tweak values, see results, iterate fast
- System literacy: Understand how videogame systems actually work
- Communication ability: Talk to engineers in their language
You don't need to be a great programmer. You need to be a competent debugger.
Teaching Debugging
Normalize Failure
Code not working isn't failure - it's the normal state. Nobody writes perfect code first try. Professional developers spend most of their time debugging.
Read Before Fix
Before changing anything, understand what's happening. Read the error message. Read the code. Articulate (in words) what you think is wrong.
One Change at a Time
Change one thing, test, repeat. If you change five things and it works, you don't know which change fixed it.
Print Statements Are Your Friend
The simplest debugging tool: print the value. See what's actually happening, not what you think is happening.
Rubber Duck Debugging
Explain the code to someone (or something - a rubber duck). The act of articulating often reveals the bug.
Use the Error Message
Error messages tell you something. Read them. They're not random noise.
The Code Bank and Debugging
The Code Bank scaffolds are designed for reading and modification, not just execution.
When a scaffold doesn't produce the feel you want:
- Read the scaffold code
- Identify which variable controls the aspect you want to change
- Hypothesize what changing it will do
- Test by changing and running
- Iterate until it feels right
This is debugging as design process.
Debugging Without Coding
The debugging mindset applies beyond code:
Debugging a design: Something doesn't work. Why? Form hypothesis. Test. Revise.
Debugging feedback: Playtesters report frustration. Where? Why? What's the root cause?
Debugging communication: Message isn't landing. What's being misunderstood? Where's the gap?
The skill transfers. Learning to debug code teaches you to debug everything.
Teaching Notes
We introduce debugging explicitly in Week 2, the first time students use the Code Bank. We talk about debugging before they encounter bugs, to normalize it.
Key Move
When students get stuck, don't give the answer. Guide them through debugging:
- "What's the error message say?"
- "What do you think is happening?"
- "How could you test that?"
This is slower. It's also where learning happens.
Exercise: Intentional Bugs
Give students code with intentional bugs. Have them debug without seeing the working version. Then discuss: how did you find it? What strategies did you use?
Exercise: Explain the Code
Students present someone else's Code Bank scaffold to the class. Forces reading and articulating unfamiliar code.
Assessment
We assess debugging process, not just outcome. "How did you approach the problem?" matters as much as "did you fix it?"
Common Challenges
Students want to be told the answer:
Resist. The learning is in the process. Give hints, not solutions. Ask questions that lead them to discover the bug themselves.
Students make random changes hoping something works:
Stop them. Require articulation before action. "Before you change anything, tell me what you think is wrong and why this change will fix it."
Students are ashamed of bugs:
Share your own bugs. Show professional code with bugs. Make it clear that bugs are normal, not a sign of incompetence.
Theoretical Background
Key Influences
Seymour Papert: Mindstorms. The idea that programming teaches thinking. Debugging is the thinking.
Brian Cantwell Smith: On the Origin of Objects. Computational thinking as a distinct mode of understanding.
Annette Vee: Coding Literacy. The argument for coding as a form of literacy, not just a technical skill.
What We're Taking
The literacy frame fundamentally changes the pedagogical stance. If debugging is literacy, it's a core skill, not a remedial one.
What We're Resisting
The "debugging is for engineers" view. Designers debug too. Just differently.
The shame around failure. CS culture often makes bugs shameful. That's counterproductive.
Unresolved Questions
- How much debugging literacy is enough for designers? They don't need to be engineers. Where's the line?
- Does debugging literacy develop specific cognitive skills? The claim that "coding teaches thinking" is contested.
- How do we assess debugging? It's process-oriented, hard to grade.
References
- Papert, Seymour. Mindstorms (1980)
- Vee, Annette. Coding Literacy (2017)
- Smith, Brian Cantwell. On the Origin of Objects (1996)
Related
- Code as Material - code as design material
- Code Bank - scaffolds designed for reading
- Play → Name → Make → Reflect - debugging in the "make" phase