Sequences
8-Week Starter Set
This is a sequence of classmaps that is ideal for beginning coaches running an 8-week course and works for students of various levels.
~60 minutes8 modes
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Award the first badge(s) of the session!
Award the first badge(s) of the session!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
All About Bugs
We have a little extra time today to discuss today's class, specifically:
what we learned about bugs today.
Before we get started as a big group, I would like you to turn to the person next to you and take turns sharing on this topic. I'll set the timer for 2 minutes for you to do that. Ready, set, go!
Students discuss for 2 minutes before Coach regains focus.
Now, as we dive deeper into our thoughts and experiences, it is important that we respect each other and have a productive conversation by:
[Coach fills in: any rules or guidelines for the Team (see below).]
Who would like to start us off?
All About Bugs ~60 minutes
Get to know BUGS and a different way of thinking about them.
The Mars Orbiter Bug
~10min
The Mars Orbiter Bug
A mission to Mars is several miles (or kilometers) off track -- leading to disaster.
Mode Summary & Goals
Summary: A true story about a famous bug that caused the loss of a Mars Orbiter -- when some coders wrote the code thinking in Metric kilometers while others were thinking and writing in Imperial miles!
Goals and Gains:- Rethinking Bugs practice -- was the bug in the computer? or in the coders?
- Learning some cool computer science history
- Seeing BUGS in the "real world" -- something that even pros deal with
Tips & Tricks:
- Don't forget ask questions throughout and at the end! (see suggestions at the end)
- The Mars Climate Orbiter was sent to Mars in 1998.
- The hopes for the mission was to study the atmosphere and climate of Mars and learn more about why the planet, which once was covered in water, became a desert.
- After 286 days of space travel, the Orbiter got to Mars!
- But something went wrong -- it entered orbit too close to the atmosphere.
- We lost contact and lost the Orbiter -- either to the surface of Mars or the depths of space. We don't know!
- What happened?
- A bug in the code written to control the Orbiter
- The code was written by many people in many places -- some of are used to the Metric system (kilometers, meters, liters, grams....) and others, the Imperial system (miles, inches, pounds...)
- What would happen if I told you to 'go forward 5' and I meant steps, but you thought I meant city blocks?
- That's what happened with the Orbiter!
Mars was once covered with water. Ever since we discovered the evidence of this, the question on everyone's mind has been: Where did Mars' water go?
In 1998, scientists launched the Mars Climate Orbiter on an unmanned mission: to study the atmosphere and climate of the red planet. Using this new information, scientists hoped to figure out where the water had gone, and what had turned that red planet from an ocean world into a desert.
The Mars Climate Orbiter flew toward Mars for 286 days. As it approached the planet, the computer began to fire its thrusters to establish an orbit around the planet. But something went wrong.
The Orbiter was too close to the atmosphere! Its engines began to fail, and communication with that $200 million dollar spaceship was lost. To this day, we don't know where it is. It may have been destroyed in the Martian atmosphere, or it may have continued onward, exiting the planet's orbit. It may be circling the sun to this day -- a tiny scrap of metal compared to the giant planets of the solar system.
Although we don't know what happened after contact was lost -- scientists and engineers back on Earth do know why the ship malfunctioned when it drew near its final destination.
The software written to control the ship from Earth was enormous -- many million lines of code. To get a feel for how big the source code for a space mission can be, here's a picture of a coder named Margaret Hamilton standing next to a printout of code she and her team wrote for a different spaceship:
As you might expect, any giant piece of text written by human beings is going to have some mistakes in it. The code that controlled communication with the Mars Climate Orbiter had one nasty bug that doomed its mission -- going entirely unnoticed until it was too late.
The bug was simply this:
So the numbers transmitted by one piece of software to the other were interpreted incorrectly, causing a message to be sent to the Orbiter that (accidentally) told the Orbiter to fly too close to the Martian atmosphere. An analogy: suppose you told someone to run for 5 -- if they assumed you meant 5 miles they would run much farther than if they assumed you meant 5 kilometers.
Millions of dollars were lost, and a scientific mission doomed. Most people say it happened because of a software bug. But at MetaCoders, we know that the stories behind software bugs is more complex. The bug caused the crash. But what caused the bug?
In 1998, scientists launched the Mars Climate Orbiter on an unmanned mission: to study the atmosphere and climate of the red planet. Using this new information, scientists hoped to figure out where the water had gone, and what had turned that red planet from an ocean world into a desert.
The Mars Climate Orbiter flew toward Mars for 286 days. As it approached the planet, the computer began to fire its thrusters to establish an orbit around the planet. But something went wrong.
The Orbiter was too close to the atmosphere! Its engines began to fail, and communication with that $200 million dollar spaceship was lost. To this day, we don't know where it is. It may have been destroyed in the Martian atmosphere, or it may have continued onward, exiting the planet's orbit. It may be circling the sun to this day -- a tiny scrap of metal compared to the giant planets of the solar system.
Although we don't know what happened after contact was lost -- scientists and engineers back on Earth do know why the ship malfunctioned when it drew near its final destination.
The software written to control the ship from Earth was enormous -- many million lines of code. To get a feel for how big the source code for a space mission can be, here's a picture of a coder named Margaret Hamilton standing next to a printout of code she and her team wrote for a different spaceship:
As you might expect, any giant piece of text written by human beings is going to have some mistakes in it. The code that controlled communication with the Mars Climate Orbiter had one nasty bug that doomed its mission -- going entirely unnoticed until it was too late.
The bug was simply this:
One piece of software for controlling the Orbiter was designed to use metric units -- like the ones used everywhere except America. You know: kilometers, meters, liters, grams, etc.
Another piece of software was designed to use the other kind of units. You know: miles, inches, pounds, etc.
So the numbers transmitted by one piece of software to the other were interpreted incorrectly, causing a message to be sent to the Orbiter that (accidentally) told the Orbiter to fly too close to the Martian atmosphere. An analogy: suppose you told someone to run for 5 -- if they assumed you meant 5 miles they would run much farther than if they assumed you meant 5 kilometers.
Millions of dollars were lost, and a scientific mission doomed. Most people say it happened because of a software bug. But at MetaCoders, we know that the stories behind software bugs is more complex. The bug caused the crash. But what caused the bug?
- Why was the Orbiter launched?
- Did anyone die on the Orbiter?
What caused the Mars Orbiter bug? Whose fault is it?
There's no clear answer to this question. You could say that the programmer who wrote the faulty line caused the bug. But then, the question is -- why did that programmer think they were supposed to be using non-metric units? Why didn't the teams who wrote the two pieces of software communicate better about the units they were supposed to use? Why does our society use two different kinds of units in the first place? When discussing this it's mainly important to leave students with the understanding that things are more complex than they first thought.
- How do you make sure there are no bugs in your code?
- How do you think programmers make sure there are no bugs in gigantic, complicated pieces of code?
Build a Bug Workshop
~25min
Build a Bug Workshop
Players purposely break and debug code in this partnered game.
Need:
- computers - 1 per Player
How to Play:
Set Up: Each Player needs complete, working code on their computer to start this game. Either tack it on to a game like Disintegrating Code, or preface the game by typing up code from reference, specification, or each Player's own imagination! Just be sure all code works before starting this game.
- Players pair up
- Players swap computers, each with complete working code
- Players put a bug in their partner's code -- causing an error
- Players swap back computers and debug their now-broken code
Tips & Tricks:
- Players can swap seats instead of computers to prevent dropping of computers.
- For some friendly competition, turn the game into a race: who can debug their code faster?
- Start this game with a discussion about the bugs they have come across so far -- spelling errors, missing paretheses, wrong keywords -- to spark creativity about the kind of errors to plant in their partner's code.
Bugs in the brain
~15min
Bugs in the brain
Many young coders (all the way through college and their first few years on the job) seem to think that bugs happen by magic. In reality, they happen because coders are not self-aware enough.
If you debug one bug, you've just debugged one bug. If you debug your thinking, you've debugged a thousand bugs. If you've debugged someone else's thinking, please tell me how you did it -- because I never can. ~Stephen R. Foster, MetaCoders Founding Member- What is the difference between a bug and a mistake?
- What causes bugs?
- What causes mistakes?
- Why is it often hard for people to admit their mistakes?
- What are some ways you can reduce the number of mistakes you make?
- What might constitute a bug in an English essay?
- What's the difference between a bug and a mistake in an English essay??
Meta Story: Deep Reflection
~10min
Meta Story: Deep Reflection
A deeper dive into the subjects, challenges, and skill-building that happened in today's class.
Tips & Tricks:
- Start with a Think/Pair/Share model before a group conversation to get all students thinking and talking the topic, even if they don't all participate in the big dicussion.
- Ask follow up questions from the students to encourage deeper understanding. Can be as simple as "Why?"
- Other great questions: Who also felt that way? Who also faced that challenge? Who has advice for that?
- This is a deep reflection, so feel free to encourage students to raise their hands to respond to each other.
- Moderate to keep the conversation respectful and productive at all times.
We have a little extra time today to discuss today's class, specifically:
what we learned about bugs today.
Before we get started as a big group, I would like you to turn to the person next to you and take turns sharing on this topic. I'll set the timer for 2 minutes for you to do that. Ready, set, go!
Students discuss for 2 minutes before Coach regains focus.
Now, as we dive deeper into our thoughts and experiences, it is important that we respect each other and have a productive conversation by:
[Coach fills in: any rules or guidelines for the Team (see below).]
Who would like to start us off?
Depending on the age, maturity and size of the Team, you may want to set some guidelines to help promote a positive and productive discussion. Such as:
- Raised hands
- A "talking stick"
- You must continue the conversation, not just blurt out a random, unrelated thought
- We can only speak to our own experience, no one else's
~60 minutes4 modes
Get to know BUGS and a different way of thinking about them.
Get to know BUGS and a different way of thinking about them.
~60 minutes5 modes
Re-enforce a specific Code, put it into practice, and grow student metacognition skills through reflection!
Re-enforce a specific Code, put it into practice, and grow student metacognition skills through reflection!
~60 minutes5 modes
Prepare for the Final Jam by reviewing code and practicing pair programming.
Prepare for the Final Jam by reviewing code and practicing pair programming.
~60 minutes5 modes
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
Computational Thinking Set
This is a sequence of classmaps that uses a blend of unplugged and coding game modes, as well as a variety of story modes.
~40 minutes5 modes
An unplugged/plugged classmap introducing the basics of inputs/outputs.
An unplugged/plugged classmap introducing the basics of inputs/outputs.
~40 minutes5 modes
A unplugged/plugged classmap introducing the basics of bugs.
A unplugged/plugged classmap introducing the basics of bugs.
~40 minutes5 modes
A unplugged/plugged classmap introducing the basics of learning how to code.
A unplugged/plugged classmap introducing the basics of learning how to code.
~40 minutes5 modes
A unplugged/plugged classmap on inputs/outputs.
A unplugged/plugged classmap on inputs/outputs.
Coder Skills
what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Coder Skills ~40 minutes
It takes more than just computer knowledge to be a coder; take a look all the different skills it takes to be the best coder in this map.
Review
~5min
Review
What skills have we learned in this class so far?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
The Life and Times of a Real Coder
~10min
The Life and Times of a Real Coder
What does it really take to be a coder?
Each Chapter of this story starts by defining a primary task a coder does before generating a list of the skills required for that task, then considering where else we use those skills. The goal being to expand the definition of what it means to be a coder and how everyone can gain from it.Tips & Tricks:
- This story is strongly based in discussion. Know what is important to touch on, but also let the students bring up ideas that you may not have thought of before!
- If possible, use visual aids/lists to keep the discussion clear and focused. Draw up on a whiteboard and/or even encourage students to draw along. An example diagram:
- Ask the students to assess their level of mastery over some/all of the skills discussed.
- Because this story mode is driven by questions to the class, there is no additional questions noted at the end.
- You can easily split this story by chapter over a class or several classes.
Chapter 1: The Code
- What does a coder do? -- Write, read, edit and debug code
- What skills do we need for that? -- (ex. coding knowledge, problem-solving, organization, logic, computational thinking, creativity...)
- Where else are these skills useful? -- (ex. math, writing, homework, art...)
- What else does a coder do? -- Work with people
- What skills do we need for that? -- (ex. communication [verbal, written and visual], teamwork...)
- Where else are these skills useful? -- (ex. school projects, sports, job, socially...)
- What else does a coder do? -- Work with own brain
- Meaning: "code" our brain by learning, "edit code" by learning new things, "debug code" by finding and fixing false assumptions
- What skills do we need for that? -- (ex. grit, self-reliance, curiosity, humility...)
- Where else are these skills useful? -- (ex. sports, musical instrument, writing...)
- It takes a lot of different skills to be a coder
- You learn and use these skills everywhere
- Like in our stories and games!
Who here wants to be some kind of coder when they grow up? Who might want to be a coder or do a job that involves coding? Who wants to do something totally different?!
Let's take a closer look at what it really takes to be the best coder -- all the different things a professional coder does and the skills it takes to be good at them. Some of these things you are already doing -- in this class or elsewhere in your life. Some of them you'll do soon! But all of these skills are valuable for all of you. Now and in the future, no matter what you end up doing!
Let's take a closer look at what it really takes to be the best coder -- all the different things a professional coder does and the skills it takes to be good at them. Some of these things you are already doing -- in this class or elsewhere in your life. Some of them you'll do soon! But all of these skills are valuable for all of you. Now and in the future, no matter what you end up doing!
[Coach asks students: What does a coder do? (It's not a trick question!)]
Guide students to the answer: Writes code! Also: reads code, edits code and debugs code.
How many of you here are coders? If you have every written, read, editted, or debugged code (even one line!) then you are a coder.
[Coach asks students: What skills does a coder, like you, need to work with code?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
Guide students to the answer: Writes code! Also: reads code, edits code and debugs code.
How many of you here are coders? If you have every written, read, editted, or debugged code (even one line!) then you are a coder.
[Coach asks students: What skills does a coder, like you, need to work with code?]
Example answers:
- knowledge of the programming language
- problem-solving skills
- organizational skills
- logical thinking
- computational thinking
- creativity
[Coach asks students: Where else do we use these skills?]
Example answers:
- organization -> writing essays/books
- logical thinking -> math
- problem-solving -> doing homework
- creativity -> art
Coders work with code; that's obvious! But there's more to coding that just writing, reading, editing and debugging the code.
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
- verbal communication skills
- writing skills
- visual communication skills (diagrams)
- teamwork skills
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- class projects
- ANY workplace
- with family/friends
So far, we have figured out that a coder works with code and works with other people. There is one last part of the coding process that I want to talk about today. It can be the hardest to grasp, and many coders never get this part, but I know you all are ready to figure this out with me.
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
- grit
- self-reliance
- perseverance
- curiosity
- meta-cognitive skills
- humility
- passion/drive
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- playing an instrument
- research
- writing
- physical creation (building/carpentry/sewing/etc)
When we look at all this -- all the stuff a coder does and all the skills we need to do them -- it is a lot! But the good news is that you are building these skills all over the place, not just in this class. Every time you figure out a tough homework problem all on your own, you are using your problem-solving, self-reliance, and perseverance skills. At soccer practice you are building up your teamwork, communication, and grit skills.
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
Build a Bug Workshop
~10min
Build a Bug Workshop
Players purposely break and debug code in this partnered game.
Need:
- computers - 1 per Player
How to Play:
Set Up: Each Player needs complete, working code on their computer to start this game. Either tack it on to a game like Disintegrating Code, or preface the game by typing up code from reference, specification, or each Player's own imagination! Just be sure all code works before starting this game.
- Players pair up
- Players swap computers, each with complete working code
- Players put a bug in their partner's code -- causing an error
- Players swap back computers and debug their now-broken code
Tips & Tricks:
- Players can swap seats instead of computers to prevent dropping of computers.
- For some friendly competition, turn the game into a race: who can debug their code faster?
- Start this game with a discussion about the bugs they have come across so far -- spelling errors, missing paretheses, wrong keywords -- to spark creativity about the kind of errors to plant in their partner's code.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
~40 minutes5 modes
It takes more than just computer knowledge to be a coder; take a look all the different skills it takes to be the best coder in this map.
It takes more than just computer knowledge to be a coder; take a look all the different skills it takes to be the best coder in this map.
More On Bugs
what we all did and learned today.
Raise your hand if you have a reflection you want to share...
More On Bugs ~40 minutes
Learn some computer science history in this map.
Review
~5min
Review
What skills do we need to be a good debugger?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
The First Computer Bug...
~10min
The First Computer Bug...
The story of the moth in Mark II
Mode Summary & Goals
Summary: Learn the story of the First Computer bug -- a literal moth! -- and the common misconceptions about the story. On the way, also learn about Grace Hopper and about the creation of some of the first computers.
Goals and Gains:- Learn about Grace Hopper, an important historical figure in CS
- Connecting with CS history
- Not all stories are as true as they seem!
- Seeing BUGS in the "real world" -- something that even pros deal with
- Introduce Grace Hopper: computer scientist of the 40's, worked on some of the first computers -- Harvard Mark I and II.
- Tell the Grace-Hopper-is-the-First-Debugger myth:
- Grace Hopper was trying to find the cause of a problem in the Harvard Mark II. She found a moth in the circuits! This is why we call it debugging.
- Clarify the detais of what really happened:
- Grace Hopper wasn't working on the Mark II when this happened (as should would tell everyone!)
- The term "bug" int this sense had been used in engineering for a long time -- Even Thomas Edison used it!
- Important Epilogue: This doesn't lessen Grace Hopper's importance! She still:
- Wrote some of the first glossaries and computer science texts, popularizing the term "bug"
- Invented one of the first programming languages: COBOL
- Co-create the Mark I and II: paving the way for all computers to come
- Believed and taught a similar philosophy that MetaCoders holds: Coding is Language, to be a good at coding (or math, or engineering) you must also be a good communicator
Grace Hopper was one of the most famous early computer scientists, a pioneer in our field, and undeniably a mathematical and linguistic genius. Among her many accomplishments, she is often credited for the first case of literal "debugging". The myth (which isn't true) often gets told as follows:
One day in 1946, Grace Hopper realized that the Harvard Mark II computer (shown in pictures below) was malfunctioning. After checking the usual sources of errors and finding nothing, she began to open up panels of her giant computer.
Eventually, she found -- deep in the wires -- a dead moth. She plucked it out and taped the moth on a log book, writing beneath it: "First actual case of bug being found." The computer began to work again after that. Thus, Grace Hopper debugged the first computer. That log book now resides in the National Museum of American History.
The truth is that Grace Hopper wasn't actually there for that event in 1946, as she readily admitted -- although she had been instrumental in working on that computer. And it was her team that found the moth. Also, the term "bug" had been used by Thomas Edison in a similar way long before the Mark II computer was even built. It was quite common for inventors to remove bugs from electrical hardware.
Still, it was one of Grace Hopper's favorite stories. If not for her, we might not otherwise have known about it. A prolific writer, she wrote some of the earliest texts on computing and some of the earliest glossaries of computing terms (which, of course, included the words "bug" and "debugging" ever since that incident with the moth). She invented one of the earliest computer languages -- COBOL -- which is still in use today. "It's much easier for most people to write an English statement than it is to use symbols. So I decided data processors ought to be able to write their programs in English, and the computers would translate them into machine code," she said. COBOL was the first language designed to allow programmers to write in what felt like English -- thus enabling them to express thoughts as programs that they would not otherwise have been able to express.
She was a fierce advocate for the power learning to write well, in all mediums, not just in code and symbols: When she was a college math professor, she would often have her math students write essay. "[It is] no use trying to learn math unless [you can] communicate it with other people," she would argue. She applied that same philsophy to her work as a hardware and software engineer. She was a fantastic engineer with top-notch communication skills -- a crisp and clear writing style that allowed her to not just be a genuis, but to help others become geniuses.
So, although she didn't physically pull a moth out of the Mark II computer, she did help design the computer that the moth came out of. During her years of designing computers and programming languages, she reached the rank of Rear Admiral in the Navy. When she died, she received full military honors.
One day in 1946, Grace Hopper realized that the Harvard Mark II computer (shown in pictures below) was malfunctioning. After checking the usual sources of errors and finding nothing, she began to open up panels of her giant computer.
Eventually, she found -- deep in the wires -- a dead moth. She plucked it out and taped the moth on a log book, writing beneath it: "First actual case of bug being found." The computer began to work again after that. Thus, Grace Hopper debugged the first computer. That log book now resides in the National Museum of American History.
The truth is that Grace Hopper wasn't actually there for that event in 1946, as she readily admitted -- although she had been instrumental in working on that computer. And it was her team that found the moth. Also, the term "bug" had been used by Thomas Edison in a similar way long before the Mark II computer was even built. It was quite common for inventors to remove bugs from electrical hardware.
Still, it was one of Grace Hopper's favorite stories. If not for her, we might not otherwise have known about it. A prolific writer, she wrote some of the earliest texts on computing and some of the earliest glossaries of computing terms (which, of course, included the words "bug" and "debugging" ever since that incident with the moth). She invented one of the earliest computer languages -- COBOL -- which is still in use today. "It's much easier for most people to write an English statement than it is to use symbols. So I decided data processors ought to be able to write their programs in English, and the computers would translate them into machine code," she said. COBOL was the first language designed to allow programmers to write in what felt like English -- thus enabling them to express thoughts as programs that they would not otherwise have been able to express.
She was a fierce advocate for the power learning to write well, in all mediums, not just in code and symbols: When she was a college math professor, she would often have her math students write essay. "[It is] no use trying to learn math unless [you can] communicate it with other people," she would argue. She applied that same philsophy to her work as a hardware and software engineer. She was a fantastic engineer with top-notch communication skills -- a crisp and clear writing style that allowed her to not just be a genuis, but to help others become geniuses.
So, although she didn't physically pull a moth out of the Mark II computer, she did help design the computer that the moth came out of. During her years of designing computers and programming languages, she reached the rank of Rear Admiral in the Navy. When she died, she received full military honors.
- Who was Grace Hopper?
- Which branch of the military was Grace Hopper in?
- What is the name of the computer that the moth was found in?
Was the moth found before or after World War II?
WWII ended in 1945. The bug was found in 1946.
- Why did Grace Hopper make her math students write essays?
- In what way can becoming a better writer make you better at math?
- In what way can becoming a better writer make you better at coding?
- In what way can becoming better at coding make you better at writing?
- In what way can becoming better at coding make you better at math?
Tips & Tricks:
- Pull up picture of the Harvard Mark I (not many photos/info about Mark II), and the infamous moth.
- Cool facts about the Harvard Mark I and II:
- Mark II was completed in 1944
- Mark I weighed over 9,000 lbs and was 51 ft long, 8 ft tall and 2 ft wide.
- Mark I had 60 sets of 24 switches each to manually enter data.
- Mark I took 6 seconds to complete a multiplication task.
- Mark II was completed in 1947
- Mark II weighed 46,000 lbs!
- Mark II took less than a second to complete a multiplication task.
Reverse Translation
~10min
Reverse Translation
Starting with just an implementation, the Team translates it back to a specification with as much detail as possible.
Follow up this activity with typing up and running the code. Hide the code and only show the description that the Players came up with for an added challenge!
How to Play:
Reverse Translation
Starting with just an implementation, the Team translates it back to a specification with as much detail as possible.
Need:
- code card
How to Play:
Break up larger Teams into smaller groups for this Game so that all members of the Team have a chance to see the code card and voice their opinions.
- Coach gives the Team a code card, implementation-side up
- Without flipping the card, Team translates the code into english, describing what the code will do when run
- Coach guides the Players to give as much detail as possible
Tips & Tricks:
- Optional final step: Team tests their hypothesis by typing up the code and running it.
- If a projector is available, project the code where everyone can see it.
- Add a competitive element by splitting the larger Team into two or more Teams, showing all Teams the same code (pass around the card, write on a whiteboard, project from computer), set the timer for discussion, and then have each team present their case. Whomever is most detailed in their translation gets a point.
- Enforce equal input within a Team by having Players raise hands and wait to be called on or take turns around a circle sharing details about the code.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
~40 minutes5 modes
Learn some computer science history in this map.
Learn some computer science history in this map.
5-Week Starter Set
This is a sequence of classmaps that is ideal for beginning coaches running a 5-week course and works for students of various levels.
~60 minutes8 modes
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Award the first badge(s) of the session!
Award the first badge(s) of the session!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
6-Week Starter Set
This is a sequence of classmaps that is ideal for beginning coaches running a 6-week course and works for students of various levels.
~60 minutes8 modes
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
~60 minutes5 modes
Award the first badge(s) of the session!
Award the first badge(s) of the session!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Prepare for the Final Jam by reviewing code and practicing pair programming.
Prepare for the Final Jam by reviewing code and practicing pair programming.
~60 minutes5 modes
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
7-Week Starter Set
This is a sequence of classmaps that is ideal for beginning coaches running a 7-week course and works for students of various levels.
~60 minutes8 modes
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Award the first badge(s) of the session!
Award the first badge(s) of the session!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Re-enforce a specific Code, put it into practice, and grow student metacognition skills through reflection!
Re-enforce a specific Code, put it into practice, and grow student metacognition skills through reflection!
~60 minutes5 modes
Prepare for the Final Jam by reviewing code and practicing pair programming.
Prepare for the Final Jam by reviewing code and practicing pair programming.
~60 minutes5 modes
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
12-Week Starter Set (in progress)
This is a sequence of classmaps that is ideal for beginning coaches running a 12-week course and works for students of various levels.
~60 minutes8 modes
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Add a new Code to your Team's Code of Awesomeness!
Add a new Code to your Team's Code of Awesomeness!
~60 minutes5 modes
Award the first badge(s) of the session!
Award the first badge(s) of the session!
All About Bugs
We have a little extra time today to discuss today's class, specifically:
what we learned about bugs today.
Before we get started as a big group, I would like you to turn to the person next to you and take turns sharing on this topic. I'll set the timer for 2 minutes for you to do that. Ready, set, go!
Students discuss for 2 minutes before Coach regains focus.
Now, as we dive deeper into our thoughts and experiences, it is important that we respect each other and have a productive conversation by:
[Coach fills in: any rules or guidelines for the Team (see below).]
Who would like to start us off?
All About Bugs ~60 minutes
Get to know BUGS and a different way of thinking about them.
The Mars Orbiter Bug
~10min
The Mars Orbiter Bug
A mission to Mars is several miles (or kilometers) off track -- leading to disaster.
Mode Summary & Goals
Summary: A true story about a famous bug that caused the loss of a Mars Orbiter -- when some coders wrote the code thinking in Metric kilometers while others were thinking and writing in Imperial miles!
Goals and Gains:- Rethinking Bugs practice -- was the bug in the computer? or in the coders?
- Learning some cool computer science history
- Seeing BUGS in the "real world" -- something that even pros deal with
Tips & Tricks:
- Don't forget ask questions throughout and at the end! (see suggestions at the end)
- The Mars Climate Orbiter was sent to Mars in 1998.
- The hopes for the mission was to study the atmosphere and climate of Mars and learn more about why the planet, which once was covered in water, became a desert.
- After 286 days of space travel, the Orbiter got to Mars!
- But something went wrong -- it entered orbit too close to the atmosphere.
- We lost contact and lost the Orbiter -- either to the surface of Mars or the depths of space. We don't know!
- What happened?
- A bug in the code written to control the Orbiter
- The code was written by many people in many places -- some of are used to the Metric system (kilometers, meters, liters, grams....) and others, the Imperial system (miles, inches, pounds...)
- What would happen if I told you to 'go forward 5' and I meant steps, but you thought I meant city blocks?
- That's what happened with the Orbiter!
Mars was once covered with water. Ever since we discovered the evidence of this, the question on everyone's mind has been: Where did Mars' water go?
In 1998, scientists launched the Mars Climate Orbiter on an unmanned mission: to study the atmosphere and climate of the red planet. Using this new information, scientists hoped to figure out where the water had gone, and what had turned that red planet from an ocean world into a desert.
The Mars Climate Orbiter flew toward Mars for 286 days. As it approached the planet, the computer began to fire its thrusters to establish an orbit around the planet. But something went wrong.
The Orbiter was too close to the atmosphere! Its engines began to fail, and communication with that $200 million dollar spaceship was lost. To this day, we don't know where it is. It may have been destroyed in the Martian atmosphere, or it may have continued onward, exiting the planet's orbit. It may be circling the sun to this day -- a tiny scrap of metal compared to the giant planets of the solar system.
Although we don't know what happened after contact was lost -- scientists and engineers back on Earth do know why the ship malfunctioned when it drew near its final destination.
The software written to control the ship from Earth was enormous -- many million lines of code. To get a feel for how big the source code for a space mission can be, here's a picture of a coder named Margaret Hamilton standing next to a printout of code she and her team wrote for a different spaceship:
As you might expect, any giant piece of text written by human beings is going to have some mistakes in it. The code that controlled communication with the Mars Climate Orbiter had one nasty bug that doomed its mission -- going entirely unnoticed until it was too late.
The bug was simply this:
So the numbers transmitted by one piece of software to the other were interpreted incorrectly, causing a message to be sent to the Orbiter that (accidentally) told the Orbiter to fly too close to the Martian atmosphere. An analogy: suppose you told someone to run for 5 -- if they assumed you meant 5 miles they would run much farther than if they assumed you meant 5 kilometers.
Millions of dollars were lost, and a scientific mission doomed. Most people say it happened because of a software bug. But at MetaCoders, we know that the stories behind software bugs is more complex. The bug caused the crash. But what caused the bug?
In 1998, scientists launched the Mars Climate Orbiter on an unmanned mission: to study the atmosphere and climate of the red planet. Using this new information, scientists hoped to figure out where the water had gone, and what had turned that red planet from an ocean world into a desert.
The Mars Climate Orbiter flew toward Mars for 286 days. As it approached the planet, the computer began to fire its thrusters to establish an orbit around the planet. But something went wrong.
The Orbiter was too close to the atmosphere! Its engines began to fail, and communication with that $200 million dollar spaceship was lost. To this day, we don't know where it is. It may have been destroyed in the Martian atmosphere, or it may have continued onward, exiting the planet's orbit. It may be circling the sun to this day -- a tiny scrap of metal compared to the giant planets of the solar system.
Although we don't know what happened after contact was lost -- scientists and engineers back on Earth do know why the ship malfunctioned when it drew near its final destination.
The software written to control the ship from Earth was enormous -- many million lines of code. To get a feel for how big the source code for a space mission can be, here's a picture of a coder named Margaret Hamilton standing next to a printout of code she and her team wrote for a different spaceship:
As you might expect, any giant piece of text written by human beings is going to have some mistakes in it. The code that controlled communication with the Mars Climate Orbiter had one nasty bug that doomed its mission -- going entirely unnoticed until it was too late.
The bug was simply this:
One piece of software for controlling the Orbiter was designed to use metric units -- like the ones used everywhere except America. You know: kilometers, meters, liters, grams, etc.
Another piece of software was designed to use the other kind of units. You know: miles, inches, pounds, etc.
So the numbers transmitted by one piece of software to the other were interpreted incorrectly, causing a message to be sent to the Orbiter that (accidentally) told the Orbiter to fly too close to the Martian atmosphere. An analogy: suppose you told someone to run for 5 -- if they assumed you meant 5 miles they would run much farther than if they assumed you meant 5 kilometers.
Millions of dollars were lost, and a scientific mission doomed. Most people say it happened because of a software bug. But at MetaCoders, we know that the stories behind software bugs is more complex. The bug caused the crash. But what caused the bug?
- Why was the Orbiter launched?
- Did anyone die on the Orbiter?
What caused the Mars Orbiter bug? Whose fault is it?
There's no clear answer to this question. You could say that the programmer who wrote the faulty line caused the bug. But then, the question is -- why did that programmer think they were supposed to be using non-metric units? Why didn't the teams who wrote the two pieces of software communicate better about the units they were supposed to use? Why does our society use two different kinds of units in the first place? When discussing this it's mainly important to leave students with the understanding that things are more complex than they first thought.
- How do you make sure there are no bugs in your code?
- How do you think programmers make sure there are no bugs in gigantic, complicated pieces of code?
Build a Bug Workshop
~25min
Build a Bug Workshop
Players purposely break and debug code in this partnered game.
Need:
- computers - 1 per Player
How to Play:
Set Up: Each Player needs complete, working code on their computer to start this game. Either tack it on to a game like Disintegrating Code, or preface the game by typing up code from reference, specification, or each Player's own imagination! Just be sure all code works before starting this game.
- Players pair up
- Players swap computers, each with complete working code
- Players put a bug in their partner's code -- causing an error
- Players swap back computers and debug their now-broken code
Tips & Tricks:
- Players can swap seats instead of computers to prevent dropping of computers.
- For some friendly competition, turn the game into a race: who can debug their code faster?
- Start this game with a discussion about the bugs they have come across so far -- spelling errors, missing paretheses, wrong keywords -- to spark creativity about the kind of errors to plant in their partner's code.
Bugs in the brain
~15min
Bugs in the brain
Many young coders (all the way through college and their first few years on the job) seem to think that bugs happen by magic. In reality, they happen because coders are not self-aware enough.
If you debug one bug, you've just debugged one bug. If you debug your thinking, you've debugged a thousand bugs. If you've debugged someone else's thinking, please tell me how you did it -- because I never can. ~Stephen R. Foster, MetaCoders Founding Member- What is the difference between a bug and a mistake?
- What causes bugs?
- What causes mistakes?
- Why is it often hard for people to admit their mistakes?
- What are some ways you can reduce the number of mistakes you make?
- What might constitute a bug in an English essay?
- What's the difference between a bug and a mistake in an English essay??
Meta Story: Deep Reflection
~10min
Meta Story: Deep Reflection
A deeper dive into the subjects, challenges, and skill-building that happened in today's class.
Tips & Tricks:
- Start with a Think/Pair/Share model before a group conversation to get all students thinking and talking the topic, even if they don't all participate in the big dicussion.
- Ask follow up questions from the students to encourage deeper understanding. Can be as simple as "Why?"
- Other great questions: Who also felt that way? Who also faced that challenge? Who has advice for that?
- This is a deep reflection, so feel free to encourage students to raise their hands to respond to each other.
- Moderate to keep the conversation respectful and productive at all times.
We have a little extra time today to discuss today's class, specifically:
what we learned about bugs today.
Before we get started as a big group, I would like you to turn to the person next to you and take turns sharing on this topic. I'll set the timer for 2 minutes for you to do that. Ready, set, go!
Students discuss for 2 minutes before Coach regains focus.
Now, as we dive deeper into our thoughts and experiences, it is important that we respect each other and have a productive conversation by:
[Coach fills in: any rules or guidelines for the Team (see below).]
Who would like to start us off?
Depending on the age, maturity and size of the Team, you may want to set some guidelines to help promote a positive and productive discussion. Such as:
- Raised hands
- A "talking stick"
- You must continue the conversation, not just blurt out a random, unrelated thought
- We can only speak to our own experience, no one else's
~60 minutes4 modes
Get to know BUGS and a different way of thinking about them.
Get to know BUGS and a different way of thinking about them.
~60 minutes5 modes
Re-enforce a specific Code, put it into practice, and grow student metacognition skills through reflection!
Re-enforce a specific Code, put it into practice, and grow student metacognition skills through reflection!
~60 minutes5 modes
Prepare for the Final Jam by reviewing code and practicing pair programming.
Prepare for the Final Jam by reviewing code and practicing pair programming.
~60 minutes5 modes
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
Classmaps
Class Launch Map ~60 minutes
Start your session with introductions, the first Code of Awesomeness, and writing the Hello World code!
Coach Story
~5min
Coach Story
A chance to introduce yourself and some values of MetaCoders.
[Coach fills in: Your coach story][Coach fills in: Any discussion questions you wish to ask about your story]
Name Memory Game
~5min
Name Memory Game
Players share about themselves and test their memory by repeating what Players before them have said.
Need:
- no required supplies
How to Play:
Coach(es) should participate in the game as a Player as well as a Coach.
- Players (and Coach) sit in a circle
- Coach sets a prompt (see suggestions below)
- Player A states their name and an answer to the prompt
- Player B, the next Player in the circle, repeats Player A's name and answer
- Player B shares their own name and answer
- Player C repeats A and B's names and answers before adding their own
- Play continues around the circle until all Players have gone
Prompt Examples:
- Continue the conversation from your Coach Story by using a relevant discussion question as the prompt
- Any previous coding experience
- Favorite computer activity
- Dream pet/vacation/job/etc
- Favorite food/color/video game/book/movie/etc
- What you did over summer break/the weekend/etc
Course Introduction
~5min
Course Introduction
Introduce the course concepts and goals: including language, gamification, and learning how to learn!
Tips & Tricks:
- You may also want to summarize the day's schedule so students know what to expect. This can be especially helpful if you have a few more things to do before getting on computers, since students can get stuck "waiting" for this and get impatient rather than focusing on the important stories/games in the meantime.
- In this class we will learn about:
- Coding
- Learning
- Code is a language, like English. The language we are learning is _______.
- (Include features of the language/what you will be learning)
- Like learning anything, there will be easy and hard parts. As we learn coding remember it’s like learning language - easy and hard but with lots of practice, we can become fluent and code like we speak -- effortlessly!
- You will earn badges as you learn in this class!
- (Introduce other gamification elements such as: game jam, dollars, market, etc.)
As with all MetaCoders classes, we're here to get better at two things:
In order to practice either one of those, we need a language to learn. That way, we can learn that language -- and (more importantly) we can learn how to learn languages.
In this class, we're going to be using a language named [Coach fills in: #lang _______]. I've been learning this language myself, and I want to tell you about a few of its interesting features.
[Coach fills in: Mention one or two features of the language.]
As with any language, there are easy things about it. And there are hard things about it. But we're going to work together as a class to find things that are just right -- not to easy, and not too hard. That way we can increase our brains' abilities to read and write in that new language.
Lastly, this class is going to involve challenging ourselves with various games. For some of those games, I'll be giving out rewards and prizes!
[Coach fills in: Any additional information about your intended gamification in this class.]
Also, the class as a whole is a kind of like a game -- because you'll be getting badges every few weeks just for showing up and working hard. Remember that 100% of winning is showing up.
- Coding
- Learning
In order to practice either one of those, we need a language to learn. That way, we can learn that language -- and (more importantly) we can learn how to learn languages.
In this class, we're going to be using a language named [Coach fills in: #lang _______]. I've been learning this language myself, and I want to tell you about a few of its interesting features.
[Coach fills in: Mention one or two features of the language.]
As with any language, there are easy things about it. And there are hard things about it. But we're going to work together as a class to find things that are just right -- not to easy, and not too hard. That way we can increase our brains' abilities to read and write in that new language.
- Who has learned a foreign language before?
- Who can tell me some good strategies for learning a new language?
Which part of our brain do we need to grow to increase our ability to understand new languages?
Left hemisphere (for most people) -- specifically areas like Broca's area and Wernike's area.
Lastly, this class is going to involve challenging ourselves with various games. For some of those games, I'll be giving out rewards and prizes!
[Coach fills in: Any additional information about your intended gamification in this class.]
Also, the class as a whole is a kind of like a game -- because you'll be getting badges every few weeks just for showing up and working hard. Remember that 100% of winning is showing up.
- Getting prizes is cool -- but what is the larger purpose of those prizes?
- Why is it important to stay motivated over a long period of time when learning new languages?
- If you train your brain to learn languages, how will that help you as a coder?
- Who has learned a foreign language before?
- Who can tell me some good strategies for learning a new language?
Which part of our brain do we need to grow to increase our ability to understand new languages?
Left hemisphere (for most people) -- specifically areas like Broca's area and Wernike's area.
- Getting prizes is cool -- but what is the larger purpose of those prizes?
- Why is it important to stay motivated over a long period of time when learning new languages?
- If you train your brain to learn languages, how will that help you as a coder?
Overcome the Unknown Fable
~15min
Overcome the Unknown Fable
A Code of Awesomeness fable about two fish who looked the same on the outside, but whose minds were very different on the inside.
Mode Summary & Goals
Summary: Introduce the OVERCOME THE UNKNOWN Code to the Code of Awesomeness. Explore the values and ideas that this Code encompasses.
Goals and Gains:- Add a new Code to the Code of Awesomeness: Overcome the Unknown!
- Discuss the benefits of taking on new challenges.
- Learn about mindsets, world-views, attitudes and how they can change our life and behavior.
- Set up a classroom norm: sometimes we will do stuff we haven't done before!
- Relate the abstract concept (Overcome the Unknown) to tangable actions and experiences through story.
- Prepare for the Code Of Awesomeness Motto Creation Game Mode
- There are two fish, Trout and Catfish, who are the same except for the way they think and talk. For example:
- While Trout says: "I hate when the bigger fish laugh at me when I do coding. One day, I’ll be the best around."
- Catfish says: “I think I got better at coding today. If I keep it up, I’ll be the best around.”
- While Trout says: "I lost the coding competition, so I'm switching to jewelry-making. I hate losing."
- Catfish says: "I lost the coding competition, so I'm going to practice even harder for the next one."
- Both fish enter coding tournaments.
- Trout wins and laughs at all the smaller fish who lost.
- Catfish doesn't win, but talks to the other fish and learns what they did better than her.
- Both fish grow up and become the biggest fish in their pond
- Catfish decides to travel and learn more.
- Catfish competes with even bigger fish in bigger ponds. When she gets to be the biggest in the pond, she moves to an even bigger pond.
- Catfish grows into a gigantic fish.
- Meanwhile, Trout stays home and wins the same competition year after year. She laughs at the smaller fish.
- When Catfish comes home to see everyone, she is the biggest fish they have ever seen!
- Trout is upset, and she refuses to talk to Catfish at all.
- Trout stays in the small pond her whole life, one day losing to young fish. She retires from coding after that.
- Catfish travels the big ponds of the world, a medium-sized fish and one of the best fish coders ever.
Once upon a time, there were two small fish; Trout and Catfish. They both lived in one big pond -- at least it was a big pond for the two very small fish. Both Trout and Catfish were young and neither one of them was very good at things that all fishes do -- like coding, and skiing, and martial arts, and creative writing, and parachuting, and making jewelry, and eating smaller fish.
Although Trout and Catfish were best friends, there was one big difference between them. It wasn't their color. (Both were rainbow-colored.) It wasn't their dreams. (Both dreamed of becoming the biggest fishes in the pond.)
No, the difference was actually in the minds of the fish. You wouldn't be able to see the difference from the outside. But if you listened carefully to them talk, you might be able to hear it.
Trout would often say things like: "I hate when the bigger fish laugh at me when I do coding. One day, I'm going to be the best coder in the pond."
Catfish would often say things like: "I feel like I'm a tiny bit better at coding today than I was yesterday. If I keep this up, one day, I'll be the best coder in the pond."
Did you catch the difference? Let's listen again.
Trout once said: "I lost the coding competition, so I'm switching to jewelry-making because I'm better at that. I hate losing." (She did not, in fact, switch to jewelry-making.)
Catfish once said: "I lost the coding competition, so I'm going to practice even harder for the next one."
Did you catch the difference that time?
Time passed and both fish grew from tiny to medium-sized. The difference between their minds grew, too. One day at their weekly brunch, Trout and Catfish discussed the coding tournaments they had competed in over the last week:
"Yesterday, I beat a bunch of little minnows in the coding competition and laughed at them." Said Trout. "Small fish are so basic."
"Hmm." Catfish said. "Well, today, I lost my coding tournament. But it was a tough competition -- against some of the best coders in the entire pond."
"How many trophies do you have?" Trout asked. "I have six trophies!"
"I don't remember," Catfish said. "Not many. I don't go to tournaments for trophies."
Trout sighed -- sometimes Catfish was very odd.
More time passed and now both Trout and Catfish had grown to be the biggest in the whole pond -- even bigger than the turtles! That difference inside of them had also grown so large that anyone who knew them could hear it in the way they talked:
One day, after comparing herself to every other fish in the pond, Trout annouced: "We finally made it! We're officially the biggest fish in the whole pond. No one can beat me at coding."
Catfish said, "No one?"
"I could beat you if I wanted to," Trout said, "but I don't want to make you look bad."
"I don't mind if you make me look bad." Catfish said.
"Look -- I'm just too busy to compete with you right now," said Trout. "Maybe tomorrow."
Catfish said, "Actually, I'm leaving today."
"Leaving? You're leaving the pond?" Trout said, surprised. "But what about our dream of becoming the biggest fish in the whole pond? We finally did it!"
"It's just..." said Catfish, "don't you ever wonder if there are bigger ponds out there?"
"No!" said Trout. "I've spent my entire life becoming the biggest fish here. If the next pond is even bigger, there might be even bigger fish!"
"That's kind of what I'm hoping for," said Catfish.
"What if they laugh at you?" asked Trout.
"I suppose that might happen," said Catfish. "I'll take the risk."
"What if they are better at coding than you?" said Trout.
"Exactly!" said Catfish. "I can become even better out there than I can in here."
Trout humphed and swished away in a swarm of bubbles, saying over her shoulder, "Fine! With you gone, I'll finally be the biggest fish of all!"
Later that day, Catfish bought plane tickets to a larger pond -- it was ten times larger, filled with gigantic fish. When Catfish arrived in the new pond -- those gigantic fish did sometimes laugh at her. And the gigantic fish did code faster and better than her -- at least at first.
But slowly, Catfish grew, and kept entering coding tournaments, and the day that she became the biggest fish in that pond -- can you guess what she did? She bought plane tickets to a new pond -- one twenty times bigger than her home pond, filled with enormous fish!
Once again, Catfish was just one of the smaller fish, and at first Catfish lost every coding tournament. But Catfish knew what she was doing. For years, she moved from pond to pond, always knowing when to go -- once she had become the biggest in the old pond.
Many years later, Catfish decided to visit her home pond again. When she swam off the plane into that tiny pond, all of the other fishes' mouths dropped open. They had never in their entire lives dreamed that a fish could ever get that big.
Trout pushed her way through the shocked crowd to the front, until she was nose to (much larger) nose with Catfish.
"What are you doing back here?" Trout snapped.
"That's no way to treat an old friend," said Catfish.
Trout humphed and swam away, saying over her shoulder, "Go back to your big ponds and leave me alone."
It's always sad when two former friends' have such different mindsets that they cannot get along. Trout stuck to her small pond, entering the same small tournaments and winning the small trophies over and over again. She retired from tournaments early, the first time a young minnow beat her at a coding tournament.
Catfish, on the other hand, grew to be a medium-sized fish in some of the biggest ponds in the whole world. She went on to become one of the most famous fish coders of all time! She traveled all over, competing in the biggest coding tournaments -- sometimes winning and sometimes losing, but always learning.
Although Trout and Catfish were best friends, there was one big difference between them. It wasn't their color. (Both were rainbow-colored.) It wasn't their dreams. (Both dreamed of becoming the biggest fishes in the pond.)
No, the difference was actually in the minds of the fish. You wouldn't be able to see the difference from the outside. But if you listened carefully to them talk, you might be able to hear it.
Trout would often say things like: "I hate when the bigger fish laugh at me when I do coding. One day, I'm going to be the best coder in the pond."
Catfish would often say things like: "I feel like I'm a tiny bit better at coding today than I was yesterday. If I keep this up, one day, I'll be the best coder in the pond."
Did you catch the difference? Let's listen again.
Trout once said: "I lost the coding competition, so I'm switching to jewelry-making because I'm better at that. I hate losing." (She did not, in fact, switch to jewelry-making.)
Catfish once said: "I lost the coding competition, so I'm going to practice even harder for the next one."
Did you catch the difference that time?
Time passed and both fish grew from tiny to medium-sized. The difference between their minds grew, too. One day at their weekly brunch, Trout and Catfish discussed the coding tournaments they had competed in over the last week:
"Yesterday, I beat a bunch of little minnows in the coding competition and laughed at them." Said Trout. "Small fish are so basic."
"Hmm." Catfish said. "Well, today, I lost my coding tournament. But it was a tough competition -- against some of the best coders in the entire pond."
"How many trophies do you have?" Trout asked. "I have six trophies!"
"I don't remember," Catfish said. "Not many. I don't go to tournaments for trophies."
Trout sighed -- sometimes Catfish was very odd.
More time passed and now both Trout and Catfish had grown to be the biggest in the whole pond -- even bigger than the turtles! That difference inside of them had also grown so large that anyone who knew them could hear it in the way they talked:
One day, after comparing herself to every other fish in the pond, Trout annouced: "We finally made it! We're officially the biggest fish in the whole pond. No one can beat me at coding."
Catfish said, "No one?"
"I could beat you if I wanted to," Trout said, "but I don't want to make you look bad."
"I don't mind if you make me look bad." Catfish said.
"Look -- I'm just too busy to compete with you right now," said Trout. "Maybe tomorrow."
Catfish said, "Actually, I'm leaving today."
"Leaving? You're leaving the pond?" Trout said, surprised. "But what about our dream of becoming the biggest fish in the whole pond? We finally did it!"
"It's just..." said Catfish, "don't you ever wonder if there are bigger ponds out there?"
"No!" said Trout. "I've spent my entire life becoming the biggest fish here. If the next pond is even bigger, there might be even bigger fish!"
"That's kind of what I'm hoping for," said Catfish.
"What if they laugh at you?" asked Trout.
"I suppose that might happen," said Catfish. "I'll take the risk."
"What if they are better at coding than you?" said Trout.
"Exactly!" said Catfish. "I can become even better out there than I can in here."
Trout humphed and swished away in a swarm of bubbles, saying over her shoulder, "Fine! With you gone, I'll finally be the biggest fish of all!"
Later that day, Catfish bought plane tickets to a larger pond -- it was ten times larger, filled with gigantic fish. When Catfish arrived in the new pond -- those gigantic fish did sometimes laugh at her. And the gigantic fish did code faster and better than her -- at least at first.
But slowly, Catfish grew, and kept entering coding tournaments, and the day that she became the biggest fish in that pond -- can you guess what she did? She bought plane tickets to a new pond -- one twenty times bigger than her home pond, filled with enormous fish!
Once again, Catfish was just one of the smaller fish, and at first Catfish lost every coding tournament. But Catfish knew what she was doing. For years, she moved from pond to pond, always knowing when to go -- once she had become the biggest in the old pond.
Many years later, Catfish decided to visit her home pond again. When she swam off the plane into that tiny pond, all of the other fishes' mouths dropped open. They had never in their entire lives dreamed that a fish could ever get that big.
Trout pushed her way through the shocked crowd to the front, until she was nose to (much larger) nose with Catfish.
"What are you doing back here?" Trout snapped.
"That's no way to treat an old friend," said Catfish.
Trout humphed and swam away, saying over her shoulder, "Go back to your big ponds and leave me alone."
It's always sad when two former friends' have such different mindsets that they cannot get along. Trout stuck to her small pond, entering the same small tournaments and winning the small trophies over and over again. She retired from tournaments early, the first time a young minnow beat her at a coding tournament.
Catfish, on the other hand, grew to be a medium-sized fish in some of the biggest ponds in the whole world. She went on to become one of the most famous fish coders of all time! She traveled all over, competing in the biggest coding tournaments -- sometimes winning and sometimes losing, but always learning.
- Which fish had a better mindset?
- What adjectives would you use to describe Trout's mindset versus Catfish?
- Which fish had a 'growth mindset' and which had a 'fixed mindset'?
- In what ways are you like Trout?
- In what ways are you like Catfish?
- How can we help each other be more like Catfish and less like Trout?
- What could Catfish have said to Trout to convince her to think differently?
- How can you tell when someone has a mindset that's more like Trout than Catfish?
Tips & Tricks:
- For younger audiences, use a whiteboard to track the size and journeys of the two fish.
- Yes, it is ridiculous that fish might code. The authors know it, you know it, the audience knows it. Use the ridiculousness to your advantage!
- Don't forget to engage with questions -- at the end and throughout!
Code of Awesomeness Mottos
~10min
Code of Awesomeness Mottos
Customize the Code of Awesomeness by creating a unique Motto for one or multiple Codes.
Mode Summary & Goals
Summary: Foster a personal connection to the Code of Awesomeness by creating a unique motto or callback for each code.
Goals and Gains:- Personalize the lessons in a Code
- Create a shorthand for those connections through a simple phrase
- Practice teamwork, communication and compromise
Need:
- Optional: Whiteboard or other writing materials for notes
How to Play:
Make sure you have introduced whatever Code(s) you plan to create a Motto for with a story and discussion PRIOR to this game!
GOALS of Motto Creation:- Students co-create a linguistic tool that you can employ throughout the class, whenever you need to nudge students to apply certain values -- i.e. tenacity (rather than fear) in debugging, eagerness (rather than avoidance) when it comes to unknown concepts, and so on. This is also a great customized attention-getter.
- Students create a personal attachment to the Code of Awesomeness by creating a callback that engages them and their particular interests/sense of humor/personal story.
- Coach chooses a specific Code to create a Motto for
- Coach explains what a Code Motto is -- your team's very own response to a Code, that is fun, personal, and clarifies what that Code means to the team
- Coach introduces three options for a Motto (see Example Mottos below)
- Team votes, winning Motto is chosen by majority
- Practice Code/Motto Call/Response several times
- Repeat for additional Code(s) as desired
- Coach chooses a specific Code to create a Motto for
- Coach explains what a Code Motto is -- your team's very own response to a Code, that is fun, personal, and clarifies what that Code means to the team
- Coach introduces a couple Motto options (see Example Mottos below)
- Coach sets timer for 3 minutes
- Players brainstorm additional Motto options
- Coach or designated Player notes options
- Team votes on all options, winning Motto is chosen by majority
- Practice Code/Motto Call/Response several times
- Repeat for additional Code(s) as desired
Follow the same steps as Version Two, but break the Team into smaller groups prior to the brainstorming stage. Each group must decide on ONE option to present to the group. Entire Team votes on all options.
- Overcome the Unknown
- CHARGE!
- To infinity and beyond!
- To bodly go where no one's gone before!
- Into the UNKNOOOWNNN! (ala Frozen 2)
- Be a Bug Hunter
- SMUSH!
- Gotta catch 'em all!
- Bug found? Don't frown!
- Teach the Team
- Coders Assemble!
- Teamwork makes the dream work!
- Be a BOSS!
Tips & Tricks:
- Some Players will have their heart set on a Motto that is not chosen. Prepare to reassure Players that are disappointed -- "There were lots of cool options, I'm sorry yours didn't win" "It's about the whole team, not just what you want, and this was the one the team chose." "It's okay! There are more Codes and Mottos to come!"
- When leading a brainstorm, you may want to combine options or narrow down the list prior to voting, to simplify the process.
"Hello, World!"
~5min
"Hello, World!"
Why do we call the first code we write our Hello World program?
- The first program a coder writes in a new language is traditionally a Hello World program.
- This tradition comes from computer science textbooks written in the 1970's.
- A literal Hello World program prints out the words "Hello, World!" in the terminal.
- If possible, show some sample Hello World programs in various languages: samples listed below.
- Nowadays, a Hello World program can be more complex and powerful than it used to be, sometimes with even simplier code.
- Sometimes a Hello World program doesn't have anything to do with the words "Hello, World!" but it is still called that as the starting program in a new language.
In a moment we will be writing our first lines of code in our language. We call these lines of code our Hello World program because of a tradition that started way back in the 1970's (that's 50 years ago!). This piece of computer science history continues to influence coders today -- coders like you.
A computer science textbook published in 1978 entitled "The C Programming Language" included the following coding exercise:
Even before that, a textbook on the B programming language published in 1972 contained this example:
These textbooks were so influential -- specifically "The C Programming Language" -- that these very coding execises started a computer science tradition that is still observed today: when learning a new language, the first program a coder writes outputs the words "Hello, World."
Now, that code might look completely different from one computer language to another (after all, "Hello, world" can look and sound very different in human languages, right?). For example:
[Coach fills in: Project or otherwise display some of the eaxmples listed below.]
This "Hello, World" tradition is so embedded in coder-culture that even when the first program a coder writes has nothing to do with the words "Hello World" (maybe the code outputs an image, webpage, game, or even blinking LEDs in "the real world" instead of text on the screen!), a coder still might refer to this first program as their Hello World Program.
So, as coders and members of this huge community and culture of other coders, we are also going to call our first program our Hello World Program.
Are you ready to try it?
A computer science textbook published in 1978 entitled "The C Programming Language" included the following coding exercise:
main() {
printf(\"hello, world\\n\");
}Even before that, a textbook on the B programming language published in 1972 contained this example:
main( ) {
extern a, b, c;
putchar(a); putchar(b); putchar(c); putchar('!*n');
}
a 'hell';
b 'o, w';
c 'orld';These textbooks were so influential -- specifically "The C Programming Language" -- that these very coding execises started a computer science tradition that is still observed today: when learning a new language, the first program a coder writes outputs the words "Hello, World."
Now, that code might look completely different from one computer language to another (after all, "Hello, world" can look and sound very different in human languages, right?). For example:
[Coach fills in: Project or otherwise display some of the eaxmples listed below.]
This "Hello, World" tradition is so embedded in coder-culture that even when the first program a coder writes has nothing to do with the words "Hello World" (maybe the code outputs an image, webpage, game, or even blinking LEDs in "the real world" instead of text on the screen!), a coder still might refer to this first program as their Hello World Program.
So, as coders and members of this huge community and culture of other coders, we are also going to call our first program our Hello World Program.
Are you ready to try it?
Here are example Hello World programs in a few different languages:
- C (from the aforementioned 1970's textbook)
main() { printf(\"hello, world\\n\"); } - Racket
#lang racket "Hello, World!"
- Python
print "Hello World"
- Javascript
console.log("Hello World"); - Java
class HelloWorld { static public void main( String args[] ) { System.out.println( "Hello World!" ); } } - Ruby
puts "Hello, world!"
- Typescript
alert('Hello world!'); - Find more in this online collection.
Hello World Game
~10min
Hello World Game
The first coding game of most courses
Need:
- no required supplies
How to Play:
Run the game below, using the Hello World code card in your #lang
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:One UNKNOWN we OVERCAME today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
Be a Bug Hunter Map ~60 minutes
Add a new Code to your Team's Code of Awesomeness!
Review
~5min
Review
Look back at what we've learned or done in previous classes.
Who can tell me anything they remember about:the Code(s) in our Code of Awesomeness so far.
Tips & Tricks:
- Guide the conversation with leading questions as needed.
- Add any follow up points that the students missed after their comments.
Be a Bug Hunter Fable
~15min
Be a Bug Hunter Fable
A Code of Awesomeness fable about two animals who have different strategies for dealing with bugs.
Mode Summary & Goals
Summary: Introduce the BE A BUG HUNTER Code to the Code of Awesomeness. Explore the values and ideas that this Code encompasses.
Goals and Gains:- Add a new Code to the Code of Awesomeness: Be a Bug Hunter!
- Introduce the concept of a bug/debugging in coding.
- Discuss contrasting attitudes when it comes to facing problems.
- Set up a classroom norm: solve your bugs!
- Relate the abstract concept (Be a Bug Hunter) to tangable actions and experiences through story.
- Prepare for the Code Of Awesomeness Motto Creation Game Mode
- There are two friends, Woodpecker and Ostrich, who each want to build the biggest house before summer.
- Sometimes there are termites in the wood that both animals use to build:
- Whenever Woodpecker finds a termite, she stops building her house to get rid of them.
- Whenever Ostrich finds a termite, he ignores them so he can spend all his time building.
- For a while, Ostrich's house is growing bigger, faster than Woodpecker's.
- But then, the termites eat away at Ostrich's house and he is spending more time fixing than building.
- Woodpecker's house keeps growing steadily.
- When summer comes, both houses are huge.
- But when the first summer storm comes, Ostrich's house collapses!
- Woodpecker helps Ostrich to build a termite-free house by teaching him to be a bug hunter!
Once, long ago, Woodpecker and Ostrich were competing to build the biggest house in the desert. They began in the Spring, knowing they would have to finish before the hot summer arrived, bringing wild winds and dangerous sandstorms.
Now, the branches they were building with occasionally housed a termite or two. Whenever Woodpecker found a termite while building her house, she stopped building to track it down. This meant her house was not growing as quickly as Ostrich's. Meanwhile Ostrich was scared that he would fall behind in the contest if he stopped too long, so he kept building and ignored the termites. His house grew quickly.
Woodpecker and Ostrich worked for many days. Both houses grew bigger and bigger, but everyone could see that Ostrich was winning the contest. But the Spring wasn't over yet, and the houses weren't finished...
Woodpecker and Ostrich worked for many, many days. Woodpecker's house was gaining on Ostrich's. Ostrich was spending less and less time building and more and more time fixing the crumbling walls the termites were eating. Meanwhile, Woodpecker's house grew at the the same, steady pace.
Finally, the hot summer arrived. Woodpecker and Ostrich stayed cool in their equally huge houses. When the first big sandstorm blew through the desert, Woodpecker hid in her house, safe from the biting wind. Ostrich's house, however, collapsed with the first strong gust of wind.
Woodpecker helped Ostrich out of the wreckage of his termite-ridden house and brought him to her own to shelter from the storm. Woodpecker insisted that Ostrich spend the summer in her house, and offered to help him rebuild his own, come Fall. She also offered to show Ostrich how to hunt down any termites they came across in the process.
Ostrich gratefully accepted the help, and over that summer and fall, learned how to be a bug hunter. His new home was strong, sturdy, and bug-free. The two houses stood for years and years to come.
Now, the branches they were building with occasionally housed a termite or two. Whenever Woodpecker found a termite while building her house, she stopped building to track it down. This meant her house was not growing as quickly as Ostrich's. Meanwhile Ostrich was scared that he would fall behind in the contest if he stopped too long, so he kept building and ignored the termites. His house grew quickly.
Woodpecker and Ostrich worked for many days. Both houses grew bigger and bigger, but everyone could see that Ostrich was winning the contest. But the Spring wasn't over yet, and the houses weren't finished...
Woodpecker and Ostrich worked for many, many days. Woodpecker's house was gaining on Ostrich's. Ostrich was spending less and less time building and more and more time fixing the crumbling walls the termites were eating. Meanwhile, Woodpecker's house grew at the the same, steady pace.
Finally, the hot summer arrived. Woodpecker and Ostrich stayed cool in their equally huge houses. When the first big sandstorm blew through the desert, Woodpecker hid in her house, safe from the biting wind. Ostrich's house, however, collapsed with the first strong gust of wind.
Woodpecker helped Ostrich out of the wreckage of his termite-ridden house and brought him to her own to shelter from the storm. Woodpecker insisted that Ostrich spend the summer in her house, and offered to help him rebuild his own, come Fall. She also offered to show Ostrich how to hunt down any termites they came across in the process.
Ostrich gratefully accepted the help, and over that summer and fall, learned how to be a bug hunter. His new home was strong, sturdy, and bug-free. The two houses stood for years and years to come.
- How did Woodpecker and Ostrich approach the same problem differently?
- Which animal had the better strategy? Why?
- How does this story relate to coding?
- What specific coding habits could you adopt to code more like the Woodpecker?
- What specific coding habits could you get rid of to code less like the Ostrich?
- Why did Woodpecker help Ostrich?
- How can we help each other be more like Woodpecker?
Tips & Tricks:
- Before you start, you can let the students pick the characters. Use these characteristics as guides:
- (Woodpecker): practical and level-headed.
- (Ostrich): impulsive and anxious
- For younger students, physically indicate how the houses grow throughout the story: ex. 'Woodpeckers house was THIS tall' and holding your hand at knee-height.
Code of Awesomeness Mottos
~10min
Code of Awesomeness Mottos
Customize the Code of Awesomeness by creating a unique Motto for one or multiple Codes.
Mode Summary & Goals
Summary: Foster a personal connection to the Code of Awesomeness by creating a unique motto or callback for each code.
Goals and Gains:- Personalize the lessons in a Code
- Create a shorthand for those connections through a simple phrase
- Practice teamwork, communication and compromise
Need:
- Optional: Whiteboard or other writing materials for notes
How to Play:
Make sure you have introduced whatever Code(s) you plan to create a Motto for with a story and discussion PRIOR to this game!
GOALS of Motto Creation:- Students co-create a linguistic tool that you can employ throughout the class, whenever you need to nudge students to apply certain values -- i.e. tenacity (rather than fear) in debugging, eagerness (rather than avoidance) when it comes to unknown concepts, and so on. This is also a great customized attention-getter.
- Students create a personal attachment to the Code of Awesomeness by creating a callback that engages them and their particular interests/sense of humor/personal story.
- Coach chooses a specific Code to create a Motto for
- Coach explains what a Code Motto is -- your team's very own response to a Code, that is fun, personal, and clarifies what that Code means to the team
- Coach introduces three options for a Motto (see Example Mottos below)
- Team votes, winning Motto is chosen by majority
- Practice Code/Motto Call/Response several times
- Repeat for additional Code(s) as desired
- Coach chooses a specific Code to create a Motto for
- Coach explains what a Code Motto is -- your team's very own response to a Code, that is fun, personal, and clarifies what that Code means to the team
- Coach introduces a couple Motto options (see Example Mottos below)
- Coach sets timer for 3 minutes
- Players brainstorm additional Motto options
- Coach or designated Player notes options
- Team votes on all options, winning Motto is chosen by majority
- Practice Code/Motto Call/Response several times
- Repeat for additional Code(s) as desired
Follow the same steps as Version Two, but break the Team into smaller groups prior to the brainstorming stage. Each group must decide on ONE option to present to the group. Entire Team votes on all options.
- Overcome the Unknown
- CHARGE!
- To infinity and beyond!
- To bodly go where no one's gone before!
- Into the UNKNOOOWNNN! (ala Frozen 2)
- Be a Bug Hunter
- SMUSH!
- Gotta catch 'em all!
- Bug found? Don't frown!
- Teach the Team
- Coders Assemble!
- Teamwork makes the dream work!
- Be a BOSS!
Tips & Tricks:
- Some Players will have their heart set on a Motto that is not chosen. Prepare to reassure Players that are disappointed -- "There were lots of cool options, I'm sorry yours didn't win" "It's about the whole team, not just what you want, and this was the one the team chose." "It's okay! There are more Codes and Mottos to come!"
- When leading a brainstorm, you may want to combine options or narrow down the list prior to voting, to simplify the process.
Code Anatomy
~20min
Code Anatomy
Work as a team to label different parts of the code, then recall the code using only those terms.
Need:
- whiteboard and markers
- code & translation
How to Play:
Set Up: Write the entire code & translation on the board
- Team works together to remember/guess where the lang line is in the code, with the Coach's guidance
- Coach and Players label all parts of the code with terms like the ones below.
- Coach erases all code, leaving the labels
- Team works together to remember the code that belongs to each label, rebuilding the code as it was
- Repeat steps 4 and 5 until recall is easy
#lang ___________
= lang line#:_______________
= keyword(_______-game ...)
= game function call(basic-______ ...)
= entity function call(define (____) ...)
= function definition(_______________)
= function call"______________"
= string
[start-game-icon]
= game function call[first-sprite-icon]
= avatar- (name each list, what it creates)
- (match parens)
Tips & Tricks:
- End this game with Players typing up the code solo or in pairs, referencing the labels and translation.
- Add the timer (with a shorter time each round) for increased challenge.
- Coach can re-write the code every time, Players can take turns, or a Scribe may be designated within the Team.
- Set up can easily be delegated to a Player.
Meta Story: Deep Reflection
~10min
Meta Story: Deep Reflection
A deeper dive into the subjects, challenges, and skill-building that happened in today's class.
Tips & Tricks:
- Start with a Think/Pair/Share model before a group conversation to get all students thinking and talking the topic, even if they don't all participate in the big dicussion.
- Ask follow up questions from the students to encourage deeper understanding. Can be as simple as "Why?"
- Other great questions: Who also felt that way? Who also faced that challenge? Who has advice for that?
- This is a deep reflection, so feel free to encourage students to raise their hands to respond to each other.
- Moderate to keep the conversation respectful and productive at all times.
We have a little extra time today to discuss today's class, specifically:
what the team did and learned today.
Before we get started as a big group, I would like you to turn to the person next to you and take turns sharing on this topic. I'll set the timer for 2 minutes for you to do that. Ready, set, go!
Students discuss for 2 minutes before Coach regains focus.
Now, as we dive deeper into our thoughts and experiences, it is important that we respect each other and have a productive conversation by:
[Coach fills in: any rules or guidelines for the Team (see below).]
Who would like to start us off?
Depending on the age, maturity and size of the Team, you may want to set some guidelines to help promote a positive and productive discussion. Such as:
- Raised hands
- A "talking stick"
- You must continue the conversation, not just blurt out a random, unrelated thought
- We can only speak to our own experience, no one else's
First Badges Awarded Map ~60 minutes
Award the first badge(s) of the session!
Badges Today!
~5min
Badges Today!
A reminder about badges, and what they mean, for days when some students will earn a badge.
Tips & Tricks:
- Make this exciting! It's your job, as Coach, to make it clear what these Badges mean and give them a high level of importance. Do this by creating a ritual, being consistant with the meaning of the Badges (learning!), and keeping the value of the Badges (only given when earned).
- If you have an alternative Badge Ceremony, be sure to describe that ritual instead!
Mode Summary & Goals
Summary: Review information about and importance of badges in prep for awarding them at the end of class.
Goals and Gains:- Explain what a badge is and why students are getting them
- Outline when students get badges/badge certificates
- At the end of class today, some of you will have earned a Badge!
- We earn Badges as we learn and become better coders and better learners.
- Everytime you are here, you are learning. We track your attendance and award Badges according to that.
- But it's not just about showing up, it's about learning.
- So, as a part of the Badge Ceremony, each of you must tell us X thing(s) you have learned since your last Badge/the start of class that have made you a better coder and learner.
- Start thinking now, [fill in names of Badge-Earning students]!
- At the end of class we will have our Ceremony for the following students...
- The first badge you earn, you will receive a badge certificate and the badge itself!
- For the 2nd and 3rd badges, you will receive a badge certificate, and will get the badge in the mail at then end of class.
- Students that have not earned this Badge yet -- you will be getting your next Badge [fill in number of attendances remain for said students].
At the end of class today, we will be having our Badge Ceremony where some of you will be earning your Badges! We talked briefly about Badges at the start of this session, does anyone remember anything about Badges?
Coach clarifies/fills in any of the information below that students do not mention:
The Badges are symbols of our knowledge and growth: both as coders and as learners! We earn Badges as we build skills and fluencies. Now, it's hard for me to go inside your brain and measure all the new growth and neural connections that happen as we learn. So, we track how many classes you attend and award you Badges when you reach the classes Badge Goals!
During the Badge Ceremony, I will ask each of the Badge-Earners to tell us [Coach fills in: chosen number, between 1 and # of class attendances] things you have learned since the beginning of this session/your last badge because this isn't just about showing up, right? This is about what you have learned that has made you a better coder and a better learner.
So start thinking of those things now! Especially the students earning their badge today: [Coach fills in: names of badge-earners]
You will recieve a Badge Certificate to show everyone that you have earned this badge. You will get (or already have gotten) the first badge with your first certificate. All other badges you earn this session will come in the mail, after the last class!
Those of you who haven't earned this badge yet, don't worry! You will soon. [Coach fills in: number of attendances remaining for students yet to earn this badge]
Coach clarifies/fills in any of the information below that students do not mention:
The Badges are symbols of our knowledge and growth: both as coders and as learners! We earn Badges as we build skills and fluencies. Now, it's hard for me to go inside your brain and measure all the new growth and neural connections that happen as we learn. So, we track how many classes you attend and award you Badges when you reach the classes Badge Goals!
During the Badge Ceremony, I will ask each of the Badge-Earners to tell us [Coach fills in: chosen number, between 1 and # of class attendances] things you have learned since the beginning of this session/your last badge because this isn't just about showing up, right? This is about what you have learned that has made you a better coder and a better learner.
So start thinking of those things now! Especially the students earning their badge today: [Coach fills in: names of badge-earners]
You will recieve a Badge Certificate to show everyone that you have earned this badge. You will get (or already have gotten) the first badge with your first certificate. All other badges you earn this session will come in the mail, after the last class!
Those of you who haven't earned this badge yet, don't worry! You will soon. [Coach fills in: number of attendances remaining for students yet to earn this badge]
How do you get the Badge as well as the Badge Certificate?
Get parent's help to follow instructions on the Badge Certificate.
What do you need to do in the Badge Ceremony before you earn your Badge Certificate?
Tell us X things you have learned that make you a better coder and/or learner.
How are these badges different than, say, a 1st place trophy? Or a runnersup ribbon?
You aren't competing against anyone but yourself to earn them. There is not a limit on how many of you can earn them.
- Where else do you earn badges/awards like badges for what you have achieved?
- Who has earned a Badge in a class with us before?
- What can you do with these Badges?
Disintegrating Code
~20min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Pair Programming: Try It First
~15min
Pair Programming: Try It First
Try It First: now with more TEAMWORK
Need:
- See Below
How to Play:
Play the game below, but use pair programming techniques. Partner up the Players and have them play as a team, replacing every mention of a single Player in the game below with that partnership:
Try It First
Players try to figure out how to code a new specification with no hints before getting hints/the answer.
Need:
- computers - 1 per Player
- code card
- whiteboard/projector
- timer
How to Play:
- Coach announces the specification
- Coach sets timer for 1-5 minutes
- Players attempt to figure out how to code the specification
- When timer goes off, Coach writes the implementation on whiteboard/projected screen
- Coach resets timer
- Players try the code as shown
Tips & Tricks:
- Great for introducing new material once Players are getting comfortable with the code structures. Many Players will need a lot of coaching, cheerleading, and "just give it a shot!" encouragement to try something they don't know the answer to!
- When showing the correct answer, ask the Team to help you. If any Players figured it out, have them tell you what to write.
- Variation: Over the allotted time, slowly fill in the code. This works well for Players who are getting stuck -- at least they can add something.
- For the full effect, do not give any answers until the first timer goes off. Offer support but ask Players to try things out, without giving them the answers.
Market
~10min
Market
A chance to spend that MetaMoney and get cool prizes!
Need:
- A Market
- Market Cards
- MetaMoney (for change)
How to Play:
Set Up: Lay out Market Cards and put actual Market Stuff out of reach of Players
- Coach sets Market rules (see Suggestions below)
- Players visit Market in small groups
- One at a time, Players choose from Market Cards any purchases they wish to make
- Coach retrieves the purchase and exchanges for Player's MetaMoney
- Once a Player has finished at Market, they go back to their seat or to other set spot (ex. rug for Meta Story)
- Wait to be called over or released to come to Market.
- You must clean up your area/close your files/wrap up your mouse/etc before you are called over to Market.
- Only unfolded MetaMoney accepted at the Market
- Wait in line until your turn
- Market prizes must remain unopened until after class
Tips & Tricks:
- Market is a privilege, not a right (to quote everyone's parent) -- feel free to cancel Market if Players cannot follow Market Rules or other expectations of the day.
- Add any rules you need to keep the experience a positive, sane one for everyone (epecially you!)
- Note that time greatly depends on number of students, so plan accordingly.
- Think of Market like an arcade's ticket-shop -- all the merch is behind the glass and you only get it after you pay!
Meta Story: Badges
~10min
Meta Story: Badges
The Badge Ceremony!
Tips & Tricks:
- The exact ceremony outlined below is an example, you may create a unique ceremony as long as it connects the badge with what it means: the Student's growing knowledge and experience as a coder and learner.
- Whenever possible share the celebration with the parents: reminding students to share the certificate with their parents and proudly telling any parents of badger-earners that you interact with.
- Strive to make the badge ceremony a time to reflect on the personal growth that everyone has experienced. It's not about the badge; it's about what the badge represents. Only you -- the coach -- can help nurture this attitude.
- Coach describes the Badge Ceremony:
- When student name called, come up
- Student tells Coach X things they have learned
- Student receives Badge Certificate, takes a seat
- Coach goes through the Ceremony for each student who has earned the badge
- Team applauds for all students at the end
- If needed, Coach reminds other students how many more attendances until their next badge
It's time for the badge ceremony! When I call your name, I want you to come to the front. I'm going to ask to name three things you have learned over your time here so far -- and the things you have learned must be related to making you a better coder and/or a better learner. If you can give me an answer, I'll give you this badge certificate and you will recieve a physical badge through the mail!
First up is, [Coach fills in: name of badge-earning student from roster]!
First up is, [Coach fills in: name of badge-earning student from roster]!
Teach the Team Map ~60 minutes
Add a new Code to your Team's Code of Awesomeness!
Review
~5min
Review
Look back at what we've learned or done in previous classes.
Who can tell me anything they remember about:the Code(s) in our Code of Awesomeness so far.
Tips & Tricks:
- Guide the conversation with leading questions as needed.
- Add any follow up points that the students missed after their comments.
Teach the Team Fable
~15min
Teach the Team Fable
A Code of Awesomeness fable about the value of teaching others, and the paradoxical pitfall of hording ones knowledge.
Mode Summary & Goals
Summary: Introduce the TEACH THE TEAM Code to the Code of Awesomeness. Explore the values and ideas that this Code encompasses.
Goals and Gains:- Add a new Code to the Code of Awesomeness: Teach the Team!
- Discuss the benefits of sharing your knowledge.
- Set up a classroom norm: help each other out!
- Relate the abstract concept (Teach the Team) to tangable actions and experiences through story.
- Prepare for the Code Of Awesomeness Motto Creation Game Mode
- There are two students, Bear and Wolf, who are the top of their class.
- They are both studying for a very challenging history test.
- All the other students keep interrupting their studying to ask them for help and advice!
- Bear gets annoyed and hides away where no one can find him. He studies alone.
- Wolf helps out the other students, and ends up with a whole study group.
- When the scores for the test are released, Bear is shocked to see that he is in the middle of the pack, with Wolf and several other students with better grades than him!
- Bear thinks there was some error in grading, asks the teacher.
- Pause here and ask students what they think happened!
- Teacher asks how Bear and Wolf studied. Bear and Wolf share their different tactics.
- Teacher explains -- by teaching others and sharing their ideas, Wolf and the rest of the students gained a deeper understanding Bear did, studying alone.
- Next time, Bear joins the study group and they all do better on the test.
Once, long ago, there was a school in the depths of the forest. All manner of forest creatures attended the Old Oak School, including two classmates: Bear and Wolf.
Bear and Wolf were the top of their class -- always getting A's in every class! But the upcoming History exam even had the two of them nervous! Ms. Badger was a very strict teacher and she had warned them many times that this test would be the toughest one so far. It had short answers, long answers, 2 essays and no multiple choice questions!
So Bear and Wolf gathered their notes, books and study guides and settled in their favorite study nook by the river to get to work. But it wasn't long until they had a vistor. You see, the other students were also extremely nervous about the test. And they knew Bear and Wolf were the best in the class. And it was well-known where the two liked to study...
"Ahem," Raccoon coughed quietly. Bear and Wolf looked up from their notes. "I was stuck on this one question on the study guide, the one about comparing the laws of the Red Squirrel and Grey Squirrel Clans of the early 10th century, and I hoped you might be able to help me..."
Raccoon looked back and forth between Bear and Wolf, hopefully. After a tense moment, Bear said:
"Listen, I have to study hard for this too. I don't have time to answer your questions today."
Raccoon looked pleadingly to Wolf.
"Well," Wolf said, "I think I have an extra minute. I needed a break anyhow."
Bear rolled his eyes as Wolf talked Raccoon through the question. Wolf is wasting his time! Bear thought to himself.
Raccoon left a little while later, thanking Wolf profusely for his help. Wolf shrugged, and turned back to his books.
But it wasn't too long until they had another vistor: Chipmunk. She couldn't remember anything about the signing of the Great River Otter Treaty! Once again, Bear refused to stop his studying. And once again, Wolf offered to help out.
After Chipmunk came Deer, then Owl and Hedgehog had some questions, then Beaver was in need of help, then Hare and Boar and Snake and Moose--
"ENOUGH!" Bear shouted. "How am I supposed to get anything done with all of you traipsing in here everytime you have a silly little question! I don't know about you, Wolf, but I am going to find somewhere with some peace and quiet!"
Bear stomped off into the forest. He stomped off to a cave, deep in the forest, holed up with his notes, books, and study guide, lit a candle and studied in silence for the next three days until the test.
Meanwhile, Wolf and Moose were left in the dust of Bear's departure.
"Well then." Moose declared. "As I was saying -- I just don't understand what Ms. Badger is asking here about the Era of the Redwoods! I don't have anything about any Red Woods in my notes... Only Brown and Green Woods!"
Wolf pulled some notes from his folder and began to explain. Shortly, they were joined again by Owl and Hedgehog, who overheard their discussion and were eager to hear Wolf's explaination. Then Hare and Chipmunk returned, with 2 more questions of their own, questions that Hedgehog had her own thoughts on.
Soon, their little group grew too big for the Study Nook by the river. Wolf and the other animals moved to a field nearby, where more animals joined them. Discussions sprung up all over the group as the animals shared questions, notes, thoughts and ideas. Wolf left his study guide behind, wandering through the large group, joining discussions and answering questions as needed. And so it continued for the three days leading up to the test.
The Big History Test came and went. The only thing now was to wait for Ms. Badger to finish grading! It seemed like ages until the day when she finally announced that she would be passing back their tests.
Bear was one of the first to get his test back (it was helpful being near the beginning of the alphabet!) and he held his breath as he looked for the final grade, in red ink --
B-?! Bear was disappointed, of course -- he rarely got anything lower than an A -- but he quickly reminded himself how difficult the test was. Bear was sure his B- still put him at the head of the class.
But then he started to hear the whispers from his classmates as they recieved their graded tests: excited whispers claiming C+'s, B-'s, even B's, B+'s! Wolf was at the top of the class with an A+!
Now this was unheard of! Wolf sometimes bested Bear, but Hedgehog? And Moose?! There must have been some kind of mistake!
"Excuse me, Ms. Badger!" Called Bear. "I think there might have been an error in my grading."
The whole class froze -- did Bear just tell Ms. Badger that she made a mistake?!
"Is that so?" Ms. Badger walked to Bear's desk and peered at his test. She flipped through the pages. She placed the test back on his desk. "The grading is correct."
"B-But," Bear protested, "how could that be?! Owl said he also got a B-. And so did Chipmunk! Moose said he got a B+. And Wolf got an A+?! That's impossible!"
"Perhaps they studied more effectively."
"I studied non-stop for three days! It would have been more if all the others did keep interrupting Wolf and I with their silly questions." Bear glared around the room. "But I finally manage to find some peace and quiet, reviewed all my notes at least two dozen times, wrote five practice essays, made a set of 50 flash cards with dates and names -- it just doesn't make sense! What could they have done that I didn't?"
"Well," Moose said, "I don't know about all that. We all kind of ended up studying -- together."
"Yeah, I had a question about the study guide, and I asked Wolf." Said Chipmunk. "And Hedgehog was there and we ended up discussing it for a while. Then Wolf helped us both understand the differences between the two Squirrel Skirmishes. Wolf really helped us all out."
Everyone looked to Wolf, who had gotten the best grade of the whole class.
"I didn't actually have any time to study." Wolf admitted. "I am surprised I did this well. Everyone had questions and I wanted to help, so I just ended up... doing that instead."
"That's why the rest of the class excelled." Ms. Badger said to Bear. "By sharing their notes and ideas, they gained more knowledge. Wolf did this the most, and he learned the most. By teaching what he knew, and listening to what others knew and thought, Wolf built a deeper understanding of the material."
Everyone looked at Wolf, again.
"I had no idea!" Wolf said. "But come to think of it, when I was explaining things to the others, I found new details I hadn't really noticed before. Because I had to be really clear, and often someone had a question I hadn't even thought of before."
"That is how I know so much about our forest history myself." Said Ms. Badger. "Teaching others helps you learn."
Some time later, Wolf and his classmates were studying for the upcoming math test. They were all in the field by the river, taking turns explaining different formulas and inventing word problems for each other. Everyone was listening to Hedgehog explain how to find the area of a triangle, when they had a very unexpected visitor.
"Hello, Bear." Said Wolf.
"Hi, everyone." Said Bear. "M-May I... Do you think... Can I join your study group?"
"Of course!" Wolf said.
Bear joined the group, and took his turn teaching the team shortly after. Later that week, Bear, Wolf and the rest of the class all aced the test!
Bear and Wolf were the top of their class -- always getting A's in every class! But the upcoming History exam even had the two of them nervous! Ms. Badger was a very strict teacher and she had warned them many times that this test would be the toughest one so far. It had short answers, long answers, 2 essays and no multiple choice questions!
So Bear and Wolf gathered their notes, books and study guides and settled in their favorite study nook by the river to get to work. But it wasn't long until they had a vistor. You see, the other students were also extremely nervous about the test. And they knew Bear and Wolf were the best in the class. And it was well-known where the two liked to study...
"Ahem," Raccoon coughed quietly. Bear and Wolf looked up from their notes. "I was stuck on this one question on the study guide, the one about comparing the laws of the Red Squirrel and Grey Squirrel Clans of the early 10th century, and I hoped you might be able to help me..."
Raccoon looked back and forth between Bear and Wolf, hopefully. After a tense moment, Bear said:
"Listen, I have to study hard for this too. I don't have time to answer your questions today."
Raccoon looked pleadingly to Wolf.
"Well," Wolf said, "I think I have an extra minute. I needed a break anyhow."
Bear rolled his eyes as Wolf talked Raccoon through the question. Wolf is wasting his time! Bear thought to himself.
Raccoon left a little while later, thanking Wolf profusely for his help. Wolf shrugged, and turned back to his books.
But it wasn't too long until they had another vistor: Chipmunk. She couldn't remember anything about the signing of the Great River Otter Treaty! Once again, Bear refused to stop his studying. And once again, Wolf offered to help out.
After Chipmunk came Deer, then Owl and Hedgehog had some questions, then Beaver was in need of help, then Hare and Boar and Snake and Moose--
"ENOUGH!" Bear shouted. "How am I supposed to get anything done with all of you traipsing in here everytime you have a silly little question! I don't know about you, Wolf, but I am going to find somewhere with some peace and quiet!"
Bear stomped off into the forest. He stomped off to a cave, deep in the forest, holed up with his notes, books, and study guide, lit a candle and studied in silence for the next three days until the test.
Meanwhile, Wolf and Moose were left in the dust of Bear's departure.
"Well then." Moose declared. "As I was saying -- I just don't understand what Ms. Badger is asking here about the Era of the Redwoods! I don't have anything about any Red Woods in my notes... Only Brown and Green Woods!"
Wolf pulled some notes from his folder and began to explain. Shortly, they were joined again by Owl and Hedgehog, who overheard their discussion and were eager to hear Wolf's explaination. Then Hare and Chipmunk returned, with 2 more questions of their own, questions that Hedgehog had her own thoughts on.
Soon, their little group grew too big for the Study Nook by the river. Wolf and the other animals moved to a field nearby, where more animals joined them. Discussions sprung up all over the group as the animals shared questions, notes, thoughts and ideas. Wolf left his study guide behind, wandering through the large group, joining discussions and answering questions as needed. And so it continued for the three days leading up to the test.
The Big History Test came and went. The only thing now was to wait for Ms. Badger to finish grading! It seemed like ages until the day when she finally announced that she would be passing back their tests.
Bear was one of the first to get his test back (it was helpful being near the beginning of the alphabet!) and he held his breath as he looked for the final grade, in red ink --
B-?! Bear was disappointed, of course -- he rarely got anything lower than an A -- but he quickly reminded himself how difficult the test was. Bear was sure his B- still put him at the head of the class.
But then he started to hear the whispers from his classmates as they recieved their graded tests: excited whispers claiming C+'s, B-'s, even B's, B+'s! Wolf was at the top of the class with an A+!
Now this was unheard of! Wolf sometimes bested Bear, but Hedgehog? And Moose?! There must have been some kind of mistake!
"Excuse me, Ms. Badger!" Called Bear. "I think there might have been an error in my grading."
The whole class froze -- did Bear just tell Ms. Badger that she made a mistake?!
"Is that so?" Ms. Badger walked to Bear's desk and peered at his test. She flipped through the pages. She placed the test back on his desk. "The grading is correct."
"B-But," Bear protested, "how could that be?! Owl said he also got a B-. And so did Chipmunk! Moose said he got a B+. And Wolf got an A+?! That's impossible!"
"Perhaps they studied more effectively."
"I studied non-stop for three days! It would have been more if all the others did keep interrupting Wolf and I with their silly questions." Bear glared around the room. "But I finally manage to find some peace and quiet, reviewed all my notes at least two dozen times, wrote five practice essays, made a set of 50 flash cards with dates and names -- it just doesn't make sense! What could they have done that I didn't?"
"Well," Moose said, "I don't know about all that. We all kind of ended up studying -- together."
"Yeah, I had a question about the study guide, and I asked Wolf." Said Chipmunk. "And Hedgehog was there and we ended up discussing it for a while. Then Wolf helped us both understand the differences between the two Squirrel Skirmishes. Wolf really helped us all out."
Everyone looked to Wolf, who had gotten the best grade of the whole class.
"I didn't actually have any time to study." Wolf admitted. "I am surprised I did this well. Everyone had questions and I wanted to help, so I just ended up... doing that instead."
"That's why the rest of the class excelled." Ms. Badger said to Bear. "By sharing their notes and ideas, they gained more knowledge. Wolf did this the most, and he learned the most. By teaching what he knew, and listening to what others knew and thought, Wolf built a deeper understanding of the material."
Everyone looked at Wolf, again.
"I had no idea!" Wolf said. "But come to think of it, when I was explaining things to the others, I found new details I hadn't really noticed before. Because I had to be really clear, and often someone had a question I hadn't even thought of before."
"That is how I know so much about our forest history myself." Said Ms. Badger. "Teaching others helps you learn."
Some time later, Wolf and his classmates were studying for the upcoming math test. They were all in the field by the river, taking turns explaining different formulas and inventing word problems for each other. Everyone was listening to Hedgehog explain how to find the area of a triangle, when they had a very unexpected visitor.
"Hello, Bear." Said Wolf.
"Hi, everyone." Said Bear. "M-May I... Do you think... Can I join your study group?"
"Of course!" Wolf said.
Bear joined the group, and took his turn teaching the team shortly after. Later that week, Bear, Wolf and the rest of the class all aced the test!
- What was Bear's studying strategy? Wolf's? The other animals'?
- Which animal had the better strategy? Why?
- Why did Wolf and many of the other animals do better on the test than Bear?
- How does this story relate to our class?
- What can we do in this class to be more like Wolf?
- How can we help each other learn? What 'helping' doesn't actually help our team learn?
- How do you like to work on homework/study for tests?
Tips & Tricks:
- Try pausing the story after revealing the grades and asking the students why Wolf and so many of the other animals did better than Bear.
- Before you start, you can let the students pick the characters. Use these characteristics as guides:
- (Bear): works alone, smart
- (Wolf): a team player, smart
Code of Awesomeness Mottos
~10min
Code of Awesomeness Mottos
Customize the Code of Awesomeness by creating a unique Motto for one or multiple Codes.
Mode Summary & Goals
Summary: Foster a personal connection to the Code of Awesomeness by creating a unique motto or callback for each code.
Goals and Gains:- Personalize the lessons in a Code
- Create a shorthand for those connections through a simple phrase
- Practice teamwork, communication and compromise
Need:
- Optional: Whiteboard or other writing materials for notes
How to Play:
Make sure you have introduced whatever Code(s) you plan to create a Motto for with a story and discussion PRIOR to this game!
GOALS of Motto Creation:- Students co-create a linguistic tool that you can employ throughout the class, whenever you need to nudge students to apply certain values -- i.e. tenacity (rather than fear) in debugging, eagerness (rather than avoidance) when it comes to unknown concepts, and so on. This is also a great customized attention-getter.
- Students create a personal attachment to the Code of Awesomeness by creating a callback that engages them and their particular interests/sense of humor/personal story.
- Coach chooses a specific Code to create a Motto for
- Coach explains what a Code Motto is -- your team's very own response to a Code, that is fun, personal, and clarifies what that Code means to the team
- Coach introduces three options for a Motto (see Example Mottos below)
- Team votes, winning Motto is chosen by majority
- Practice Code/Motto Call/Response several times
- Repeat for additional Code(s) as desired
- Coach chooses a specific Code to create a Motto for
- Coach explains what a Code Motto is -- your team's very own response to a Code, that is fun, personal, and clarifies what that Code means to the team
- Coach introduces a couple Motto options (see Example Mottos below)
- Coach sets timer for 3 minutes
- Players brainstorm additional Motto options
- Coach or designated Player notes options
- Team votes on all options, winning Motto is chosen by majority
- Practice Code/Motto Call/Response several times
- Repeat for additional Code(s) as desired
Follow the same steps as Version Two, but break the Team into smaller groups prior to the brainstorming stage. Each group must decide on ONE option to present to the group. Entire Team votes on all options.
- Overcome the Unknown
- CHARGE!
- To infinity and beyond!
- To bodly go where no one's gone before!
- Into the UNKNOOOWNNN! (ala Frozen 2)
- Be a Bug Hunter
- SMUSH!
- Gotta catch 'em all!
- Bug found? Don't frown!
- Teach the Team
- Coders Assemble!
- Teamwork makes the dream work!
- Be a BOSS!
Tips & Tricks:
- Some Players will have their heart set on a Motto that is not chosen. Prepare to reassure Players that are disappointed -- "There were lots of cool options, I'm sorry yours didn't win" "It's about the whole team, not just what you want, and this was the one the team chose." "It's okay! There are more Codes and Mottos to come!"
- When leading a brainstorm, you may want to combine options or narrow down the list prior to voting, to simplify the process.
Pair Programming: Create a Challenge
~25min
Pair Programming: Create a Challenge
Create a Challenge: now with more TEAMWORK
Need:
- See Below
How to Play:
Play the game below, but use pair programming techniques. Partner up the Players and have them play as a team, replacing every mention of a single Player in the game below with that partnership:
Create a Challenge
The Team works together to design specification for a coding challenge, before taking on that challenge themselves.
Need:
- whiteboard/paper and writing utensils
- computers - 1 per Player
How to Play:
- Team designs an achievable specification
- The finalized specification is written down where everyone can see
- Team designates a time limit and sets the timer
- Players code an implementation on individual computers
Tips & Tricks:
- Ideally, a Team could run this game entirely by themselves without the Coach's help! But most teams, especially those with younger or inexperienced Players, will need the Coach's guidance to work well as a team and find a specification and time limit that is a good balance of challenging and acheivable. Experienment with when to step in and when to let the Team figure it out.
- Teams with a wide range in skill and experience can easily be split into smaller Teams, each running this game independently of the other Team(s).
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
All About Bugs ~60 minutes
Get to know BUGS and a different way of thinking about them.
The Mars Orbiter Bug
~10min
The Mars Orbiter Bug
A mission to Mars is several miles (or kilometers) off track -- leading to disaster.
Mode Summary & Goals
Summary: A true story about a famous bug that caused the loss of a Mars Orbiter -- when some coders wrote the code thinking in Metric kilometers while others were thinking and writing in Imperial miles!
Goals and Gains:- Rethinking Bugs practice -- was the bug in the computer? or in the coders?
- Learning some cool computer science history
- Seeing BUGS in the "real world" -- something that even pros deal with
Tips & Tricks:
- Don't forget ask questions throughout and at the end! (see suggestions at the end)
- The Mars Climate Orbiter was sent to Mars in 1998.
- The hopes for the mission was to study the atmosphere and climate of Mars and learn more about why the planet, which once was covered in water, became a desert.
- After 286 days of space travel, the Orbiter got to Mars!
- But something went wrong -- it entered orbit too close to the atmosphere.
- We lost contact and lost the Orbiter -- either to the surface of Mars or the depths of space. We don't know!
- What happened?
- A bug in the code written to control the Orbiter
- The code was written by many people in many places -- some of are used to the Metric system (kilometers, meters, liters, grams....) and others, the Imperial system (miles, inches, pounds...)
- What would happen if I told you to 'go forward 5' and I meant steps, but you thought I meant city blocks?
- That's what happened with the Orbiter!
Mars was once covered with water. Ever since we discovered the evidence of this, the question on everyone's mind has been: Where did Mars' water go?
In 1998, scientists launched the Mars Climate Orbiter on an unmanned mission: to study the atmosphere and climate of the red planet. Using this new information, scientists hoped to figure out where the water had gone, and what had turned that red planet from an ocean world into a desert.
The Mars Climate Orbiter flew toward Mars for 286 days. As it approached the planet, the computer began to fire its thrusters to establish an orbit around the planet. But something went wrong.
The Orbiter was too close to the atmosphere! Its engines began to fail, and communication with that $200 million dollar spaceship was lost. To this day, we don't know where it is. It may have been destroyed in the Martian atmosphere, or it may have continued onward, exiting the planet's orbit. It may be circling the sun to this day -- a tiny scrap of metal compared to the giant planets of the solar system.
Although we don't know what happened after contact was lost -- scientists and engineers back on Earth do know why the ship malfunctioned when it drew near its final destination.
The software written to control the ship from Earth was enormous -- many million lines of code. To get a feel for how big the source code for a space mission can be, here's a picture of a coder named Margaret Hamilton standing next to a printout of code she and her team wrote for a different spaceship:
As you might expect, any giant piece of text written by human beings is going to have some mistakes in it. The code that controlled communication with the Mars Climate Orbiter had one nasty bug that doomed its mission -- going entirely unnoticed until it was too late.
The bug was simply this:
So the numbers transmitted by one piece of software to the other were interpreted incorrectly, causing a message to be sent to the Orbiter that (accidentally) told the Orbiter to fly too close to the Martian atmosphere. An analogy: suppose you told someone to run for 5 -- if they assumed you meant 5 miles they would run much farther than if they assumed you meant 5 kilometers.
Millions of dollars were lost, and a scientific mission doomed. Most people say it happened because of a software bug. But at MetaCoders, we know that the stories behind software bugs is more complex. The bug caused the crash. But what caused the bug?
In 1998, scientists launched the Mars Climate Orbiter on an unmanned mission: to study the atmosphere and climate of the red planet. Using this new information, scientists hoped to figure out where the water had gone, and what had turned that red planet from an ocean world into a desert.
The Mars Climate Orbiter flew toward Mars for 286 days. As it approached the planet, the computer began to fire its thrusters to establish an orbit around the planet. But something went wrong.
The Orbiter was too close to the atmosphere! Its engines began to fail, and communication with that $200 million dollar spaceship was lost. To this day, we don't know where it is. It may have been destroyed in the Martian atmosphere, or it may have continued onward, exiting the planet's orbit. It may be circling the sun to this day -- a tiny scrap of metal compared to the giant planets of the solar system.
Although we don't know what happened after contact was lost -- scientists and engineers back on Earth do know why the ship malfunctioned when it drew near its final destination.
The software written to control the ship from Earth was enormous -- many million lines of code. To get a feel for how big the source code for a space mission can be, here's a picture of a coder named Margaret Hamilton standing next to a printout of code she and her team wrote for a different spaceship:
As you might expect, any giant piece of text written by human beings is going to have some mistakes in it. The code that controlled communication with the Mars Climate Orbiter had one nasty bug that doomed its mission -- going entirely unnoticed until it was too late.
The bug was simply this:
One piece of software for controlling the Orbiter was designed to use metric units -- like the ones used everywhere except America. You know: kilometers, meters, liters, grams, etc.
Another piece of software was designed to use the other kind of units. You know: miles, inches, pounds, etc.
So the numbers transmitted by one piece of software to the other were interpreted incorrectly, causing a message to be sent to the Orbiter that (accidentally) told the Orbiter to fly too close to the Martian atmosphere. An analogy: suppose you told someone to run for 5 -- if they assumed you meant 5 miles they would run much farther than if they assumed you meant 5 kilometers.
Millions of dollars were lost, and a scientific mission doomed. Most people say it happened because of a software bug. But at MetaCoders, we know that the stories behind software bugs is more complex. The bug caused the crash. But what caused the bug?
- Why was the Orbiter launched?
- Did anyone die on the Orbiter?
What caused the Mars Orbiter bug? Whose fault is it?
There's no clear answer to this question. You could say that the programmer who wrote the faulty line caused the bug. But then, the question is -- why did that programmer think they were supposed to be using non-metric units? Why didn't the teams who wrote the two pieces of software communicate better about the units they were supposed to use? Why does our society use two different kinds of units in the first place? When discussing this it's mainly important to leave students with the understanding that things are more complex than they first thought.
- How do you make sure there are no bugs in your code?
- How do you think programmers make sure there are no bugs in gigantic, complicated pieces of code?
Build a Bug Workshop
~25min
Build a Bug Workshop
Players purposely break and debug code in this partnered game.
Need:
- computers - 1 per Player
How to Play:
Set Up: Each Player needs complete, working code on their computer to start this game. Either tack it on to a game like Disintegrating Code, or preface the game by typing up code from reference, specification, or each Player's own imagination! Just be sure all code works before starting this game.
- Players pair up
- Players swap computers, each with complete working code
- Players put a bug in their partner's code -- causing an error
- Players swap back computers and debug their now-broken code
Tips & Tricks:
- Players can swap seats instead of computers to prevent dropping of computers.
- For some friendly competition, turn the game into a race: who can debug their code faster?
- Start this game with a discussion about the bugs they have come across so far -- spelling errors, missing paretheses, wrong keywords -- to spark creativity about the kind of errors to plant in their partner's code.
Bugs in the brain
~15min
Bugs in the brain
Many young coders (all the way through college and their first few years on the job) seem to think that bugs happen by magic. In reality, they happen because coders are not self-aware enough.
If you debug one bug, you've just debugged one bug. If you debug your thinking, you've debugged a thousand bugs. If you've debugged someone else's thinking, please tell me how you did it -- because I never can. ~Stephen R. Foster, MetaCoders Founding Member- What is the difference between a bug and a mistake?
- What causes bugs?
- What causes mistakes?
- Why is it often hard for people to admit their mistakes?
- What are some ways you can reduce the number of mistakes you make?
- What might constitute a bug in an English essay?
- What's the difference between a bug and a mistake in an English essay??
Meta Story: Deep Reflection
~10min
Meta Story: Deep Reflection
A deeper dive into the subjects, challenges, and skill-building that happened in today's class.
Tips & Tricks:
- Start with a Think/Pair/Share model before a group conversation to get all students thinking and talking the topic, even if they don't all participate in the big dicussion.
- Ask follow up questions from the students to encourage deeper understanding. Can be as simple as "Why?"
- Other great questions: Who also felt that way? Who also faced that challenge? Who has advice for that?
- This is a deep reflection, so feel free to encourage students to raise their hands to respond to each other.
- Moderate to keep the conversation respectful and productive at all times.
We have a little extra time today to discuss today's class, specifically:
what we learned about bugs today.
Before we get started as a big group, I would like you to turn to the person next to you and take turns sharing on this topic. I'll set the timer for 2 minutes for you to do that. Ready, set, go!
Students discuss for 2 minutes before Coach regains focus.
Now, as we dive deeper into our thoughts and experiences, it is important that we respect each other and have a productive conversation by:
[Coach fills in: any rules or guidelines for the Team (see below).]
Who would like to start us off?
Depending on the age, maturity and size of the Team, you may want to set some guidelines to help promote a positive and productive discussion. Such as:
- Raised hands
- A "talking stick"
- You must continue the conversation, not just blurt out a random, unrelated thought
- We can only speak to our own experience, no one else's
Code of Awesomeness Focus Map ~60 minutes
Re-enforce a specific Code, put it into practice, and grow student metacognition skills through reflection!
Code of Awesomeness Focus
~5min
Code of Awesomeness Focus
Review all Codes of Awesomeness as a group and choose one to make into a theme for the day.
Tips & Tricks:
- Values discussed in one class should be reenforced in subsequent classes. That's the point of this Story Mode.
- If you know that the class needs to focus on a particular set of ideas, tell them that; and tell them why. Then lead a discussion about how that Code of Awesomeness will help them practice those ideas.
- If it doesn't matter which set of ideas the team focuses on today, let the group choose (or perhaps vote on) the Code of Awesomeness to focus on.
- Use the discussion questions below as a way to start this Story Mode.
- Who can tell me the three Codes of Awesomeness we selected as a class?
- Which one shall we focus on today and why?
Code Anatomy
~25min
Code Anatomy
Work as a team to label different parts of the code, then recall the code using only those terms.
Need:
- whiteboard and markers
- code & translation
How to Play:
Set Up: Write the entire code & translation on the board
- Team works together to remember/guess where the lang line is in the code, with the Coach's guidance
- Coach and Players label all parts of the code with terms like the ones below.
- Coach erases all code, leaving the labels
- Team works together to remember the code that belongs to each label, rebuilding the code as it was
- Repeat steps 4 and 5 until recall is easy
#lang ___________
= lang line#:_______________
= keyword(_______-game ...)
= game function call(basic-______ ...)
= entity function call(define (____) ...)
= function definition(_______________)
= function call"______________"
= string
[start-game-icon]
= game function call[first-sprite-icon]
= avatar- (name each list, what it creates)
- (match parens)
Tips & Tricks:
- End this game with Players typing up the code solo or in pairs, referencing the labels and translation.
- Add the timer (with a shorter time each round) for increased challenge.
- Coach can re-write the code every time, Players can take turns, or a Scribe may be designated within the Team.
- Set up can easily be delegated to a Player.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:the Code you chose to focus on.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
Disintegrating Code
~15min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Meta Story: Deep Reflection
~10min
Meta Story: Deep Reflection
A deeper dive into the subjects, challenges, and skill-building that happened in today's class.
Tips & Tricks:
- Start with a Think/Pair/Share model before a group conversation to get all students thinking and talking the topic, even if they don't all participate in the big dicussion.
- Ask follow up questions from the students to encourage deeper understanding. Can be as simple as "Why?"
- Other great questions: Who also felt that way? Who also faced that challenge? Who has advice for that?
- This is a deep reflection, so feel free to encourage students to raise their hands to respond to each other.
- Moderate to keep the conversation respectful and productive at all times.
We have a little extra time today to discuss today's class, specifically:
the Code you chose to focus on.
Before we get started as a big group, I would like you to turn to the person next to you and take turns sharing on this topic. I'll set the timer for 2 minutes for you to do that. Ready, set, go!
Students discuss for 2 minutes before Coach regains focus.
Now, as we dive deeper into our thoughts and experiences, it is important that we respect each other and have a productive conversation by:
[Coach fills in: any rules or guidelines for the Team (see below).]
Who would like to start us off?
Depending on the age, maturity and size of the Team, you may want to set some guidelines to help promote a positive and productive discussion. Such as:
- Raised hands
- A "talking stick"
- You must continue the conversation, not just blurt out a random, unrelated thought
- We can only speak to our own experience, no one else's
Partner Practice ~60 minutes
Prepare for the Final Jam by reviewing code and practicing pair programming.
Review
~5min
Review
Look back at what we've learned or done in previous classes.
Who can tell me anything they remember about:Final Jam.
Tips & Tricks:
- Guide the conversation with leading questions as needed.
- Add any follow up points that the students missed after their comments.
Pair Programming: Reverse Translation
~20min
Pair Programming: Reverse Translation
Reverse Translation: now with more TEAMWORK
Need:
- See Below
How to Play:
Play the game below, but use pair programming techniques. Partner up the Players and have them play as a team, replacing every mention of a single Player in the game below with that partnership:
Reverse Translation
Starting with just an implementation, the Team translates it back to a specification with as much detail as possible.
Need:
- code card
How to Play:
Break up larger Teams into smaller groups for this Game so that all members of the Team have a chance to see the code card and voice their opinions.
- Coach gives the Team a code card, implementation-side up
- Without flipping the card, Team translates the code into english, describing what the code will do when run
- Coach guides the Players to give as much detail as possible
Tips & Tricks:
- Optional final step: Team tests their hypothesis by typing up the code and running it.
- If a projector is available, project the code where everyone can see it.
- Add a competitive element by splitting the larger Team into two or more Teams, showing all Teams the same code (pass around the card, write on a whiteboard, project from computer), set the timer for discussion, and then have each team present their case. Whomever is most detailed in their translation gets a point.
- Enforce equal input within a Team by having Players raise hands and wait to be called on or take turns around a circle sharing details about the code.
Meta Story: Reflection
~10min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:coding with a partner: what's challenging? What's easier?
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
Pair Programming: Building Up
~20min
Pair Programming: Building Up
Building Up: now with more TEAMWORK
Need:
- See Below
How to Play:
Play the game below, but use pair programming techniques. Partner up the Players and have them play as a team, replacing every mention of a single Player in the game below with that partnership:
Building Up
Team works together to break a large translation task into the smallest possible steps, then follows the steps to code the game.
Need:
- computers - 1 per Player
- paper/whiteboard & writing utensils
- specification
How to Play:
- Coach shows Team the specification
- Team breaks down the specification into ordered steps, each step as small as possible while still resulting in working code (see example below)
- Each Player progresses through the steps, typing up code on a computer
Example Steps:
Specification: Code an adventure game with an NPC who has a quest to find their lost sword. Give the quest an ending cutscene including the NPC sprite and some text.- Code a basic adventure game
- Define an NPC
- Add NPC to game
- Give NPC a fetch quest for a sword
- Define a cutscene
- Add cutscene to game
- Add 1 page with text to cutscene
- Customize NPC sprite
- Add NPC sprite to cutscene
Tips & Tricks:
- The specification might need to remain visible through the entire process -- ex: written on the whiteboard or on the top of the paper.
- More beginner Players will likely need Coach's guidance breaking the specification down into the smallest steps possible.
- Add the requirement to RUN the code after every step to practice frequent testing
- Can be made into a competition if each Player "races" through the steps, testing after each one. Players can "sign off" next to each step as completed with initials/signature/unique symbol. First Player to the end of the list wins!
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
Final Jam Map ~60 minutes
Celebrate student progress by showcasing everything they have learned. Have an AWESOME last class!
Final Jam Rules & Resources
~10min
Final Jam Rules & Resources
Prepare to JAM OUT!
Mode Summary & Goals
Summary: Review how it works, inspire confidence, and pump up students for the Final Jam!
Goals and Gains:- Get students excited, make the day special!
- Prep as needed -- pair up, create team names, hand out bonus point cards...
- Briefly explain scoring
- Clarify: Coach is now a judge!
- Review class rules and Code of Awesomeness as needed
- Give advice: start small and test often!
- Pair up -- either assigned partners, random, or pick-your own
- Review good pair programming practices
- Coach is now the judge
- Games must RUN!
- Scored at end by:
- K-2nd: total number of code cards completed.
- 3rd and up: number of parens, keywords, and bonus point awarded by Judge throughout Jam.
- 3rd+: You get 3 code cards for inspiration, but only the specification/english side up!
- Resources for help:
- Flip a code card: pay 2 dollars of MetaMoney to see the implementation/code of a card
- Get Coach help: pay 5 dollars of MetaMoney to get Coach help with a bug.
- Add others here
- Meta-rule: Judge can change the rules at any time! (ex. price of resources)
- Excited! Can do it! Let's go!
When some of you walked in the door on your first day of class, you hadn't done any coding. But today, you're going to make an entire game on your own. Everyone give yourselves a round of applause!
When some of you walked in the door on your first day of class, you had never read a line of code. But because of your hard work and practice, you brain has literally grown since then.
When some of you walked in the door on your first day, you had never experienced a flow state while coding. Today, the main goal is to get into the zone and code for [Coach fills in: number of minutes].
We are going to be pair programming today, so let's take a moment to figure out our partners.
[Coach fills in: partnering process: assigned, random or pick-your-own.]
[Coach asks students: How do we code well with a partner?]
Example answers:
Your goal is to do as much coding as you can with as little help from me as possible. Today, I am not a coach. I'm a judge!
Rule number one as a judge is that I will only give points for running games. If your game has bugs in it and won't run, I can't give you any points. That means zero!
If your game does run, you will receive a score based on the number of parentheses and keywords in your running game. I will show you the exact formula later, but keep that in mind as you code.
You will also get bonus points! In a moment I'm going to pass out index cards where you will write your team name and where I will put stickers whenever you earn bonus points.
I'll be giving bonuses for activities that demonstrate excellent coding habits. For example, if I see people working together effectively as a team -- I might give bonuses for teamwork. If I see something really cool and creative -- I might give bonuses for that. If I hear someone exhibiting excellent sportsmanship, I might give bonuses for that.
If I hear someone complaining or being negative, I might take bonuses away!
Lastly, and this is the main rule: You're allowed to code any game you want -- using any tricks you might know. But I'm going to pass out three code cards to give you some ideas. So if you don't know what game to make, you should start with those.
You're not allowed to flip them and look at the code unless you ask. That will cost you two dollars of your MetaMoney. You're allowed to ask me for help, but that will cost you five dollars.
[Coach fills in: additional resources and prices]
That reminds me: There's one meta-rule that I want you all to remember. It goes like this: I'm the judge, so I get to change the rules at any time. I'll put up the prices of these two resources where you can see them, but at any time I may make them cost more, or less -- I am the judge and I get to decide! I may even add new ones, or take some away!
I am so exited to see what you all create. You have learned so much during this class and I know you can all do this!!
When some of you walked in the door on your first day of class, you had never read a line of code. But because of your hard work and practice, you brain has literally grown since then.
When some of you walked in the door on your first day, you had never experienced a flow state while coding. Today, the main goal is to get into the zone and code for [Coach fills in: number of minutes].
We are going to be pair programming today, so let's take a moment to figure out our partners.
[Coach fills in: partnering process: assigned, random or pick-your-own.]
[Coach asks students: How do we code well with a partner?]
Example answers:
- Change who's typing every 2 minutes when the timer buzzes
- Be supportive
- Pay attention, even when not typing
- Compromise
Your goal is to do as much coding as you can with as little help from me as possible. Today, I am not a coach. I'm a judge!
Rule number one as a judge is that I will only give points for running games. If your game has bugs in it and won't run, I can't give you any points. That means zero!
If your game does run, you will receive a score based on the number of parentheses and keywords in your running game. I will show you the exact formula later, but keep that in mind as you code.
You will also get bonus points! In a moment I'm going to pass out index cards where you will write your team name and where I will put stickers whenever you earn bonus points.
I'll be giving bonuses for activities that demonstrate excellent coding habits. For example, if I see people working together effectively as a team -- I might give bonuses for teamwork. If I see something really cool and creative -- I might give bonuses for that. If I hear someone exhibiting excellent sportsmanship, I might give bonuses for that.
If I hear someone complaining or being negative, I might take bonuses away!
Lastly, and this is the main rule: You're allowed to code any game you want -- using any tricks you might know. But I'm going to pass out three code cards to give you some ideas. So if you don't know what game to make, you should start with those.
You're not allowed to flip them and look at the code unless you ask. That will cost you two dollars of your MetaMoney. You're allowed to ask me for help, but that will cost you five dollars.
[Coach fills in: additional resources and prices]
That reminds me: There's one meta-rule that I want you all to remember. It goes like this: I'm the judge, so I get to change the rules at any time. I'll put up the prices of these two resources where you can see them, but at any time I may make them cost more, or less -- I am the judge and I get to decide! I may even add new ones, or take some away!
I am so exited to see what you all create. You have learned so much during this class and I know you can all do this!!
What is the overall goal of any Game Mode?
Get into a flow state while coding!
What's the main thing that makes Final Jam different from other Game Modes?
It lasts longer, and we code more! And it's on the last day of class.
When can you flip a code card?
When you ask and pay 2 dollars.
What other resource is available to you? For how much?
Ask Coach/Judge for help. Costs 5 dollars.
What's the meta-rule?
Coach/Judge can change rules at any time.
Tips & Tricks:
- Remember the goals of a Jam:
- This class is exciting and different than other classes.
- Students write code.
- Students feel accomplished and proudof what they did and have learned!
- Adjust rules, supports, and scoring as needed to achieve the goals above.
- Additional resources may include:
- An Asset Library -- a list of availble sprites/assets on a computer or written elsewhere
- A Definitions Library -- a list of available functions/definitions on a computer or written elsewhere
- A Code Guide -- an outline of common code structure, such as definitions. Shown to all on projector or available for checking in
- Don't get hung up on the details. Help students focus on the achievement: Writing a large amount of code over a large amount of time, largely without help.
Final Jam!
~25min
Final Jam!
It's the Final JAM-down!
Mode Summary & Goals
Summary: Players pair program to code in their learned language, practicing all the skills they have learned in this course.
Goals and Gains:- This feels like a different, special day
- Players write working code
- Players feel accomplished and proud of what they have done and learned
Need:
- computers - 1 per pair plus some spare
- code card deck
- index cards
- writing utencils
- stickers
How to Play:
- Players pair up, if not already partnered
- Judge hands out index cards
- Partners create their own Team Name; write it on the card
- Partners keep card nearby, to collect bonus point stickers/total point stickers
- Judge hands out three random code cards to each Pair code-side-down
- Judge reiterates: Players can not flip card without paying the cost in MetaMoney
- Judge reiterates: Players can use these cards to insprire their coding, not required
- Judge starts a timer, set for the length of the Jam
- Judge sets a second timer, for 3 minutes
- Judge gives each pair a small stack of code cards, code-side-down
- If using ratchet, make sure lang line matches the cards given
- Judge can swap out langs for new cards occasionally through the Jam
- Players begin, coding the first card!
- One partner types at a time
- When 3 min timer beeps, Partners swap "drivers"/typists
- Judge restarts 3 min timer each time
- Judge awards stickers for every code card completed
- Judge supervises and:
- Refreshes stacks of code cards, when running low
- Recieves MetaMoney for purchases of resources
- Adjusts prices for resources higher or lower to balance challenge level
- Adds new resources if needed
- Reminds players to swap drivers/typists
- Gives frequent time warnings
- Judge starts a timer, set for the length of the Jam
- Judge sets a second timer, for 3 minutes
- Players begin!
- One partner types at a time
- When 3 min timer beeps, Partners swap "drivers"/typists
- Judge restarts 3 min timer each time
- Judge supervises and:
- Awards bonus points
- Takes away bonus points, if needed
- Recieves MetaMoney for purchases of resources
- Adjusts prices for resources higher or lower to balance challenge level
- Adds new resources if needed
- Reminds players to swap drivers/typists
- Gives frequent time warnings
Tips & Tricks:
- Additional Resources to add may include:
- An Asset Library -- a list of availble sprites/assets on a computer or written elsewhere
- A Definitions Library -- a list of available functions/definitions on a computer or written elsewhere
- A Code Guide -- an outline of common code structure, such as definitions. Shown to all on projector or available for checking in
- All players should end with some running code. Assist as needed, within the given rules, even if you have to make it free to ask Coach assistance for the last 2 minutes.
- You should take a strong tone in the beginning regarding The Judge Will Not Help. But if students are struggling during the Game Jam, you can (of course) be helpful in giving hints.
- K-2nd: create extra challenges for students to complete beyond the code cards as well, if needed!
Final Jam Scoring & Awarding
~10min
Final Jam Scoring & Awarding
Players score their own creation using the following formula with the Coach's guidance.
Mode Summary & Goals
Summary: Players use a formula to score their own games, with Coach assistance. Coach awards MetaMoney!
Goals and Gains:- Focus on success, less on competition
- Players feel accomplished!
Need:
- 3rd and up: completed, running code
- K-2nd: total number of cards completed
- index card (same as bonus/team name cards)
- writing utencils
- MetaMoney
- OPTIONAL: whiteboard/projector for displaying formula
How to Play:
Standard Formula:
GAME-SCORE = (BONUSES * 5) + (NUMBER-OF-PARENTHESES + NUMBER-OF-KEYWORDS)
You are welcome to adjust this formula as needed (especially the Bonus * 5 for groups where you want to limit multiplication). However, it is suggested to adjust the point:dollar ratio instead.
- If possible: Coach displays entire formula and explains it
- Coach guides Players through steps one at a time:
- Count total parens, write number down
- Count total keywords, write number down
- Add parens and keywords together
- Count total bonuses, write number down
- Multiply bonuses by 5
- Add bonus total and paren/keyword total
- Coach decides point:dollar ratio based on point range (see below)
- Coach briefly proofs point total, awards MetaMoney to each pair
Standard Formula:
GAME-SCORE = TOTAL-CARDS-COMPLETED
- Coach helps Players count up total stickers
- Coach decides point:dollar ratio based on point range (see below)
- Coach briefly proofs point total, awards MetaMoney to each pair
Players should earn roughly between 15 and 25 dollars of MetaMoney EACH during the Jam. Too little, and it feels disappointing. Too much, and you have just made Market a very difficult time for yourself!Adjust how much MetaMoney students receive by customizing the point:dollar ratio:
- Take a look at Players' point totals to get an approximate average
- Do some vague mental algebra: POINT-AVERAGE / ?? = ~20
- Announce the point:dollar ratio to Players
- Pair A has 55 points. Pair B has 43 points. Pair C has 68 points.
- Approx average: 55
- 55 / 3 = ~18
- Ratio is 3 points:1 dollar, always rounding up.
- Pair A gets $19 each. Pair B gets $15 each . Pair C gets $23 each.
- Pair A has 130 points. Pair B has 97 points. Pair C has 80 points. Pair D has 150 points.
- Approx average: 125
- 125 / 6 = ~20
- Pair A gets $22 each. Pair B gets $17 each. Pair C gets $14 each. Pair D gets $25 each.
- Low point outlier:
- Pair A has 70. Pair B has 96. But Pair C only has 30.
- You choose to average at 80
- 80 / 4 = 20
- Pair A gets $18 each. Pair B gets $24 each.
- Pair C gets $8 each; but when you see they are disappointed, you quietly award them an extra $5 each for the excellent debugging you saw them do.
- High point outlier:
- Pair A has 25 points. Pair B has 36 points. But Pair C has 89 points.
- You choose to average at 30
- 30 / 2 = 15
- Pair A gets $13 each. Pair B has $18 each.
- For Pair C, you decide there is a $25 max, tell the Pair, and give each $25.
- Be sure to consider the amount of money Players SPEND during the jam as well, when calculating your ratio.
- You can also decide if pairs each get the total MetaMoney, or they split it. Either way, they should still end up with roughly $15-25.
- If you have a pair or two with a significantly lower total and you felt their performance was still worth more than the dollars they would earn (they were doing well, just typing slower, had more bugs, just not as skilled yet as the rest of the group), you can either try to see it coming and balance with extra bonus points during Jam, or post-Jam give them extra bonus dollars for great debugging/great teamwork/etc. Note that if a pair was misbehaving or otherwise not earning points through their chosen behavior, it is okay if they earn less!
- If you have a pair with a significantly higher total that will bankrupt the Market you can instate a dollar max -- no matter how many points you earn over __ you still just get the max dollars.
Tips & Tricks:
- Mind the urge to compare points -- in many groups this is fun, but some groups may not be able to handle this competitive comparison and you will have bring attention back to everyone's individual success!
Market
~10min
Market
A chance to spend that MetaMoney and get cool prizes!
Need:
- A Market
- Market Cards
- MetaMoney (for change)
How to Play:
Set Up: Lay out Market Cards and put actual Market Stuff out of reach of Players
- Coach sets Market rules (see Suggestions below)
- Players visit Market in small groups
- One at a time, Players choose from Market Cards any purchases they wish to make
- Coach retrieves the purchase and exchanges for Player's MetaMoney
- Once a Player has finished at Market, they go back to their seat or to other set spot (ex. rug for Meta Story)
- Wait to be called over or released to come to Market.
- You must clean up your area/close your files/wrap up your mouse/etc before you are called over to Market.
- Only unfolded MetaMoney accepted at the Market
- Wait in line until your turn
- Market prizes must remain unopened until after class
Tips & Tricks:
- Market is a privilege, not a right (to quote everyone's parent) -- feel free to cancel Market if Players cannot follow Market Rules or other expectations of the day.
- Add any rules you need to keep the experience a positive, sane one for everyone (epecially you!)
- Note that time greatly depends on number of students, so plan accordingly.
- Think of Market like an arcade's ticket-shop -- all the merch is behind the glass and you only get it after you pay!
Meta Story: Badges
~5min
Meta Story: Badges
The Badge Ceremony!
Tips & Tricks:
- The exact ceremony outlined below is an example, you may create a unique ceremony as long as it connects the badge with what it means: the Student's growing knowledge and experience as a coder and learner.
- Whenever possible share the celebration with the parents: reminding students to share the certificate with their parents and proudly telling any parents of badger-earners that you interact with.
- Strive to make the badge ceremony a time to reflect on the personal growth that everyone has experienced. It's not about the badge; it's about what the badge represents. Only you -- the coach -- can help nurture this attitude.
- Coach describes the Badge Ceremony:
- When student name called, come up
- Student tells Coach X things they have learned
- Student receives Badge Certificate, takes a seat
- Coach goes through the Ceremony for each student who has earned the badge
- Team applauds for all students at the end
- If needed, Coach reminds other students how many more attendances until their next badge
It's time for the badge ceremony! When I call your name, I want you to come to the front. I'm going to ask to name three things you have learned over your time here so far -- and the things you have learned must be related to making you a better coder and/or a better learner. If you can give me an answer, I'll give you this badge certificate and you will recieve a physical badge through the mail!
First up is, [Coach fills in: name of badge-earning student from roster]!
First up is, [Coach fills in: name of badge-earning student from roster]!
Intro to Inputs/Outputs ~40 minutes
An unplugged/plugged classmap introducing the basics of inputs/outputs.
Coach Story
~5min
Coach Story
A chance to introduce yourself and some values of MetaCoders.
[Coach fills in: Your coach story][Coach fills in: Any discussion questions you wish to ask about your story]
Person-Bot (or Code the Coach/Kid)
~10min
Person-Bot (or Code the Coach/Kid)
Team works together to 'code' a Bot (the Coach or a Player) to achieve a Goal.
Need:
- no required supplies
How to Play:
- Coach sets the Goal (see Example Goals below)
- Coach picks a Bot -- often the Coach themselves for the first round
- Coach picks 1-3 Bot Coders
- Bot Coders work as a team to give clear, exact instructions to Bot to achieve the Goal
- Bot follows the instructions EXACTLY (see Example Instructions below)
- Follow up with additional rounds with new Bots and new Bot Coders
Example Goals:
- Get from Point A to B (ideal with some obstacles in the way!)
- Move the book from the table to the shelf
- Draw a smiley face on the white board
- Put on your sweatshirt
Example Clear, Executable Instructions:
- Take 3 steps forward
- Turn 1 quarter turn to your left
- Grab the sweatshirt with your right hand
Example UNCLEAR, Inexecutable Instructions:
- Turn around (Bot does a 360 spin, ends up exactly where they were)
- Go backwards (Bot walks backwards -- and keeps going!)
- Go to the shelf (Bot makes error sound or shrugs -- what is 'the shelf?')
- Put the sweatshirt over your head (Bot holds the sweatshirt up in the air, over their head)
Tips & Tricks:
- Players as Bots may need help following directions EXACTLY and not making assumptions or going out of their way to wrongly interpret a clear instruction!
- Variation: Have the Bot leave the room when the Goal is being determined, so they don't know the Goal.
- Variation: Have all Players be the Bot Coders. All must agree on an instruction and a Master Coder relays that to the Bot.
- Variation: Team works together to write down all their instructions at once, before the Bot reads and executes all the instructions in a row. Great for predictive thinking!
- Variation: Include a Bot error sound/response that the Bot uses when given an unclear instruction.
Thinking about Inputs and Outputs
~10min
Thinking about Inputs and Outputs
Learn about inputs and outputs on a computer, then map them on to a human!
Outline- Computers have inputs -- how they receive information -- and outputs -- how they give information.
- With the help of students, list computers INPUTS:
- keyboard
- mouse/trackpad
- camera
- microphone
- USB port
- ...
- With the help of students, list computer OUTPUTS:
- screen
- speakers
- USB port
- ...
- What about HUMANS? What are our inputs -- ways to recieve information -- and outputs -- ways to give information?
- With the help of students, list human INPUTS (the 5 senses):
- eyes
- ears
- nose
- mouth
- skin
- With the help of students, list human OUTPUTS:
- voice
- fingers (pointing)
- hands (sign language)
- whole body (body language, dance)
- face (expression)
- writing
- drawing
- ...
What Does This Do?
~10min
What Does This Do?
Players type up and run code, before explaining the result in detail.
Need:
- computers - 1 per Player
- code
- whiteboard/projector or alternative way to show Team the code
- timer
How to Play:
- Coach writes up/displays code
- Coach does NOT say what the code does
- Coach sets timer for 1-5 minutes
- Players type up the code and run it
- When timer goes off, Coach asks Players to share what they observed about the code
Tips & Tricks:
- Keep the experimentation phase "top secret" -- have Players be secretive about what they find until the timer goes off and you all share! This keeps faster Players from spoiling the game for slower typists.
- Varitation: Players discuss their hypotheses for what the code will do prior to trying it.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
Intro to Bugs ~40 minutes
A unplugged/plugged classmap introducing the basics of bugs.
Review
~5min
Review
What did we do last time?
Person-Bot (or Code the Coach/Kid)
~10min
Person-Bot (or Code the Coach/Kid)
Team works together to 'code' a Bot (the Coach or a Player) to achieve a Goal.
Tips & Tricks:
- Give bots an error code -- specific phrase or motion when they have a bug
- Increase difficulty -- (reccomended for younger groups) use 1 Player as the bot instead of the Coach/all Players, add a language restriction, etc.
- Change the goal -- draw a house, put on a sweatshirt, complete a math problem, fold a paper airplane, etc.
- Have the Bot Coders write all the instructions down at once before Bot begins to execute -- (reccomended for older groups) this can be done with multiple teams, and with multiple testing cycles.
How to Play:
Person-Bot (or Code the Coach/Kid)
Team works together to 'code' a Bot (the Coach or a Player) to achieve a Goal.
Need:
- no required supplies
How to Play:
- Coach sets the Goal (see Example Goals below)
- Coach picks a Bot -- often the Coach themselves for the first round
- Coach picks 1-3 Bot Coders
- Bot Coders work as a team to give clear, exact instructions to Bot to achieve the Goal
- Bot follows the instructions EXACTLY (see Example Instructions below)
- Follow up with additional rounds with new Bots and new Bot Coders
Example Goals:
- Get from Point A to B (ideal with some obstacles in the way!)
- Move the book from the table to the shelf
- Draw a smiley face on the white board
- Put on your sweatshirt
Example Clear, Executable Instructions:
- Take 3 steps forward
- Turn 1 quarter turn to your left
- Grab the sweatshirt with your right hand
Example UNCLEAR, Inexecutable Instructions:
- Turn around (Bot does a 360 spin, ends up exactly where they were)
- Go backwards (Bot walks backwards -- and keeps going!)
- Go to the shelf (Bot makes error sound or shrugs -- what is 'the shelf?')
- Put the sweatshirt over your head (Bot holds the sweatshirt up in the air, over their head)
Tips & Tricks:
- Players as Bots may need help following directions EXACTLY and not making assumptions or going out of their way to wrongly interpret a clear instruction!
- Variation: Have the Bot leave the room when the Goal is being determined, so they don't know the Goal.
- Variation: Have all Players be the Bot Coders. All must agree on an instruction and a Master Coder relays that to the Bot.
- Variation: Team works together to write down all their instructions at once, before the Bot reads and executes all the instructions in a row. Great for predictive thinking!
- Variation: Include a Bot error sound/response that the Bot uses when given an unclear instruction.
Debugging the Pizza
~10min
Debugging the Pizza
Mia uses a debugging process to figure out why the pizza suddenly tastes like soap.
Mode Summary & Goals
Summary: Learn about the debugging process in a non-computer frame -- pizza!
Goals and Gains:- Define bug, debug
- Investigate the subtle difference between problem-solving and debugging (debugging often involves FINDING the problem!)
- Practice our own debugging skills
- Get comfortable with the idea of bugs and debugging as part of the coding process
Tips & Tricks:
- For a shorter story, take out some of the hypotheses/tests.
- Use the name of a student in the room instead of Mia.
- Ask students to create their own hypotheses -- even tests (you give the result).
- Don't forget to engage with questions -- at the end and throughout!
- Mia's excited -- tonight her dad is ordering pizza for dinner.
- But when she takes her first bite, it tastes like SOAP!
- Mia's brother tries it -- he thinks it's fine...
- Mia needs to figure out what is going on/debug her pizza.
- Debugging attempt #1 --
- Hypothesis: Mia's brother is tricking her.
- Test: Ask him (he's a very bad liar, she can always tell).
- Result? He isn't tricking her.
- Debugging attempt #2 --
- Hypothesis: Mia's brother doesn't know better (he eats wierd stuff...)
- Test: Mia's dad tries it.
- Result? He thinks it's delicious.
- Debugging attempt #3 --
- Hypothesis: Mia's tastebuds are wrong.
- Test: Mia tries other foods.
- Result? Everything tastes normal...
- Debugging attempt #4 --
- Hypothesis: It's not all of the pizza, just one part.
- Test: Mia tries each part of the pizza.
- Result? It's the sauce! Specifically, green specks in the sauce...
- Mia asks her dad what the green specks are.
- It's cilantro! Some people, like Mia's mom, taste soap in cilantro -- it's genetic!
- Mia's dad promises never to get pizza with cilantro again.
Wednesday is Mia's favorite day -- because it's pizza night. Every Wednesday, instead of cooking, Mia's dad orders a different kind of pizza. It's not that Mia doesn't like her dad's cooking. It's just that pizza is her favorite food and always will be, forever. Cheese, pepperoni, vegetable, meatball -- the kind of pizza didn't matter. They were all her favorites.
Her mouth has been watering all day. When the doorbell rings, she calls, "Dad! The pizza is here." He takes forever to come downstairs. It feels like it takes years for him to pay the pizza delivery man, and another few years before he finally places the giant pizza box on the kitchen table and announces:
"Dinner is served."
Mia snatches up a slice and takes it to her room to eat it while she plays video games with her twin brother. She has a video game controller in one hand and a slice of pizza in the other. So does her brother.
"Ready to lose?" says her brother, starting a racing game with his free hand and taking a bite with the other.
"I never lose," she replies as she takes her first big bite of pizza.
She chews as the race begins. At first, her car surges ahead -- but suddenly she freezes, no longer chewing. The taste in her mouth is terrible! It's as if someone covered the whole pizza in soap. She drops her video game conroller.
"Shomthong's wong with my pizza!" she mumbles with her mouth full.
Dropping the video game controller on the floor, she runs to the bathroom, hearing her brother call after her:
"You're just mad because you know I'm going to win!"
Mia spits out the bite of pizza and examines the slice carefully under the bathroom light. It looks normal. She sniffs it. It smells normal. She takes a smaller bite this time.
Sure enough, though, as she begins to chew, it tastes like her mouth is full of soap. She has to spit the bite into the trash.
She marches back into her room and switches off the video game.
"Hey!" her brother says. He's almost done with his own slice of pizza by now.
"Taste this," she demands, giving him her slice. "There's something wrong with my slice."
Cautiously, he tastes takes it, sniffs it, and bites into it.
"It tastes fine to me," he says. "I'll eat it if you don't want it." [Need another beat...]
What's happening? she wonders. I must debug my pizza...
Her mouth has been watering all day. When the doorbell rings, she calls, "Dad! The pizza is here." He takes forever to come downstairs. It feels like it takes years for him to pay the pizza delivery man, and another few years before he finally places the giant pizza box on the kitchen table and announces:
"Dinner is served."
Mia snatches up a slice and takes it to her room to eat it while she plays video games with her twin brother. She has a video game controller in one hand and a slice of pizza in the other. So does her brother.
"Ready to lose?" says her brother, starting a racing game with his free hand and taking a bite with the other.
"I never lose," she replies as she takes her first big bite of pizza.
She chews as the race begins. At first, her car surges ahead -- but suddenly she freezes, no longer chewing. The taste in her mouth is terrible! It's as if someone covered the whole pizza in soap. She drops her video game conroller.
"Shomthong's wong with my pizza!" she mumbles with her mouth full.
Dropping the video game controller on the floor, she runs to the bathroom, hearing her brother call after her:
"You're just mad because you know I'm going to win!"
Mia spits out the bite of pizza and examines the slice carefully under the bathroom light. It looks normal. She sniffs it. It smells normal. She takes a smaller bite this time.
Sure enough, though, as she begins to chew, it tastes like her mouth is full of soap. She has to spit the bite into the trash.
She marches back into her room and switches off the video game.
"Hey!" her brother says. He's almost done with his own slice of pizza by now.
"Taste this," she demands, giving him her slice. "There's something wrong with my slice."
Cautiously, he tastes takes it, sniffs it, and bites into it.
"It tastes fine to me," he says. "I'll eat it if you don't want it." [Need another beat...]
What's happening? she wonders. I must debug my pizza...
First Debugging Attempt
Mia_'s first thought is that her brother is playing a trick on her. "Is this another one of your pranks?" she demands.
His eyes go wide. "Me prank you? You're the one who always pranks me!"
"Yeah, that's true," she says.
"Do you want me to pinky swear?" he asks, holding out his pinky.
"That won't be necessary," she says. She can always tell when he's lying because he blushes when he does. He was definitely telling the truth though.
Hmmm, she wonders, Why would the pizza taste like soap to me but not to him?
Another Debugging Attempt
It occurs to Mia that although her brother might not be lying, he might simply be wrong and not know it. Maybe he just doesn't realize that the pizza tastes bad. One time, he spent an entire week eating nothing but pickles. Another time, he drank an entire bottle of ketchup on a dare.
"I'll be back," she says, taking her pizza with her and marching to her dad's room. As usual, he's doing work at his desk. "Dad," she says, "I need you to try this pizza."
"Mia, you know I'm on a diet," he says.
"Dad! Please!" she begs. "There's something wrong with it. It tastes all weird."
Sighing, he takes the pizza, sniffs it, and takes a tiny bite. Mia holds her breath as she waits -- expecting him to spit it out.
Slowly, he swallows, sniffs the pizza again, and takes another bite.
"Dad!" she cries. "What are you doing?"
"It tastes great," he says, turing back to his comptuer. "If you don't want it, just give it to your brother."
Stunned, she leaves the room, taking the mysterious pizza with her.
Yet Another Debugging Attempt
Her brother might not be able to taste the difference between soap and pizza, but her dad was practically a professional chef. He could taste food and tell you all of its ingredients without even seeing the recipe.
There was only one conclusion she could draw. The bug must not be in the pizza. It must be in her!
Panicked, she ran to the kitchen. She put the slice of pizza on the table and yanked the refrigerator door open. She pulled out a jar of pickles, some leftover cake from her dad's birthday, and some leftover meatballs from yesterday's dinner.
One by one, she tasted each of them. The bite of pickles tasted like pickles. The bite of cake tasted like cake. And the meatballs tasted like meatballs.
Maybe I'm cured, she thought. But when she tasted the pizza again... it tasted like soap. She had to spit it into the trashcan yet again.
Mia_'s first thought is that her brother is playing a trick on her. "Is this another one of your pranks?" she demands.
His eyes go wide. "Me prank you? You're the one who always pranks me!"
"Yeah, that's true," she says.
"Do you want me to pinky swear?" he asks, holding out his pinky.
"That won't be necessary," she says. She can always tell when he's lying because he blushes when he does. He was definitely telling the truth though.
Hmmm, she wonders, Why would the pizza taste like soap to me but not to him?
- What was the hypothesis?
- What does ___ do to test it?
- What reasonable hypotheses might ___ form now?
Another Debugging Attempt
It occurs to Mia that although her brother might not be lying, he might simply be wrong and not know it. Maybe he just doesn't realize that the pizza tastes bad. One time, he spent an entire week eating nothing but pickles. Another time, he drank an entire bottle of ketchup on a dare.
"I'll be back," she says, taking her pizza with her and marching to her dad's room. As usual, he's doing work at his desk. "Dad," she says, "I need you to try this pizza."
"Mia, you know I'm on a diet," he says.
"Dad! Please!" she begs. "There's something wrong with it. It tastes all weird."
Sighing, he takes the pizza, sniffs it, and takes a tiny bite. Mia holds her breath as she waits -- expecting him to spit it out.
Slowly, he swallows, sniffs the pizza again, and takes another bite.
"Dad!" she cries. "What are you doing?"
"It tastes great," he says, turing back to his comptuer. "If you don't want it, just give it to your brother."
Stunned, she leaves the room, taking the mysterious pizza with her.
- What was the hypothesis?
- What does ___ do to test it?
- What reasonable hypotheses might ___ form now?
Yet Another Debugging Attempt
Her brother might not be able to taste the difference between soap and pizza, but her dad was practically a professional chef. He could taste food and tell you all of its ingredients without even seeing the recipe.
There was only one conclusion she could draw. The bug must not be in the pizza. It must be in her!
Panicked, she ran to the kitchen. She put the slice of pizza on the table and yanked the refrigerator door open. She pulled out a jar of pickles, some leftover cake from her dad's birthday, and some leftover meatballs from yesterday's dinner.
One by one, she tasted each of them. The bite of pickles tasted like pickles. The bite of cake tasted like cake. And the meatballs tasted like meatballs.
Maybe I'm cured, she thought. But when she tasted the pizza again... it tasted like soap. She had to spit it into the trashcan yet again.
- What was the hypothesis?
- What does ___ do to test it?
- What reasonable hypotheses might ___ form now?
Final Debugging Attempt
This is my favorite food of all time, thinks Mia_. There is no way I'm going to bed tonight without solving this mystery.
Suddenly, it occurs to her that maybe it's not the whole pizza that tastes like soap -- but only part of it. She puts the pizza on a plate and gets a knife from the drawer. She cuts off a bit of the crust, a scrap of cheese, and a single pepperoni.
She puts the crust in her mouth and begins to chew, waiting for the soap taste. But the crust tastes like crust.
She puts the pepperoni in her mouth and begins to chew, waiting for the soap taste. But the pepperoni tastes like pepperoni.
She puts the scrap of cheese in her mouth and begins to chew, waiting for the soap taste. But the cheese tastes like cheese -- or almost like it. The taste of soap is faint, but it's there.
With the fork, she takes all of the cheese off of the pizza, revealing the tomato sauce beneath. She scoops up a bit of the sauce and puts it in her mouth. The moment she does, she gags on the soap taste and must spit the sauce into the sink.
She looks very closely at the pizza and notices that there are little specks of green inside the red sauce. They smell just fine, but she knows better than to put them in her mouth again. Gross.
She takes the cheeseless pizza upstairs to her dad's room again and says, "Dad, I figured it out. It's the sauce."
"What's the sauce?"
"That's where the soap is. What are these green things?"
Her dad takes the pizza and holds it under his desk lamp, looking very closely. "It's cilantro."
"What kind of soap is that?" she asks. "And why did they put it on the pizza?"
"It's not soap," says her father, chuckling. "It's a kind of spice. It can taste like soap to some people, though. It's genetic. Your mom can't stand the stuff either. You can ask her about it when she gets home."
"What is genetic?" Mia she says.
"Inside everyone's body is something called a genetic code," he says. "It's like a code that says what color hair you'll have, what color eyes, whether you'll be tall or short, and whether or not cilantro tastes like soap or not."
"Does that mean there's a bug in my code?" she says.
Her father laughs. "You could call it a bug, or you could call it a super power. Basically, your tongue is able to detect a chemical in the cilantro that most people can't taste. It's always there -- but people like me and your brother."
"I'll consider it a super power," she says. "But can we never get pizza with cilantro again? Please!"
Her father nods. "I promise."
This is my favorite food of all time, thinks Mia_. There is no way I'm going to bed tonight without solving this mystery.
Suddenly, it occurs to her that maybe it's not the whole pizza that tastes like soap -- but only part of it. She puts the pizza on a plate and gets a knife from the drawer. She cuts off a bit of the crust, a scrap of cheese, and a single pepperoni.
She puts the crust in her mouth and begins to chew, waiting for the soap taste. But the crust tastes like crust.
She puts the pepperoni in her mouth and begins to chew, waiting for the soap taste. But the pepperoni tastes like pepperoni.
She puts the scrap of cheese in her mouth and begins to chew, waiting for the soap taste. But the cheese tastes like cheese -- or almost like it. The taste of soap is faint, but it's there.
With the fork, she takes all of the cheese off of the pizza, revealing the tomato sauce beneath. She scoops up a bit of the sauce and puts it in her mouth. The moment she does, she gags on the soap taste and must spit the sauce into the sink.
She looks very closely at the pizza and notices that there are little specks of green inside the red sauce. They smell just fine, but she knows better than to put them in her mouth again. Gross.
She takes the cheeseless pizza upstairs to her dad's room again and says, "Dad, I figured it out. It's the sauce."
"What's the sauce?"
"That's where the soap is. What are these green things?"
Her dad takes the pizza and holds it under his desk lamp, looking very closely. "It's cilantro."
"What kind of soap is that?" she asks. "And why did they put it on the pizza?"
"It's not soap," says her father, chuckling. "It's a kind of spice. It can taste like soap to some people, though. It's genetic. Your mom can't stand the stuff either. You can ask her about it when she gets home."
"What is genetic?" Mia she says.
"Inside everyone's body is something called a genetic code," he says. "It's like a code that says what color hair you'll have, what color eyes, whether you'll be tall or short, and whether or not cilantro tastes like soap or not."
"Does that mean there's a bug in my code?" she says.
Her father laughs. "You could call it a bug, or you could call it a super power. Basically, your tongue is able to detect a chemical in the cilantro that most people can't taste. It's always there -- but people like me and your brother."
"I'll consider it a super power," she says. "But can we never get pizza with cilantro again? Please!"
Her father nods. "I promise."
- What is a "bug" in coding?
- What does it mean to "debug"?
How are debugging and problem-solving the same? How are they different?
Debugging often involves similar skills, but a big part of debugging is finding the cuase of the problem, which isn't always included in problem-solving.
- When is a time you debugged something? On the computer? Off the computer?
- What skills do you need to be the best debugger?
Disintegrating Code
~10min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
Intro to Thinking Code ~40 minutes
A unplugged/plugged classmap introducing the basics of learning how to code.
Review
~5min
Review
What did we do last time?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
You will play this game again in the More on Inputs and Outputs map, so keep that in mind when how much time you spend on each level.
How to Play:
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
A Path in Your Brain
~10min
A Path in Your Brain
A metaphor for learning in your brain. Or: why it takes so darn long to learn something new.
Tips & Tricks:
- Choose a volunteer: use this person's name instead of Joe. Use something that they are trying to learn instead of German (piano, algebra, soccer, CODING). You can even bring them up to sit next to you and keep pointing at their brain to keep reminding the audience that this is happening inside a brain.
- You can illustrate this story as you tell it -- drawing the cottage, clearing and paths on a whiteboard, widening the lines or erasing them as fits the story.
- Don't forget to ask questions: at the end and throughout!
- Joe is someone much like you (the audience). But he is just starting German class.
- Let's look inside Joe's brain while he does his German homework.
- Imagine his brain is a forest, and there's a Tiny Joe trying to make a new trail through it.
- It's difficult for Tiny Joe to get through the forest.
- Just like it's difficult for Real Joe to do the homework.
- Over time, as Real Joe learns more German, Tiny Joe clears a wider, better trail.
- After being sick and not practicing for a time, Real Joe has a hard time doing what had been easy before.
- The trail in Joe's brain had become a bit overgrown.
- With practice, the skill returned, and the trail cleared.
- Over many years of German classes and practice, Tiny Joe's trail in Real Joe's brain is made into a long, clear, easy-to-travel path and Real Joe can use German fluently.
We are going to going into someone's brain -- any volunteers? Where did I put my scapel... I'm kidding! No, we aren't really going into someone's brain, but we are going to imagine that we are. We are going to use a metaphor to understand what goes on in your brain -- and yours, and yours, and mine, and your uncle's, and your grandma's brain -- what goes on in everyone's brain when they are learning.
The brain we are going to take our journey into today belongs to Joe. Joe is about your age. He is just starting to learn how to speak German. Let's hop into his brain while he is struggling through some German homework after his very first German class.
Let's imagine the inside of Joe's brain as a giant forest. Here's is a little cottage in a clearing, and on the edges of the clearing we can see lots of little trails going out into the forest. Some of these trailheads are clearly marked, with a wide entrance, big signs and arrows. Others are almost invisible they are so small. There is even one or two places where it looks like there used to be a trail but the forest has grown over it, covering the entrance.
Coming out of the cottage -- look it's Joe! It's a tiny Joe, inside the real Joe's brain-forest. He has his adventuring backpack with him, complete with flashlight, machete and snacks. Tiny Joe is heading to the forest.
But Tiny Joe doesn't take one of the clearly marked paths. He doesn't take any of the smaller paths either. Tiny Joe walks straight to the edge of the forest and starts pushing his way through.
It's very slow-going; this forest is very thick. Tiny Joe has to kick big stones, slice through heavy vines, stomp through thick bushes, even push some very large boulders out of his way. At one point, Tiny Joe comes to a river and creates a small, haphazard bridge out of a fallen log.
After struggling through his German homework for 30 minutes (remember, that's what real Joe is actually doing), Joe is done with his vocabulary review. He's tired and glad to be done!
Let's fast-forward a bit. Joe keeps going to his German classes, keeps doing his German vocabulary homework. And Tiny Joe keeps traipsing down that path in his brain-forest.
Everytime Tiny Joe journey's down that same trail, it gets easier. There are fewer rocks and bushes in his way. He has built on that bridge across the river so that it's much safe and easier to cross. He has made the path wider and flatter by walking down it so many times.
Real Joe is finding it easier and easier to remember the German vocabulary and grammar. Now he doesn't have to stare at his textbook the whole class -- he can even have a whole (short) conversation in German without needing his notes once!
One day, when Joe gets the flu, he misses two whole weeks of German class. He doesn't pick up his German textbook once in those two weeks. When he comes back to class, and Tiny Joe goes traipsing down that trail again, he struggles a bit! Real Joe is frustrated; he could have this conversation easily two weeks ago!
But in those two weeks, when Joe didn't think about German once, the trail in his brain-forest started to grow over with little bushes and vines. A few of those stones cam tumbling back. A rainstorm roughed up the nicely trampled dirt. It was harder for Tiny Joe to walk that path; and harder for Real Joe to remember his German!
After a little extra practice, Tiny Joe had that trail cleared nicely again and continued his progress of widening it and making it better. Tiny Joe added some nice clear signs showing the way, built up that bridge, and made the trail twice as long as it was before. The next time Real Joe takes two weeks of vacation from his German class, he shows off his German to his grandparents and spent some time reviewing his vocabularly list. He has hardly any trouble coming back to class after the break, this time!
Several years of German classes later, Joe is quite fluent in the language. He can have long conversations in German with his classmates and with his cousins who live in Germany and speak German every day. Joe can read some German books, write essays in German -- he even dreams in German sometimes!
The trail in Joe's brain is wide, welcoming and inviting. It's so easy to travel that Tiny Joe can run down it with his eyes closed! It's hard to remember that there was ever a time that the trail didn't exist at all.
The brain we are going to take our journey into today belongs to Joe. Joe is about your age. He is just starting to learn how to speak German. Let's hop into his brain while he is struggling through some German homework after his very first German class.
Let's imagine the inside of Joe's brain as a giant forest. Here's is a little cottage in a clearing, and on the edges of the clearing we can see lots of little trails going out into the forest. Some of these trailheads are clearly marked, with a wide entrance, big signs and arrows. Others are almost invisible they are so small. There is even one or two places where it looks like there used to be a trail but the forest has grown over it, covering the entrance.
Coming out of the cottage -- look it's Joe! It's a tiny Joe, inside the real Joe's brain-forest. He has his adventuring backpack with him, complete with flashlight, machete and snacks. Tiny Joe is heading to the forest.
But Tiny Joe doesn't take one of the clearly marked paths. He doesn't take any of the smaller paths either. Tiny Joe walks straight to the edge of the forest and starts pushing his way through.
It's very slow-going; this forest is very thick. Tiny Joe has to kick big stones, slice through heavy vines, stomp through thick bushes, even push some very large boulders out of his way. At one point, Tiny Joe comes to a river and creates a small, haphazard bridge out of a fallen log.
After struggling through his German homework for 30 minutes (remember, that's what real Joe is actually doing), Joe is done with his vocabulary review. He's tired and glad to be done!
Let's fast-forward a bit. Joe keeps going to his German classes, keeps doing his German vocabulary homework. And Tiny Joe keeps traipsing down that path in his brain-forest.
Everytime Tiny Joe journey's down that same trail, it gets easier. There are fewer rocks and bushes in his way. He has built on that bridge across the river so that it's much safe and easier to cross. He has made the path wider and flatter by walking down it so many times.
Real Joe is finding it easier and easier to remember the German vocabulary and grammar. Now he doesn't have to stare at his textbook the whole class -- he can even have a whole (short) conversation in German without needing his notes once!
One day, when Joe gets the flu, he misses two whole weeks of German class. He doesn't pick up his German textbook once in those two weeks. When he comes back to class, and Tiny Joe goes traipsing down that trail again, he struggles a bit! Real Joe is frustrated; he could have this conversation easily two weeks ago!
But in those two weeks, when Joe didn't think about German once, the trail in his brain-forest started to grow over with little bushes and vines. A few of those stones cam tumbling back. A rainstorm roughed up the nicely trampled dirt. It was harder for Tiny Joe to walk that path; and harder for Real Joe to remember his German!
After a little extra practice, Tiny Joe had that trail cleared nicely again and continued his progress of widening it and making it better. Tiny Joe added some nice clear signs showing the way, built up that bridge, and made the trail twice as long as it was before. The next time Real Joe takes two weeks of vacation from his German class, he shows off his German to his grandparents and spent some time reviewing his vocabularly list. He has hardly any trouble coming back to class after the break, this time!
Several years of German classes later, Joe is quite fluent in the language. He can have long conversations in German with his classmates and with his cousins who live in Germany and speak German every day. Joe can read some German books, write essays in German -- he even dreams in German sometimes!
The trail in Joe's brain is wide, welcoming and inviting. It's so easy to travel that Tiny Joe can run down it with his eyes closed! It's hard to remember that there was ever a time that the trail didn't exist at all.
- What made the trail in Joe's brain-forest easier to travel?
- When did the trail more difficult again?
What real thing in your brain does the forest trail in this story represent?
A neural pathway -- connections between neurons in the brain
What real thing in your brain does "Tiny Joe" represent?
Electricity and neurotransmitters -- communications between neurons
- When was a time that it felt very difficult or frustrating to learn something new?
- What can we learn from this story that we can use in this class?
- How can knowing what happens in our brain as we learn help us learn better?
Disintegrating Code
~10min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
More On Inputs and Outputs ~40 minutes
A unplugged/plugged classmap on inputs/outputs.
Review
~5min
Review
What do you remember about Inputs and Outputs?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Review the levels you got to last time you played this game or just jump right into the next level
How to Play:
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
A System-atic World
~10min
A System-atic World
Learning about systems and thinking about everyday things as systems.
Mode Summary & Goals
Summary: Get the students to think creatively about systems by viewing everyday things as systems of input and outputs.
Goals and Gains:- Define input, output and system
- Increase understanding of the concepts above by apply them to objects and situations both techincal and completely untechnical!
- Gain more technical knowledge and greater understanding of computers
- Practice good discussion skills like listening, talking one at a time, being respectful, and learning from each other.
- Ask students: Who can define the word system?
- Many definitions, but as used in our context: A network of interdependent things working as one whole (define the words within this definition as needed!)
- Pick an example system or two to explore (laptop, factory, restaurant, person...).
- Guide the students through breaking the example system down into parts:
- A laptop is a system of hardware and software -- CPU, RAM, screen, operating system, apps, keyboard...
- A factory is a system of machines and/or people -- makers, assemblers, quality-checkers, testers...
- A restaurant is a system of people and equipment -- customers, waiters, cooks, stoves, food, dishes...
- A person is a system of systems! -- circulatory, digestive, nervous, immune, respiratory...
- An entire system can be defined by its input(s) and output, sometimes multiple inputs/outputs.
- Guide the students through defining the input(s)/output(s) of the example:
- Laptop -- inputs: power, user interaction (key strokes, mouse etc.) data (usb, internet, downloads) -> outputs: screen images, printed pages, sound, lights, data (usb, internet, uploads)
- Factory -- raw materials -> product
- Restaurant -- hungry customers, money -> satisfied customers (hopefully!), food
- Person -- food, water, sensory input -> waste, thoughts, ideas, words, movement ...
- Each part of a system can also be broken down into it's input/output(s).
- Guide the students through defining the input/outputs of the example. For example a laptop has:
- Mouse -- physical movement -> cursor movement, clicks, etc
- Keyboard -- key presses / text, shortcuts, etc
- Screen -- code data / images
- CPU -- (reading) memory data / (writing) memory data
- etc
- Repeat with other Systems.
How do we define the word System in this context?
A network of interdependent things working as one whole.
How do inputs and outputs relate to systems?
A system has inputs and outputs, as do the elements within a system
Can systems be nested? As in, can one system have another system within it?
Yes!
- Who can think of something that CANNOT be seen as some kind of system? Can anyone prove that IS a system?
- How does this exercise (breaking down everyday things as systems) help us be better coders?
Tips & Tricks:
- Drawing the system can help explain the different parts. Here are some example diagrams:
- After this discussion, you can break students into smaller groups and have each group diagram a different thing as a system.
- Try to break one of the games you have played recently down through the system perspective (what parts were everyone playing? what where their input/outputs? What was the output of the whole game (goal)?)
Running out of ideas? Try these on for size!
- A School
- An Oven
- A Kitchen
- A Library
- An Amusement Park
- A Grocery Store
- A Car Wash
Try It First
~10min
Try It First
Players try to figure out how to code a new specification with no hints before getting hints/the answer.
Need:
- computers - 1 per Player
- code card
- whiteboard/projector
- timer
How to Play:
- Coach announces the specification
- Coach sets timer for 1-5 minutes
- Players attempt to figure out how to code the specification
- When timer goes off, Coach writes the implementation on whiteboard/projected screen
- Coach resets timer
- Players try the code as shown
Tips & Tricks:
- Great for introducing new material once Players are getting comfortable with the code structures. Many Players will need a lot of coaching, cheerleading, and "just give it a shot!" encouragement to try something they don't know the answer to!
- When showing the correct answer, ask the Team to help you. If any Players figured it out, have them tell you what to write.
- Variation: Over the allotted time, slowly fill in the code. This works well for Players who are getting stuck -- at least they can add something.
- For the full effect, do not give any answers until the first timer goes off. Offer support but ask Players to try things out, without giving them the answers.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
Coder Skills ~40 minutes
It takes more than just computer knowledge to be a coder; take a look all the different skills it takes to be the best coder in this map.
Review
~5min
Review
What skills have we learned in this class so far?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
The Life and Times of a Real Coder
~10min
The Life and Times of a Real Coder
What does it really take to be a coder?
Each Chapter of this story starts by defining a primary task a coder does before generating a list of the skills required for that task, then considering where else we use those skills. The goal being to expand the definition of what it means to be a coder and how everyone can gain from it.Tips & Tricks:
- This story is strongly based in discussion. Know what is important to touch on, but also let the students bring up ideas that you may not have thought of before!
- If possible, use visual aids/lists to keep the discussion clear and focused. Draw up on a whiteboard and/or even encourage students to draw along. An example diagram:
- Ask the students to assess their level of mastery over some/all of the skills discussed.
- Because this story mode is driven by questions to the class, there is no additional questions noted at the end.
- You can easily split this story by chapter over a class or several classes.
Chapter 1: The Code
- What does a coder do? -- Write, read, edit and debug code
- What skills do we need for that? -- (ex. coding knowledge, problem-solving, organization, logic, computational thinking, creativity...)
- Where else are these skills useful? -- (ex. math, writing, homework, art...)
- What else does a coder do? -- Work with people
- What skills do we need for that? -- (ex. communication [verbal, written and visual], teamwork...)
- Where else are these skills useful? -- (ex. school projects, sports, job, socially...)
- What else does a coder do? -- Work with own brain
- Meaning: "code" our brain by learning, "edit code" by learning new things, "debug code" by finding and fixing false assumptions
- What skills do we need for that? -- (ex. grit, self-reliance, curiosity, humility...)
- Where else are these skills useful? -- (ex. sports, musical instrument, writing...)
- It takes a lot of different skills to be a coder
- You learn and use these skills everywhere
- Like in our stories and games!
Who here wants to be some kind of coder when they grow up? Who might want to be a coder or do a job that involves coding? Who wants to do something totally different?!
Let's take a closer look at what it really takes to be the best coder -- all the different things a professional coder does and the skills it takes to be good at them. Some of these things you are already doing -- in this class or elsewhere in your life. Some of them you'll do soon! But all of these skills are valuable for all of you. Now and in the future, no matter what you end up doing!
Let's take a closer look at what it really takes to be the best coder -- all the different things a professional coder does and the skills it takes to be good at them. Some of these things you are already doing -- in this class or elsewhere in your life. Some of them you'll do soon! But all of these skills are valuable for all of you. Now and in the future, no matter what you end up doing!
[Coach asks students: What does a coder do? (It's not a trick question!)]
Guide students to the answer: Writes code! Also: reads code, edits code and debugs code.
How many of you here are coders? If you have every written, read, editted, or debugged code (even one line!) then you are a coder.
[Coach asks students: What skills does a coder, like you, need to work with code?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
Guide students to the answer: Writes code! Also: reads code, edits code and debugs code.
How many of you here are coders? If you have every written, read, editted, or debugged code (even one line!) then you are a coder.
[Coach asks students: What skills does a coder, like you, need to work with code?]
Example answers:
- knowledge of the programming language
- problem-solving skills
- organizational skills
- logical thinking
- computational thinking
- creativity
[Coach asks students: Where else do we use these skills?]
Example answers:
- organization -> writing essays/books
- logical thinking -> math
- problem-solving -> doing homework
- creativity -> art
Coders work with code; that's obvious! But there's more to coding that just writing, reading, editing and debugging the code.
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
- verbal communication skills
- writing skills
- visual communication skills (diagrams)
- teamwork skills
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- class projects
- ANY workplace
- with family/friends
So far, we have figured out that a coder works with code and works with other people. There is one last part of the coding process that I want to talk about today. It can be the hardest to grasp, and many coders never get this part, but I know you all are ready to figure this out with me.
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
- grit
- self-reliance
- perseverance
- curiosity
- meta-cognitive skills
- humility
- passion/drive
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- playing an instrument
- research
- writing
- physical creation (building/carpentry/sewing/etc)
When we look at all this -- all the stuff a coder does and all the skills we need to do them -- it is a lot! But the good news is that you are building these skills all over the place, not just in this class. Every time you figure out a tough homework problem all on your own, you are using your problem-solving, self-reliance, and perseverance skills. At soccer practice you are building up your teamwork, communication, and grit skills.
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
Build a Bug Workshop
~10min
Build a Bug Workshop
Players purposely break and debug code in this partnered game.
Need:
- computers - 1 per Player
How to Play:
Set Up: Each Player needs complete, working code on their computer to start this game. Either tack it on to a game like Disintegrating Code, or preface the game by typing up code from reference, specification, or each Player's own imagination! Just be sure all code works before starting this game.
- Players pair up
- Players swap computers, each with complete working code
- Players put a bug in their partner's code -- causing an error
- Players swap back computers and debug their now-broken code
Tips & Tricks:
- Players can swap seats instead of computers to prevent dropping of computers.
- For some friendly competition, turn the game into a race: who can debug their code faster?
- Start this game with a discussion about the bugs they have come across so far -- spelling errors, missing paretheses, wrong keywords -- to spark creativity about the kind of errors to plant in their partner's code.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
More on Coder Skills ~40 minutes
Continuing the discovery of the whole collection of skills it takes to be a coder.
Review
~5min
Review
What did we learn about coder skills last time?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
The Life and Times of a Real Coder: Chapter 2/3
~10min
The Life and Times of a Real Coder: Chapter 2/3
The second part of a three-part story, investigating all the different skills it takes to be the best coder we can be.
Tips & Tricks:
- This story is strongly based in discussion. Know what is important to touch on, but also let the students bring up ideas that you may not have thought of before!
- If possible, use visual aids/lists to keep the discussion clear and focused. Draw up on a whiteboard and/or even encourage students to draw along. An example diagram:
- Ask the students to assess their level of mastery over some/all of the skills discussed.
- Because this story mode is driven by questions to the class, there is no additional questions noted at the end.
Review
- What did we learn about coders and the skills we need last time?
- What else does a coder do? -- Work with people
- What skills do we need for that? -- (ex. communication [verbal, written and visual], teamwork...)
- Where else are these skills useful? -- (ex. school projects, sports, job, socially...)
Coders work with code; that's obvious! But there's more to coding that just writing, reading, editing and debugging the code.
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
- verbal communication skills
- writing skills
- visual communication skills (diagrams)
- teamwork skills
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- class projects
- ANY workplace
- with family/friends
Create a Challenge
~10min
Create a Challenge
The Team works together to design specification for a coding challenge, before taking on that challenge themselves.
Need:
- whiteboard/paper and writing utensils
- computers - 1 per Player
How to Play:
- Team designs an achievable specification
- The finalized specification is written down where everyone can see
- Team designates a time limit and sets the timer
- Players code an implementation on individual computers
Tips & Tricks:
- Ideally, a Team could run this game entirely by themselves without the Coach's help! But most teams, especially those with younger or inexperienced Players, will need the Coach's guidance to work well as a team and find a specification and time limit that is a good balance of challenging and acheivable. Experienment with when to step in and when to let the Team figure it out.
- Teams with a wide range in skill and experience can easily be split into smaller Teams, each running this game independently of the other Team(s).
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
Coder Skills: The Final Chapter ~40 minutes
Focusing on the most challenging part of being a coder -- coding your own brain.
Review
~5min
Review
What did we learn about coder skills last time?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
The Life and Times of a Real Coder: Chapter 3/3
~10min
The Life and Times of a Real Coder: Chapter 3/3
The third and final part of a three-part story, investigating all the different skills it takes to be the best coder we can be.
Tips & Tricks:
- This story is strongly based in discussion. Know what is important to touch on, but also let the students bring up ideas that you may not have thought of before!
- If possible, use visual aids/lists to keep the discussion clear and focused. Draw up on a whiteboard and/or even encourage students to draw along. An example diagram:
- Ask the students to assess their level of mastery over some/all of the skills discussed.
- Because this story mode is driven by questions to the class, there is no additional questions noted at the end.
Review
- What have we learned about coders and the skills we need so far?
- What else does a coder do? -- Work with own brain
- Meaning: "code" our brain by learning, "edit code" by learning new things, "debug code" by finding and fixing false assumptions
- What skills do we need for that? -- (ex. grit, self-reliance, curiosity, humility...)
- Where else are these skills useful? -- (ex. sports, musical instrument, writing...)
- It takes a lot of different skills to be a coder
- You learn and use these skills everywhere
- Like in our stories and games!
So far, we have figured out that a coder works with code and works with other people. There is one last part of the coding process that I want to talk about today. It can be the hardest to grasp, and many coders never get this part, but I know you all are ready to figure this out with me.
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
- grit
- self-reliance
- perseverance
- curiosity
- meta-cognitive skills
- humility
- passion/drive
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- playing an instrument
- research
- writing
- physical creation (building/carpentry/sewing/etc)
When we look at all this -- all the stuff a coder does and all the skills we need to do them -- it is a lot! But the good news is that you are building these skills all over the place, not just in this class. Every time you figure out a tough homework problem all on your own, you are using your problem-solving, self-reliance, and perseverance skills. At soccer practice you are building up your teamwork, communication, and grit skills.
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
Try It First
~10min
Try It First
Players try to figure out how to code a new specification with no hints before getting hints/the answer.
Need:
- computers - 1 per Player
- code card
- whiteboard/projector
- timer
How to Play:
- Coach announces the specification
- Coach sets timer for 1-5 minutes
- Players attempt to figure out how to code the specification
- When timer goes off, Coach writes the implementation on whiteboard/projected screen
- Coach resets timer
- Players try the code as shown
Tips & Tricks:
- Great for introducing new material once Players are getting comfortable with the code structures. Many Players will need a lot of coaching, cheerleading, and "just give it a shot!" encouragement to try something they don't know the answer to!
- When showing the correct answer, ask the Team to help you. If any Players figured it out, have them tell you what to write.
- Variation: Over the allotted time, slowly fill in the code. This works well for Players who are getting stuck -- at least they can add something.
- For the full effect, do not give any answers until the first timer goes off. Offer support but ask Players to try things out, without giving them the answers.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
Intro to Inputs/Outputs ~40 minutes
An unplugged/plugged classmap introducing the basics of inputs/outputs.
Coach Story
~5min
Coach Story
A chance to introduce yourself and some values of MetaCoders.
[Coach fills in: Your coach story][Coach fills in: Any discussion questions you wish to ask about your story]
Person-Bot (or Code the Coach/Kid)
~10min
Person-Bot (or Code the Coach/Kid)
Team works together to 'code' a Bot (the Coach or a Player) to achieve a Goal.
Need:
- no required supplies
How to Play:
- Coach sets the Goal (see Example Goals below)
- Coach picks a Bot -- often the Coach themselves for the first round
- Coach picks 1-3 Bot Coders
- Bot Coders work as a team to give clear, exact instructions to Bot to achieve the Goal
- Bot follows the instructions EXACTLY (see Example Instructions below)
- Follow up with additional rounds with new Bots and new Bot Coders
Example Goals:
- Get from Point A to B (ideal with some obstacles in the way!)
- Move the book from the table to the shelf
- Draw a smiley face on the white board
- Put on your sweatshirt
Example Clear, Executable Instructions:
- Take 3 steps forward
- Turn 1 quarter turn to your left
- Grab the sweatshirt with your right hand
Example UNCLEAR, Inexecutable Instructions:
- Turn around (Bot does a 360 spin, ends up exactly where they were)
- Go backwards (Bot walks backwards -- and keeps going!)
- Go to the shelf (Bot makes error sound or shrugs -- what is 'the shelf?')
- Put the sweatshirt over your head (Bot holds the sweatshirt up in the air, over their head)
Tips & Tricks:
- Players as Bots may need help following directions EXACTLY and not making assumptions or going out of their way to wrongly interpret a clear instruction!
- Variation: Have the Bot leave the room when the Goal is being determined, so they don't know the Goal.
- Variation: Have all Players be the Bot Coders. All must agree on an instruction and a Master Coder relays that to the Bot.
- Variation: Team works together to write down all their instructions at once, before the Bot reads and executes all the instructions in a row. Great for predictive thinking!
- Variation: Include a Bot error sound/response that the Bot uses when given an unclear instruction.
Thinking about Inputs and Outputs
~10min
Thinking about Inputs and Outputs
Learn about inputs and outputs on a computer, then map them on to a human!
Outline- Computers have inputs -- how they receive information -- and outputs -- how they give information.
- With the help of students, list computers INPUTS:
- keyboard
- mouse/trackpad
- camera
- microphone
- USB port
- ...
- With the help of students, list computer OUTPUTS:
- screen
- speakers
- USB port
- ...
- What about HUMANS? What are our inputs -- ways to recieve information -- and outputs -- ways to give information?
- With the help of students, list human INPUTS (the 5 senses):
- eyes
- ears
- nose
- mouth
- skin
- With the help of students, list human OUTPUTS:
- voice
- fingers (pointing)
- hands (sign language)
- whole body (body language, dance)
- face (expression)
- writing
- drawing
- ...
What Does This Do?
~10min
What Does This Do?
Players type up and run code, before explaining the result in detail.
Need:
- computers - 1 per Player
- code
- whiteboard/projector or alternative way to show Team the code
- timer
How to Play:
- Coach writes up/displays code
- Coach does NOT say what the code does
- Coach sets timer for 1-5 minutes
- Players type up the code and run it
- When timer goes off, Coach asks Players to share what they observed about the code
Tips & Tricks:
- Keep the experimentation phase "top secret" -- have Players be secretive about what they find until the timer goes off and you all share! This keeps faster Players from spoiling the game for slower typists.
- Varitation: Players discuss their hypotheses for what the code will do prior to trying it.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
Intro to Bugs: on-computer games only ~60 minutes
A classmap introducing the basics of bugs, with all on-computer game modes.
Review
~5min
Review
What did we do last time?
Disintegrating Code
~20min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Debugging the Pizza
~15min
Debugging the Pizza
Mia uses a debugging process to figure out why the pizza suddenly tastes like soap.
Mode Summary & Goals
Summary: Learn about the debugging process in a non-computer frame -- pizza!
Goals and Gains:- Define bug, debug
- Investigate the subtle difference between problem-solving and debugging (debugging often involves FINDING the problem!)
- Practice our own debugging skills
- Get comfortable with the idea of bugs and debugging as part of the coding process
Tips & Tricks:
- For a shorter story, take out some of the hypotheses/tests.
- Use the name of a student in the room instead of Mia.
- Ask students to create their own hypotheses -- even tests (you give the result).
- Don't forget to engage with questions -- at the end and throughout!
- Mia's excited -- tonight her dad is ordering pizza for dinner.
- But when she takes her first bite, it tastes like SOAP!
- Mia's brother tries it -- he thinks it's fine...
- Mia needs to figure out what is going on/debug her pizza.
- Debugging attempt #1 --
- Hypothesis: Mia's brother is tricking her.
- Test: Ask him (he's a very bad liar, she can always tell).
- Result? He isn't tricking her.
- Debugging attempt #2 --
- Hypothesis: Mia's brother doesn't know better (he eats wierd stuff...)
- Test: Mia's dad tries it.
- Result? He thinks it's delicious.
- Debugging attempt #3 --
- Hypothesis: Mia's tastebuds are wrong.
- Test: Mia tries other foods.
- Result? Everything tastes normal...
- Debugging attempt #4 --
- Hypothesis: It's not all of the pizza, just one part.
- Test: Mia tries each part of the pizza.
- Result? It's the sauce! Specifically, green specks in the sauce...
- Mia asks her dad what the green specks are.
- It's cilantro! Some people, like Mia's mom, taste soap in cilantro -- it's genetic!
- Mia's dad promises never to get pizza with cilantro again.
Wednesday is Mia's favorite day -- because it's pizza night. Every Wednesday, instead of cooking, Mia's dad orders a different kind of pizza. It's not that Mia doesn't like her dad's cooking. It's just that pizza is her favorite food and always will be, forever. Cheese, pepperoni, vegetable, meatball -- the kind of pizza didn't matter. They were all her favorites.
Her mouth has been watering all day. When the doorbell rings, she calls, "Dad! The pizza is here." He takes forever to come downstairs. It feels like it takes years for him to pay the pizza delivery man, and another few years before he finally places the giant pizza box on the kitchen table and announces:
"Dinner is served."
Mia snatches up a slice and takes it to her room to eat it while she plays video games with her twin brother. She has a video game controller in one hand and a slice of pizza in the other. So does her brother.
"Ready to lose?" says her brother, starting a racing game with his free hand and taking a bite with the other.
"I never lose," she replies as she takes her first big bite of pizza.
She chews as the race begins. At first, her car surges ahead -- but suddenly she freezes, no longer chewing. The taste in her mouth is terrible! It's as if someone covered the whole pizza in soap. She drops her video game conroller.
"Shomthong's wong with my pizza!" she mumbles with her mouth full.
Dropping the video game controller on the floor, she runs to the bathroom, hearing her brother call after her:
"You're just mad because you know I'm going to win!"
Mia spits out the bite of pizza and examines the slice carefully under the bathroom light. It looks normal. She sniffs it. It smells normal. She takes a smaller bite this time.
Sure enough, though, as she begins to chew, it tastes like her mouth is full of soap. She has to spit the bite into the trash.
She marches back into her room and switches off the video game.
"Hey!" her brother says. He's almost done with his own slice of pizza by now.
"Taste this," she demands, giving him her slice. "There's something wrong with my slice."
Cautiously, he tastes takes it, sniffs it, and bites into it.
"It tastes fine to me," he says. "I'll eat it if you don't want it." [Need another beat...]
What's happening? she wonders. I must debug my pizza...
Her mouth has been watering all day. When the doorbell rings, she calls, "Dad! The pizza is here." He takes forever to come downstairs. It feels like it takes years for him to pay the pizza delivery man, and another few years before he finally places the giant pizza box on the kitchen table and announces:
"Dinner is served."
Mia snatches up a slice and takes it to her room to eat it while she plays video games with her twin brother. She has a video game controller in one hand and a slice of pizza in the other. So does her brother.
"Ready to lose?" says her brother, starting a racing game with his free hand and taking a bite with the other.
"I never lose," she replies as she takes her first big bite of pizza.
She chews as the race begins. At first, her car surges ahead -- but suddenly she freezes, no longer chewing. The taste in her mouth is terrible! It's as if someone covered the whole pizza in soap. She drops her video game conroller.
"Shomthong's wong with my pizza!" she mumbles with her mouth full.
Dropping the video game controller on the floor, she runs to the bathroom, hearing her brother call after her:
"You're just mad because you know I'm going to win!"
Mia spits out the bite of pizza and examines the slice carefully under the bathroom light. It looks normal. She sniffs it. It smells normal. She takes a smaller bite this time.
Sure enough, though, as she begins to chew, it tastes like her mouth is full of soap. She has to spit the bite into the trash.
She marches back into her room and switches off the video game.
"Hey!" her brother says. He's almost done with his own slice of pizza by now.
"Taste this," she demands, giving him her slice. "There's something wrong with my slice."
Cautiously, he tastes takes it, sniffs it, and bites into it.
"It tastes fine to me," he says. "I'll eat it if you don't want it." [Need another beat...]
What's happening? she wonders. I must debug my pizza...
First Debugging Attempt
Mia_'s first thought is that her brother is playing a trick on her. "Is this another one of your pranks?" she demands.
His eyes go wide. "Me prank you? You're the one who always pranks me!"
"Yeah, that's true," she says.
"Do you want me to pinky swear?" he asks, holding out his pinky.
"That won't be necessary," she says. She can always tell when he's lying because he blushes when he does. He was definitely telling the truth though.
Hmmm, she wonders, Why would the pizza taste like soap to me but not to him?
Another Debugging Attempt
It occurs to Mia that although her brother might not be lying, he might simply be wrong and not know it. Maybe he just doesn't realize that the pizza tastes bad. One time, he spent an entire week eating nothing but pickles. Another time, he drank an entire bottle of ketchup on a dare.
"I'll be back," she says, taking her pizza with her and marching to her dad's room. As usual, he's doing work at his desk. "Dad," she says, "I need you to try this pizza."
"Mia, you know I'm on a diet," he says.
"Dad! Please!" she begs. "There's something wrong with it. It tastes all weird."
Sighing, he takes the pizza, sniffs it, and takes a tiny bite. Mia holds her breath as she waits -- expecting him to spit it out.
Slowly, he swallows, sniffs the pizza again, and takes another bite.
"Dad!" she cries. "What are you doing?"
"It tastes great," he says, turing back to his comptuer. "If you don't want it, just give it to your brother."
Stunned, she leaves the room, taking the mysterious pizza with her.
Yet Another Debugging Attempt
Her brother might not be able to taste the difference between soap and pizza, but her dad was practically a professional chef. He could taste food and tell you all of its ingredients without even seeing the recipe.
There was only one conclusion she could draw. The bug must not be in the pizza. It must be in her!
Panicked, she ran to the kitchen. She put the slice of pizza on the table and yanked the refrigerator door open. She pulled out a jar of pickles, some leftover cake from her dad's birthday, and some leftover meatballs from yesterday's dinner.
One by one, she tasted each of them. The bite of pickles tasted like pickles. The bite of cake tasted like cake. And the meatballs tasted like meatballs.
Maybe I'm cured, she thought. But when she tasted the pizza again... it tasted like soap. She had to spit it into the trashcan yet again.
Mia_'s first thought is that her brother is playing a trick on her. "Is this another one of your pranks?" she demands.
His eyes go wide. "Me prank you? You're the one who always pranks me!"
"Yeah, that's true," she says.
"Do you want me to pinky swear?" he asks, holding out his pinky.
"That won't be necessary," she says. She can always tell when he's lying because he blushes when he does. He was definitely telling the truth though.
Hmmm, she wonders, Why would the pizza taste like soap to me but not to him?
- What was the hypothesis?
- What does ___ do to test it?
- What reasonable hypotheses might ___ form now?
Another Debugging Attempt
It occurs to Mia that although her brother might not be lying, he might simply be wrong and not know it. Maybe he just doesn't realize that the pizza tastes bad. One time, he spent an entire week eating nothing but pickles. Another time, he drank an entire bottle of ketchup on a dare.
"I'll be back," she says, taking her pizza with her and marching to her dad's room. As usual, he's doing work at his desk. "Dad," she says, "I need you to try this pizza."
"Mia, you know I'm on a diet," he says.
"Dad! Please!" she begs. "There's something wrong with it. It tastes all weird."
Sighing, he takes the pizza, sniffs it, and takes a tiny bite. Mia holds her breath as she waits -- expecting him to spit it out.
Slowly, he swallows, sniffs the pizza again, and takes another bite.
"Dad!" she cries. "What are you doing?"
"It tastes great," he says, turing back to his comptuer. "If you don't want it, just give it to your brother."
Stunned, she leaves the room, taking the mysterious pizza with her.
- What was the hypothesis?
- What does ___ do to test it?
- What reasonable hypotheses might ___ form now?
Yet Another Debugging Attempt
Her brother might not be able to taste the difference between soap and pizza, but her dad was practically a professional chef. He could taste food and tell you all of its ingredients without even seeing the recipe.
There was only one conclusion she could draw. The bug must not be in the pizza. It must be in her!
Panicked, she ran to the kitchen. She put the slice of pizza on the table and yanked the refrigerator door open. She pulled out a jar of pickles, some leftover cake from her dad's birthday, and some leftover meatballs from yesterday's dinner.
One by one, she tasted each of them. The bite of pickles tasted like pickles. The bite of cake tasted like cake. And the meatballs tasted like meatballs.
Maybe I'm cured, she thought. But when she tasted the pizza again... it tasted like soap. She had to spit it into the trashcan yet again.
- What was the hypothesis?
- What does ___ do to test it?
- What reasonable hypotheses might ___ form now?
Final Debugging Attempt
This is my favorite food of all time, thinks Mia_. There is no way I'm going to bed tonight without solving this mystery.
Suddenly, it occurs to her that maybe it's not the whole pizza that tastes like soap -- but only part of it. She puts the pizza on a plate and gets a knife from the drawer. She cuts off a bit of the crust, a scrap of cheese, and a single pepperoni.
She puts the crust in her mouth and begins to chew, waiting for the soap taste. But the crust tastes like crust.
She puts the pepperoni in her mouth and begins to chew, waiting for the soap taste. But the pepperoni tastes like pepperoni.
She puts the scrap of cheese in her mouth and begins to chew, waiting for the soap taste. But the cheese tastes like cheese -- or almost like it. The taste of soap is faint, but it's there.
With the fork, she takes all of the cheese off of the pizza, revealing the tomato sauce beneath. She scoops up a bit of the sauce and puts it in her mouth. The moment she does, she gags on the soap taste and must spit the sauce into the sink.
She looks very closely at the pizza and notices that there are little specks of green inside the red sauce. They smell just fine, but she knows better than to put them in her mouth again. Gross.
She takes the cheeseless pizza upstairs to her dad's room again and says, "Dad, I figured it out. It's the sauce."
"What's the sauce?"
"That's where the soap is. What are these green things?"
Her dad takes the pizza and holds it under his desk lamp, looking very closely. "It's cilantro."
"What kind of soap is that?" she asks. "And why did they put it on the pizza?"
"It's not soap," says her father, chuckling. "It's a kind of spice. It can taste like soap to some people, though. It's genetic. Your mom can't stand the stuff either. You can ask her about it when she gets home."
"What is genetic?" Mia she says.
"Inside everyone's body is something called a genetic code," he says. "It's like a code that says what color hair you'll have, what color eyes, whether you'll be tall or short, and whether or not cilantro tastes like soap or not."
"Does that mean there's a bug in my code?" she says.
Her father laughs. "You could call it a bug, or you could call it a super power. Basically, your tongue is able to detect a chemical in the cilantro that most people can't taste. It's always there -- but people like me and your brother."
"I'll consider it a super power," she says. "But can we never get pizza with cilantro again? Please!"
Her father nods. "I promise."
This is my favorite food of all time, thinks Mia_. There is no way I'm going to bed tonight without solving this mystery.
Suddenly, it occurs to her that maybe it's not the whole pizza that tastes like soap -- but only part of it. She puts the pizza on a plate and gets a knife from the drawer. She cuts off a bit of the crust, a scrap of cheese, and a single pepperoni.
She puts the crust in her mouth and begins to chew, waiting for the soap taste. But the crust tastes like crust.
She puts the pepperoni in her mouth and begins to chew, waiting for the soap taste. But the pepperoni tastes like pepperoni.
She puts the scrap of cheese in her mouth and begins to chew, waiting for the soap taste. But the cheese tastes like cheese -- or almost like it. The taste of soap is faint, but it's there.
With the fork, she takes all of the cheese off of the pizza, revealing the tomato sauce beneath. She scoops up a bit of the sauce and puts it in her mouth. The moment she does, she gags on the soap taste and must spit the sauce into the sink.
She looks very closely at the pizza and notices that there are little specks of green inside the red sauce. They smell just fine, but she knows better than to put them in her mouth again. Gross.
She takes the cheeseless pizza upstairs to her dad's room again and says, "Dad, I figured it out. It's the sauce."
"What's the sauce?"
"That's where the soap is. What are these green things?"
Her dad takes the pizza and holds it under his desk lamp, looking very closely. "It's cilantro."
"What kind of soap is that?" she asks. "And why did they put it on the pizza?"
"It's not soap," says her father, chuckling. "It's a kind of spice. It can taste like soap to some people, though. It's genetic. Your mom can't stand the stuff either. You can ask her about it when she gets home."
"What is genetic?" Mia she says.
"Inside everyone's body is something called a genetic code," he says. "It's like a code that says what color hair you'll have, what color eyes, whether you'll be tall or short, and whether or not cilantro tastes like soap or not."
"Does that mean there's a bug in my code?" she says.
Her father laughs. "You could call it a bug, or you could call it a super power. Basically, your tongue is able to detect a chemical in the cilantro that most people can't taste. It's always there -- but people like me and your brother."
"I'll consider it a super power," she says. "But can we never get pizza with cilantro again? Please!"
Her father nods. "I promise."
- What is a "bug" in coding?
- What does it mean to "debug"?
How are debugging and problem-solving the same? How are they different?
Debugging often involves similar skills, but a big part of debugging is finding the cuase of the problem, which isn't always included in problem-solving.
- When is a time you debugged something? On the computer? Off the computer?
- What skills do you need to be the best debugger?
Build a Bug Workshop
~15min
Build a Bug Workshop
Players purposely break and debug code in this partnered game.
Need:
- computers - 1 per Player
How to Play:
Set Up: Each Player needs complete, working code on their computer to start this game. Either tack it on to a game like Disintegrating Code, or preface the game by typing up code from reference, specification, or each Player's own imagination! Just be sure all code works before starting this game.
- Players pair up
- Players swap computers, each with complete working code
- Players put a bug in their partner's code -- causing an error
- Players swap back computers and debug their now-broken code
Tips & Tricks:
- Players can swap seats instead of computers to prevent dropping of computers.
- For some friendly competition, turn the game into a race: who can debug their code faster?
- Start this game with a discussion about the bugs they have come across so far -- spelling errors, missing paretheses, wrong keywords -- to spark creativity about the kind of errors to plant in their partner's code.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
Intro to Thinking Code ~40 minutes
A unplugged/plugged classmap introducing the basics of learning how to code.
Review
~5min
Review
What did we do last time?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
You will play this game again in the More on Inputs and Outputs map, so keep that in mind when how much time you spend on each level.
How to Play:
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
A Path in Your Brain
~10min
A Path in Your Brain
A metaphor for learning in your brain. Or: why it takes so darn long to learn something new.
Tips & Tricks:
- Choose a volunteer: use this person's name instead of Joe. Use something that they are trying to learn instead of German (piano, algebra, soccer, CODING). You can even bring them up to sit next to you and keep pointing at their brain to keep reminding the audience that this is happening inside a brain.
- You can illustrate this story as you tell it -- drawing the cottage, clearing and paths on a whiteboard, widening the lines or erasing them as fits the story.
- Don't forget to ask questions: at the end and throughout!
- Joe is someone much like you (the audience). But he is just starting German class.
- Let's look inside Joe's brain while he does his German homework.
- Imagine his brain is a forest, and there's a Tiny Joe trying to make a new trail through it.
- It's difficult for Tiny Joe to get through the forest.
- Just like it's difficult for Real Joe to do the homework.
- Over time, as Real Joe learns more German, Tiny Joe clears a wider, better trail.
- After being sick and not practicing for a time, Real Joe has a hard time doing what had been easy before.
- The trail in Joe's brain had become a bit overgrown.
- With practice, the skill returned, and the trail cleared.
- Over many years of German classes and practice, Tiny Joe's trail in Real Joe's brain is made into a long, clear, easy-to-travel path and Real Joe can use German fluently.
We are going to going into someone's brain -- any volunteers? Where did I put my scapel... I'm kidding! No, we aren't really going into someone's brain, but we are going to imagine that we are. We are going to use a metaphor to understand what goes on in your brain -- and yours, and yours, and mine, and your uncle's, and your grandma's brain -- what goes on in everyone's brain when they are learning.
The brain we are going to take our journey into today belongs to Joe. Joe is about your age. He is just starting to learn how to speak German. Let's hop into his brain while he is struggling through some German homework after his very first German class.
Let's imagine the inside of Joe's brain as a giant forest. Here's is a little cottage in a clearing, and on the edges of the clearing we can see lots of little trails going out into the forest. Some of these trailheads are clearly marked, with a wide entrance, big signs and arrows. Others are almost invisible they are so small. There is even one or two places where it looks like there used to be a trail but the forest has grown over it, covering the entrance.
Coming out of the cottage -- look it's Joe! It's a tiny Joe, inside the real Joe's brain-forest. He has his adventuring backpack with him, complete with flashlight, machete and snacks. Tiny Joe is heading to the forest.
But Tiny Joe doesn't take one of the clearly marked paths. He doesn't take any of the smaller paths either. Tiny Joe walks straight to the edge of the forest and starts pushing his way through.
It's very slow-going; this forest is very thick. Tiny Joe has to kick big stones, slice through heavy vines, stomp through thick bushes, even push some very large boulders out of his way. At one point, Tiny Joe comes to a river and creates a small, haphazard bridge out of a fallen log.
After struggling through his German homework for 30 minutes (remember, that's what real Joe is actually doing), Joe is done with his vocabulary review. He's tired and glad to be done!
Let's fast-forward a bit. Joe keeps going to his German classes, keeps doing his German vocabulary homework. And Tiny Joe keeps traipsing down that path in his brain-forest.
Everytime Tiny Joe journey's down that same trail, it gets easier. There are fewer rocks and bushes in his way. He has built on that bridge across the river so that it's much safe and easier to cross. He has made the path wider and flatter by walking down it so many times.
Real Joe is finding it easier and easier to remember the German vocabulary and grammar. Now he doesn't have to stare at his textbook the whole class -- he can even have a whole (short) conversation in German without needing his notes once!
One day, when Joe gets the flu, he misses two whole weeks of German class. He doesn't pick up his German textbook once in those two weeks. When he comes back to class, and Tiny Joe goes traipsing down that trail again, he struggles a bit! Real Joe is frustrated; he could have this conversation easily two weeks ago!
But in those two weeks, when Joe didn't think about German once, the trail in his brain-forest started to grow over with little bushes and vines. A few of those stones cam tumbling back. A rainstorm roughed up the nicely trampled dirt. It was harder for Tiny Joe to walk that path; and harder for Real Joe to remember his German!
After a little extra practice, Tiny Joe had that trail cleared nicely again and continued his progress of widening it and making it better. Tiny Joe added some nice clear signs showing the way, built up that bridge, and made the trail twice as long as it was before. The next time Real Joe takes two weeks of vacation from his German class, he shows off his German to his grandparents and spent some time reviewing his vocabularly list. He has hardly any trouble coming back to class after the break, this time!
Several years of German classes later, Joe is quite fluent in the language. He can have long conversations in German with his classmates and with his cousins who live in Germany and speak German every day. Joe can read some German books, write essays in German -- he even dreams in German sometimes!
The trail in Joe's brain is wide, welcoming and inviting. It's so easy to travel that Tiny Joe can run down it with his eyes closed! It's hard to remember that there was ever a time that the trail didn't exist at all.
The brain we are going to take our journey into today belongs to Joe. Joe is about your age. He is just starting to learn how to speak German. Let's hop into his brain while he is struggling through some German homework after his very first German class.
Let's imagine the inside of Joe's brain as a giant forest. Here's is a little cottage in a clearing, and on the edges of the clearing we can see lots of little trails going out into the forest. Some of these trailheads are clearly marked, with a wide entrance, big signs and arrows. Others are almost invisible they are so small. There is even one or two places where it looks like there used to be a trail but the forest has grown over it, covering the entrance.
Coming out of the cottage -- look it's Joe! It's a tiny Joe, inside the real Joe's brain-forest. He has his adventuring backpack with him, complete with flashlight, machete and snacks. Tiny Joe is heading to the forest.
But Tiny Joe doesn't take one of the clearly marked paths. He doesn't take any of the smaller paths either. Tiny Joe walks straight to the edge of the forest and starts pushing his way through.
It's very slow-going; this forest is very thick. Tiny Joe has to kick big stones, slice through heavy vines, stomp through thick bushes, even push some very large boulders out of his way. At one point, Tiny Joe comes to a river and creates a small, haphazard bridge out of a fallen log.
After struggling through his German homework for 30 minutes (remember, that's what real Joe is actually doing), Joe is done with his vocabulary review. He's tired and glad to be done!
Let's fast-forward a bit. Joe keeps going to his German classes, keeps doing his German vocabulary homework. And Tiny Joe keeps traipsing down that path in his brain-forest.
Everytime Tiny Joe journey's down that same trail, it gets easier. There are fewer rocks and bushes in his way. He has built on that bridge across the river so that it's much safe and easier to cross. He has made the path wider and flatter by walking down it so many times.
Real Joe is finding it easier and easier to remember the German vocabulary and grammar. Now he doesn't have to stare at his textbook the whole class -- he can even have a whole (short) conversation in German without needing his notes once!
One day, when Joe gets the flu, he misses two whole weeks of German class. He doesn't pick up his German textbook once in those two weeks. When he comes back to class, and Tiny Joe goes traipsing down that trail again, he struggles a bit! Real Joe is frustrated; he could have this conversation easily two weeks ago!
But in those two weeks, when Joe didn't think about German once, the trail in his brain-forest started to grow over with little bushes and vines. A few of those stones cam tumbling back. A rainstorm roughed up the nicely trampled dirt. It was harder for Tiny Joe to walk that path; and harder for Real Joe to remember his German!
After a little extra practice, Tiny Joe had that trail cleared nicely again and continued his progress of widening it and making it better. Tiny Joe added some nice clear signs showing the way, built up that bridge, and made the trail twice as long as it was before. The next time Real Joe takes two weeks of vacation from his German class, he shows off his German to his grandparents and spent some time reviewing his vocabularly list. He has hardly any trouble coming back to class after the break, this time!
Several years of German classes later, Joe is quite fluent in the language. He can have long conversations in German with his classmates and with his cousins who live in Germany and speak German every day. Joe can read some German books, write essays in German -- he even dreams in German sometimes!
The trail in Joe's brain is wide, welcoming and inviting. It's so easy to travel that Tiny Joe can run down it with his eyes closed! It's hard to remember that there was ever a time that the trail didn't exist at all.
- What made the trail in Joe's brain-forest easier to travel?
- When did the trail more difficult again?
What real thing in your brain does the forest trail in this story represent?
A neural pathway -- connections between neurons in the brain
What real thing in your brain does "Tiny Joe" represent?
Electricity and neurotransmitters -- communications between neurons
- When was a time that it felt very difficult or frustrating to learn something new?
- What can we learn from this story that we can use in this class?
- How can knowing what happens in our brain as we learn help us learn better?
Disintegrating Code
~10min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
More On Inputs and Outputs: on-computer games only ~60 minutes
A classmap on inputs/outputs, with all on-computer game modes.
Review
~5min
Review
What do you remember about Inputs and Outputs?
Disintegrating Code
~20min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
The World Through Inputs and Outputs
~15min
The World Through Inputs and Outputs
Cats/animalsHousesBottle/CupFridgeYour Room
Try It First
~15min
Try It First
Players try to figure out how to code a new specification with no hints before getting hints/the answer.
Need:
- computers - 1 per Player
- code card
- whiteboard/projector
- timer
How to Play:
- Coach announces the specification
- Coach sets timer for 1-5 minutes
- Players attempt to figure out how to code the specification
- When timer goes off, Coach writes the implementation on whiteboard/projected screen
- Coach resets timer
- Players try the code as shown
Tips & Tricks:
- Great for introducing new material once Players are getting comfortable with the code structures. Many Players will need a lot of coaching, cheerleading, and "just give it a shot!" encouragement to try something they don't know the answer to!
- When showing the correct answer, ask the Team to help you. If any Players figured it out, have them tell you what to write.
- Variation: Over the allotted time, slowly fill in the code. This works well for Players who are getting stuck -- at least they can add something.
- For the full effect, do not give any answers until the first timer goes off. Offer support but ask Players to try things out, without giving them the answers.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
More On Bugs ~40 minutes
Learn some computer science history in this map.
Review
~5min
Review
What do you remember about Bugs?
Chain Reaction
~10min
Chain Reaction
Define multiple bot-groups with different definitions and create a chain reaction...
Need:
- Optional: whiteboard for writing language definitions
How to Play:
Move through each of the levels at a pace that makes sense for your Players. Remember: doing something once does not make one an expert, or even just capable!
- Coach defines a language with inputs (words or motions the Coach will make), and outputs (what the Players or "bots" will do when they hear/see that input). Examples:
- Say "Go!" = 1 step forward
- Hold both arms straight up = crouch to the ground
- Say "Reverse" = 1 step backward
- Point at bots = clap hands once
- Coach runs several tests to make sure all bots understand
- Coach programs the bots using the defined language
- Repeat steps 1-3, adding more definitions to the language each time.
- Coach splits all Players into 2 bot-groups
- Coach gives each group an identifier (name) (see tips for suggestions)
- Coach defines a language with inputs and various ouputs for the different bot groups. Include:
- Inputs that 1 bot group receives but means nothing to the other bot group (ex. 1 Clap = A-bots jumps in place // 2 Claps = B-bots jumps in place)
- Inputs that trigger different outputs (ex. say "Blorp" = A-bots crouch to the ground/B-bots turn in a circle)
- Inputs that trigger the same output (ex. Point = A-bots and B-bots look in pointed direction and gasp dramatically)
- Coach programs the bots using the defined language
- Repeat steps 3 and 4, adding more definitions to the language each time
- Coach adds new definitions to the language that include chain reaction potential: an output is the input for another bot-group. An example:
- Thumbs up = B-bots clap 1 time
- say "Beep Beep" = A-bots give thumbs up
- Avoid definitions that could create loops! (see level 3)
- Coach clarifies: Bots can now receive input from anywhere outside their own group, not just Coach
- Coach programs the bots, starting simple chain reactions
- Repeat steps 1 and 4, adding more to the language each time. An example:
- say "Road Runner!" = B-bots say "Beep Beep"
- Coach adds more complex definitions to the language; creating possible infinite loops. An example:
- X jump(s) = A-bots and B-bots jump (X+1) times
- Coach programs the bots
- Coach starts an infinite loop
- Once never-ending loop is clear to Players, Coach pauses game
- Coach leads quick discussion: What just happened?
- Coach continues game, can delete loop-causing definitions or keep them in play
- Coach splits groups further, into three or even four groups
- Coach adds to language accordingly, before programming bots
Tips & Tricks:
- Group identifiers can be as simple as A-bots and B-bots. Or you can try colors, animals, computer-themed (ex. Android bots and iPhone/iOS bots), or anything the Players choose.
- Writing the language up on a whiteboard can help Players who are stuggling to understand/stay focused.
- Be prepared for loops before starting level 3! When a loop starts, the game will disitegrate into giggles/some amount of chaos. That's okay! Just be prepared to re-gather attention and focus back.
- Add a "Hold" and "Run" command -- where Coach can pause all bots, give a couple commands in a row, before "running" the code, having bots run those commands consecutively.
- Can be made into an elimination-style competitive game.
The First Computer Bug...
~10min
The First Computer Bug...
The story of the moth in Mark II
Mode Summary & Goals
Summary: Learn the story of the First Computer bug -- a literal moth! -- and the common misconceptions about the story. On the way, also learn about Grace Hopper and about the creation of some of the first computers.
Goals and Gains:- Learn about Grace Hopper, an important historical figure in CS
- Connecting with CS history
- Not all stories are as true as they seem!
- Seeing BUGS in the "real world" -- something that even pros deal with
- Introduce Grace Hopper: computer scientist of the 40's, worked on some of the first computers -- Harvard Mark I and II.
- Tell the Grace-Hopper-is-the-First-Debugger myth:
- Grace Hopper was trying to find the cause of a problem in the Harvard Mark II. She found a moth in the circuits! This is why we call it debugging.
- Clarify the detais of what really happened:
- Grace Hopper wasn't working on the Mark II when this happened (as should would tell everyone!)
- The term "bug" int this sense had been used in engineering for a long time -- Even Thomas Edison used it!
- Important Epilogue: This doesn't lessen Grace Hopper's importance! She still:
- Wrote some of the first glossaries and computer science texts, popularizing the term "bug"
- Invented one of the first programming languages: COBOL
- Co-create the Mark I and II: paving the way for all computers to come
- Believed and taught a similar philosophy that MetaCoders holds: Coding is Language, to be a good at coding (or math, or engineering) you must also be a good communicator
Grace Hopper was one of the most famous early computer scientists, a pioneer in our field, and undeniably a mathematical and linguistic genius. Among her many accomplishments, she is often credited for the first case of literal "debugging". The myth (which isn't true) often gets told as follows:
One day in 1946, Grace Hopper realized that the Harvard Mark II computer (shown in pictures below) was malfunctioning. After checking the usual sources of errors and finding nothing, she began to open up panels of her giant computer.
Eventually, she found -- deep in the wires -- a dead moth. She plucked it out and taped the moth on a log book, writing beneath it: "First actual case of bug being found." The computer began to work again after that. Thus, Grace Hopper debugged the first computer. That log book now resides in the National Museum of American History.
The truth is that Grace Hopper wasn't actually there for that event in 1946, as she readily admitted -- although she had been instrumental in working on that computer. And it was her team that found the moth. Also, the term "bug" had been used by Thomas Edison in a similar way long before the Mark II computer was even built. It was quite common for inventors to remove bugs from electrical hardware.
Still, it was one of Grace Hopper's favorite stories. If not for her, we might not otherwise have known about it. A prolific writer, she wrote some of the earliest texts on computing and some of the earliest glossaries of computing terms (which, of course, included the words "bug" and "debugging" ever since that incident with the moth). She invented one of the earliest computer languages -- COBOL -- which is still in use today. "It's much easier for most people to write an English statement than it is to use symbols. So I decided data processors ought to be able to write their programs in English, and the computers would translate them into machine code," she said. COBOL was the first language designed to allow programmers to write in what felt like English -- thus enabling them to express thoughts as programs that they would not otherwise have been able to express.
She was a fierce advocate for the power learning to write well, in all mediums, not just in code and symbols: When she was a college math professor, she would often have her math students write essay. "[It is] no use trying to learn math unless [you can] communicate it with other people," she would argue. She applied that same philsophy to her work as a hardware and software engineer. She was a fantastic engineer with top-notch communication skills -- a crisp and clear writing style that allowed her to not just be a genuis, but to help others become geniuses.
So, although she didn't physically pull a moth out of the Mark II computer, she did help design the computer that the moth came out of. During her years of designing computers and programming languages, she reached the rank of Rear Admiral in the Navy. When she died, she received full military honors.
One day in 1946, Grace Hopper realized that the Harvard Mark II computer (shown in pictures below) was malfunctioning. After checking the usual sources of errors and finding nothing, she began to open up panels of her giant computer.
Eventually, she found -- deep in the wires -- a dead moth. She plucked it out and taped the moth on a log book, writing beneath it: "First actual case of bug being found." The computer began to work again after that. Thus, Grace Hopper debugged the first computer. That log book now resides in the National Museum of American History.
The truth is that Grace Hopper wasn't actually there for that event in 1946, as she readily admitted -- although she had been instrumental in working on that computer. And it was her team that found the moth. Also, the term "bug" had been used by Thomas Edison in a similar way long before the Mark II computer was even built. It was quite common for inventors to remove bugs from electrical hardware.
Still, it was one of Grace Hopper's favorite stories. If not for her, we might not otherwise have known about it. A prolific writer, she wrote some of the earliest texts on computing and some of the earliest glossaries of computing terms (which, of course, included the words "bug" and "debugging" ever since that incident with the moth). She invented one of the earliest computer languages -- COBOL -- which is still in use today. "It's much easier for most people to write an English statement than it is to use symbols. So I decided data processors ought to be able to write their programs in English, and the computers would translate them into machine code," she said. COBOL was the first language designed to allow programmers to write in what felt like English -- thus enabling them to express thoughts as programs that they would not otherwise have been able to express.
She was a fierce advocate for the power learning to write well, in all mediums, not just in code and symbols: When she was a college math professor, she would often have her math students write essay. "[It is] no use trying to learn math unless [you can] communicate it with other people," she would argue. She applied that same philsophy to her work as a hardware and software engineer. She was a fantastic engineer with top-notch communication skills -- a crisp and clear writing style that allowed her to not just be a genuis, but to help others become geniuses.
So, although she didn't physically pull a moth out of the Mark II computer, she did help design the computer that the moth came out of. During her years of designing computers and programming languages, she reached the rank of Rear Admiral in the Navy. When she died, she received full military honors.
- Who was Grace Hopper?
- Which branch of the military was Grace Hopper in?
- What is the name of the computer that the moth was found in?
Was the moth found before or after World War II?
WWII ended in 1945. The bug was found in 1946.
- Why did Grace Hopper make her math students write essays?
- In what way can becoming a better writer make you better at math?
- In what way can becoming a better writer make you better at coding?
- In what way can becoming better at coding make you better at writing?
- In what way can becoming better at coding make you better at math?
Tips & Tricks:
- Pull up picture of the Harvard Mark I (not many photos/info about Mark II), and the infamous moth.
- Cool facts about the Harvard Mark I and II:
- Mark II was completed in 1944
- Mark I weighed over 9,000 lbs and was 51 ft long, 8 ft tall and 2 ft wide.
- Mark I had 60 sets of 24 switches each to manually enter data.
- Mark I took 6 seconds to complete a multiplication task.
- Mark II was completed in 1947
- Mark II weighed 46,000 lbs!
- Mark II took less than a second to complete a multiplication task.
Reverse Translation
~10min
Reverse Translation
Starting with just an implementation, the Team translates it back to a specification with as much detail as possible.
Follow up this activity with typing up and running the code. Hide the code and only show the description that the Players came up with for an added challenge!
How to Play:
Reverse Translation
Starting with just an implementation, the Team translates it back to a specification with as much detail as possible.
Need:
- code card
How to Play:
Break up larger Teams into smaller groups for this Game so that all members of the Team have a chance to see the code card and voice their opinions.
- Coach gives the Team a code card, implementation-side up
- Without flipping the card, Team translates the code into english, describing what the code will do when run
- Coach guides the Players to give as much detail as possible
Tips & Tricks:
- Optional final step: Team tests their hypothesis by typing up the code and running it.
- If a projector is available, project the code where everyone can see it.
- Add a competitive element by splitting the larger Team into two or more Teams, showing all Teams the same code (pass around the card, write on a whiteboard, project from computer), set the timer for discussion, and then have each team present their case. Whomever is most detailed in their translation gets a point.
- Enforce equal input within a Team by having Players raise hands and wait to be called on or take turns around a circle sharing details about the code.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
More on to Code is Language: on-computer games only ~60 minutes
A classmap on coding as a language, with all on-computer game modes.
Review
~5min
Review
What do you remember about Coding as a Language?
Try It First
~20min
Try It First
Players try to figure out how to code a new specification with no hints before getting hints/the answer.
Need:
- computers - 1 per Player
- code card
- whiteboard/projector
- timer
How to Play:
- Coach announces the specification
- Coach sets timer for 1-5 minutes
- Players attempt to figure out how to code the specification
- When timer goes off, Coach writes the implementation on whiteboard/projected screen
- Coach resets timer
- Players try the code as shown
Tips & Tricks:
- Great for introducing new material once Players are getting comfortable with the code structures. Many Players will need a lot of coaching, cheerleading, and "just give it a shot!" encouragement to try something they don't know the answer to!
- When showing the correct answer, ask the Team to help you. If any Players figured it out, have them tell you what to write.
- Variation: Over the allotted time, slowly fill in the code. This works well for Players who are getting stuck -- at least they can add something.
- For the full effect, do not give any answers until the first timer goes off. Offer support but ask Players to try things out, without giving them the answers.
Tell a Story with Words Changed
~15min
Tell a Story with Words Changed
Jimmy went on a *Bloop* Hunt
Disintegrating Code
~15min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
Intro to Inputs/Outputs: Intermediate ~60 minutes
A classmap covering depth 1 and 2 on inputs/outputs.
Coach Story
~5min
Coach Story
A chance to introduce yourself and some values of MetaCoders.
[Coach fills in: Your coach story][Coach fills in: Any discussion questions you wish to ask about your story]
The World Through Inputs and Outputs
~15min
The World Through Inputs and Outputs
Talk about 5 senses (input), and speaking/signing/writing/coding (outputs)Then expand that idea into: Cats/animalsHousesBottle/CupFridgeYour Room
Person-Bot (or Code the Coach/Kid)
~15min
Person-Bot (or Code the Coach/Kid)
Team works together to 'code' a Bot (the Coach or a Player) to achieve a Goal.
Need:
- no required supplies
How to Play:
- Coach sets the Goal (see Example Goals below)
- Coach picks a Bot -- often the Coach themselves for the first round
- Coach picks 1-3 Bot Coders
- Bot Coders work as a team to give clear, exact instructions to Bot to achieve the Goal
- Bot follows the instructions EXACTLY (see Example Instructions below)
- Follow up with additional rounds with new Bots and new Bot Coders
Example Goals:
- Get from Point A to B (ideal with some obstacles in the way!)
- Move the book from the table to the shelf
- Draw a smiley face on the white board
- Put on your sweatshirt
Example Clear, Executable Instructions:
- Take 3 steps forward
- Turn 1 quarter turn to your left
- Grab the sweatshirt with your right hand
Example UNCLEAR, Inexecutable Instructions:
- Turn around (Bot does a 360 spin, ends up exactly where they were)
- Go backwards (Bot walks backwards -- and keeps going!)
- Go to the shelf (Bot makes error sound or shrugs -- what is 'the shelf?')
- Put the sweatshirt over your head (Bot holds the sweatshirt up in the air, over their head)
Tips & Tricks:
- Players as Bots may need help following directions EXACTLY and not making assumptions or going out of their way to wrongly interpret a clear instruction!
- Variation: Have the Bot leave the room when the Goal is being determined, so they don't know the Goal.
- Variation: Have all Players be the Bot Coders. All must agree on an instruction and a Master Coder relays that to the Bot.
- Variation: Team works together to write down all their instructions at once, before the Bot reads and executes all the instructions in a row. Great for predictive thinking!
- Variation: Include a Bot error sound/response that the Bot uses when given an unclear instruction.
What Does This Do?
~20min
What Does This Do?
Players type up and run code, before explaining the result in detail.
Need:
- computers - 1 per Player
- code
- whiteboard/projector or alternative way to show Team the code
- timer
How to Play:
- Coach writes up/displays code
- Coach does NOT say what the code does
- Coach sets timer for 1-5 minutes
- Players type up the code and run it
- When timer goes off, Coach asks Players to share what they observed about the code
Tips & Tricks:
- Keep the experimentation phase "top secret" -- have Players be secretive about what they find until the timer goes off and you all share! This keeps faster Players from spoiling the game for slower typists.
- Varitation: Players discuss their hypotheses for what the code will do prior to trying it.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
Intro to Bugs: Intermediate ~60 minutes
A classmap covering depth 1 and 2 on bugs.
Review
~5min
Review
What did we do last time?
Open Code Review
~10min
Open Code Review
Players have free time to review what they have learned so far. Works well as an opening warmup.
Need:
- computers - 1 per Player
- timer
How to Play:
- Coach sets timer for the duration of Mode
- Players have free time to code, reviewing what they have learned so far.
Tips & Tricks:
- This is not a time for Players to ask Coach how to do NEW things, but experienmentation should be welcome and encouraged.
- Perfect to give extra setup or prep time for Coach -- since Players should be able to do this game with minimal Coach intervention.
Be a Bug Hunter Fable
~15min
Be a Bug Hunter Fable
A Code of Awesomeness fable about two animals who have different strategies for dealing with bugs.
Mode Summary & Goals
Summary: Introduce the BE A BUG HUNTER Code to the Code of Awesomeness. Explore the values and ideas that this Code encompasses.
Goals and Gains:- Add a new Code to the Code of Awesomeness: Be a Bug Hunter!
- Introduce the concept of a bug/debugging in coding.
- Discuss contrasting attitudes when it comes to facing problems.
- Set up a classroom norm: solve your bugs!
- Relate the abstract concept (Be a Bug Hunter) to tangable actions and experiences through story.
- Prepare for the Code Of Awesomeness Motto Creation Game Mode
- There are two friends, Woodpecker and Ostrich, who each want to build the biggest house before summer.
- Sometimes there are termites in the wood that both animals use to build:
- Whenever Woodpecker finds a termite, she stops building her house to get rid of them.
- Whenever Ostrich finds a termite, he ignores them so he can spend all his time building.
- For a while, Ostrich's house is growing bigger, faster than Woodpecker's.
- But then, the termites eat away at Ostrich's house and he is spending more time fixing than building.
- Woodpecker's house keeps growing steadily.
- When summer comes, both houses are huge.
- But when the first summer storm comes, Ostrich's house collapses!
- Woodpecker helps Ostrich to build a termite-free house by teaching him to be a bug hunter!
Once, long ago, Woodpecker and Ostrich were competing to build the biggest house in the desert. They began in the Spring, knowing they would have to finish before the hot summer arrived, bringing wild winds and dangerous sandstorms.
Now, the branches they were building with occasionally housed a termite or two. Whenever Woodpecker found a termite while building her house, she stopped building to track it down. This meant her house was not growing as quickly as Ostrich's. Meanwhile Ostrich was scared that he would fall behind in the contest if he stopped too long, so he kept building and ignored the termites. His house grew quickly.
Woodpecker and Ostrich worked for many days. Both houses grew bigger and bigger, but everyone could see that Ostrich was winning the contest. But the Spring wasn't over yet, and the houses weren't finished...
Woodpecker and Ostrich worked for many, many days. Woodpecker's house was gaining on Ostrich's. Ostrich was spending less and less time building and more and more time fixing the crumbling walls the termites were eating. Meanwhile, Woodpecker's house grew at the the same, steady pace.
Finally, the hot summer arrived. Woodpecker and Ostrich stayed cool in their equally huge houses. When the first big sandstorm blew through the desert, Woodpecker hid in her house, safe from the biting wind. Ostrich's house, however, collapsed with the first strong gust of wind.
Woodpecker helped Ostrich out of the wreckage of his termite-ridden house and brought him to her own to shelter from the storm. Woodpecker insisted that Ostrich spend the summer in her house, and offered to help him rebuild his own, come Fall. She also offered to show Ostrich how to hunt down any termites they came across in the process.
Ostrich gratefully accepted the help, and over that summer and fall, learned how to be a bug hunter. His new home was strong, sturdy, and bug-free. The two houses stood for years and years to come.
Now, the branches they were building with occasionally housed a termite or two. Whenever Woodpecker found a termite while building her house, she stopped building to track it down. This meant her house was not growing as quickly as Ostrich's. Meanwhile Ostrich was scared that he would fall behind in the contest if he stopped too long, so he kept building and ignored the termites. His house grew quickly.
Woodpecker and Ostrich worked for many days. Both houses grew bigger and bigger, but everyone could see that Ostrich was winning the contest. But the Spring wasn't over yet, and the houses weren't finished...
Woodpecker and Ostrich worked for many, many days. Woodpecker's house was gaining on Ostrich's. Ostrich was spending less and less time building and more and more time fixing the crumbling walls the termites were eating. Meanwhile, Woodpecker's house grew at the the same, steady pace.
Finally, the hot summer arrived. Woodpecker and Ostrich stayed cool in their equally huge houses. When the first big sandstorm blew through the desert, Woodpecker hid in her house, safe from the biting wind. Ostrich's house, however, collapsed with the first strong gust of wind.
Woodpecker helped Ostrich out of the wreckage of his termite-ridden house and brought him to her own to shelter from the storm. Woodpecker insisted that Ostrich spend the summer in her house, and offered to help him rebuild his own, come Fall. She also offered to show Ostrich how to hunt down any termites they came across in the process.
Ostrich gratefully accepted the help, and over that summer and fall, learned how to be a bug hunter. His new home was strong, sturdy, and bug-free. The two houses stood for years and years to come.
- How did Woodpecker and Ostrich approach the same problem differently?
- Which animal had the better strategy? Why?
- How does this story relate to coding?
- What specific coding habits could you adopt to code more like the Woodpecker?
- What specific coding habits could you get rid of to code less like the Ostrich?
- Why did Woodpecker help Ostrich?
- How can we help each other be more like Woodpecker?
Tips & Tricks:
- Before you start, you can let the students pick the characters. Use these characteristics as guides:
- (Woodpecker): practical and level-headed.
- (Ostrich): impulsive and anxious
- For younger students, physically indicate how the houses grow throughout the story: ex. 'Woodpeckers house was THIS tall' and holding your hand at knee-height.
Disintegrating Code
~15min
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Build a Bug Workshop
~10min
Build a Bug Workshop
Players purposely break and debug code in this partnered game.
Need:
- computers - 1 per Player
How to Play:
Set Up: Each Player needs complete, working code on their computer to start this game. Either tack it on to a game like Disintegrating Code, or preface the game by typing up code from reference, specification, or each Player's own imagination! Just be sure all code works before starting this game.
- Players pair up
- Players swap computers, each with complete working code
- Players put a bug in their partner's code -- causing an error
- Players swap back computers and debug their now-broken code
Tips & Tricks:
- Players can swap seats instead of computers to prevent dropping of computers.
- For some friendly competition, turn the game into a race: who can debug their code faster?
- Start this game with a discussion about the bugs they have come across so far -- spelling errors, missing paretheses, wrong keywords -- to spark creativity about the kind of errors to plant in their partner's code.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:what we all did and learned today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
Intro to Code is Language: Intermediate ~60 minutes
A classmap introducing dept 1 and 2 of coding as a language.
Review
~5min
Review
What did we do last time?
Open Code Review
~10min
Open Code Review
Players have free time to review what they have learned so far. Works well as an opening warmup.
Need:
- computers - 1 per Player
- timer
How to Play:
- Coach sets timer for the duration of Mode
- Players have free time to code, reviewing what they have learned so far.
Tips & Tricks:
- This is not a time for Players to ask Coach how to do NEW things, but experienmentation should be welcome and encouraged.
- Perfect to give extra setup or prep time for Coach -- since Players should be able to do this game with minimal Coach intervention.
Coach tells story and leads discussion about language
~15min
Coach tells story and leads discussion about language
Coding is a language to communicate with computers.
Person-Bot: Define Shapes and Sizes
~15min
Person-Bot: Define Shapes and Sizes
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Need:
- no required supplies
How to Play:
- Coach introduces the following operations and what they mean:
- Input: "Draw a Circle" and holds up hands to indicate size
- Output: Bot draws a circle of the indicated size
- Input: "Draw a Square" and holds up hands to indicate size
- Output: Bot draws a square of the indicated size
- Input: "Draw a Triangle" and holds up hands to indicate size
- Output: Bot draws a triangle of the indicated size
- Input: "Move pen [Right/Left/Up/Down]" and holds up hands to indicate distance
- Output: Bot moves pen in the indicated direction in the indicated distance
- Coach shows examples
- Coach picks a Bot -- often the Coach themselves for the first round
- Team codes the Bot to achieve the following goal(s), using only the defined operations:
- Draw a tree
- Draw a house
- Draw a cat
Draw this shape
Tips & Tricks:
- Player-Bots may need help only following the exact defined operations -- not using their "human brain" to automatically assume what the Team means or try to make it harder on the Team!
- If the Team is having trouble communicating 1 operation at a time, designate a Master Coder responsible for relaying the Team's instructions (not just their own!) to the Bot. Bot must only listen to the Master Coder.
- Be sure to switch out the Bot often.
- Variation: Pick two Bots and two Goals. Split into 2 Teams who code their bot (in parallel) to achieve the same or different goal(s).
- After a few rounds, work together to define new operations.
- Partner up to play this game -- give each pair paper and pen to try this together, after a couple example rounds all together.
- Send the Bot out of the room when the Goal is being chosen for an extra challenge/test of the skill of the Team.
Try It First
~10min
Try It First
Players try to figure out how to code a new specification with no hints before getting hints/the answer.
Need:
- computers - 1 per Player
- code card
- whiteboard/projector
- timer
How to Play:
- Coach announces the specification
- Coach sets timer for 1-5 minutes
- Players attempt to figure out how to code the specification
- When timer goes off, Coach writes the implementation on whiteboard/projected screen
- Coach resets timer
- Players try the code as shown
Tips & Tricks:
- Great for introducing new material once Players are getting comfortable with the code structures. Many Players will need a lot of coaching, cheerleading, and "just give it a shot!" encouragement to try something they don't know the answer to!
- When showing the correct answer, ask the Team to help you. If any Players figured it out, have them tell you what to write.
- Variation: Over the allotted time, slowly fill in the code. This works well for Players who are getting stuck -- at least they can add something.
- For the full effect, do not give any answers until the first timer goes off. Offer support but ask Players to try things out, without giving them the answers.
Meta Story: One Word
~5min
Meta Story: One Word
A speedy mini-reflection where each student sums up their experience in one word.
We all did a lot today! But I want you all to think of just one word that helps sum it all up. For example, my word is "Proud" (or [Coach fills in: any positive word for how you are feeling]).We'll go one at a time. [Coach fills in: name of student], what's your word?
Ruby's Awesome Class Launch Map (v3) ~60 minutes
A variation on the Class Launch Map by Coach Ruby
Coach Story
~5min
Coach Story
A chance to introduce yourself and some values of MetaCoders.
[Coach fills in: Your coach story][Coach fills in: Any discussion questions you wish to ask about your story]
Compass Name Game
~5min
Compass Name Game
A multi-level name game with speed and a technological flavor.
Need:
- no required supplies
How to Play:
Levels must be played in order.
- Players circle up around Coach
- Coach points to a Player in the circle
- That Player says their name and a fact of a given type (favorite computer activity, video game, food, what they did last weekend, etc)
- Repeat steps 2 and 3 until every Player has shared at least once, Coach speeding up/switchng up order to keep Players on their toes!
- Coach assigns a Player to be the Online Player
- Coach points to another Player
- Online Player says this Player's name and fact
- Repeat steps 2 and 3 several times
- Coach assigns a new Online Player
- Repeat steps 2 and 3 several times
- Repeat steps 5 and 6 multiple times
- Coach assigns an Online Player
- Coach points to two different Players, one with each hand
- Online Player says the name of the Player that Coach is pointing to with their left hand
- Online Player says the fact of the Player that Coach is pointing to with their right hand
- Repeat steps 2-4 several times before assigning a new Online Player
- Repeat steps 2-5 multiple times
Tips & Tricks:
- Additional level options:
- Designate a Player to take over the Coach's role as 'Pointer'.
- Designate two 'Online' students.
- Run an elimination round, where 'Online' students compete to stay in the circle.
- Have the students come up with new favorite things.
- Have the students mix up their positions in the circle.
- Run two circles at the same time. When students are eliminated from one, send them to the other.
Course Introduction
~5min
Course Introduction
Introduce the course concepts and goals: including language, gamification, and learning how to learn!
Tips & Tricks:
- You may also want to summarize the day's schedule so students know what to expect. This can be especially helpful if you have a few more things to do before getting on computers, since students can get stuck "waiting" for this and get impatient rather than focusing on the important stories/games in the meantime.
- In this class we will learn about:
- Coding
- Learning
- Code is a language, like English. The language we are learning is _______.
- (Include features of the language/what you will be learning)
- Like learning anything, there will be easy and hard parts. As we learn coding remember it’s like learning language - easy and hard but with lots of practice, we can become fluent and code like we speak -- effortlessly!
- You will earn badges as you learn in this class!
- (Introduce other gamification elements such as: game jam, dollars, market, etc.)
As with all MetaCoders classes, we're here to get better at two things:
In order to practice either one of those, we need a language to learn. That way, we can learn that language -- and (more importantly) we can learn how to learn languages.
In this class, we're going to be using a language named [Coach fills in: #lang _______]. I've been learning this language myself, and I want to tell you about a few of its interesting features.
[Coach fills in: Mention one or two features of the language.]
As with any language, there are easy things about it. And there are hard things about it. But we're going to work together as a class to find things that are just right -- not to easy, and not too hard. That way we can increase our brains' abilities to read and write in that new language.
Lastly, this class is going to involve challenging ourselves with various games. For some of those games, I'll be giving out rewards and prizes!
[Coach fills in: Any additional information about your intended gamification in this class.]
Also, the class as a whole is a kind of like a game -- because you'll be getting badges every few weeks just for showing up and working hard. Remember that 100% of winning is showing up.
- Coding
- Learning
In order to practice either one of those, we need a language to learn. That way, we can learn that language -- and (more importantly) we can learn how to learn languages.
In this class, we're going to be using a language named [Coach fills in: #lang _______]. I've been learning this language myself, and I want to tell you about a few of its interesting features.
[Coach fills in: Mention one or two features of the language.]
As with any language, there are easy things about it. And there are hard things about it. But we're going to work together as a class to find things that are just right -- not to easy, and not too hard. That way we can increase our brains' abilities to read and write in that new language.
- Who has learned a foreign language before?
- Who can tell me some good strategies for learning a new language?
Which part of our brain do we need to grow to increase our ability to understand new languages?
Left hemisphere (for most people) -- specifically areas like Broca's area and Wernike's area.
Lastly, this class is going to involve challenging ourselves with various games. For some of those games, I'll be giving out rewards and prizes!
[Coach fills in: Any additional information about your intended gamification in this class.]
Also, the class as a whole is a kind of like a game -- because you'll be getting badges every few weeks just for showing up and working hard. Remember that 100% of winning is showing up.
- Getting prizes is cool -- but what is the larger purpose of those prizes?
- Why is it important to stay motivated over a long period of time when learning new languages?
- If you train your brain to learn languages, how will that help you as a coder?
- Who has learned a foreign language before?
- Who can tell me some good strategies for learning a new language?
Which part of our brain do we need to grow to increase our ability to understand new languages?
Left hemisphere (for most people) -- specifically areas like Broca's area and Wernike's area.
- Getting prizes is cool -- but what is the larger purpose of those prizes?
- Why is it important to stay motivated over a long period of time when learning new languages?
- If you train your brain to learn languages, how will that help you as a coder?
Code of Awesomeness Fables
~15min
Code of Awesomeness Fables
A story comparision activity that introduces the Code of Awesomeness Codes with these fables. The Code of Awesomeness is a chance to discuss critical values while learning to code. It also (along with the Code of Awesomeness Game Modes) provides an opportunity to co-create call-and-response traditions within a group of students -- great for team-building and for forging a strong group identity.
Read the following stories and discuss:Mode Summary & Goals
Summary: Introduce the OVERCOME THE UNKNOWN Code to the Code of Awesomeness. Explore the values and ideas that this Code encompasses.
Goals and Gains:- Add a new Code to the Code of Awesomeness: Overcome the Unknown!
- Discuss the benefits of taking on new challenges.
- Learn about mindsets, world-views, attitudes and how they can change our life and behavior.
- Set up a classroom norm: sometimes we will do stuff we haven't done before!
- Relate the abstract concept (Overcome the Unknown) to tangable actions and experiences through story.
- Prepare for the Code Of Awesomeness Motto Creation Game Mode
- There are two fish, Trout and Catfish, who are the same except for the way they think and talk. For example:
- While Trout says: "I hate when the bigger fish laugh at me when I do coding. One day, I’ll be the best around."
- Catfish says: “I think I got better at coding today. If I keep it up, I’ll be the best around.”
- While Trout says: "I lost the coding competition, so I'm switching to jewelry-making. I hate losing."
- Catfish says: "I lost the coding competition, so I'm going to practice even harder for the next one."
- Both fish enter coding tournaments.
- Trout wins and laughs at all the smaller fish who lost.
- Catfish doesn't win, but talks to the other fish and learns what they did better than her.
- Both fish grow up and become the biggest fish in their pond
- Catfish decides to travel and learn more.
- Catfish competes with even bigger fish in bigger ponds. When she gets to be the biggest in the pond, she moves to an even bigger pond.
- Catfish grows into a gigantic fish.
- Meanwhile, Trout stays home and wins the same competition year after year. She laughs at the smaller fish.
- When Catfish comes home to see everyone, she is the biggest fish they have ever seen!
- Trout is upset, and she refuses to talk to Catfish at all.
- Trout stays in the small pond her whole life, one day losing to young fish. She retires from coding after that.
- Catfish travels the big ponds of the world, a medium-sized fish and one of the best fish coders ever.
Once upon a time, there were two small fish; Trout and Catfish. They both lived in one big pond -- at least it was a big pond for the two very small fish. Both Trout and Catfish were young and neither one of them was very good at things that all fishes do -- like coding, and skiing, and martial arts, and creative writing, and parachuting, and making jewelry, and eating smaller fish.
Although Trout and Catfish were best friends, there was one big difference between them. It wasn't their color. (Both were rainbow-colored.) It wasn't their dreams. (Both dreamed of becoming the biggest fishes in the pond.)
No, the difference was actually in the minds of the fish. You wouldn't be able to see the difference from the outside. But if you listened carefully to them talk, you might be able to hear it.
Trout would often say things like: "I hate when the bigger fish laugh at me when I do coding. One day, I'm going to be the best coder in the pond."
Catfish would often say things like: "I feel like I'm a tiny bit better at coding today than I was yesterday. If I keep this up, one day, I'll be the best coder in the pond."
Did you catch the difference? Let's listen again.
Trout once said: "I lost the coding competition, so I'm switching to jewelry-making because I'm better at that. I hate losing." (She did not, in fact, switch to jewelry-making.)
Catfish once said: "I lost the coding competition, so I'm going to practice even harder for the next one."
Did you catch the difference that time?
Time passed and both fish grew from tiny to medium-sized. The difference between their minds grew, too. One day at their weekly brunch, Trout and Catfish discussed the coding tournaments they had competed in over the last week:
"Yesterday, I beat a bunch of little minnows in the coding competition and laughed at them." Said Trout. "Small fish are so basic."
"Hmm." Catfish said. "Well, today, I lost my coding tournament. But it was a tough competition -- against some of the best coders in the entire pond."
"How many trophies do you have?" Trout asked. "I have six trophies!"
"I don't remember," Catfish said. "Not many. I don't go to tournaments for trophies."
Trout sighed -- sometimes Catfish was very odd.
More time passed and now both Trout and Catfish had grown to be the biggest in the whole pond -- even bigger than the turtles! That difference inside of them had also grown so large that anyone who knew them could hear it in the way they talked:
One day, after comparing herself to every other fish in the pond, Trout annouced: "We finally made it! We're officially the biggest fish in the whole pond. No one can beat me at coding."
Catfish said, "No one?"
"I could beat you if I wanted to," Trout said, "but I don't want to make you look bad."
"I don't mind if you make me look bad." Catfish said.
"Look -- I'm just too busy to compete with you right now," said Trout. "Maybe tomorrow."
Catfish said, "Actually, I'm leaving today."
"Leaving? You're leaving the pond?" Trout said, surprised. "But what about our dream of becoming the biggest fish in the whole pond? We finally did it!"
"It's just..." said Catfish, "don't you ever wonder if there are bigger ponds out there?"
"No!" said Trout. "I've spent my entire life becoming the biggest fish here. If the next pond is even bigger, there might be even bigger fish!"
"That's kind of what I'm hoping for," said Catfish.
"What if they laugh at you?" asked Trout.
"I suppose that might happen," said Catfish. "I'll take the risk."
"What if they are better at coding than you?" said Trout.
"Exactly!" said Catfish. "I can become even better out there than I can in here."
Trout humphed and swished away in a swarm of bubbles, saying over her shoulder, "Fine! With you gone, I'll finally be the biggest fish of all!"
Later that day, Catfish bought plane tickets to a larger pond -- it was ten times larger, filled with gigantic fish. When Catfish arrived in the new pond -- those gigantic fish did sometimes laugh at her. And the gigantic fish did code faster and better than her -- at least at first.
But slowly, Catfish grew, and kept entering coding tournaments, and the day that she became the biggest fish in that pond -- can you guess what she did? She bought plane tickets to a new pond -- one twenty times bigger than her home pond, filled with enormous fish!
Once again, Catfish was just one of the smaller fish, and at first Catfish lost every coding tournament. But Catfish knew what she was doing. For years, she moved from pond to pond, always knowing when to go -- once she had become the biggest in the old pond.
Many years later, Catfish decided to visit her home pond again. When she swam off the plane into that tiny pond, all of the other fishes' mouths dropped open. They had never in their entire lives dreamed that a fish could ever get that big.
Trout pushed her way through the shocked crowd to the front, until she was nose to (much larger) nose with Catfish.
"What are you doing back here?" Trout snapped.
"That's no way to treat an old friend," said Catfish.
Trout humphed and swam away, saying over her shoulder, "Go back to your big ponds and leave me alone."
It's always sad when two former friends' have such different mindsets that they cannot get along. Trout stuck to her small pond, entering the same small tournaments and winning the small trophies over and over again. She retired from tournaments early, the first time a young minnow beat her at a coding tournament.
Catfish, on the other hand, grew to be a medium-sized fish in some of the biggest ponds in the whole world. She went on to become one of the most famous fish coders of all time! She traveled all over, competing in the biggest coding tournaments -- sometimes winning and sometimes losing, but always learning.
Although Trout and Catfish were best friends, there was one big difference between them. It wasn't their color. (Both were rainbow-colored.) It wasn't their dreams. (Both dreamed of becoming the biggest fishes in the pond.)
No, the difference was actually in the minds of the fish. You wouldn't be able to see the difference from the outside. But if you listened carefully to them talk, you might be able to hear it.
Trout would often say things like: "I hate when the bigger fish laugh at me when I do coding. One day, I'm going to be the best coder in the pond."
Catfish would often say things like: "I feel like I'm a tiny bit better at coding today than I was yesterday. If I keep this up, one day, I'll be the best coder in the pond."
Did you catch the difference? Let's listen again.
Trout once said: "I lost the coding competition, so I'm switching to jewelry-making because I'm better at that. I hate losing." (She did not, in fact, switch to jewelry-making.)
Catfish once said: "I lost the coding competition, so I'm going to practice even harder for the next one."
Did you catch the difference that time?
Time passed and both fish grew from tiny to medium-sized. The difference between their minds grew, too. One day at their weekly brunch, Trout and Catfish discussed the coding tournaments they had competed in over the last week:
"Yesterday, I beat a bunch of little minnows in the coding competition and laughed at them." Said Trout. "Small fish are so basic."
"Hmm." Catfish said. "Well, today, I lost my coding tournament. But it was a tough competition -- against some of the best coders in the entire pond."
"How many trophies do you have?" Trout asked. "I have six trophies!"
"I don't remember," Catfish said. "Not many. I don't go to tournaments for trophies."
Trout sighed -- sometimes Catfish was very odd.
More time passed and now both Trout and Catfish had grown to be the biggest in the whole pond -- even bigger than the turtles! That difference inside of them had also grown so large that anyone who knew them could hear it in the way they talked:
One day, after comparing herself to every other fish in the pond, Trout annouced: "We finally made it! We're officially the biggest fish in the whole pond. No one can beat me at coding."
Catfish said, "No one?"
"I could beat you if I wanted to," Trout said, "but I don't want to make you look bad."
"I don't mind if you make me look bad." Catfish said.
"Look -- I'm just too busy to compete with you right now," said Trout. "Maybe tomorrow."
Catfish said, "Actually, I'm leaving today."
"Leaving? You're leaving the pond?" Trout said, surprised. "But what about our dream of becoming the biggest fish in the whole pond? We finally did it!"
"It's just..." said Catfish, "don't you ever wonder if there are bigger ponds out there?"
"No!" said Trout. "I've spent my entire life becoming the biggest fish here. If the next pond is even bigger, there might be even bigger fish!"
"That's kind of what I'm hoping for," said Catfish.
"What if they laugh at you?" asked Trout.
"I suppose that might happen," said Catfish. "I'll take the risk."
"What if they are better at coding than you?" said Trout.
"Exactly!" said Catfish. "I can become even better out there than I can in here."
Trout humphed and swished away in a swarm of bubbles, saying over her shoulder, "Fine! With you gone, I'll finally be the biggest fish of all!"
Later that day, Catfish bought plane tickets to a larger pond -- it was ten times larger, filled with gigantic fish. When Catfish arrived in the new pond -- those gigantic fish did sometimes laugh at her. And the gigantic fish did code faster and better than her -- at least at first.
But slowly, Catfish grew, and kept entering coding tournaments, and the day that she became the biggest fish in that pond -- can you guess what she did? She bought plane tickets to a new pond -- one twenty times bigger than her home pond, filled with enormous fish!
Once again, Catfish was just one of the smaller fish, and at first Catfish lost every coding tournament. But Catfish knew what she was doing. For years, she moved from pond to pond, always knowing when to go -- once she had become the biggest in the old pond.
Many years later, Catfish decided to visit her home pond again. When she swam off the plane into that tiny pond, all of the other fishes' mouths dropped open. They had never in their entire lives dreamed that a fish could ever get that big.
Trout pushed her way through the shocked crowd to the front, until she was nose to (much larger) nose with Catfish.
"What are you doing back here?" Trout snapped.
"That's no way to treat an old friend," said Catfish.
Trout humphed and swam away, saying over her shoulder, "Go back to your big ponds and leave me alone."
It's always sad when two former friends' have such different mindsets that they cannot get along. Trout stuck to her small pond, entering the same small tournaments and winning the small trophies over and over again. She retired from tournaments early, the first time a young minnow beat her at a coding tournament.
Catfish, on the other hand, grew to be a medium-sized fish in some of the biggest ponds in the whole world. She went on to become one of the most famous fish coders of all time! She traveled all over, competing in the biggest coding tournaments -- sometimes winning and sometimes losing, but always learning.
- Which fish had a better mindset?
- What adjectives would you use to describe Trout's mindset versus Catfish?
- Which fish had a 'growth mindset' and which had a 'fixed mindset'?
- In what ways are you like Trout?
- In what ways are you like Catfish?
- How can we help each other be more like Catfish and less like Trout?
- What could Catfish have said to Trout to convince her to think differently?
- How can you tell when someone has a mindset that's more like Trout than Catfish?
Tips & Tricks:
- For younger audiences, use a whiteboard to track the size and journeys of the two fish.
- Yes, it is ridiculous that fish might code. The authors know it, you know it, the audience knows it. Use the ridiculousness to your advantage!
- Don't forget to engage with questions -- at the end and throughout!
Mode Summary & Goals
Summary: Introduce the BE A BUG HUNTER Code to the Code of Awesomeness. Explore the values and ideas that this Code encompasses.
Goals and Gains:- Add a new Code to the Code of Awesomeness: Be a Bug Hunter!
- Introduce the concept of a bug/debugging in coding.
- Discuss contrasting attitudes when it comes to facing problems.
- Set up a classroom norm: solve your bugs!
- Relate the abstract concept (Be a Bug Hunter) to tangable actions and experiences through story.
- Prepare for the Code Of Awesomeness Motto Creation Game Mode
- There are two friends, Woodpecker and Ostrich, who each want to build the biggest house before summer.
- Sometimes there are termites in the wood that both animals use to build:
- Whenever Woodpecker finds a termite, she stops building her house to get rid of them.
- Whenever Ostrich finds a termite, he ignores them so he can spend all his time building.
- For a while, Ostrich's house is growing bigger, faster than Woodpecker's.
- But then, the termites eat away at Ostrich's house and he is spending more time fixing than building.
- Woodpecker's house keeps growing steadily.
- When summer comes, both houses are huge.
- But when the first summer storm comes, Ostrich's house collapses!
- Woodpecker helps Ostrich to build a termite-free house by teaching him to be a bug hunter!
Once, long ago, Woodpecker and Ostrich were competing to build the biggest house in the desert. They began in the Spring, knowing they would have to finish before the hot summer arrived, bringing wild winds and dangerous sandstorms.
Now, the branches they were building with occasionally housed a termite or two. Whenever Woodpecker found a termite while building her house, she stopped building to track it down. This meant her house was not growing as quickly as Ostrich's. Meanwhile Ostrich was scared that he would fall behind in the contest if he stopped too long, so he kept building and ignored the termites. His house grew quickly.
Woodpecker and Ostrich worked for many days. Both houses grew bigger and bigger, but everyone could see that Ostrich was winning the contest. But the Spring wasn't over yet, and the houses weren't finished...
Woodpecker and Ostrich worked for many, many days. Woodpecker's house was gaining on Ostrich's. Ostrich was spending less and less time building and more and more time fixing the crumbling walls the termites were eating. Meanwhile, Woodpecker's house grew at the the same, steady pace.
Finally, the hot summer arrived. Woodpecker and Ostrich stayed cool in their equally huge houses. When the first big sandstorm blew through the desert, Woodpecker hid in her house, safe from the biting wind. Ostrich's house, however, collapsed with the first strong gust of wind.
Woodpecker helped Ostrich out of the wreckage of his termite-ridden house and brought him to her own to shelter from the storm. Woodpecker insisted that Ostrich spend the summer in her house, and offered to help him rebuild his own, come Fall. She also offered to show Ostrich how to hunt down any termites they came across in the process.
Ostrich gratefully accepted the help, and over that summer and fall, learned how to be a bug hunter. His new home was strong, sturdy, and bug-free. The two houses stood for years and years to come.
Now, the branches they were building with occasionally housed a termite or two. Whenever Woodpecker found a termite while building her house, she stopped building to track it down. This meant her house was not growing as quickly as Ostrich's. Meanwhile Ostrich was scared that he would fall behind in the contest if he stopped too long, so he kept building and ignored the termites. His house grew quickly.
Woodpecker and Ostrich worked for many days. Both houses grew bigger and bigger, but everyone could see that Ostrich was winning the contest. But the Spring wasn't over yet, and the houses weren't finished...
Woodpecker and Ostrich worked for many, many days. Woodpecker's house was gaining on Ostrich's. Ostrich was spending less and less time building and more and more time fixing the crumbling walls the termites were eating. Meanwhile, Woodpecker's house grew at the the same, steady pace.
Finally, the hot summer arrived. Woodpecker and Ostrich stayed cool in their equally huge houses. When the first big sandstorm blew through the desert, Woodpecker hid in her house, safe from the biting wind. Ostrich's house, however, collapsed with the first strong gust of wind.
Woodpecker helped Ostrich out of the wreckage of his termite-ridden house and brought him to her own to shelter from the storm. Woodpecker insisted that Ostrich spend the summer in her house, and offered to help him rebuild his own, come Fall. She also offered to show Ostrich how to hunt down any termites they came across in the process.
Ostrich gratefully accepted the help, and over that summer and fall, learned how to be a bug hunter. His new home was strong, sturdy, and bug-free. The two houses stood for years and years to come.
- How did Woodpecker and Ostrich approach the same problem differently?
- Which animal had the better strategy? Why?
- How does this story relate to coding?
- What specific coding habits could you adopt to code more like the Woodpecker?
- What specific coding habits could you get rid of to code less like the Ostrich?
- Why did Woodpecker help Ostrich?
- How can we help each other be more like Woodpecker?
Tips & Tricks:
- Before you start, you can let the students pick the characters. Use these characteristics as guides:
- (Woodpecker): practical and level-headed.
- (Ostrich): impulsive and anxious
- For younger students, physically indicate how the houses grow throughout the story: ex. 'Woodpeckers house was THIS tall' and holding your hand at knee-height.
Mode Summary & Goals
Summary: Introduce the TEACH THE TEAM Code to the Code of Awesomeness. Explore the values and ideas that this Code encompasses.
Goals and Gains:- Add a new Code to the Code of Awesomeness: Teach the Team!
- Discuss the benefits of sharing your knowledge.
- Set up a classroom norm: help each other out!
- Relate the abstract concept (Teach the Team) to tangable actions and experiences through story.
- Prepare for the Code Of Awesomeness Motto Creation Game Mode
- There are two students, Bear and Wolf, who are the top of their class.
- They are both studying for a very challenging history test.
- All the other students keep interrupting their studying to ask them for help and advice!
- Bear gets annoyed and hides away where no one can find him. He studies alone.
- Wolf helps out the other students, and ends up with a whole study group.
- When the scores for the test are released, Bear is shocked to see that he is in the middle of the pack, with Wolf and several other students with better grades than him!
- Bear thinks there was some error in grading, asks the teacher.
- Pause here and ask students what they think happened!
- Teacher asks how Bear and Wolf studied. Bear and Wolf share their different tactics.
- Teacher explains -- by teaching others and sharing their ideas, Wolf and the rest of the students gained a deeper understanding Bear did, studying alone.
- Next time, Bear joins the study group and they all do better on the test.
Once, long ago, there was a school in the depths of the forest. All manner of forest creatures attended the Old Oak School, including two classmates: Bear and Wolf.
Bear and Wolf were the top of their class -- always getting A's in every class! But the upcoming History exam even had the two of them nervous! Ms. Badger was a very strict teacher and she had warned them many times that this test would be the toughest one so far. It had short answers, long answers, 2 essays and no multiple choice questions!
So Bear and Wolf gathered their notes, books and study guides and settled in their favorite study nook by the river to get to work. But it wasn't long until they had a vistor. You see, the other students were also extremely nervous about the test. And they knew Bear and Wolf were the best in the class. And it was well-known where the two liked to study...
"Ahem," Raccoon coughed quietly. Bear and Wolf looked up from their notes. "I was stuck on this one question on the study guide, the one about comparing the laws of the Red Squirrel and Grey Squirrel Clans of the early 10th century, and I hoped you might be able to help me..."
Raccoon looked back and forth between Bear and Wolf, hopefully. After a tense moment, Bear said:
"Listen, I have to study hard for this too. I don't have time to answer your questions today."
Raccoon looked pleadingly to Wolf.
"Well," Wolf said, "I think I have an extra minute. I needed a break anyhow."
Bear rolled his eyes as Wolf talked Raccoon through the question. Wolf is wasting his time! Bear thought to himself.
Raccoon left a little while later, thanking Wolf profusely for his help. Wolf shrugged, and turned back to his books.
But it wasn't too long until they had another vistor: Chipmunk. She couldn't remember anything about the signing of the Great River Otter Treaty! Once again, Bear refused to stop his studying. And once again, Wolf offered to help out.
After Chipmunk came Deer, then Owl and Hedgehog had some questions, then Beaver was in need of help, then Hare and Boar and Snake and Moose--
"ENOUGH!" Bear shouted. "How am I supposed to get anything done with all of you traipsing in here everytime you have a silly little question! I don't know about you, Wolf, but I am going to find somewhere with some peace and quiet!"
Bear stomped off into the forest. He stomped off to a cave, deep in the forest, holed up with his notes, books, and study guide, lit a candle and studied in silence for the next three days until the test.
Meanwhile, Wolf and Moose were left in the dust of Bear's departure.
"Well then." Moose declared. "As I was saying -- I just don't understand what Ms. Badger is asking here about the Era of the Redwoods! I don't have anything about any Red Woods in my notes... Only Brown and Green Woods!"
Wolf pulled some notes from his folder and began to explain. Shortly, they were joined again by Owl and Hedgehog, who overheard their discussion and were eager to hear Wolf's explaination. Then Hare and Chipmunk returned, with 2 more questions of their own, questions that Hedgehog had her own thoughts on.
Soon, their little group grew too big for the Study Nook by the river. Wolf and the other animals moved to a field nearby, where more animals joined them. Discussions sprung up all over the group as the animals shared questions, notes, thoughts and ideas. Wolf left his study guide behind, wandering through the large group, joining discussions and answering questions as needed. And so it continued for the three days leading up to the test.
The Big History Test came and went. The only thing now was to wait for Ms. Badger to finish grading! It seemed like ages until the day when she finally announced that she would be passing back their tests.
Bear was one of the first to get his test back (it was helpful being near the beginning of the alphabet!) and he held his breath as he looked for the final grade, in red ink --
B-?! Bear was disappointed, of course -- he rarely got anything lower than an A -- but he quickly reminded himself how difficult the test was. Bear was sure his B- still put him at the head of the class.
But then he started to hear the whispers from his classmates as they recieved their graded tests: excited whispers claiming C+'s, B-'s, even B's, B+'s! Wolf was at the top of the class with an A+!
Now this was unheard of! Wolf sometimes bested Bear, but Hedgehog? And Moose?! There must have been some kind of mistake!
"Excuse me, Ms. Badger!" Called Bear. "I think there might have been an error in my grading."
The whole class froze -- did Bear just tell Ms. Badger that she made a mistake?!
"Is that so?" Ms. Badger walked to Bear's desk and peered at his test. She flipped through the pages. She placed the test back on his desk. "The grading is correct."
"B-But," Bear protested, "how could that be?! Owl said he also got a B-. And so did Chipmunk! Moose said he got a B+. And Wolf got an A+?! That's impossible!"
"Perhaps they studied more effectively."
"I studied non-stop for three days! It would have been more if all the others did keep interrupting Wolf and I with their silly questions." Bear glared around the room. "But I finally manage to find some peace and quiet, reviewed all my notes at least two dozen times, wrote five practice essays, made a set of 50 flash cards with dates and names -- it just doesn't make sense! What could they have done that I didn't?"
"Well," Moose said, "I don't know about all that. We all kind of ended up studying -- together."
"Yeah, I had a question about the study guide, and I asked Wolf." Said Chipmunk. "And Hedgehog was there and we ended up discussing it for a while. Then Wolf helped us both understand the differences between the two Squirrel Skirmishes. Wolf really helped us all out."
Everyone looked to Wolf, who had gotten the best grade of the whole class.
"I didn't actually have any time to study." Wolf admitted. "I am surprised I did this well. Everyone had questions and I wanted to help, so I just ended up... doing that instead."
"That's why the rest of the class excelled." Ms. Badger said to Bear. "By sharing their notes and ideas, they gained more knowledge. Wolf did this the most, and he learned the most. By teaching what he knew, and listening to what others knew and thought, Wolf built a deeper understanding of the material."
Everyone looked at Wolf, again.
"I had no idea!" Wolf said. "But come to think of it, when I was explaining things to the others, I found new details I hadn't really noticed before. Because I had to be really clear, and often someone had a question I hadn't even thought of before."
"That is how I know so much about our forest history myself." Said Ms. Badger. "Teaching others helps you learn."
Some time later, Wolf and his classmates were studying for the upcoming math test. They were all in the field by the river, taking turns explaining different formulas and inventing word problems for each other. Everyone was listening to Hedgehog explain how to find the area of a triangle, when they had a very unexpected visitor.
"Hello, Bear." Said Wolf.
"Hi, everyone." Said Bear. "M-May I... Do you think... Can I join your study group?"
"Of course!" Wolf said.
Bear joined the group, and took his turn teaching the team shortly after. Later that week, Bear, Wolf and the rest of the class all aced the test!
Bear and Wolf were the top of their class -- always getting A's in every class! But the upcoming History exam even had the two of them nervous! Ms. Badger was a very strict teacher and she had warned them many times that this test would be the toughest one so far. It had short answers, long answers, 2 essays and no multiple choice questions!
So Bear and Wolf gathered their notes, books and study guides and settled in their favorite study nook by the river to get to work. But it wasn't long until they had a vistor. You see, the other students were also extremely nervous about the test. And they knew Bear and Wolf were the best in the class. And it was well-known where the two liked to study...
"Ahem," Raccoon coughed quietly. Bear and Wolf looked up from their notes. "I was stuck on this one question on the study guide, the one about comparing the laws of the Red Squirrel and Grey Squirrel Clans of the early 10th century, and I hoped you might be able to help me..."
Raccoon looked back and forth between Bear and Wolf, hopefully. After a tense moment, Bear said:
"Listen, I have to study hard for this too. I don't have time to answer your questions today."
Raccoon looked pleadingly to Wolf.
"Well," Wolf said, "I think I have an extra minute. I needed a break anyhow."
Bear rolled his eyes as Wolf talked Raccoon through the question. Wolf is wasting his time! Bear thought to himself.
Raccoon left a little while later, thanking Wolf profusely for his help. Wolf shrugged, and turned back to his books.
But it wasn't too long until they had another vistor: Chipmunk. She couldn't remember anything about the signing of the Great River Otter Treaty! Once again, Bear refused to stop his studying. And once again, Wolf offered to help out.
After Chipmunk came Deer, then Owl and Hedgehog had some questions, then Beaver was in need of help, then Hare and Boar and Snake and Moose--
"ENOUGH!" Bear shouted. "How am I supposed to get anything done with all of you traipsing in here everytime you have a silly little question! I don't know about you, Wolf, but I am going to find somewhere with some peace and quiet!"
Bear stomped off into the forest. He stomped off to a cave, deep in the forest, holed up with his notes, books, and study guide, lit a candle and studied in silence for the next three days until the test.
Meanwhile, Wolf and Moose were left in the dust of Bear's departure.
"Well then." Moose declared. "As I was saying -- I just don't understand what Ms. Badger is asking here about the Era of the Redwoods! I don't have anything about any Red Woods in my notes... Only Brown and Green Woods!"
Wolf pulled some notes from his folder and began to explain. Shortly, they were joined again by Owl and Hedgehog, who overheard their discussion and were eager to hear Wolf's explaination. Then Hare and Chipmunk returned, with 2 more questions of their own, questions that Hedgehog had her own thoughts on.
Soon, their little group grew too big for the Study Nook by the river. Wolf and the other animals moved to a field nearby, where more animals joined them. Discussions sprung up all over the group as the animals shared questions, notes, thoughts and ideas. Wolf left his study guide behind, wandering through the large group, joining discussions and answering questions as needed. And so it continued for the three days leading up to the test.
The Big History Test came and went. The only thing now was to wait for Ms. Badger to finish grading! It seemed like ages until the day when she finally announced that she would be passing back their tests.
Bear was one of the first to get his test back (it was helpful being near the beginning of the alphabet!) and he held his breath as he looked for the final grade, in red ink --
B-?! Bear was disappointed, of course -- he rarely got anything lower than an A -- but he quickly reminded himself how difficult the test was. Bear was sure his B- still put him at the head of the class.
But then he started to hear the whispers from his classmates as they recieved their graded tests: excited whispers claiming C+'s, B-'s, even B's, B+'s! Wolf was at the top of the class with an A+!
Now this was unheard of! Wolf sometimes bested Bear, but Hedgehog? And Moose?! There must have been some kind of mistake!
"Excuse me, Ms. Badger!" Called Bear. "I think there might have been an error in my grading."
The whole class froze -- did Bear just tell Ms. Badger that she made a mistake?!
"Is that so?" Ms. Badger walked to Bear's desk and peered at his test. She flipped through the pages. She placed the test back on his desk. "The grading is correct."
"B-But," Bear protested, "how could that be?! Owl said he also got a B-. And so did Chipmunk! Moose said he got a B+. And Wolf got an A+?! That's impossible!"
"Perhaps they studied more effectively."
"I studied non-stop for three days! It would have been more if all the others did keep interrupting Wolf and I with their silly questions." Bear glared around the room. "But I finally manage to find some peace and quiet, reviewed all my notes at least two dozen times, wrote five practice essays, made a set of 50 flash cards with dates and names -- it just doesn't make sense! What could they have done that I didn't?"
"Well," Moose said, "I don't know about all that. We all kind of ended up studying -- together."
"Yeah, I had a question about the study guide, and I asked Wolf." Said Chipmunk. "And Hedgehog was there and we ended up discussing it for a while. Then Wolf helped us both understand the differences between the two Squirrel Skirmishes. Wolf really helped us all out."
Everyone looked to Wolf, who had gotten the best grade of the whole class.
"I didn't actually have any time to study." Wolf admitted. "I am surprised I did this well. Everyone had questions and I wanted to help, so I just ended up... doing that instead."
"That's why the rest of the class excelled." Ms. Badger said to Bear. "By sharing their notes and ideas, they gained more knowledge. Wolf did this the most, and he learned the most. By teaching what he knew, and listening to what others knew and thought, Wolf built a deeper understanding of the material."
Everyone looked at Wolf, again.
"I had no idea!" Wolf said. "But come to think of it, when I was explaining things to the others, I found new details I hadn't really noticed before. Because I had to be really clear, and often someone had a question I hadn't even thought of before."
"That is how I know so much about our forest history myself." Said Ms. Badger. "Teaching others helps you learn."
Some time later, Wolf and his classmates were studying for the upcoming math test. They were all in the field by the river, taking turns explaining different formulas and inventing word problems for each other. Everyone was listening to Hedgehog explain how to find the area of a triangle, when they had a very unexpected visitor.
"Hello, Bear." Said Wolf.
"Hi, everyone." Said Bear. "M-May I... Do you think... Can I join your study group?"
"Of course!" Wolf said.
Bear joined the group, and took his turn teaching the team shortly after. Later that week, Bear, Wolf and the rest of the class all aced the test!
- What was Bear's studying strategy? Wolf's? The other animals'?
- Which animal had the better strategy? Why?
- Why did Wolf and many of the other animals do better on the test than Bear?
- How does this story relate to our class?
- What can we do in this class to be more like Wolf?
- How can we help each other learn? What 'helping' doesn't actually help our team learn?
- How do you like to work on homework/study for tests?
Tips & Tricks:
- Try pausing the story after revealing the grades and asking the students why Wolf and so many of the other animals did better than Bear.
- Before you start, you can let the students pick the characters. Use these characteristics as guides:
- (Bear): works alone, smart
- (Wolf): a team player, smart
What is an alegory?
An alegory is a story whose true meaning is encoded -- where each story part seems to mean one thing but actually means something different.
- What is each story an alegory for?
- Pick one story. Write down notes about that story on the board. Discuss which of those parts has a hidden meaning.
- Which of the stories might be an alegory for more than one thing? How so?
Code of Awesomeness Mottos
~10min
Code of Awesomeness Mottos
Customize the Code of Awesomeness by creating a unique Motto for one or multiple Codes.
Mode Summary & Goals
Summary: Foster a personal connection to the Code of Awesomeness by creating a unique motto or callback for each code.
Goals and Gains:- Personalize the lessons in a Code
- Create a shorthand for those connections through a simple phrase
- Practice teamwork, communication and compromise
Need:
- Optional: Whiteboard or other writing materials for notes
How to Play:
Make sure you have introduced whatever Code(s) you plan to create a Motto for with a story and discussion PRIOR to this game!
GOALS of Motto Creation:- Students co-create a linguistic tool that you can employ throughout the class, whenever you need to nudge students to apply certain values -- i.e. tenacity (rather than fear) in debugging, eagerness (rather than avoidance) when it comes to unknown concepts, and so on. This is also a great customized attention-getter.
- Students create a personal attachment to the Code of Awesomeness by creating a callback that engages them and their particular interests/sense of humor/personal story.
- Coach chooses a specific Code to create a Motto for
- Coach explains what a Code Motto is -- your team's very own response to a Code, that is fun, personal, and clarifies what that Code means to the team
- Coach introduces three options for a Motto (see Example Mottos below)
- Team votes, winning Motto is chosen by majority
- Practice Code/Motto Call/Response several times
- Repeat for additional Code(s) as desired
- Coach chooses a specific Code to create a Motto for
- Coach explains what a Code Motto is -- your team's very own response to a Code, that is fun, personal, and clarifies what that Code means to the team
- Coach introduces a couple Motto options (see Example Mottos below)
- Coach sets timer for 3 minutes
- Players brainstorm additional Motto options
- Coach or designated Player notes options
- Team votes on all options, winning Motto is chosen by majority
- Practice Code/Motto Call/Response several times
- Repeat for additional Code(s) as desired
Follow the same steps as Version Two, but break the Team into smaller groups prior to the brainstorming stage. Each group must decide on ONE option to present to the group. Entire Team votes on all options.
- Overcome the Unknown
- CHARGE!
- To infinity and beyond!
- To bodly go where no one's gone before!
- Into the UNKNOOOWNNN! (ala Frozen 2)
- Be a Bug Hunter
- SMUSH!
- Gotta catch 'em all!
- Bug found? Don't frown!
- Teach the Team
- Coders Assemble!
- Teamwork makes the dream work!
- Be a BOSS!
Tips & Tricks:
- Some Players will have their heart set on a Motto that is not chosen. Prepare to reassure Players that are disappointed -- "There were lots of cool options, I'm sorry yours didn't win" "It's about the whole team, not just what you want, and this was the one the team chose." "It's okay! There are more Codes and Mottos to come!"
- When leading a brainstorm, you may want to combine options or narrow down the list prior to voting, to simplify the process.
"Hello, World!"
~5min
"Hello, World!"
Why do we call the first code we write our Hello World program?
- The first program a coder writes in a new language is traditionally a Hello World program.
- This tradition comes from computer science textbooks written in the 1970's.
- A literal Hello World program prints out the words "Hello, World!" in the terminal.
- If possible, show some sample Hello World programs in various languages: samples listed below.
- Nowadays, a Hello World program can be more complex and powerful than it used to be, sometimes with even simplier code.
- Sometimes a Hello World program doesn't have anything to do with the words "Hello, World!" but it is still called that as the starting program in a new language.
In a moment we will be writing our first lines of code in our language. We call these lines of code our Hello World program because of a tradition that started way back in the 1970's (that's 50 years ago!). This piece of computer science history continues to influence coders today -- coders like you.
A computer science textbook published in 1978 entitled "The C Programming Language" included the following coding exercise:
Even before that, a textbook on the B programming language published in 1972 contained this example:
These textbooks were so influential -- specifically "The C Programming Language" -- that these very coding execises started a computer science tradition that is still observed today: when learning a new language, the first program a coder writes outputs the words "Hello, World."
Now, that code might look completely different from one computer language to another (after all, "Hello, world" can look and sound very different in human languages, right?). For example:
[Coach fills in: Project or otherwise display some of the eaxmples listed below.]
This "Hello, World" tradition is so embedded in coder-culture that even when the first program a coder writes has nothing to do with the words "Hello World" (maybe the code outputs an image, webpage, game, or even blinking LEDs in "the real world" instead of text on the screen!), a coder still might refer to this first program as their Hello World Program.
So, as coders and members of this huge community and culture of other coders, we are also going to call our first program our Hello World Program.
Are you ready to try it?
A computer science textbook published in 1978 entitled "The C Programming Language" included the following coding exercise:
main() {
printf(\"hello, world\\n\");
}Even before that, a textbook on the B programming language published in 1972 contained this example:
main( ) {
extern a, b, c;
putchar(a); putchar(b); putchar(c); putchar('!*n');
}
a 'hell';
b 'o, w';
c 'orld';These textbooks were so influential -- specifically "The C Programming Language" -- that these very coding execises started a computer science tradition that is still observed today: when learning a new language, the first program a coder writes outputs the words "Hello, World."
Now, that code might look completely different from one computer language to another (after all, "Hello, world" can look and sound very different in human languages, right?). For example:
[Coach fills in: Project or otherwise display some of the eaxmples listed below.]
This "Hello, World" tradition is so embedded in coder-culture that even when the first program a coder writes has nothing to do with the words "Hello World" (maybe the code outputs an image, webpage, game, or even blinking LEDs in "the real world" instead of text on the screen!), a coder still might refer to this first program as their Hello World Program.
So, as coders and members of this huge community and culture of other coders, we are also going to call our first program our Hello World Program.
Are you ready to try it?
Here are example Hello World programs in a few different languages:
- C (from the aforementioned 1970's textbook)
main() { printf(\"hello, world\\n\"); } - Racket
#lang racket "Hello, World!"
- Python
print "Hello World"
- Javascript
console.log("Hello World"); - Java
class HelloWorld { static public void main( String args[] ) { System.out.println( "Hello World!" ); } } - Ruby
puts "Hello, world!"
- Typescript
alert('Hello world!'); - Find more in this online collection.
Hello World Game
~10min
Hello World Game
The first coding game of most courses
Need:
- no required supplies
How to Play:
Run the game below, using the Hello World code card in your #lang
Disintegrating Code
Write the code multiple times, but with fewer and fewer hints each time.
Need:
- computers - 1 per Player
- whiteboard and markers
- timer
- code & translation
How to Play:
- Coach writes the entire code & translation on the whiteboard
- Players type up code as Coach does so
- Players test their code
- Players erase their code
- Coach erases 1-4 words from the code on the whiteboard (leaving parens, hyphens, other symbols)
- Timer set for roughly 1 min per line of code
- Players type up code, remembering what goes into the blanks
- Round ends when timer goes off
- Repeat steps 4-9 until no words are left on the board, only symbols
- Last round, everything but the translation is erased from the board
Tips & Tricks:
- For Ratchet langs: create shorthand drawing for the symbols with the players. For example -- rather than trying to draw the knight icon as it looks in game, ask the players "What can I draw that means 'knight' to us?" Players suggest horse, sword, helmet, shield. You decide on a shield -- and draw that everytime you need a knight.
- Replace erased words with blanks (______) for extra clarity.
- For new coders, start by erasing one word that appears two or more times in the code.
- Tag in an advanced student to play the Coach role!
- For Ratchet code, draw symbols and erase those one at a time.
Meta Story: Reflection
~5min
Meta Story: Reflection
A chance to practice those metacognition skills.
We're going to reflect for a few minutes on:One UNKNOWN we OVERCAME today.
Raise your hand if you have a reflection you want to share...
Tips & Tricks:
- Call on a few students.
- Add words of wisdom and encouragement where necessary.
Story Modes
Story Modes all have a few things in common.
Focal Points 1
All students share a common point of focus -- usually the coach, sometimes other students
Energy Level Normal
Students are engaged and interested -- but heartrates are low (compared to playing games). It's the kind of energy you experence when you watch an interesting show on television, or read an interesting book.
Comfort Zone Inside
Students are inside their comfort zone and able to pick up new information because they are relaxed and, ideally, in a state of narrative transportation.
Learning Gains Information and Values
During Story Mode, students may learn many things -- but the type of thing that stories teach is always the same. Stories communicate information and values.
The Story Mode database
activebadgescode of awesomenesscodingcommunicationcompetitivecompetitive optioncs-conceptculturaldatabasesdebuggingdiscussion basedfablefinal jamhigh schoolhistoricalinterface designintro new codelanguage gamesmemorizationmeta-classroommeta-cognitionmiddle schoolmulti-storyname gamepartnerspatternsreflectionreviewsimplesoftware engineeringteamworktrue storyunpluggedupper elementarywork in progressyoung elementaryyoung engineer
The first part of a three-part story, investigating all the different skills it takes to be the best coder we can be.
The second part of a three-part story, investigating all the different skills it takes to be the best coder we can be.
The third and final part of a three-part story, investigating all the different skills it takes to be the best coder we can be.
"Hello, World!"
historicalcultural
Why do we call the first code we write our Hello World program?
Why do we call the first code we write our Hello World program?
Ancient Badges
badges
A badge two thousand years ago. A chance to meditate on how symbols tell stories.
A badge two thousand years ago. A chance to meditate on how symbols tell stories.
Bugs in the brain
debugging
Many young coders (all the way through college and their first few years on the job) seem to think that bugs happen by magic. In reality, they happen because coders are not self-aware enough.
Many young coders (all the way through college and their first few years on the job) seem to think that bugs happen by magic. In reality, they happen because coders are not self-aware enough.
Coach Story
fable
A chance to introduce yourself and some values of MetaCoders.
A chance to introduce yourself and some values of MetaCoders.
Coding Badges
badges
A badge at MetaCoders. A chance to meditate on how even a MetaCoders badge can mean more than it means.
A badge at MetaCoders. A chance to meditate on how even a MetaCoders badge can mean more than it means.
Debugging the Pizza
cs-conceptyoung elementaryupper elementarymiddle schoolhigh school
Mia uses a debugging process to figure out why the pizza suddenly tastes like soap.
Mia uses a debugging process to figure out why the pizza suddenly tastes like soap.
Hacking All Around
cs-conceptdiscussion basedupper elementarymiddle schoolhigh school
An introductory, discussion-driven conversation about hacking.
An introductory, discussion-driven conversation about hacking.
Hello World History
historicalculturalmiddle schoolhigh school
About the phrase 'Hello World' in the computer science context, and why you'll see it again and again on your journey to become a coder.
About the phrase 'Hello World' in the computer science context, and why you'll see it again and again on your journey to become a coder.
How to capture a Boid
interface designsoftware engineeringtrue story
Jason captures several Boids and puts them on a website
Jason captures several Boids and puts them on a website
Meta Story: Deep Reflection
reflection
A deeper dive into the subjects, challenges, and skill-building that happened in today's class.
A deeper dive into the subjects, challenges, and skill-building that happened in today's class.
Meta Story: One Word
reflection
A speedy mini-reflection where each student sums up their experience in one word.
A speedy mini-reflection where each student sums up their experience in one word.
Meta Story: Reflection
reflection
A chance to practice those metacognition skills.
A chance to practice those metacognition skills.
Open Source Code: A Fable
fablecs-conceptwork in progress
A Code of Awesomeness fable about the value of teaching others, and the paradoxical pitfall of hording ones knowledge.
A Code of Awesomeness fable about the value of teaching others, and the paradoxical pitfall of hording ones knowledge.
Open Source Code: A Fable
A Code of Awesomeness fable about the value of teaching others, and the paradoxical pitfall of hording ones knowledge.fablecs-conceptwork in progress
Once upon a time, there were two young squirrels -- one brown, the other gray. They were friends, but the brown squirrel always seemed to do better in school -- earning more acorns than the gray squirrel.
Like all squirrels, whenever they learned something new from their teacher, they would write the information down on a tiny piece of paper. Then, like all squirrels, they would both sneak away after school to their secret places and bury their notes for later.
Before big tests, squirrel students always go to their secret places alone and dig up their notes to study (and nuts to snack on).
One day, the gray squirrel was sneaking off to its secret place, when suddenly it noticed another squirrel just up ahead, digging in the ground.
The gray squirrel snuck closer, realizing that it had stumbled upon the brown squirrel's secret hiding place. Peering through the trees, the gray squirrel saw the brown squirrel dig up note after note. It was studying furiously for the big test tomorrow.
When the brown squirrel was done studying it looked around to make sure it was alone, buried its notes, and scurried away. The gray squirrel crept out and walked to the patch of freshly packed dirt.
"Should I dig it up?" the gray squirrel thought to itself. "The brown squirrel always makes better grades than I do."
The gray squirrel begins to dig and finds a note from the coding class.
The squirrel recognizes it as a note about how to code a red circle. It buries that note, and digs farther to find another:
The squirrel recognizes it as a note about how to code two red circles -- one on top of the other. So it goes for several hours -- the gray squirrel digging up the brown squirrel's notes and studying them, and burying them again. Then it scurried away to its own secret place, where it continued studying its own notes.
The next day, all the squirrels took the coding test. The day after that, the coding teacher -- a giant beige squirrel -- posted all the grades on the big oak tree. The gray squirrel was pleased to see its name at the top of the list. The brown squirrel's name was just below -- on the second line. The giant beige teacher squirrel shook the gray squirrel's hand and gave it a bag containing two hundred acorns.
"Well done," said the teacher squirrel. "You've earned your bonus acorns."
But all that week, the gray squirrel couldn't sleep. It felt bad about what it had done. It wasn't exactly stealing -- but looking at someone's code without permission just felt wrong.
On the night before the next coding test, the gray squirrel crept out in the middle of the night and buried the two hundred acorns in the brown squirrel's secret place. Not only that, the gray squirrel also dug up all of its own notes, copied each one, and buried the new notes in the brown squirrel's secret place.
The next day, they took the test. And the day after that, the beige squirrel posted the results on the oak tree. The gray squirrel was certain that, this time, the brown squirrel would be at the top of the list. But no.
"Well done," said the teacher squirrel to the gray squirrel. "You've earned two hundred more acorns."
Now the gray squirrel felt even worse.
So it went for the rest of the month. The gray squirrel kept trying to make things right by burying more notes for the brown squirrel to find -- hoping that the brown squirrel would finally be at the top of the list. But the brown squirrel always came in second. And the gray squirrel always came in first -- earning more and more acorns.
One day, when the gray squirrel was burying more notes for the brown squirrel to find, it heard a rustling in the leaves overhead. Suddenly, the brown squirrel lept down and shouted, "Caught you! I knew someone had found my secret place. I kept finding notes that I didn't remember writing."
The gray squirrel confessed, telling the brown squirrel how it had dug up the notes once and then tried to make things right ever since. "I don't understand, though," said the gray squirrel. "I've been trying help you. But somehow I keep coming in first."
The brown squirrel thought for a moment. "You really want to make things right?"
The gray squirrel nodded.
"Then show me where your secret place is. And promise me you won't ever come back to mine."
The day before the next test, the gray squirrel went to its secret place to begin studying. As it dug, it began to find notes that it didn't remember hiding -- written in what looked suspiciously like the brown squirrel's handwritting.
Like:
That one showed how to display the colors of the rainbow -- like so:
There were many more -- all sorts of notes about things that the gray squirrel wouldn't otherwise have remembered.
The next day, the squirrels took the coding test. And the day after, the results were posted on the old oak tree. To the gray squirrel's surprise, the brown squirrel was at the top of the list.
The teacher squirrel shook the brown squirrel's hand and said, "It's been a while! But here are your two hundred acorns."
The gray squirrel could take it no more. "It doesn't make sense," it said, going on to explain to the teacher what had been happening over these last few months. "Whoever studies the most should make the best grade," said the gray squirrel. "But that only happened the first time. Since then, it's been backward. When I study my notes and the brown squirrel's, I come in second. When brown squirrel studies the my notes and its own, it comes in second."
The teacher squirrel nodded its head wisely. "Brains don't always work the way you might expect. Do you think I became the best coding teacher in the forest because I studied the most?"
The gray squirrel and the brown squirrel both noded.
"Nope," said the teacher. "I became the best coding teacher in the forest because I taught the most. Brains learn best when they teach. When you were burying notes for each other to find, you were teaching each other. That means you were studying. In fact, teaching is the best kind of studying: whoever teaches the most that learns the most."
From that day forward, the gray squirrel and the brown squirrel agreed to take turns teaching each other and their fellow squirrels -- sharing their notes instead of burying and hording them. The grades on the next test were so high that the teacher handed out two hundred bonus acorns to all the squirrels in the class.
Once upon a time, there were two young squirrels -- one brown, the other gray. They were friends, but the brown squirrel always seemed to do better in school -- earning more acorns than the gray squirrel.
Like all squirrels, whenever they learned something new from their teacher, they would write the information down on a tiny piece of paper. Then, like all squirrels, they would both sneak away after school to their secret places and bury their notes for later.
Before big tests, squirrel students always go to their secret places alone and dig up their notes to study (and nuts to snack on).
One day, the gray squirrel was sneaking off to its secret place, when suddenly it noticed another squirrel just up ahead, digging in the ground.
The gray squirrel snuck closer, realizing that it had stumbled upon the brown squirrel's secret hiding place. Peering through the trees, the gray squirrel saw the brown squirrel dig up note after note. It was studying furiously for the big test tomorrow.
When the brown squirrel was done studying it looked around to make sure it was alone, buried its notes, and scurried away. The gray squirrel crept out and walked to the patch of freshly packed dirt.
"Should I dig it up?" the gray squirrel thought to itself. "The brown squirrel always makes better grades than I do."
- Who owns the information in the notes -- the gray squirrel, the brown squirrel, the teacher squirrel, or someone else?
- Is it morally right for the gray squirrel to dig up another squirrel's notes?
- What if it just looks at the notes and puts it back?
The gray squirrel begins to dig and finds a note from the coding class.
#lang racket
(require 2htdp/image)
(circle 40 'solid 'red)The squirrel recognizes it as a note about how to code a red circle. It buries that note, and digs farther to find another:
#lang racket
(require 2htdp/image)
(above
(circle 40 'solid 'red)
(circle 40 'solid 'red))The squirrel recognizes it as a note about how to code two red circles -- one on top of the other. So it goes for several hours -- the gray squirrel digging up the brown squirrel's notes and studying them, and burying them again. Then it scurried away to its own secret place, where it continued studying its own notes.
The next day, all the squirrels took the coding test. The day after that, the coding teacher -- a giant beige squirrel -- posted all the grades on the big oak tree. The gray squirrel was pleased to see its name at the top of the list. The brown squirrel's name was just below -- on the second line. The giant beige teacher squirrel shook the gray squirrel's hand and gave it a bag containing two hundred acorns.
"Well done," said the teacher squirrel. "You've earned your bonus acorns."
But all that week, the gray squirrel couldn't sleep. It felt bad about what it had done. It wasn't exactly stealing -- but looking at someone's code without permission just felt wrong.
On the night before the next coding test, the gray squirrel crept out in the middle of the night and buried the two hundred acorns in the brown squirrel's secret place. Not only that, the gray squirrel also dug up all of its own notes, copied each one, and buried the new notes in the brown squirrel's secret place.
The next day, they took the test. And the day after that, the beige squirrel posted the results on the oak tree. The gray squirrel was certain that, this time, the brown squirrel would be at the top of the list. But no.
"Well done," said the teacher squirrel to the gray squirrel. "You've earned two hundred more acorns."
Now the gray squirrel felt even worse.
So it went for the rest of the month. The gray squirrel kept trying to make things right by burying more notes for the brown squirrel to find -- hoping that the brown squirrel would finally be at the top of the list. But the brown squirrel always came in second. And the gray squirrel always came in first -- earning more and more acorns.
One day, when the gray squirrel was burying more notes for the brown squirrel to find, it heard a rustling in the leaves overhead. Suddenly, the brown squirrel lept down and shouted, "Caught you! I knew someone had found my secret place. I kept finding notes that I didn't remember writing."
The gray squirrel confessed, telling the brown squirrel how it had dug up the notes once and then tried to make things right ever since. "I don't understand, though," said the gray squirrel. "I've been trying help you. But somehow I keep coming in first."
The brown squirrel thought for a moment. "You really want to make things right?"
The gray squirrel nodded.
"Then show me where your secret place is. And promise me you won't ever come back to mine."
The day before the next test, the gray squirrel went to its secret place to begin studying. As it dug, it began to find notes that it didn't remember hiding -- written in what looked suspiciously like the brown squirrel's handwritting.
Like:
#lang racket
(require 2htdp/image)
(beside
(square 30 'solid 'red)
(square 30 'solid 'orange)
(square 30 'solid 'yellow)
(square 30 'solid 'green)
(square 30 'solid 'blue)
(square 30 'solid 'purple))That one showed how to display the colors of the rainbow -- like so:
There were many more -- all sorts of notes about things that the gray squirrel wouldn't otherwise have remembered.
The next day, the squirrels took the coding test. And the day after, the results were posted on the old oak tree. To the gray squirrel's surprise, the brown squirrel was at the top of the list.
The teacher squirrel shook the brown squirrel's hand and said, "It's been a while! But here are your two hundred acorns."
The gray squirrel could take it no more. "It doesn't make sense," it said, going on to explain to the teacher what had been happening over these last few months. "Whoever studies the most should make the best grade," said the gray squirrel. "But that only happened the first time. Since then, it's been backward. When I study my notes and the brown squirrel's, I come in second. When brown squirrel studies the my notes and its own, it comes in second."
The teacher squirrel nodded its head wisely. "Brains don't always work the way you might expect. Do you think I became the best coding teacher in the forest because I studied the most?"
The gray squirrel and the brown squirrel both noded.
"Nope," said the teacher. "I became the best coding teacher in the forest because I taught the most. Brains learn best when they teach. When you were burying notes for each other to find, you were teaching each other. That means you were studying. In fact, teaching is the best kind of studying: whoever teaches the most that learns the most."
From that day forward, the gray squirrel and the brown squirrel agreed to take turns teaching each other and their fellow squirrels -- sharing their notes instead of burying and hording them. The grades on the next test were so high that the teacher handed out two hundred bonus acorns to all the squirrels in the class.
What is open source software?
Code that is written and given freely to other coders.
- Who can share an example of a time that teaching something helped them learn it?
- How does teaching others relate to teamwork?
- When you are learning a new language, why is it better to teach others than to learn on your own?
- Why do brains learn better when they teach?
- What are the benefits of open source software?
Purple Hearts
badges
A badge in the attic. A chance to meditate on a badge that symbolizes a major sacrifice.
A badge in the attic. A chance to meditate on a badge that symbolizes a major sacrifice.
The First Computer Bug...
historicaldebugging
The story of the moth in Mark II
The story of the moth in Mark II
The First Computer Bug...
The story of the moth in Mark IIhistoricaldebugging
Mode Summary & Goals
Summary: Learn the story of the First Computer bug -- a literal moth! -- and the common misconceptions about the story. On the way, also learn about Grace Hopper and about the creation of some of the first computers.
Goals and Gains:- Learn about Grace Hopper, an important historical figure in CS
- Connecting with CS history
- Not all stories are as true as they seem!
- Seeing BUGS in the "real world" -- something that even pros deal with
- Introduce Grace Hopper: computer scientist of the 40's, worked on some of the first computers -- Harvard Mark I and II.
- Tell the Grace-Hopper-is-the-First-Debugger myth:
- Grace Hopper was trying to find the cause of a problem in the Harvard Mark II. She found a moth in the circuits! This is why we call it debugging.
- Clarify the detais of what really happened:
- Grace Hopper wasn't working on the Mark II when this happened (as should would tell everyone!)
- The term "bug" int this sense had been used in engineering for a long time -- Even Thomas Edison used it!
- Important Epilogue: This doesn't lessen Grace Hopper's importance! She still:
- Wrote some of the first glossaries and computer science texts, popularizing the term "bug"
- Invented one of the first programming languages: COBOL
- Co-create the Mark I and II: paving the way for all computers to come
- Believed and taught a similar philosophy that MetaCoders holds: Coding is Language, to be a good at coding (or math, or engineering) you must also be a good communicator
Grace Hopper was one of the most famous early computer scientists, a pioneer in our field, and undeniably a mathematical and linguistic genius. Among her many accomplishments, she is often credited for the first case of literal "debugging". The myth (which isn't true) often gets told as follows:
One day in 1946, Grace Hopper realized that the Harvard Mark II computer (shown in pictures below) was malfunctioning. After checking the usual sources of errors and finding nothing, she began to open up panels of her giant computer.
Eventually, she found -- deep in the wires -- a dead moth. She plucked it out and taped the moth on a log book, writing beneath it: "First actual case of bug being found." The computer began to work again after that. Thus, Grace Hopper debugged the first computer. That log book now resides in the National Museum of American History.
The truth is that Grace Hopper wasn't actually there for that event in 1946, as she readily admitted -- although she had been instrumental in working on that computer. And it was her team that found the moth. Also, the term "bug" had been used by Thomas Edison in a similar way long before the Mark II computer was even built. It was quite common for inventors to remove bugs from electrical hardware.
Still, it was one of Grace Hopper's favorite stories. If not for her, we might not otherwise have known about it. A prolific writer, she wrote some of the earliest texts on computing and some of the earliest glossaries of computing terms (which, of course, included the words "bug" and "debugging" ever since that incident with the moth). She invented one of the earliest computer languages -- COBOL -- which is still in use today. "It's much easier for most people to write an English statement than it is to use symbols. So I decided data processors ought to be able to write their programs in English, and the computers would translate them into machine code," she said. COBOL was the first language designed to allow programmers to write in what felt like English -- thus enabling them to express thoughts as programs that they would not otherwise have been able to express.
She was a fierce advocate for the power learning to write well, in all mediums, not just in code and symbols: When she was a college math professor, she would often have her math students write essay. "[It is] no use trying to learn math unless [you can] communicate it with other people," she would argue. She applied that same philsophy to her work as a hardware and software engineer. She was a fantastic engineer with top-notch communication skills -- a crisp and clear writing style that allowed her to not just be a genuis, but to help others become geniuses.
So, although she didn't physically pull a moth out of the Mark II computer, she did help design the computer that the moth came out of. During her years of designing computers and programming languages, she reached the rank of Rear Admiral in the Navy. When she died, she received full military honors.
One day in 1946, Grace Hopper realized that the Harvard Mark II computer (shown in pictures below) was malfunctioning. After checking the usual sources of errors and finding nothing, she began to open up panels of her giant computer.
Eventually, she found -- deep in the wires -- a dead moth. She plucked it out and taped the moth on a log book, writing beneath it: "First actual case of bug being found." The computer began to work again after that. Thus, Grace Hopper debugged the first computer. That log book now resides in the National Museum of American History.
The truth is that Grace Hopper wasn't actually there for that event in 1946, as she readily admitted -- although she had been instrumental in working on that computer. And it was her team that found the moth. Also, the term "bug" had been used by Thomas Edison in a similar way long before the Mark II computer was even built. It was quite common for inventors to remove bugs from electrical hardware.
Still, it was one of Grace Hopper's favorite stories. If not for her, we might not otherwise have known about it. A prolific writer, she wrote some of the earliest texts on computing and some of the earliest glossaries of computing terms (which, of course, included the words "bug" and "debugging" ever since that incident with the moth). She invented one of the earliest computer languages -- COBOL -- which is still in use today. "It's much easier for most people to write an English statement than it is to use symbols. So I decided data processors ought to be able to write their programs in English, and the computers would translate them into machine code," she said. COBOL was the first language designed to allow programmers to write in what felt like English -- thus enabling them to express thoughts as programs that they would not otherwise have been able to express.
She was a fierce advocate for the power learning to write well, in all mediums, not just in code and symbols: When she was a college math professor, she would often have her math students write essay. "[It is] no use trying to learn math unless [you can] communicate it with other people," she would argue. She applied that same philsophy to her work as a hardware and software engineer. She was a fantastic engineer with top-notch communication skills -- a crisp and clear writing style that allowed her to not just be a genuis, but to help others become geniuses.
So, although she didn't physically pull a moth out of the Mark II computer, she did help design the computer that the moth came out of. During her years of designing computers and programming languages, she reached the rank of Rear Admiral in the Navy. When she died, she received full military honors.
- Who was Grace Hopper?
- Which branch of the military was Grace Hopper in?
- What is the name of the computer that the moth was found in?
Was the moth found before or after World War II?
WWII ended in 1945. The bug was found in 1946.
- Why did Grace Hopper make her math students write essays?
- In what way can becoming a better writer make you better at math?
- In what way can becoming a better writer make you better at coding?
- In what way can becoming better at coding make you better at writing?
- In what way can becoming better at coding make you better at math?
Tips & Tricks:
- Pull up picture of the Harvard Mark I (not many photos/info about Mark II), and the infamous moth.
- Cool facts about the Harvard Mark I and II:
- Mark II was completed in 1944
- Mark I weighed over 9,000 lbs and was 51 ft long, 8 ft tall and 2 ft wide.
- Mark I had 60 sets of 24 switches each to manually enter data.
- Mark I took 6 seconds to complete a multiplication task.
- Mark II was completed in 1947
- Mark II weighed 46,000 lbs!
- Mark II took less than a second to complete a multiplication task.
The Life and Times of a Real Coder
meta-cognition
What does it really take to be a coder?
What does it really take to be a coder?
The Life and Times of a Real Coder
What does it really take to be a coder?meta-cognition
Each Chapter of this story starts by defining a primary task a coder does before generating a list of the skills required for that task, then considering where else we use those skills. The goal being to expand the definition of what it means to be a coder and how everyone can gain from it.
Each Chapter of this story starts by defining a primary task a coder does before generating a list of the skills required for that task, then considering where else we use those skills. The goal being to expand the definition of what it means to be a coder and how everyone can gain from it.
Tips & Tricks:
- This story is strongly based in discussion. Know what is important to touch on, but also let the students bring up ideas that you may not have thought of before!
- If possible, use visual aids/lists to keep the discussion clear and focused. Draw up on a whiteboard and/or even encourage students to draw along. An example diagram:
- Ask the students to assess their level of mastery over some/all of the skills discussed.
- Because this story mode is driven by questions to the class, there is no additional questions noted at the end.
- You can easily split this story by chapter over a class or several classes.
Chapter 1: The Code
- What does a coder do? -- Write, read, edit and debug code
- What skills do we need for that? -- (ex. coding knowledge, problem-solving, organization, logic, computational thinking, creativity...)
- Where else are these skills useful? -- (ex. math, writing, homework, art...)
- What else does a coder do? -- Work with people
- What skills do we need for that? -- (ex. communication [verbal, written and visual], teamwork...)
- Where else are these skills useful? -- (ex. school projects, sports, job, socially...)
- What else does a coder do? -- Work with own brain
- Meaning: "code" our brain by learning, "edit code" by learning new things, "debug code" by finding and fixing false assumptions
- What skills do we need for that? -- (ex. grit, self-reliance, curiosity, humility...)
- Where else are these skills useful? -- (ex. sports, musical instrument, writing...)
- It takes a lot of different skills to be a coder
- You learn and use these skills everywhere
- Like in our stories and games!
Who here wants to be some kind of coder when they grow up? Who might want to be a coder or do a job that involves coding? Who wants to do something totally different?!
Let's take a closer look at what it really takes to be the best coder -- all the different things a professional coder does and the skills it takes to be good at them. Some of these things you are already doing -- in this class or elsewhere in your life. Some of them you'll do soon! But all of these skills are valuable for all of you. Now and in the future, no matter what you end up doing!
Let's take a closer look at what it really takes to be the best coder -- all the different things a professional coder does and the skills it takes to be good at them. Some of these things you are already doing -- in this class or elsewhere in your life. Some of them you'll do soon! But all of these skills are valuable for all of you. Now and in the future, no matter what you end up doing!
[Coach asks students: What does a coder do? (It's not a trick question!)]
Guide students to the answer: Writes code! Also: reads code, edits code and debugs code.
How many of you here are coders? If you have every written, read, editted, or debugged code (even one line!) then you are a coder.
[Coach asks students: What skills does a coder, like you, need to work with code?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
Guide students to the answer: Writes code! Also: reads code, edits code and debugs code.
How many of you here are coders? If you have every written, read, editted, or debugged code (even one line!) then you are a coder.
[Coach asks students: What skills does a coder, like you, need to work with code?]
Example answers:
- knowledge of the programming language
- problem-solving skills
- organizational skills
- logical thinking
- computational thinking
- creativity
[Coach asks students: Where else do we use these skills?]
Example answers:
- organization -> writing essays/books
- logical thinking -> math
- problem-solving -> doing homework
- creativity -> art
Coders work with code; that's obvious! But there's more to coding that just writing, reading, editing and debugging the code.
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
- verbal communication skills
- writing skills
- visual communication skills (diagrams)
- teamwork skills
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- class projects
- ANY workplace
- with family/friends
So far, we have figured out that a coder works with code and works with other people. There is one last part of the coding process that I want to talk about today. It can be the hardest to grasp, and many coders never get this part, but I know you all are ready to figure this out with me.
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
- grit
- self-reliance
- perseverance
- curiosity
- meta-cognitive skills
- humility
- passion/drive
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- playing an instrument
- research
- writing
- physical creation (building/carpentry/sewing/etc)
When we look at all this -- all the stuff a coder does and all the skills we need to do them -- it is a lot! But the good news is that you are building these skills all over the place, not just in this class. Every time you figure out a tough homework problem all on your own, you are using your problem-solving, self-reliance, and perseverance skills. At soccer practice you are building up your teamwork, communication, and grit skills.
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
The Life and Times of a Real Coder: Chapter 1/3
The first part of a three-part story, investigating all the different skills it takes to be the best coder we can be.
The Life and Times of a Real Coder: Chapter 1/3
The first part of a three-part story, investigating all the different skills it takes to be the best coder we can be.Tips & Tricks:
- This story is strongly based in discussion. Know what is important to touch on, but also let the students bring up ideas that you may not have thought of before!
- If possible, use visual aids/lists to keep the discussion clear and focused. Draw up on a whiteboard and/or even encourage students to draw along. An example diagram:
- Ask the students to assess their level of mastery over some/all of the skills discussed.
- Because this story mode is driven by questions to the class, there is no additional questions noted at the end.
Prologue
- Who here wants to code as a job? Who wants to do something else?
- Being a coder takes a lot of different skills that cna help us in lots of different fields
- What does a coder do? -- Write, read, edit and debug code
- What skills do we need for that? -- (ex. coding knowledge, problem-solving, organization, logic, computational thinking, creativity...)
- Where else are these skills useful? -- (ex. math, writing, homework, art...)
Who here wants to be some kind of coder when they grow up? Who might want to be a coder or do a job that involves coding? Who wants to do something totally different?!
Let's take a closer look at what it really takes to be the best coder -- all the different things a professional coder does and the skills it takes to be good at them. Some of these things you are already doing -- in this class or elsewhere in your life. Some of them you'll do soon! But all of these skills are valuable for all of you. Now and in the future, no matter what you end up doing!
Let's take a closer look at what it really takes to be the best coder -- all the different things a professional coder does and the skills it takes to be good at them. Some of these things you are already doing -- in this class or elsewhere in your life. Some of them you'll do soon! But all of these skills are valuable for all of you. Now and in the future, no matter what you end up doing!
[Coach asks students: What does a coder do? (It's not a trick question!)]
Guide students to the answer: Writes code! Also: reads code, edits code and debugs code.
How many of you here are coders? If you have every written, read, editted, or debugged code (even one line!) then you are a coder.
[Coach asks students: What skills does a coder, like you, need to work with code?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
Guide students to the answer: Writes code! Also: reads code, edits code and debugs code.
How many of you here are coders? If you have every written, read, editted, or debugged code (even one line!) then you are a coder.
[Coach asks students: What skills does a coder, like you, need to work with code?]
Example answers:
- knowledge of the programming language
- problem-solving skills
- organizational skills
- logical thinking
- computational thinking
- creativity
[Coach asks students: Where else do we use these skills?]
Example answers:
- organization -> writing essays/books
- logical thinking -> math
- problem-solving -> doing homework
- creativity -> art
The Life and Times of a Real Coder: Chapter 2/3
The second part of a three-part story, investigating all the different skills it takes to be the best coder we can be.
The Life and Times of a Real Coder: Chapter 2/3
The second part of a three-part story, investigating all the different skills it takes to be the best coder we can be.Tips & Tricks:
- This story is strongly based in discussion. Know what is important to touch on, but also let the students bring up ideas that you may not have thought of before!
- If possible, use visual aids/lists to keep the discussion clear and focused. Draw up on a whiteboard and/or even encourage students to draw along. An example diagram:
- Ask the students to assess their level of mastery over some/all of the skills discussed.
- Because this story mode is driven by questions to the class, there is no additional questions noted at the end.
Review
- What did we learn about coders and the skills we need last time?
- What else does a coder do? -- Work with people
- What skills do we need for that? -- (ex. communication [verbal, written and visual], teamwork...)
- Where else are these skills useful? -- (ex. school projects, sports, job, socially...)
Coders work with code; that's obvious! But there's more to coding that just writing, reading, editing and debugging the code.
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: What else does a coder do?]
Guide students to the answer: Communicate with people! Other coders, non-coders (coworkers, users, customers...)
Now, professional coders have a bit of a reputation for being introverted -- or even anti-social! But the truth is, to be the best at coding you have to work with other people. Your code is for people. Other people will use it, build on it, and learn from it!
[Coach asks students: What skills does a coder, like you, need to work with other people?]
Example answers:
- verbal communication skills
- writing skills
- visual communication skills (diagrams)
- teamwork skills
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- class projects
- ANY workplace
- with family/friends
The Life and Times of a Real Coder: Chapter 3/3
The third and final part of a three-part story, investigating all the different skills it takes to be the best coder we can be.
The Life and Times of a Real Coder: Chapter 3/3
The third and final part of a three-part story, investigating all the different skills it takes to be the best coder we can be.Tips & Tricks:
- This story is strongly based in discussion. Know what is important to touch on, but also let the students bring up ideas that you may not have thought of before!
- If possible, use visual aids/lists to keep the discussion clear and focused. Draw up on a whiteboard and/or even encourage students to draw along. An example diagram:
- Ask the students to assess their level of mastery over some/all of the skills discussed.
- Because this story mode is driven by questions to the class, there is no additional questions noted at the end.
Review
- What have we learned about coders and the skills we need so far?
- What else does a coder do? -- Work with own brain
- Meaning: "code" our brain by learning, "edit code" by learning new things, "debug code" by finding and fixing false assumptions
- What skills do we need for that? -- (ex. grit, self-reliance, curiosity, humility...)
- Where else are these skills useful? -- (ex. sports, musical instrument, writing...)
- It takes a lot of different skills to be a coder
- You learn and use these skills everywhere
- Like in our stories and games!
So far, we have figured out that a coder works with code and works with other people. There is one last part of the coding process that I want to talk about today. It can be the hardest to grasp, and many coders never get this part, but I know you all are ready to figure this out with me.
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
[Coach asks students: Where else do we use these skills?]
Example answers:
[Coach asks students: Can anyone think of another thing a coder works with?]
Guide students to the answer: Themselves and their own brain!
A coder is always, always learning. No matter how much experience you have, there is always going to be something you don't know, a bug you have never seen, or a problem you have never solved. To be the best coders, you must code your own brain -- write new code (learn new things), edit existing code (change your mind when you learn something new), read your code (break down your thinking process), and debug (look for preconcived notions that are leading you off course and reassess them).
[Coach asks students: What skills does a coder, like you, need to be able to work with their own brain?]
Example answers:
- grit
- self-reliance
- perseverance
- curiosity
- meta-cognitive skills
- humility
- passion/drive
[Coach asks students: Where else do we use these skills?]
Example answers:
- sports
- playing an instrument
- research
- writing
- physical creation (building/carpentry/sewing/etc)
When we look at all this -- all the stuff a coder does and all the skills we need to do them -- it is a lot! But the good news is that you are building these skills all over the place, not just in this class. Every time you figure out a tough homework problem all on your own, you are using your problem-solving, self-reliance, and perseverance skills. At soccer practice you are building up your teamwork, communication, and grit skills.
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
Even in this class, we work on these skills in different ways -- stories and games involving coding, and stories and games that don't seem to have anything to do with computers and coding. We are always improving the skills and knowledge that it takes to be a great coder so you can go on to be the very best coders! Or, you can take these skills and go be awesome at any one of these other things, and more!
The Mars Orbiter Bug
historical
A mission to Mars is several miles (or kilometers) off track -- leading to disaster.
A mission to Mars is several miles (or kilometers) off track -- leading to disaster.
The Mars Orbiter Bug
A mission to Mars is several miles (or kilometers) off track -- leading to disaster.historical
Mode Summary & Goals
Summary: A true story about a famous bug that caused the loss of a Mars Orbiter -- when some coders wrote the code thinking in Metric kilometers while others were thinking and writing in Imperial miles!
Goals and Gains:- Rethinking Bugs practice -- was the bug in the computer? or in the coders?
- Learning some cool computer science history
- Seeing BUGS in the "real world" -- something that even pros deal with
Tips & Tricks:
- Don't forget ask questions throughout and at the end! (see suggestions at the end)
- The Mars Climate Orbiter was sent to Mars in 1998.
- The hopes for the mission was to study the atmosphere and climate of Mars and learn more about why the planet, which once was covered in water, became a desert.
- After 286 days of space travel, the Orbiter got to Mars!
- But something went wrong -- it entered orbit too close to the atmosphere.
- We lost contact and lost the Orbiter -- either to the surface of Mars or the depths of space. We don't know!
- What happened?
- A bug in the code written to control the Orbiter
- The code was written by many people in many places -- some of are used to the Metric system (kilometers, meters, liters, grams....) and others, the Imperial system (miles, inches, pounds...)
- What would happen if I told you to 'go forward 5' and I meant steps, but you thought I meant city blocks?
- That's what happened with the Orbiter!
Mars was once covered with water. Ever since we discovered the evidence of this, the question on everyone's mind has been: Where did Mars' water go?
In 1998, scientists launched the Mars Climate Orbiter on an unmanned mission: to study the atmosphere and climate of the red planet. Using this new information, scientists hoped to figure out where the water had gone, and what had turned that red planet from an ocean world into a desert.
The Mars Climate Orbiter flew toward Mars for 286 days. As it approached the planet, the computer began to fire its thrusters to establish an orbit around the planet. But something went wrong.
The Orbiter was too close to the atmosphere! Its engines began to fail, and communication with that $200 million dollar spaceship was lost. To this day, we don't know where it is. It may have been destroyed in the Martian atmosphere, or it may have continued onward, exiting the planet's orbit. It may be circling the sun to this day -- a tiny scrap of metal compared to the giant planets of the solar system.
Although we don't know what happened after contact was lost -- scientists and engineers back on Earth do know why the ship malfunctioned when it drew near its final destination.
The software written to control the ship from Earth was enormous -- many million lines of code. To get a feel for how big the source code for a space mission can be, here's a picture of a coder named Margaret Hamilton standing next to a printout of code she and her team wrote for a different spaceship:
As you might expect, any giant piece of text written by human beings is going to have some mistakes in it. The code that controlled communication with the Mars Climate Orbiter had one nasty bug that doomed its mission -- going entirely unnoticed until it was too late.
The bug was simply this:
So the numbers transmitted by one piece of software to the other were interpreted incorrectly, causing a message to be sent to the Orbiter that (accidentally) told the Orbiter to fly too close to the Martian atmosphere. An analogy: suppose you told someone to run for 5 -- if they assumed you meant 5 miles they would run much farther than if they assumed you meant 5 kilometers.
Millions of dollars were lost, and a scientific mission doomed. Most people say it happened because of a software bug. But at MetaCoders, we know that the stories behind software bugs is more complex. The bug caused the crash. But what caused the bug?
In 1998, scientists launched the Mars Climate Orbiter on an unmanned mission: to study the atmosphere and climate of the red planet. Using this new information, scientists hoped to figure out where the water had gone, and what had turned that red planet from an ocean world into a desert.
The Mars Climate Orbiter flew toward Mars for 286 days. As it approached the planet, the computer began to fire its thrusters to establish an orbit around the planet. But something went wrong.
The Orbiter was too close to the atmosphere! Its engines began to fail, and communication with that $200 million dollar spaceship was lost. To this day, we don't know where it is. It may have been destroyed in the Martian atmosphere, or it may have continued onward, exiting the planet's orbit. It may be circling the sun to this day -- a tiny scrap of metal compared to the giant planets of the solar system.
Although we don't know what happened after contact was lost -- scientists and engineers back on Earth do know why the ship malfunctioned when it drew near its final destination.
The software written to control the ship from Earth was enormous -- many million lines of code. To get a feel for how big the source code for a space mission can be, here's a picture of a coder named Margaret Hamilton standing next to a printout of code she and her team wrote for a different spaceship:
As you might expect, any giant piece of text written by human beings is going to have some mistakes in it. The code that controlled communication with the Mars Climate Orbiter had one nasty bug that doomed its mission -- going entirely unnoticed until it was too late.
The bug was simply this:
One piece of software for controlling the Orbiter was designed to use metric units -- like the ones used everywhere except America. You know: kilometers, meters, liters, grams, etc.
Another piece of software was designed to use the other kind of units. You know: miles, inches, pounds, etc.
So the numbers transmitted by one piece of software to the other were interpreted incorrectly, causing a message to be sent to the Orbiter that (accidentally) told the Orbiter to fly too close to the Martian atmosphere. An analogy: suppose you told someone to run for 5 -- if they assumed you meant 5 miles they would run much farther than if they assumed you meant 5 kilometers.
Millions of dollars were lost, and a scientific mission doomed. Most people say it happened because of a software bug. But at MetaCoders, we know that the stories behind software bugs is more complex. The bug caused the crash. But what caused the bug?
- Why was the Orbiter launched?
- Did anyone die on the Orbiter?
What caused the Mars Orbiter bug? Whose fault is it?
There's no clear answer to this question. You could say that the programmer who wrote the faulty line caused the bug. But then, the question is -- why did that programmer think they were supposed to be using non-metric units? Why didn't the teams who wrote the two pieces of software communicate better about the units they were supposed to use? Why does our society use two different kinds of units in the first place? When discussing this it's mainly important to leave students with the understanding that things are more complex than they first thought.
- How do you make sure there are no bugs in your code?
- How do you think programmers make sure there are no bugs in gigantic, complicated pieces of code?
Thinking about Inputs and Outputs
young elementaryupper elementarycs-concept
Learn about inputs and outputs on a computer, then map them on to a human!
Learn about inputs and outputs on a computer, then map them on to a human!
YouTube can't tell me what language to use!
software engineeringtrue storyyoung engineer
A high schooler embeds youtube videos on their site, but prefers to use Lisp instead of HTML.
A high schooler embeds youtube videos on their site, but prefers to use Lisp instead of HTML.
Game Modes
Game Modes all have a few things in common.
Focal Points Many
Students have multiple points of focus -- a few may be focused on one computer and activity here, and someone working solo on another task over there, these two working with a coach here...
Energy Level High
Students are striving to achieve a well-defined goal -- and heartrates may be higher (compared to listening to stories). It's the kind of energy you experence when you have to finish a difficult but acheivable task under time pressure.
Comfort Zone Outside
Students are slightly outside of their comfort zone. Psychologists use the term "flow state" to describe what we experience when we play games -- when we are doing something that is not too easy (so we need to focus) and not too hard (so we stay engaged), challenging but acheivable.
Learning Gains Skills and Fluencies
During Game Mode, students may learn many things -- but the type of thing they teach is always the same. Games train skills and fluencies.
The Game Mode database
activebadgescode of awesomenesscodingcommunicationcompetitivecompetitive optioncs-conceptculturaldatabasesdebuggingdiscussion basedfablefinal jamhigh schoolhistoricalinterface designintro new codelanguage gamesmemorizationmeta-classroommeta-cognitionmiddle schoolmulti-storyname gamepartnerspatternsreflectionreviewsimplesoftware engineeringteamworktrue storyunpluggedupper elementarywork in progressyoung elementaryyoung engineer
Harry Potter reference is mandatory
A chance to spend that MetaMoney and get cool prizes!
Each pair creates their own language
Build a Bug Workshop
codingpartnersdebuggingreviewcompetitive optionyoung elementaryupper elementarymiddle schoolhigh school
Players purposely break and debug code in this partnered game.
Players purposely break and debug code in this partnered game.
Building Up
codingteamworkcommunicationreviewcompetitive optionupper elementarymiddle schoolhigh school
Team works together to break a large translation task into the smallest possible steps, then follows the steps to code the game.
Team works together to break a large translation task into the smallest possible steps, then follows the steps to code the game.
Chain Reaction
unpluggedactivecompetitive optionlanguage gamessimpleyoung elementaryupper elementarymiddle schoolhigh school
Define multiple bot-groups with different definitions and create a chain reaction...
Define multiple bot-groups with different definitions and create a chain reaction...
Code Anatomy
codingmemorizationintro new codecommunicationteamworkunpluggedyoung elementaryupper elementarymiddle schoolhigh school
Work as a team to label different parts of the code, then recall the code using only those terms.
Work as a team to label different parts of the code, then recall the code using only those terms.
Code Carousel
codingpartnerscommunicationteamworkreviewupper elementarymiddle schoolhigh school
Players work in pairs translating english prompt into code, rotating to a new computer every 30 seconds.
Players work in pairs translating english prompt into code, rotating to a new computer every 30 seconds.
Code Olympics
codingteamworkcompetitivereviewupper elementarymiddle schoolhigh school
Small teams travel from 'event' to 'event' -- completing a Game Mode at each station.
Small teams travel from 'event' to 'event' -- completing a Game Mode at each station.
Code Relay
codingteamworkcompetitiveupper elementarymiddle schoolhigh school
Race against each other (or the clock) to complete the coding challenges!
Race against each other (or the clock) to complete the coding challenges!
Code of Awesomeness Mottos
unplugged
Customize the Code of Awesomeness by creating a unique Motto for one or multiple Codes.
Customize the Code of Awesomeness by creating a unique Motto for one or multiple Codes.
Compass Name Game
name gameunpluggedyoung elementaryupper elementary
A multi-level name game with speed and a technological flavor.
A multi-level name game with speed and a technological flavor.
Connect Four
codingreviewcompetitive optionupper elementarymiddle schoolhigh school
Players creatively connect different code cards to create a custom specification and write the resulting code.
Players creatively connect different code cards to create a custom specification and write the resulting code.
Create a Challenge
codingteamworkcommunicationreviewyoung elementaryupper elementarymiddle schoolhigh school
The Team works together to design specification for a coding challenge, before taking on that challenge themselves.
The Team works together to design specification for a coding challenge, before taking on that challenge themselves.
Disintegrating Code
codingmemorizationintro new codeyoung elementaryupper elementarymiddle schoolhigh school
Write the code multiple times, but with fewer and fewer hints each time.
Write the code multiple times, but with fewer and fewer hints each time.
Final Jam Scoring & Awarding
final jampartnerscompetitive optionyoung elementaryupper elementarymiddle schoolhigh school
Players score their own creation using the following formula with the Coach's guidance.
Players score their own creation using the following formula with the Coach's guidance.
Final Jam!
final jamcodingteamworkpartnersreviewcompetitive optionreviewyoung elementaryupper elementarymiddle schoolhigh school
It's the Final JAM-down!
It's the Final JAM-down!
Find the Portkey
Harry Potter reference is mandatory
Hello World Game
codingsimpleintro new codeyoung elementaryupper elementarymiddle schoolhigh school
The first coding game of most courses
The first coding game of most courses
Market
A chance to spend that MetaMoney and get cool prizes!
Mind Meld
codingmemorizationteamworkreviewupper elementarymiddle schoolhigh school
Can your whole Team think with ONE MIND?!
Can your whole Team think with ONE MIND?!
Name Alliteration
name gameunpluggedupper elementarymiddle schoolhigh school
Players introduce themselves with an alliterative adjective/name combo and a matching movement.
Players introduce themselves with an alliterative adjective/name combo and a matching movement.
Name Memory Game
name gameunpluggedyoung elementaryupper elementarymiddle schoolhigh school
Players share about themselves and test their memory by repeating what Players before them have said.
Players share about themselves and test their memory by repeating what Players before them have said.
Name and Motion
name gameunpluggedyoung elementaryupper elementary
Players introduce themselves with a name, an activity they like to do and a matching movement.
Players introduce themselves with a name, an activity they like to do and a matching movement.
Open Code Review
codingsimplereviewyoung elementaryupper elementarymiddle schoolhigh school
Players have free time to review what they have learned so far. Works well as an opening warmup.
Players have free time to review what they have learned so far. Works well as an opening warmup.
Pattern Prediction
unpluggedpatternsyoung elementarymiddle schoolhigh school
Coach shows an unfinished pattern and the Team guesses the ending.
Coach shows an unfinished pattern and the Team guesses the ending.
Pattern Prediction
Coach shows an unfinished pattern and the Team guesses the ending.unpluggedpatternsyoung elementarymiddle schoolhigh school
Need:
- whiteboard (paper can work for small Teams)
- Writing utensils
How to Play:
- Coach writes out the first several pieces of a pattern (see examples below)
- Players guess the next piece in the pattern
Example Patterns:
Tips & Tricks:
- Variation: Give Players paper and have each them draw their answers before calling on one to draw on the board.
- Give Players paper and have each of them draw a pattern. Collect the papers and use those patterns to create new puzzles.
Person-Bot (or Code the Coach/Kid)
unpluggedcommunicationteamworkcompetitive optionyoung elementaryupper elementary
Team works together to 'code' a Bot (the Coach or a Player) to achieve a Goal.
Team works together to 'code' a Bot (the Coach or a Player) to achieve a Goal.
Person-Bot: Define Movement
unpluggedlanguage gamescompetitive optionteamworkyoung elementaryupper elementary
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Person-Bot: Define Point
unpluggedlanguage gamescompetitive optionteamworkyoung elementaryupper elementary
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Person-Bot: Define Shapes and Sizes
unpluggedlanguage gamescompetitive optionteamworkyoung elementaryupper elementary
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Person-Bot: Define Shapes and Sizes
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.unpluggedlanguage gamescompetitive optionteamworkyoung elementaryupper elementary
Need:
- no required supplies
How to Play:
- Coach introduces the following operations and what they mean:
- Input: "Draw a Circle" and holds up hands to indicate size
- Output: Bot draws a circle of the indicated size
- Input: "Draw a Square" and holds up hands to indicate size
- Output: Bot draws a square of the indicated size
- Input: "Draw a Triangle" and holds up hands to indicate size
- Output: Bot draws a triangle of the indicated size
- Input: "Move pen [Right/Left/Up/Down]" and holds up hands to indicate distance
- Output: Bot moves pen in the indicated direction in the indicated distance
- Coach shows examples
- Coach picks a Bot -- often the Coach themselves for the first round
- Team codes the Bot to achieve the following goal(s), using only the defined operations:
- Draw a tree
- Draw a house
- Draw a cat
Draw this shape
Tips & Tricks:
- Player-Bots may need help only following the exact defined operations -- not using their "human brain" to automatically assume what the Team means or try to make it harder on the Team!
- If the Team is having trouble communicating 1 operation at a time, designate a Master Coder responsible for relaying the Team's instructions (not just their own!) to the Bot. Bot must only listen to the Master Coder.
- Be sure to switch out the Bot often.
- Variation: Pick two Bots and two Goals. Split into 2 Teams who code their bot (in parallel) to achieve the same or different goal(s).
- After a few rounds, work together to define new operations.
- Partner up to play this game -- give each pair paper and pen to try this together, after a couple example rounds all together.
- Send the Bot out of the room when the Goal is being chosen for an extra challenge/test of the skill of the Team.
Person-Bot: Gone Meta
unpluggedlanguage gamescompetitive optionteamworkyoung elementaryupper elementary
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Team defines a set of operations before working together to 'code' the Coach or a Player like a Bot to achieve a goal -- only using their defined language.
Reverse Engineering
codingteamworkcommunicationreviewcompetitive optionyoung elementaryupper elementarymiddle schoolhigh school
Coach shows the Team running code, who then work backwards to write the code.
Coach shows the Team running code, who then work backwards to write the code.
Reverse Translation
codingcommunicationunpluggedreviewcompetitive optionyoung elementaryupper elementarymiddle schoolhigh school
Starting with just an implementation, the Team translates it back to a specification with as much detail as possible.
Starting with just an implementation, the Team translates it back to a specification with as much detail as possible.
Try It First
codingsimpleintro new codeyoung elementaryupper elementarymiddle schoolhigh school
Players try to figure out how to code a new specification with no hints before getting hints/the answer.
Players try to figure out how to code a new specification with no hints before getting hints/the answer.
Whaddya Call That?!
language gamesteamworkcommunicationunpluggedupper elementarymiddle schoolhigh school
Team works together to create their own language for unique shapes before using that language to communicate a picture to draw.
Team works together to create their own language for unique shapes before using that language to communicate a picture to draw.
Whaddya Call That?!
Team works together to create their own language for unique shapes before using that language to communicate a picture to draw.language gamesteamworkcommunicationunpluggedupper elementarymiddle schoolhigh school
Need:
- whiteboard or other way to display drawings to the whole group
- paper for each Player
- writing utensils
How to Play:
Set Up: Coach prepares or chooses a premade final picture and constructor shapes (see Samples below)
- Coach draws all the 'constructor shapes' where everyone can see them (ex. a whiteboard)
- Team works together to create a one-word name for each constructor shape, Coach notes the names
- Coach verbally describes a picture, using the defined words for the constructor shapes
- Players draw the picture on their own papers
- Once all players are finished, Coach displays the correct picture
- Team can compare and share their results
An Example with Pictures
- Coach says: "Draw a Pointy at the bottom of your page. Put a small Blorp on top of the Pointy. Then, put a Steve on the very top."
Sample Pictures
Whaddya Call That?! Partner Version
Each pair creates their own language
What Does This Do?
codingsimpleintro new codeyoung elementaryupper elementarymiddle schoolhigh school
Players type up and run code, before explaining the result in detail.
Players type up and run code, before explaining the result in detail.
Transitions
Because there are only two acceptable classroom modalities, there are four primary kinds of transitions coaches must be fluent in. In addition, there are transistions into and out of class. All of these transitions are simplified into three or fewer steps to enable you to start using them with high mastery in your first class. Check them out in the tabs below.
A Note on Attention Getters:
Having the student's attention is required in order to transisition effectively. Conveniently, most Class Launch Maps include the Code of Awesomeness Mottos Game Mode, where the class generates their very own call and response -- a perfect attention getter! Use these often.
The attention getter rule of thumb is: If it works, it's fine. If you google for attention getters, you'll find hundreds. Most of them are based on the highly effective call/response model. Find your favorite or build a repertoire of dozens. That's up to you.
Here's a video with several:
Story Mode to Game Mode
Transitioning from Story Mode to Game Mode involves:
- Ending the current story.
- Explaining the upcoming game.
- Raising the energy level.
- Preparing students for flow state.
Do you need an attention getter? No. You should be in Story Mode already, meaning that the class's attention is focused on you or people you designate. You only need an attention getter if you aren't really in Story Mode -- i.e. if the class's focused attention has begun to fray.
What are the ABCs of a Story Mode to Game Mode transition?
- (A)nnounce that you are about to transition to a Game Mode. But tell the class to wait until you say "Start".
(B)uild tension. Recommendations for this step can be found in the various Game Modes on this site, but the general idea is:
- Give the instructions you want students to perform after you say "Start".
- Tell them what the challenge will be. If there is a time limit, tell them now. This gives them time to rally cognitive resources for the challenge ahead.
- Explain the cognitive benefit of the Game Mode. Tell them why you are asking them to do it.
- (C)hange the space and (C)ontinue. Alter the room in a visually distinguishable way -- turn the lights on, have students open their computers, etc. Say "Start".
Game Mode to Story Mode
Transitioning from Game Mode to Story Mode involves:
- Ending the current game.
- Handling byproducts of interrupted flow state.
- Lowering the energy level.
- Preparing students for narrative transportation.
Do you need an attention getter? Almost always. In Game Mode, the class's attention should be focused on their task at hand. Ideally, they will be in a state of flow, fully absorbed. The only time you won't need an attention getter is if you weren't really in a Game Mode -- i.e. if the task was too hard or too easy to induce a flow state -- and students are already looking at you, waiting for you to do something.
What are the ABCs of a Game Mode to Story Mode transition?
- (C)all attention and (C)hange the space. Use your attention getter and immediately make a visually distinguishable change in the classroom -- i.e. turn off the lights, have students move to a new place and circle up, have students shut their computers.
(B)ring down the energy. In a well-run Game Mode, heart rates and excitement should be high. So you'll need to help students calm down.
- Lead a breathing or stretching exercise.
- Ask a student to tell you a positive story about their experience in the previous Game Mode.
- Tell the students they did well in the previous Game Mode. Remind them of the cognitive benefits of that Game Mode. This helps them become more focused on their own long-term growth and less focused on their performace (good or bad) in the specific Game Mode that just ended.
- (A)dvance into the story. Begin with any necessary meta-data about the story (Why you are telling it? Why do you think it is valuable?). Tell the story.
Game Mode to Game Mode
Do you need an attention getter? Almost always. In Game Mode, the class's attention should be focused on their task at hand. Ideally, they will be in a state of flow, fully absorbed. The only time you won't need an attention getter is if you weren't really in a Game Mode -- i.e. if the task was too hard or too easy to induce a flow state.
These transitions should be quick and efficient. You don't need to have students change space. And you aren't interrupting their flow state for very long. Usually, Game Mode to Game Mode transitions are used to "patch" the current Game Mode -- i.e. to add a new rule, to raise the challenge, to introduce a new round.
If done correctly, students should not feel that the Game Mode ever ended -- just that it was briefly interrupted and subtley changed from that point forward.
Story Mode to Story Mode
Do you need an attention getter? No. You should already have their attention. It's Story Mode.
These transitions should be barely noticeable. You should end one story and begin another, without loss of momentum.
If done correctly, students should not feel that the Story Mode ever ended -- just that it happened to contain more than one story.
Transitioning Into Class
Create a starting-class routine for yourself and your students. Whether you arrive to a room where all students are waiting for you, or students join you one by one, create a routine on the very first class and stick with it.
This routine will help students "get into the right headspace" for class and sustain a sense cohesion through a class where you may be doing wildly different things day-to-day. Students will also become more independant as they grow accustomed the the routine, giving you time to finish setting up, take attendance, check in with HQ or deal with anything else that arises.
A recommended Start-Class routine to begin with is:
- Have a specific location for students to go and sit.
- Talk to them about their day (Story Mode!)
- Take attendance as each student arrives. Submit attendance and start with classmap when ready.
As you develop your own favorite routines, keep in mind:
Start-Class routines must include:
- Taking of attendance (and reporting as needed).
Start-Class routines can include:
- Staggered, independant tasks like having a snack or putting your lunch bag by the door
- Coding warmups
- Group check-ins ("How was everyone's day?" "Anyone do anything cool over the last week?")
- Attention Getters
Transitioning Out of Class
End of class dismissal must always be safe and organized. All students must be released to an adult (a parent/guardian, or staff of another program) unless explicitly stated otherwise on the roster or by MetaCoders HQ staff.
Create an ending-class routine to help you achieve this goal. Whether you walk the students to a dismissal location or release them from the room; create this routine on the very first day and stick with it.
End-Class routines must include:
- Safe and organized dismissal to an adult for every student.
End-Class routines can include:
- Lining up at the door
- Sitting on "the rug" or at a specific table
- High five the coach before leaving (confirms checkout!)
- A verbal exit ticket told to the coach before leaving