The first class I told them we would be using something called Sonic Pi this year and then without any further explanation showed about 6-7 minutes of Sam Aaron live coding. From there I asked the students to think about what they had seen and heard and what they thought was going on. Responses varied but most pointed out that the music they were hearing corresponded to the words on the screen. I was also surprised that quite a few of them went right to the word “code” which is where I was hoping things would go. From there, we had a brief discussion on what “coding” was and how it can be used for creative purposes.
We also talked about the concept of “Live coding”. I did a quick demo in p5.js showing how each time I wanted to make a change, I had to stop the code and rerun it. Sonic Pi (as we all know) has the ability to change without stopping. It’s funny how this seems like a no-brainer when making music, but I had to explain that in the world of computer programming, this is not the easiest thing to do. But the ability to do this provides us with the option of using Sonic Pi not just as a compositional tool but as a performance tool as well.
I used this opportunity to pose a question “What is the difference between composing and performing?” I also asked how our mind state differs when doing one or the other. Kids had some interesting answers. Several equated performing with being in front of an audience while composing is done alone away from others. Others pointed out that when composing, you have the opportunity to make changes while when performing, you have to just do it and “can’t make mistakes” .
This led to the point I wanted to make: “What happens if you make a mistake when composing?” The consensus was that you can change it or fix it. “What about when you are performing?” They had to think about this one. “You just have to keep going, I guess”. I used this line of questioning to stress that mistakes do happen and in performance, you can’t go back and fix them, you have to move forward. I shared a piece of advice someone told me once “It’s not a mistake unless you let the audience know it was a mistake” They might think you meant to do that. Sometimes the mistake winds up being better than what we originally intended to do.
I shared the piece of wisdom given by Sam Aaron when referring to Sonic Pi “There are no mistakes, only opportunities”. I really like this idea, but I also wanted to set the tone from the beginning that mistakes are part of the process. We are going to make a lot of mistakes. We will learn from them. Mistakes are not a bad thing.
I referred back to my p5.js demonstration where I had tried to get a circle to move across the screen but couldn’t and that was where I had ended that demo. While the kids were discussing the differences between performing and composing, I took a second to debug the code and it was just a capital letter where there should have been a lower case. I was glad this had happened so I could point it out to the kids that often your code will not work because of a simple little problem like that. When I told them what the bug was, many couldn’t believe that a simple oversight like that would stop everything from running (especially as middle schoolers who regularly make punctuation mistakes but somehow are able to get by). But it was a great opportunity to highlight that these types of mistakes will happen and happen often and we just get used to it. All programmers experience this. In fact, it happens so much, they don’t even call them mistakes, they call them bugs and the process of fixing is called debugging. This was the first real programming term I used up to this point and it wasn’t by accident.
Students, especially middle schoolers are always afraid to make mistakes in front of their peers and give a negative impression, so much so that many refuse to do anything simply to avoid that even being a possibility. So I had made a conscious decision to make the point of my first lesson be that mistakes are ok. They come with the territory and we will embrace them and learn from them.
Also, I’m really glad you’re emphasising risk and mistake making as part of the reality of live coding. Personally I expect mistakes in live coded gigs - and when they happen I’m excited to see how the performer responds. I think the sign of a good live coder is not someone that avoids mistakes, but someone that embraces them and responds in ways that excite the audience.