How I learned :code, through: :music_teaching
Part 1- Errors forte and piano
A few months ago, I made the decision to make a major career change. After being a music teacher for around 8 1/2 years, I mustered up the will to give coding a shot. I discovered coding through a friend who had done a bootcamp at Flatiron School; a bootcamp that I would soon also find myself joining.
I had my work cut out for me. The sooner I learned the basics, the sooner I would be able to write more complex code and then grow my knowledge base from there. I was on a mission. It was within the first few days of that mission that I discovered something a bit unexpected. Being a music teacher and being a programmer are a lot more similar than I had originally thought. It was clear to me that making my prior knowledge a useable asset in this field would be a primary goal during my first module.
The first connection came in the very beginning when I ran into my first sets of errors. Errors are something you cannot avoid in programming. If you’re looking to be someone who always gets things right on the first try, sorry. Coding, like music, is also an art of practice. Lucky for me my teaching experience made me really used to errors. You can’t teach elementary school band and choir and expect no wrong notes or rhythms during a rehearsal.
For the uninitiated, ensemble rehearsals follow a flow. A director would have a set list of goals in mind for that day, much like a list of coding deliverables. The conductor might decide to go through sections that were a problem in a previous rehearsal, or move onto a new section that the group was told to practice. Typically, especially in younger groups, you’ll be hard-pressed to find that each of your students practiced, and this leads to both expected errors and unexpected errors. In programming, you’ll find the same types of errors.
Expect the expected:
We all experience growing pains when approaching new, challenging material. As a band director it was up to me to find music that I knew that, with practice, my students could play. I knew well ahead of time which errors were most likely come up. Some students would look terrified at the variety of rhythms they were expected to play when I first handed out and rehearsed a piece. When I first began coding, I tried new methods that I hadn’t used before and expected there to be an error or two somewhere in my code, and most of the time I was right.
Here’s where coding and teaching music differ a bit. While I knew that there would be errors in some sections of our music, I wasn’t always able to perfectly predict where exactly they would be in the music. On the other hand, coding errors will usually pinpoint exactly where your mistakes lie, making it easier to fix and continue with our workflow.
If you check out the beginning of this NoMethodError message, it gives us information we love to see. It tells us that our error is in our ruby file on line 177. Think of it as a really easy to hear musical mistake. Like a piccolo hitting an octave above where they were supposed to (my ears!). Now if you’re like me when you were just starting out I bet your code wasn’t very well refactored, and you probably called a method like ‘titlr’ in a ton of different places.
That’s why code errors that show us information like this are amazing because even though we made a silly typo in ‘titlr’ instead of ‘title’, we can easily find the instance of the method that created our error.
And the unexpected:
Getting back to a rehearsal setting, let’s look at a common musical error example. Let’s say for instance the 2nd flute section are missing a few notes within a passage. Unbeknownst to them their errors are causing the clarinets to miss their entrance. For all we know the clarinets know their part really well, in fact, let’s say that they know it perfectly. It takes some analysis of the music around that error to discover that it was the flutes that were causing the issue in the first place. There are layers upon layers to both pieces of music and pieces of code. Sometimes our error messages aren’t enough and It’s up to us to use our knowledge to figure out where those errors are coming from.
It’s alright that this error doesn’t have a line of code associated with it. If we pick this apart and analyze the parts of the error that we understand, we can figure out what’s going on here. In this case, we can tell that there’s something wrong with our database because we can see: ActiveRecord::StatementInvalid: SQLite3::SQLException
Next, if we look at the details of our error we can see that there wasn’t a column for our npc_id in our quests database. That’s no good! Our NPC’s need to be able to give out quests! It’s part of our MVP! Building a new migration to add a column for our npc_id will take care of that issue! Don’t forget to rake db:migrate afterwards!
I’m still super jazzed about how similar my most recent career and programming ended up being. Everyday as I learn more at Flatiron, I’m doing my best to find even deeper connections to music with even more complex code. I look forward to sharing my findings in the next blog!
