Over the past several years, I’ve had the chance to teach coding in two very different settings: at a local community college, where students are often brand new to the world of development, and in the workplace, mentoring other software engineers as they level up their skills. These experiences have taught me that great teaching doesn’t require flashiness or complexity — it requires clarity, patience, and a strong desire to foster success in others.
When you’re teaching someone how to code, you’re not just handing them knowledge, you’re building their confidence and excitement. You’re showing them what they can accomplish; and when someone realizes the cool things they can do with code, it’s a powerful moment that makes them want to keep going.
Here are the principles I stick to every time I teach, whether I’m in a classroom, leading a workshop, or just pair programming with a teammate:
1. Nice 'n' Slow.
One of the most important things I’ve learned is to check my ego at the door. Teaching is not a performance. It’s not about dazzling people with your speed or cleverness. It’s about clarity.
That means moving through concepts slowly and intentionally. It means pausing after introducing new ideas and repeating key concepts, especially when they’re foundational or unintuitive.
Sometimes your inner voice wants to rush ahead — “They’re smart, they’ll catch up.” or, "We're running short on time. You've got to finish this module quickly!" But that voice is wrong. Slowing down creates space for understanding, and that space is where learning success happens.
2. Show, Don’t Just Tell — Code Examples All Day Long
You can talk about useEffect or map or async functions all you want — but it won’t really land until someone sees the concepts in action.
That’s why I rely heavily on real, working code examples when I teach. Not slides. Not pseudo-code. Actual code, ideally something others can copy, run, and tweak themselves.
I don’t stop at code, either — I fill it with comments. Every key waypoint in the code's logic gets a quick explanation. I want my learners to see what the code is doing, why it’s doing it, and where they might go wrong if they’re not careful.
3. Never Give a Blank Slate
There’s almost nothing more intimidating than an empty file and a blinking cursor — especially when you’re just starting out.
That’s why I never create a hands-on lesson with a totally blank starting point. Instead, I provide skeleton code: all the scaffolding is there, with numbered TODOs and clear, encouraging instructions in the comments.
Think of it like trail markers on a hiking path. You still have to do the walking, but you’re not guessing which direction to go. When you detect a commonly established level of understanding and confidence, you can gradually remove some of the scaffolding to test the new skills.
This approach builds confidence, and particuarly helps out the student who lacks confidence to begin with. Students spend their energy solving the problem, not panicking about where to begin.
4. Make Sure the "Why" Sinks In
One of the best ways to turn a short-term fix into long-term understanding is to explain not just what you're doing, but why.
- “This works because…”
- “We could’ve done it this other way, but I chose this approach because…”
- “If the app needed to scale, I’d probably take a different route, but for now…”
… or, turn these points into questions that encourage thought:
- “Why do you think we went with this approach?”
- “What are the trade-offs of this method?”
- “How might this change if we had different requirements?”
These little side conversations are gold. They help others learn how to think through problems, which helps others build their own instincts. It also invites questions — not just “how do I do this?” but, “when should I do this?”
5. Keep Your Eyes Open and Stay Encouraging
Learning how to code is hard. It’s frustrating, confusing, and it’s really easy to feel like the only person who’s struggling; even when everyone else is quietly just as lost.
That’s why I make it a point to watch for signs of discouragement or confusion, and to address them directly.
I’ll say things like:
This stuff looks weird at first, but I promise there’s a moment soon when it will all click.
or
Don’t worry if it's not sinking in yet; I had to practice this over and over too.
Even experienced engineers benefit from reminders like these. Encouragement isn’t just for beginners — it’s for anyone doing something new.
6. Make It a Conversation, Not a Lecture
The best learning environments are interactive. I don’t want students just passively absorbing — I want them thinking, talking, and experimenting with me.
That’s why I frequently stop and ask:
Does that make sense? I know that was a lot I just threw at you. Who has questions?
… or prompt for involvement:
Who wants to take a guess at what the next step here should be?
And when I’m live coding, I’ll often pause and invite a bold student to take the reins:
Hey, wanna try coding this next part? I’ll spot you. Take your time.
We work through it as a group. It becomes less of a monologue and more of a shared experience. People engage more when they’re in the code — not just watching it go by.
Live group programming, in particular, is one of my favorite tools. It keeps everyone alert, builds confidence, and creates a sense of team problem-solving. Even if someone’s just reading a line of code out loud or pointing out a typo, they’re participating — and participation leads to retention.
Teaching Is a Long Game
Try to focus on the long-term outcome. You goals should be to help others build confidence, fluency, and independence over time. From this can grow a real love for coding and a desire to keep learning.
That’s why you should take your time, use real code, give good scaffolding, explain your reasoning, encourage participation, and stay positive. It works in the classroom. It works in code reviews. It works in 1:1s.
Teaching isn’t just about transferring knowledge. It’s about creating space for understanding and walking beside someone until they can find their way on their own.