Learning to code is really hard and teaching code is even harder. There is no bootcamp in ‘How to Teach Code’. Most teachers do not have any formal training in education and come from a software background.
I’ve had the pleasure of working with several bootcamps in different ways (as a student, teacher or experience partner). I’ve also:
- Ran a code Meetup club teaching code
- Delivered a Hackathon series
- Helped out with various learning code events.
It’s amazing how little regulation there is in teaching code. The result is students can receive wildly different experiences. I’ve seen some of the best education on the planet being given away for free. Yet I’ve also seen other bootcamps delivering their students 3 months of confusion and charged £9,000 for the pleasure.
I’ve seen bootcamps struggle along until they inevitably fail whilst others just continue to grow and grow.
Below is what I’ve learnt myself about the difficulties in teaching code. How to teach code it in a way that gives the best experience for students. And how to grow a sustainable business by delivering a great experience.
(Note – as a student on a bootcamp it is worth reading this. If your course if making some of these mistakes you might be able to help save your education by encouraging some better practices.)
Part 1 — Why Learning Code is Hard
Learning to speak computer is hard. Due to general variance in the way we think, perceive and learn things; some people find it frustratingly easy and other people find it impossible. For the average person, it’s just really hard. However, it is totally doable…
Learning your second and third computer language is comparatively easier and only gets easier the more you know.
You don’t know what you didn’t know
The problem with teaching it is that you have to know a lot about talking computer before you are qualified to teach others to speak computer. Yet for you learning a new computer language is now quite easy. It’s hard to understand the difficulties you faced 10 years ago. For you, it’s just assigning a new bunch of syntax into ready-made concepts.
The first human spoken language is the hardest to learn as you’ve never learnt a language before. Privileged students get taught Latin to understand the roots of how languages are built. They can quickly understand new modern languages that are used around the world with this core knowledge. Similarly, computer scientists commonly learn C so they can understand the root of most languages they encounter, even though they don’t expect to really ever use it.
Learning a language in school is good. You slowly build up a bunch of syntax over many years and eventually get you to be able to understand and speak most things, but it takes immersion to really get the context and master it.
Alternatively, you can go to a foreign country and with lessons and constant immersion you will learn a lot more in 3 months. But this is still a bewildering and challenging experience and you wouldn’t be qualified to take on a high-level job in a complex business environment, but you could work in a coffee shop just fine.
Compared to speaking computer though, you already know your mother tongue, this is your language zero and it gives you have a bunch of template concepts to reference from.
Finding a reference point
People don’t speak computer, there is no language zero for any frame of reference the first time they learn.
You can practice speaking computer a few hours every week to learn syntax, but it will take you years to become proficient. If you study a lot of hours a week it might take you a year to feel comfortable. Or you could even do a 3 month bootcamp with full immersion.
However, you still aren’t a master and a lot of what you say (write) will come out a bit retarded and a lot of what other people say to you may go over your head, but in your own time, you can look it up and build from there.
You won’t be qualified to demand a high-level job but entry-level junior work is perfect.
In summary, learning a completely new thing is not easy and teaching something you know deeply to a beginner has a lot of challenges you need to be mindful of.
This is the broad-line concept of the difficulties to teach someone their first programming language. The rest of this blog answers the original question of ‘How To Teach Code’
Part 2 – Lecturing teaches nothing, Make the complex simple
A teacher will commonly like to show students everything they need to ever know about a concept so they can kick off and be a pro. This could be an hour lecture. Computer scientists (after learning C) can handle that. Code newbies can’t.
After the first 5 minutes of lecturing anything else you say is pointless and goes over their heads. Stop talking and go through some exercises they can follow along.
(If you’re learning via video stop after 5 minutes and do the exercises).
Exercises need to be pitched at the right level at the right time. With a group of studnets who learn at different paces and in different styles, this is no easy task. It can take mastery to understand what is appropriate when and I cover this later on.
Lets pause for another analogy.
Learning to Bike
Lecture 1. You go deep into the physics of how balancing on a bike works and the shifting of body weight to apply correct force on the pedal to provide momentum. This is core stuff and super important.
Pause for a coffee break, your structuring the day well.
Lecture 2. You talk about steering and how to lean into the corners. It doesn’t take as long as expected. Your on a roll and a bit excited so you explain how riding no hands isn’t even that hard when you understand the above processes correctly. One student, Jimmy, say’s he rode a bike once before and say’s no hands is really hard. You cleverly correct him that it just takes proper understanding of the physics and he clearly wasn’t taught very well by his last teacher.
Wow that was fun. Lunch break — yea, munchtime whooop!. You tell some students about times you were cycling in the alps and how beautiful it was, but also remind them how you cycle to work every day even in the rain, being a cyclist isn’t all fun and it’s good you’ve told them the high’s and lows. (You make sure Jimmy was listening. what a dick.)
Afternoon — lets put it all together!
You jump on a bike and cycle around the class for a bit so students can see just how it works in the real world. You over-emphasise you’re movements and almost fall off yourself showing them how to lean into corners as your going slowly so they can see it properly. It all must be coming together in their minds in glorious perfection. Shit they must know everything about biking by now.
You are such a good teacher these are going to be the best bikers ever.
Delay other plans
You already have plans of how you are going to explain changing gears, navigating the road safely, fixing punctures but it’s really time to give them a go. You check you metal list of biking and yep, you’ve really taught them the core fundamentals that covers everything you need to practically ride a bike.
That other stuff is extra fluff and you had time to throw in the no hands concept for anyone that gets it quickly. (that was smart, go you!)
The big event
You the hand each of the students a bike.
The first student falls flat on the floor like some retard. Two others try to help him but now another student tries to get on their bike and she falls into them causing a mess. Blimey they are so stupid. These are going to be the slow group, you make a note to spend extra time with this group an walk over to help.
You untangle their bikes and try to hide you’re bafflement at how stupid they are as you ask them what the problem is. You’re distracted by a loud yelp and look up to see there is chaos everywhere. What’s going on? Why don’t they get it. Next thing you know your rushing round madly trying to help each student get on a bloody bicycle but none of them seem to understand the first concept of how to even maintain equal balance. This was the start of the first lecture, they must have understood that they were all listening!
Soon one student is crying, two have injuries and another is walking out the door claiming they are never going to be able to ride a bike. Smart arse Jimmy smart trousers, smart ideas, clever twat walks up to you. He asks why you didn’t just give them fucking stabilisers.
This is really awkward.
Death by Theory
At its simple level coding is just knowing a bunch of syntax and the context around when to use it. That is literally it. in fact you don’t even need to know the syntax all that well if your able to look it up at the right time.
But like learning to bike the theory is largely pointless without doing any coding. After 5 minutes of talking anything else is wasted. The student has no real concept of what you are actually saying and however, much context and syntax you throw at them it still doesn’t help.
People learn by doing.
Students might look like they’re following along but if they aren’t doing something their minds regularly wander away from any abstract theory, even when they are trying to concentrate and even when its 6 minutes in.
Don’t even bother showing them the super simple version of a use case, just do it with them.
Together make the simplest core example of this concept/method/function without anything else clouding it. Just the syntax of what it is. Then have them build it again but with a different variable.
Depending on the concept give a slightly more complicated version or go into some of the context of where to use it. Then do let provide some exercises for them to do on it.
Carry on building the layers of complexion along with them with bigger pauses for longer unassisted exercises as you go further.
By the afternoon they are ready to use the set of idea’s all together in a project situation or in solving harder algorithms. Don’t teach them more shit. Just be there to guide them as different things go wrong and let them self learn and really explore what they can do with what you taught them in the morning.
Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.Steve Jobs
Part 3 – Good Exercises by Blending Context with Syntax
In terms of a recipe for building exercises, start with SYNTAX
Give them a small amount of syntax. Have them use it.
If this is day one of learning a language then you’re probably going to have to teach some more syntax and have them use that.
After they’ve learnt a few things they can put these different syntax’s together to have them interact and start understanding the context of what they’ve learnt.
If this is a few weeks into learning a framework then they might need some context first. But keep it short.
Code used to cover a concept may be in various places across multiple files and their may not be an intuitive first place to teach syntax from. Try and start with the first logical user action. Don’t show them the whole path followed by the user action just show them the syntax of the first piece of code you write to deal with it.
Then add in the context of what that does and which other files or functions it might be interacting with. Go through the syntax of the interaction with the second file/function from the first one.
Build the full context of all interactions with this first function. Then follow the paths of the second function, third etc… until you have closed the loop.
Make sure you have made the loop of logic as small and clean as possible for this first demo and ideally have something happen at the end of it. If it is a really long loop then break for some exercises before completing the whole thing.
Things to Note
As you’re going along it is also handy to put comments on each function / method so the students have a well commented demo file they have built themselves to refer back to. Of course it also gets them into good practice blah blah…
Print out a lot of what your doing along the way to show what each thing is doing and what the student should expect to along the path of logic. this can help provide context and help them master debugging so you don’t spend as much time helping them in debugging.
Separate Projects and examples
When teaching a framework you’ll usually have a project that everyone is working on to provide the overall context and get them building something themselves. Something like a Facebook for Cats etc.. Whilst giving lesson examples its tempting to just show them using the same project analogy. It is really important that you use a different project analogy.
It could just be a Facebook for Dogs so the student just changes the word dog to cat.
but ideally you want it to be a slightly different concept so all the further back end things will have different names such as database collections etc…
It’s important to provide a list of useful resources but you must also expect that not a single resource will be used unless you give them a specific reason to use it in their exercises.
So the most important resources you should blend into their exercises.
So an exercise asking for a super simple API reference look up of a specific term they are using will get them using API docs. You want to end up with them navigating these themselves without ever having to ask but to start with you need to do it for them.
You are teaching callbacks and you want them to use the loupe tool. Don’t just leave it hidden in a list of useful stuff to explore. Literally give them a few exercises where they have to interpret a callback function you’ve given them by using the tool. Then perhaps they can try making the callback function work differently still using the tool.
Now whenever they are stuck on callbacks they will instantly think to go and use the tool and probably have it saved in their favourites. See how useful this is compared to it being hidden in a slide deck they won’t have open next week when they get stuck.
Part 4 – What to do about Homework
Home-Work vs. Extra Work.
As with the resources. its tempting to just give a list of extra work which students must do. But just assume that it largely won’t be done. Everything that must be learnt to get to the next level must be explained and done inside the classroom.
Students need to get closure on an idea and way to cement it going forwards. Allow time and space in your working day or at the end of each week for students to step back and assess which things they have learnt well and which things challenge them. They need to identify the key parts they need to practice more.
This is especially important over weekends. It’s so tempting to provide big projects as they love building stuff. Students aren’t stupid. If they have the correct tools they can make projects themselves that add complexity and this should be self-lead. Sure students are keen to learn as quickly as possible but some will always have a reason to not be working on the weekend, be it a job or a birthday or just life….
Define What is Required and What is Extra
What should be enforced is reviewing any content they haven’t understood and making sure they have caught up with that. By next week you need everyone at the same level ready to move onto the next set of concepts on an even footing.
Example Bad Homework – Add google maps journey for each cat user in their Catbook project.
Some students will get really into it and learn lots. Whilst other students might be working all weekend to pay for their course and still lost on stuff from the week before. It isn’t fair to assume all students have mastered the GoogleMaps API by Monday morning as this simply isn’t the case.
You shouldn’t require Maps API knowledge for the next lessons and should teach the new things yourself first.
Example Good Homework – Take a test of the things covered in the week. Any identified weak points complete suggested extra exercises
This homework helps students get closure on what they have been learning during the week so that as a teacher you know that what the course directly covers is being learnt.
As an extra, you could suggest the maps project idea for those with time to learn cool stuff. You don’t want to hold people back that can learn faster than others. But you also don’t want them to be learning lots of new material that you will cover later as they will get further ahead than the others.
It is generally better to try and get them to a higher state of proficiency in the same topic rather than them just learning the topic for next week which will give you a completely divided class.
Part 5 – Feedback and using Questions as a tool for teaching
Having a good feedback loop for students to anonymously give their opinions is essential. I’ve explained the fundamental layout and speed of teaching a concept, but in the real world, your students should be setting the speed.
Having data on what your students do and don’t understand is essential. It allows you to dynamically deliver the best content at the right time and to continuously improve it for later students.
Questions as a tool for teaching
As part of feedback simply asking questions during any lecture can be your speedometer on the fly. This seems obvious but is actually an art in itself.
You must AVOID LOADED QUESTIONS
When you finish explaining something difficult, don’t simply ask if that is okay. If you don’t get any real answer this is not a sign to simply move on.
Instead try asking if someone can explain the concept back to the class. Now if you don’t get an answer is that a sign to move on? Of course not.
When your starting off people will be shy and won’t really say anything. If you pick a student to explain a concept and they look at you with eyes of terror, don’t just move on! It may save them embarrassment but it doesn’t solve their problem. Go back through the concept in a more simple way or ask a more simple question.
As you get to know the class and they get to know each other this will be easier. You should cultivate them getting comfortable talking in front of others. They should be confident to try and explain things they don’t really understand. Then you can see exactly the parts they do and don’t get. Ideally, you can have an active group discussion which is a great dynamic to hear different people’s understanding.
Explain to Each Other
A good exercise can be pausing the whole class and getting pairs of students to explain a concept to each other. When two students who are clueless get a chance to find out the other person has no idea what is going on, they don’t feel embarrassed to ask a question or admit they don’t understand.
After the 60-second break, people will be psychologically ready to talk and when you ask for feedback on which groups got it you’ll know exactly what’s going on. Even if only one person in the whole room got it you’ll know and they can explain it to everyone. You’re quickly breaking down the barriers to an open discussion and cultivating peer-learning instead of isolated drifting.
Part 6 – Teach Students at the Same Level
Trying to teach students of varying degrees of proficiency is a nightmare and a recipe for complete disaster.
If your course accepts absolute beginners then it is an absolute beginners course. Having more advanced people on the course will course a nightmare as you try and teach different levels to different people.
Even with just a group of absolute beginners, most will be very slow. You risk some students finding out they hate it whilst others finding out they are geniuses and going at a million miles an hour.
Most courses are aimed at people who have a basic understanding of JS, CSS and HTML. I personally think it is wrong to take money of any student for a one month or longer course if they have never coded before. They have no idea if they would like it or would be good at it and need to at least have some form of test experience first.
The best strategy is to have some none-arbitrary pre-requisites that all students have to pass to be eligible to take the course. This will cut out the people that aren’t right for coding and will mean you have a group of people who are able and interested to learn.
You could offer a small pre-course for those to learn the basics with you or facilitate the odd meetup each week for newbies to work on the pre-course stuff and learn what’s right for them.
The Business Sense Behind Turning People Away
I appreciate that a Bootcamp is a business and teachers need to earn money, classrooms need to be paid for. But it is very important that you turn away people who should not on the course.
It is better to deliver a good education to a few people than to sell an education you can’t deliver to many people. The ones who could have learnt will have reduced learning and the ones that shouldn’t be there will fail and demand their money back. You will have chaos on your hands and a bunch of bad reviews and your business will go nowhere.
If you only give your education to those capable of receiving it you will supply a great experience and deliver a cohort of students that will represent and grow your brand. This will lead to a sustainable long-term business.
But Anyone Can Learn To Code
Considering I run the Growth Mindset Podcast which teaches how you can do anything and to never tie yourself into negative beliefs. I don’t believe everyone should learn to code.
I agree that hypothetically any human capable of learning a language should be able to learn a set of definitions and behaviours for a group of new words and thus eventually be able to learn to programme. But, how many people:
- Have asked you the most ridiculous questions about a computer?
- Will diligently keep trying after 4 hours of their code not working?
- Enjoy spending 30 hours teaching a computer to do Sudoko when they could be watching Netflix?
Not everyone would enjoy it at all and accepting someone onto a course who has suddenly developed an aspiration to learn tech who has never typed a line of code in their life is dangerous.
In much the same way, any human who can sit still for 5 minutes without their phone or a book or TV is completely physically able to take a 10-day meditation retreat. On the retreat, they need to sit still for ten days in silence and not read, write or watch anything but their own mind. I’m pretty sure it wouldn’t be most peoples cup of tea.
I’ll repeat, learning to code is really hard and mastering it is a long-road. But learning to teach coding is just as hard and there is a much less documented set of resources.
It is really exciting to empower people with such an awesome skill. You want the class to learn as much as possible from their time with you but teaching newbies is depressingly slow if you’ve never done it before.
Quality not Quantity
Instead of trying to teach them as much as possible you need to focus on teaching them as well as possible. If they have no depth in their knowledge your teaching has been completely pointless.
There is no point rushing to complete everything they need to know to build a full-stack application when they haven’t understood all the parts you’ve taught so far. If you find yourself doing parts for them and they don’t understand everything they can’t do it without you. When they leave the course they won’t be able to do it again and you won’t have a bunch of students going out to the world showcasing how good your course was.
Some of the best bootcamps just focus on getting really good at the core concepts so that students have the power to teach themselves things like React and other frameworks afterwards. If they tried to stuff it all into a zero-to-hero course they end up with a lot of people who don’t quite make it and just fall back to zero after-wards.
It’s better to teach them half as much material and have them master it. They must feel really confident to go out and carry on using what they know and build on it. If they finish with confusion about the stuff you’ve taught them they won’t be able to get jobs or make cool shit => the course and your efforts will all be for nothing.
Done means Done
Just like building software, it’s done when it’s done. You can’t release an app that’s 90% done as it just doesn’t work. When teaching important concepts if students 90% get it but can’t practically explain how to use it then they can’t use it.
Don’t teach them more stuff in the hope it will just happen to make sense. Complete what you’ve started or empower them to get the final 10% as their homework.
Start with Small Steps
Like learning anything, learning to teach needs baby steps and learning by doing is key. It’s better to practice teaching in a smaller environment before launching into a full course.
Try running a meetup event or a weekend course. Find some students to mentor. I love it but you might hate it and you can’t tell unless you’ve tried.
This may sound obvious but some people literally start a bootcamp and day 1 is the first time they have ever tried to teach someone coding. DO NOT DO THIS!
Why do it?
Teaching is the best thing in the world. It’s not easy but soon all your students will be talking computer and you’ll be so proud of getting them to talk properly. Even smart arses like Jimmy (see bike analogy) if you haven’t killed them in the process. Watching them master the skills and go out in the world and build cool things is just awesome.
So please try out these principles, add your own personal flavour on top, and provide any comments to help others teach better.
If you enjoyed this post you might like some of my other writing about Coding and learning:
If you enjoyed this please give it a clap and subscribe to learn more =]