# Three Rules for Teaching Beginners How to Code

After teaming up with Elliot and Jack from CodeAtUni to work on a startup last year, plans were in the works for me to help them with teaching after the startup stress was over.

As you probably guessed from the name, CodeAtUni run coding workshops at Universities. Anybody that attends the University can usually sign up to the workshops, which brings a diverse range of thought to the clasroom. From my own experience, the most common subjects that CAU students study are business, marketing, and economics.

I've helped out in the classroom four times with CAU so far. At Kings College London and Nottingham Business School. The first time I helped out in the classroom I was surprised to find that teaching is ~60% self-censoring and ~40% communication. To teach absolute newbies how to code, teachers have to learn to pick their words very carefully. Getting this wrong is obvious when there's a room of confused faces looking back at you.

In the interest of sharing, coming up are three rules that combine the best of what I've learned so far from first hand teaching experience, with the outcomes of conversations with more experienced teachers (thanks to Ed and Adam).

## Rule #1: Teach problem solving before answers.

For most of us, when invited to teach someone how to do something new, the logical thing to do is show them, step by step, *how to do it*.

Ostensibly, at first, this seems to work. But before long people forget the learned steps because brains don't hold onto information that way. Brains appear to retain information that's earned, and not handed to them. After all, if we had to work for it, it must be important.

One of the first things I noticed when watching more experienced teachers than myself was that they seemed determined not to give students direct answers to their questions. Instead, the teacher might drop a clue to point the student in the right direction.

This seemed counter-intuitive to me at first. Surely if the student just got the information they needed the class would run more smoothly? Turns out my intuition was wrong.

Only bad teachers give out answers like they're a tanking cryptocurrency. Effective teachers help students build a framework for problem solving. Then students can continue to learn without them.

## Rule #2: Encourage cheating.

In school cheating is discouraged because the system can't function if everybody cheats. It turns out this isn't a very effective way to learn because information remains static, and not free to migrate between brains.

When students are encouraged to share what they know and ask for what they don't, it has a positive effect on the overall progress of the class. Individual differences average out as students exchange knowledge with each other. It's a lot of fun to cheat, too.

Teachers even gain from cheating because often they'll only need to explain something to one person in the class. Before long, the explanation will have made its way around the class driven by necessity and the curiosity of the students. The teacher is now unblocked to continue helping other students.

Cheating even helps the cheatee because, as they explain their solution, they have to understand it enough to communicate it effectively.

Software devs are all too familiar with this effect: you're stuck on a problem for what seems like forever. With reluctance, you decide to ask somebody for help. As you carefully explain your problem, the answer pops into view – as if it were there all along – and you're left to walk away in shame.

## Rule #3: Lead students to water, don't drink for them.

Teachers are like bicycle training wheels. They're required for a short amount of time to gain proficiency, but the real goal is to make them unnecessary.

When a student is stuck, the best way to help them is to train them them into a self-guided learning behaviour. This takes time upfront, then the rewards are clear as students become more autonimous. To do this, encourage them to frame their problem using precise language so that they can grapple with the problem.

A contrived example of this is:

Student: "I just want to make the spacing on the top of this element larger."

Teacher: "Okay. Do you remember what we called the CSS property for adding a gap between elements?"

Student: "Um... margin?"

Teacher: "Exactly. So what do you want to do?"

Student: "Add margin to the top!"

If the framing exercise doesn't help the student reveal the answer for themselves (50% of the time it will), have them search google for the answer.

Repeat these steps if the student still can't find the answer, adding just enough information to orientate them each time, until they find the answer for themselves. The moment lightening strikes is the moment they learn.

I quite like enjoy teaching people how to code. I never thought I would, but it's turned out to be a fulfilling pursuit.

Sometime in the near future I'd like to have a go at teaching somebody with little knowledge the skills to become a full stack web developer. If you're interested, email me on yo at nosaj dot io, or tweet me.

If you work for a University in England and want to run a intensive coding workshop at your school, contact CodeAtUni and they'll hook you up.