My programming students had deadlines this weekend and I've been chatting with quite a few of them on GitHub, Slack, and Teams about their misbehaving programs. I've been interested to see how some approach problems with their code, and I'm reflecting on how to go about teaching the others to change theirs.
Let's start with the fundamental experience of writing software, which I would summarize as: "it doesn't work." That is, your program doesn't work, and doesn't work, and doesn't work, until suddenly, it works! It isn't just you; it really "doesn't work" for anyone. Programming is a psychological test of your patience. How long can you tolerate failure? "But Dave," I hear you asking, "we're talking about students, not expert programmers." It makes no difference. I think I've been programming for about 35 years and I still spend most of my time at "it doesn't work."
There's a secret to overcoming "it doesn't work," and it depends on you reframing the experience. You have to stop thinking about what isn't happening and start focusing instead on what is. "It doesn't work" will always be your default state, right up to the ecstatic moment when it isn't. You can't move beyond "it doesn't work" if you stay focused on it. Shift your gaze away from the goal, and start contemplating "it's doing this."
The shift to "it's doing this" opens a whole new set of doors. Where we previously only saw the lack of something, now we are presented with a wealth of information. It's throwing this very specific error. It's crashing when I do x, y, and z. It's hanging after I enter 'abc.' Where "it doesn't work" is a ghost we can't see, touch, or smell, "it's doing this" has definite shape, weight, and measurements. We can interrogate "it's doing this."
Taking your eyes off of "it' doesn't work," and gazing instead off into "it's doing this" feels like a distraction. We're supposed to be moving forward, but now we're looking down. Why would we want to spend time looking at something we don't want? Our goal is up ahead! Surely that's where we should focus?
It's tempting to ignore what's in front of you as a temporary thing, one which doesn't require your attention. However, where your feet are now tells you a lot about your next step. Don't be afraid to get distracted by what's immediately (and obviously) available. Shifting to "it's doing this" will always mean stopping to look down at your feet, and therefore pausing your forward progress.
Let me give you an example. Last night I had three or four students all tell me that they couldn't build their web site. In this lab we're using the amazing Parcel bundler, and it requires a build step. "It doesn't work," they told me. What doesn't work? What's happening? What are you seeing? "It doesn't work."
One of the students came to me with "it's doing this." Amasia noticed that she was getting a segmentation fault, and also gave the exact error message that she saw each time. She also noted that it would work on the fourth try, but not the 1st, 2nd, or 3rd. "It's doing this" led us to an existing issue where others were busy discussing the same problem, possible workarounds, and trying to figure out the root cause.
"It's doing this" doesn't necessarily fix your problem, and it can feel like a waste of time: why over-rotate on this thing I don't want anyway? But the step beyond "it's doing this" is much shorter to make than the leap required to overcome "it's not working." Progress in programming is small, measured in milliseconds and little bits concatenated together. We only get there by degrees.
Whenever you feel your fingers tying "it doesn't work," force yourself to pause. How could you rephrase what you're about to write so that it sounds more like "it's doing this."
Your program is doing all kinds of things. You just want it to do something else.