I Taught Coding Once…
This is the story of how that went and what I learned in the process.
I was hired as a learning analyst last summer. It was a welcomed pivot to the tragic career path I found as a inner city public school principal. It was also the most perfect-fit job I have ever had. It merged my expert knowledge of education, pedagogy and learning with my past-proficient knowledge of programming.
There was also the subtle bullet point in my offer that asked I “teach more advanced Computer Science” to a small group of middle school students sometime during the day. I had learned programming in middle school, I still remember learning BASIC in that old terminal. Programming had always been such a big part of my life so I was super excited to be able to teach it to a bunch of 12 year olds.
The Plan
I figured that the ‘easiest’ path for both of us would be to learn the full stack. Start with the front end, and ease into the back end. Easy right? Wrong. very, very wrong.
The Syllabus
I decided to write my own curriculum because of my strong aversion towards gamification in education. After several re-writes, I landed on what I figured this elective course would look like:
Fall Semester
- Logic (flowcharting, pseudo code, development, application, user stories)
- How the internet really works (what really happens when I make that HTTP request)
- Front End Basics (HTML, CSS, Javascript)
Spring Semester
- How servers impact your life (all about servers)
- Databases rock
- Back End Basics with Node JS
I would purposefully stay away from libraries and keep it simple. Easy right? Wrong, very, very wrong.
The Pitch
Before I begin, I had to recruit kids to sign up for my class. I was given 5 minutes to give an overview of my class and what they would learn in it, then after listening to 20 of these pitches from different professionals, they would sign up for their top 3 choices. This is what I said:
“If you love being stuck in a problem so long that quitting seems like the best option, yet you are not allowed to quit nor throw the laptop across the table, pull your hair (or someone else’s) out no matter how much you want to, you should sign up for this class.”
I also remember mentioning that “if you want to look cool and be a hacker, you should definitely pick something else, like fitness or dance.”
I still think some of the kids thought I was kidding and took it as a “dare”.
The First Challenge: Knowing How to Learn
The problem with doing a demo in coding is that your audience has to have some level of metacognitive skills. I had my 12 students and class was in session. I didn’t waste one second. I was demo-ing away and I realized nobody was writing anything.
I had 12 twelve-year olds attentively watching but not one writing anything down. So anytime I asked them to do/discuss/say something, they would just stare blindly and ask each other.
I quickly added a homework note: get a notebook.
The next day I made sure I embedded several reflection pauses after a new key idea so kids could jot down what they understood from demos, lectures, videos or discussions we had.
And that’s how I found out they didn’t know what to write.
They wrote, but they wrote broadly. They didn’t write organized steps, examples, or one-sentence key ideas. They wrote multiple sentences with little meaning with repeated use of the words ‘like’, ‘this’, ‘that’, in a way that if they were to read it again, months from now, they would have no clue.
I added a feedback session after the reflection pause to make sure that I could address any misinformation and teach a quick note-taking tip.
Very quickly, with all these pauses and feedback loops, one lesson stretched into 3 days. Before long, it was October and I was still teaching HTML.
The Second Challenge: Learning Resourcefulness
One of my strong dislikes for the gamification in education, especially when it comes to coding for older kids, is that it removes the struggle and responsibility of learning. Learning is hard. Learning involves mistakes, failure and changing course. Yet, we seem to be stuck in a learning culture that operates with drag-and-drop policies and “teach me” attitudes.
When kids started writing scripts and got their first errors, they just raised their hands and expected me to give them the answer.
The real truth is that in life, you are responsible for your own learning. Only you.
I had to essentially re-program their attitudes to solve their own problems. We didn’t have an “ask three before me” routine. Yet they knew that if they had their hand raised, I would ask any of these questions:
- What did you find in Google regarding that problem?
- What did the MDN docs have regarding that?
- When you checked your code against <insert top student’s name here>, what changes did you make?
- What is printing in your console?
Pretty quickly, students wouldn’t raise their hands anymore and would speak up saying:
- The MDN says I should pass in (these ) parameters, and my console says (this) but <insert a well-formulated, specific question here>.
It wasn’t easy, but these twelve year olds began to think like programmers. As they talked out their logic, I noticed some kids nodding while others shaking their heads ready to pinpoint flaws in it. The real learning had begun, but it was November and we were just learning CSS.
The Third and Final Challenge: Persistence
The handful of kids who “dared” themselves into this class, found themselves listening to music instead of programming in November. They were lost. They had no interest in solving their own problems or persisting through one more activity. I added the CSS Plates activity into our class in spite of its gamey nature, primarily because it is a really good activity and would give them some practice time before moving on to Javascript. That was the last activity they tuned into.
No matter how much freedom I gave kids, when the first hurdle came along, they quit. They had spurts when a friend showed them their cool project and they picked it back up again, for a minute, then to quit again.
Kids were used to getting rewards quickly and in programming, you just don’t get those.
Before I knew it, December came and we had not even started Javascript. It was also then that I got wind that they would open my class up for enrollment in January. Wait, what?
Even though, in paper, we hadn’t accomplished much, we had accomplished so much in one semester. How could I add new kids to this mix who had work/study habits that didn’t match the rest?
January came and about five students were replaced with new ones. Those students quickly found themselves having to emulate the habits of the other ones. The five students who remained from the Fall semester quickly rose to the occasion and acted as mentors to the new ones, it wasn’t that bad after all.
It was January and we finally started learning Javascript.
The interesting thing was that even though the new kids didn’t have the skills and habits that my “veterans” had, they didn’t complain or gripe, they just went along with it! This was completely new behavior than the Fall. I suppose that when you have a large enough group of students who perform at a certain level, and you’re not, you are more motivated to get there quickly.
Shortly after the beginning of the Spring semester, we had to pause our curriculum to let the team from Code Park join us. They have a really cool VR program using glitch that I thought was just too good to pass up.
The kids picked it up quickly and you can even see some of their projects up on the Code Park site. Learning two things at once was just too much for them and we decided to dedicate our space 100% to VR instead.
Some of them promised to come back next year for more. Including myself.
“Next year though”, I said, “we’re learning Swift, and I mean we.”
Their eyes beamed and they grinned. I guess the Class of 2023 will have some programmers in it after all.
