Helping People Learn to Code

Hello there. I’m Steve Barnett. I used to work at codeX and now help to run CTFEDs, RailsBridge and (soon) also codebar. I also facilitate front-end and UX workshops for companies. The common denominator of all these different projects is that I really enjoy helping people to learn how to code. Over the years and many events and workshops, my teams and I have made a lot of mistakes.

If you’re teaching others how to code, here are some hard earned lessons and handy tips to make the whole experience more fun and effective for everybody involved.

The Lessons

Amongst many other things, we’ve found it most important to think about three things when planning our workshops:

• Foundations (solid blocks to build on),
• The principles behind Agile (short feedback loops) and
• the practical wisdom in Training From the Back of the Room by Sharon Bowman (positive environment). The book provides a great framework for designing training, I can’t recommend it highly enough!

But first things first.

Foundations

Something we’ve learned is the importance of being clear on why we do what we do. Things that seem obvious to an experienced developer might not be for a junior. We also value creating a solid base for everyone to start from. We’re helping people see what the most important blocks are and how they fit together.

At the workshops, we try and help people think about their journey as a developer by asking some probing questions: What do you already know about programming? What are the things you want to learn? What will you do with what you learn?

Agile

Cognitive neuroscience says that we learn best when we are motivated and have timely evaluations. If you take any inspiration from the agile manifesto, it should be this: make your workshop preparation about allowing for iterations, short feedback loops and reflection:

Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts its behaviour accordingly.

One way to do this are repeated exercises with things like code katas (like codewars, exercism, or CodeNewbie). These let people check in with their progress and adapt to new challenges.

We also often use retrospectives-like activities: regular get-togethers where teams reflect on how they’re doing. We often use these three questions:

• What worked well?
• What didn’t work well?
• What will we do differently from now on?

This sort of quick feedback and reflection helps solidify newly acquired knowledge.

Training From The Back Of The Room

TFTBOTR talks a lot about optimising the learning experience through the 4 Cs:

• Connections
• Concepts
• Concrete Practice
• Conclusions

Our experience shows that there are a few different elements to this.

Connections: Welcome! :)

This might be one of the most important (and often overlooked) factors: creating a positive, welcoming, environment where both facilitators and learners freely offer their assistance and students aren’t afraid to ask questions is essential for effective learning.

That’s why a great training starts by creating connections; between the participants but also to the topic of the course, the aim of the training, and the students’ personal goals. While it can be hard to get people to ask questions, it’s very important that they do. Someone who’s asking questions is someone who’s learning: they’ve spotted a gap in their knowledge and they want to close it. This brings us to the next point:

Concepts: Tools, Tasks, and Terminals

TFTBOTR says that learning has the highest chance of success if it’s self-motivated. The goal of the facilitator is to give nudges and signposts rather than entire lectures, and to provide tools like timeboxing and the pomodoro technique 🍅 so that learners can make the most of their time.

Few courses have very work-like conditions: a team-work on the same project, on the same repo, at the same time. Doing this brings up all kinds of exciting code and interpersonal issues! It also allows students to make connections between things themselves though: they’re doing rather than listening.

Concrete Practice

Simply put, that means that in any “How To Code”-course, most of the time should be spent actually writing code. We make sure that people have biggish blocks of time so they can sit and focus on a task without being interrupted, and really get their teeth into it. At the end of each block, there’s a chance for mentor interaction. Lecture-type things still have a place, but they should be short and interactive.

Conclusions: What's next?

A great facilitator will encourage their students to start thinking about what comes after the training: how can they take what they’ve learned outside the workshop? That can mean talking about things like:

• the (potential) long life of a piece of code,
• other people using their code: their team, their future self, consumers,
• the importance of testing.

These can all spark motivation to think further than the workshop. You’ll end up with excited participants who are keen to share their experience and plans with each other and go out to tell the world about their awesome work.

Steve Barnett works as Front-end developer and User Experience consultant.