These days I've been teaching some programming to kids online. As I've mentioned before in this blog, I've already done it many times, I really enjoy designing classes for technology topics. And this time I'm also trying to introduce them to collaborative coding, or at least to the collaborative thinking way, and I'm sharing here my class development for the ones who want to try with their own kids or students.
Programming thinking and society
First of all I taught them programming thinking with a game I already described here. But this time I used this drawing of a maker room, meant to normalize some stuff such a workshop corner, "You can do it!" reference, and others. I also enjoy using female references: I once worked in a project about telling kids in different schools about computer engineer but only women (like myself) were hired as main speakers. We used female references, but didn't mention female professionals in computer science were a minority or an exception, and they seemed to don't care at all and found it normal to find girls telling them about computer science, and learning it from females examples. So I think, in terms of kids, it's better to just subtlety add female references and leave the complaints about the minority for the adults who are already working at it.
When learning about programming I think it's important not just to tell them about logic and "how" but also "why". That's why the first class involves explaining them the impact of technology in any career path and in the world around us. We talked (not just me talking!) about what kind of things are around us that involves technology. "Let's think of at least six examples!" and then we list stuff such as "TV, smartphone, tablets..." and ask them if they remotely know how do those gadgets work. They will realize their surrounding works for a reason and they can be part of that, by thinking about the future. "Now let's think about how can those be improved... how would you like a TV to be in the future?" we can ask. In my student's case he thought holographic TV would be neat (me too!). Let's also think about robots, and cool stuff, tell them cool things that are easy to remember, for example how in the year II b.c. a mechanical robot that served wine was invented, and that in the XV s. everything was so steampunk and scientist designed toys that moved on their own and they started to write about how robots will be today! Not everything needs to be about logic, they need to understand and discuss this things.
Scratch
Once they've discussed about this and they've learned some basic programming using "turn right-turn left-1 step" the next step is Scratch. Scratch has some amazing options that makes easier for a kid to understand programming, such as blocks and colors. But I don't want to get into explaining how to use Scratch, instead I want to explain how to teach this collaborative abilities using it. First of all they need to understand how it works, so using some basic blocks will give them enough freedom to feel comfortable designing programs:
- Moving x steps
- Saying or thinking
- Using sounds (they always like this part)
- Using if and if-else with basic statements
- Loops
And my personal advise, teach them to define functions, even the basic ones, for example functions "Walking" and "Jump" or "going backwards". It might seem like unnecessary to this point, but this will teach them thinking with functions and be organized since the very first program. Let them explore, and encourage them to use more objects in the same scenario. My students chose a dinosaur and a bear. In this part they'll probably mess up sometimes, let them mess up, realize and correct. Taadaa! Debugging! tell them having mistakes while programming is normal and even professionals have them all the time. Include yourself in this group! (which is true btw, we all have bugs, if you say you don't you are totally lying) they will feel like improving and having more experience, rather than failing (we all feel frustrated by bugs, at 10 years old, 20 or 60). If they get stuck try not to tell them the bug even if you saw it from the beginning, but where could it be. "did you checked the conditionals?" this will teach them where to look for regular bugs in the future. This I was taught by the compilers through all my degree.
When I teach Arduino I sometimes see how they are forgetting a wire, or using an incorrect pin or forgetting a semicolon. So I sometimes tell them to check a couple of things all the time before trying, same thing I always do: "Do the circuit have this essential wires? Do I have the correct board selected?" discovering the usual bugs is just about experience, and that's what we can share with them.
Once they've created and understood their own programs they are all set to understand how to contribute to bigger projects. For this, I made my own program with 3 different objects: The main character (the Scratch's mascot) that they already programmed before, a radio and a robot. The radio has a function that lets the radio reproduce 2 songs using a random binary option (I was careful to not use math that they won't clearly understand yet such as "module") and I prepared a variable called "turned on". This variable is on the dashboard but it's unlinked, so I have this comment in the dashboard encouraging the students to:
- Add a song name to show in the program (editing the conditional)
- Add a sound to it (editing the conditional as well)
- Attaching the "turned on" global variable and see how it changes.
Maybe the whole object would be difficult for them to program, but I was careful to build something understandable (using things they already understand) so they have to read, understand and edit. Which is, basically, the idea of open software and collaborative thinking. This way they understand learning to code is not just about building your own programs but to take a moment to understand other's and enhance it. The program is not originally theirs, but they will feel part of it when executing it, because it works thanks to their help.
At the end of this class is ideal to tell them about open software community and how can they collaborate eventually with their knowledge, as they enhanced my program. They will probably come up with ideas for it that I didn't think of such as adding a new sentence, a new sound, a new character, that's okay! The whole thing about programming and open software is being creative and create a healthy environment to share it. You can even encourage them to share it to the Scratch community. A nice exercise if you have several students (more than 2 or 3) is to create a basic program, ask the first child to add something, the second one to add something over the already edited and repeat that with the whole class. This way they will understand how even with a small contribution a whole class can create a big program. It's very easy to extrapolate to the Internet community. "If a single class can create something out of contribution, imagine what the Internet can create!", and this way open operating systems, open programs, open games will make much more sense. The idea is to make them understand coding is not just about being a professional programmer and get paid a lot for it, but instead realize code is part of society and we can improve it even with small contributions.
I encourage you to share in the comments your experience teaching kids about programming and technology and how did you manage to do it!
Plus, I'm sharing with you robots my students drew, and the repository where I'm uploading all the theory.
My repository, as my students are Spanish, they are in Spanish.