This year I find myself repeating a phrase now aphoristic in my classroom: “paper and pencil are your best friends.” Admittedly, the lonely will find no truth in these words, but they are a constant reminder to my students who I find “coding on the fly.”
A common draw to computer
science is immediate feedback. Most IDEs feature syntax highlighting and messages for what you’ve done successfully — or not. Building something and seeing it on screen justifies the start of this journey with some well-timed dopamine. I love this element of CS and see it as foundational to my interest in programming.
And yet, such a constant companion can create dependency for early coders who often see coding problems having a singular solution or approach: if I get an error, I approached it wrong, if not I did it right. Left unchecked, this dependency causes developers to forget their process and focus singularly on the result. They want “right” code. I often find my students in this state. Their frustration increasing — hacks on the keyboard intensifying — fingers dancing from typing to backspacing — I ask them to stop and remind them: “this is when paper and pencil are your best friends.” This is rarely accepted with a smile, but medicine doesn’t always taste great.
“How is that going to help?” is where the discussion starts every year. Handing them a fresh sheet of paper and a pencil, I ask them to walk through a conversation about the problem with me. “What is the goal here? What are you trying to do should this all work out?” Step-by-step I write out what they say in bullet points on the desk (An aside: I often write on my laminate desks with dry erase markers and try to keep enough supplies that the students can do this too. Markings erase easily with alcohol spray and it’s fun, try it.) In these early stages I have to be adamant that we aren’t talking in code. We’re talking about thinking and problem-solving. Outside of a programming language, how would you solve this?
Eventually we have a set of steps to approach the problem and then we can talk code. “Hmm, you want to take the vowels out of that String, but how would a computer know if a letter was a vowel? How would a computer have to read that String to begin with?” What they don’t know is that I am working them through Bloom’s Taxonomy with questioning to scale up their thinking. Throughout the year this will take them from comprehending to creating and evaluating algorithms and the like. Simultaneously I am teaching them organizational thinking strategies and that when developers get stuck, we don’t give into frustration. We simply track our thinking and approach it methodically.
Paper and pencil, markers and laminate surfaces, or even structured comments in the code are inexpensive tools that we often leave aside in CS classrooms. The ease of tying and erasing or copying and pasting can make those feel like the most visceral options. For someone like me, who has ADHD, the temptation can lead to branching off into another solution only to realize I was on the right track to begin with. Without my notebook (always in my bag or beside my computer) and my whiteboard, I would have deleted my code and moved on, now starting from scratch.
Walk your students (or yourself) through the wonders of mapping, charting, listing, and brainstorming possible approaches to problems. Not only will you think clearer, you will notice the structure and reoccurrence of those strategies cropping up over and over in programming challenges.
Cheers.
Comments
Post a Comment