What Teaching Programming Taught Me About Patience

Programming looks very logical from the outside. Teaching programming is much more emotional. A student can understand a difficult idea in five minutes and then spend half an hour looking for a missing semicolon. Another student may struggle with the same topic for days and suddenly understand it after one small example — the third or fourth version of an explanation you were not sure was any different from the others.

Watching these moments taught me that learning has its own speed, and it does not negotiate with the lesson plan.

The gap between understanding and explaining

When I explain something, I naturally start with the version that makes sense to me. That is normal, but it is also limited. Recursion felt clear to me once I understood the call stack. Not everyone builds their intuition that way. Some students need to see the same recursive function traced as a tree of calls, expanding and collapsing. Some need to write it out as a sequence of returns on paper before the substitution model clicks. Some need the analogy of a to-do list where each task can add new tasks to the top.

I used to think that repeating an explanation meant the first explanation had failed. Now I see it differently. A different explanation is not a repetition — it is another door into the same room. Some students find the first door, some find the third. A teacher who has only one door prepared will lose students who needed a different angle.

The sentence that isn’t a code problem

There is a difficult moment in any programming class when a student says “my code does not work” and then, after a while, says “I am not good at programming.” These are not the same problem, and treating them as the same problem makes both worse. A broken program is normal — it is the ordinary state of code that has not been debugged yet. Professional programmers spend most of their working hours fixing code that does not work. A syntax error or a logic bug at the end of a homework assignment is not evidence about someone’s future in the field.

Teaching made me more careful about this distinction. The code problem needs diagnosis. The confidence problem needs a different kind of response — showing the student that their error is ordinary, not exceptional.

The discipline of waiting

I also learned to wait. When you already know the answer, silence feels longer than it actually is. A student is working through something, you can already see the next step, and it is very easy to say it too early. But sometimes those extra ten seconds are exactly where learning happens — the student making the last connection themselves rather than receiving it already completed.

The hardest part is that you cannot always tell, in the moment, whether the silence is productive thinking or a student who has stopped and needs a prompt. Experience helps, but it does not eliminate the uncertainty.

The mirror

This changed how I see my own learning too. There are still technologies that make me feel like a beginner. There are still topics that take me longer than I expected. Years of experience do not remove this feeling — they only make it less frightening, because I have been through the slow part enough times to recognise that it is temporary.

When I cannot understand something quickly, I sometimes remember the students who only needed one more example. Then I look for one more example for myself.

Teaching programming has taught me many things about code, but one lesson is larger than code. Progress is not always visible while it is happening. Sometimes patience is simply trusting that understanding can arrive a little later — and that the waiting is not wasted time.