It’s Teacher Time
by Sam Morgan
11 August 2015
We’re getting a few calls from prospective students worried that Makers “don’t do teacher time”. Apparently, some of our competitors have been taking our approach to educating developers — with an 86% hire rate — as if it’s mostly a laid-back, ‘do as you want’ approach. I’d like to set the record straight about how we do education at Makers, what our reasoning is, and why it works.
Before we kick off, I’d like to nail one thing down: we don’t like the word ‘teacher’. Teachers are for when you were doing Year 11 GCSE Biology, and if you’re anything like me you can write pretty much everything you remember from those long classroom hours on the back of a postage stamp. ‘Teacher’ implies that the new neural connections and internalised ideas — which form the backbone of learning — are somehow in the hands of another individual, who can impart them to you with little to no effort on your part. You know, that works some of the time. For a while. Sit me in an amazing lecture by one of my science heroes and I’ll drink in every word. Put me in a classroom with them for 12 weeks, and I’ll be begging for something interactive within a day.
At Makers Academy, we use the word ‘coach’. Being a developer is like being a sports player: less about what you know, and more about how you do it. Because of the obvious connection with sports, ‘coach’ seemed like the right word.
How we do education
Here’s a typical day for a student at Makers Academy:
- 9am ‘standup’ — relate what you did yesterday, what you’re planning on today, where you got stuck, and how you got unstuck. Lots of clapping and feel-goods.
- 9.30am ‘breakout’ — depending on what got brought up at the standup, students might need to have a coach demo some stuff, or visualise things using a board.
- 10.30am pair programming — we have an awesome project-based curriculum (more on that in a moment). Students pair with coach and alumni helper support throughout the morning, building real stuff using tools and practices we’d expect from a professional junior developer. From day one.
- 1.00pm lunch — our cohorts tend to lunch together. Generally they like to go out in droves to one of Shoreditch’s fine local eateries.
- 2.00pm meditation — programming is extremely challenging. Meditation helps keep a lid on things, keeps you grounded, and keeps your brain sharp.
- 2.30pm ‘standup’ — same as the morning. Keep the feel-goods flowing.
- 3.00pm ‘breakout’ — sometimes students don’t need this one. They’re usually pretty keen to get back to the project they were working on.
- 8.30pm — beverage (personally, I prefer something non-alcoholic) of your choice at the pub two doors down the road. De-stress.
Throughout the day, we’ve got table tennis, yoga, discussion groups, excessive N64 gaming, and the odd NERF battle. These kinds of activities are designed to keep your brain alive and your motivation intact.
Now I’d like to pick a few key parts and dive into them a bit more.
Contextualised learning. Here’s the problem with lectures in a bootcamp: they introduce overwhelmingly complex topics at an abstract level, without giving you any time to ground yourself in the realities. An example: I could give you a good hour on the Open/Closed principle of good programming. Fun, hey? You might come away with a batch of notes, some words about classes and modification ringing in your ears — but no real ability to apply these things. No contextualisation for the abstract concepts I’ve been chucking at you.
By planning structured projects, then waiting until students raise issues within them at the time they’re doing them, we can give tighter, more focussed breakouts on concepts as if they were ways to solve problems. No front-loading. Just “oh, you’re having that difficulty because you’ve left that class open for modification, here’s what that means — oh, and by the way, that’s the Open/Closed principle in action”. Want to know more about this stuff? Read up on Jerome Bruner, the educational theorist credited with the whole caboodle.
Doing, doing, doing. I love watching stuff. In my final year of Uni, I bunked off all my relativity lectures because I couldn’t understand the lecturer’s handwriting, and because I’d found a series of lectures on iTunes U — lectures given by the world’s foremost expert in relativity (who had great handwriting). I swallowed those videos whole, ignoring the increasingly persistent requests from the Dean that I did some of my assignments, and went into the exam totally comfortable that I knew this topic inside out.
Except I didn’t. I flunked it. All year I’d been watching, digesting, chatting about relativity, but I couldn’t actually do any of it. Worst of all, I stared at the first question and I knew that I knew it — but I had no idea how to make my brain do the somersaults required to come to an answer. That sucked. We don’t want students to feel that way when they hit their first programming job.
Programming is a lot like sports. You can learn about ball trajectories and watch swing techniques and understand physiology and sports psychology, but none of that counts for a damn when you’re facing a tennis serve, or a cricket bowl, or a penalty kick. To do sports right, you have to practice, practice, practice: and so with programming.
Programming is all about coming up against vaguely familiar problem sets, having no idea how to solve them, and working it all out from scratch. That’s a skill, not a bunch of knowledge in your head. You can watch videos and lectures and code-alongs all day long, but if you want to be able to build stuff yourself, you’re much better off bashing your head against the brick wall of a problem for a few hours until you get a glimpse of what the solution might be. Plus, it feels great — the sense of satisfaction from solving a difficult programming problem is like nothing else on earth.
Pairing. At Makers Academy, like almost every good software company, we advocate pairing. ‘Pair programming’ is a lot more than just ‘working in a two’. I did a lot of ‘pairing’ at school, and I hated it — either my partner was way too slow, or way too fast, for me to get anything from them. Pairing meant the additional stress of managing another person, or my own feelings of inadequacy, in addition to the stress of the task at hand. Programmer pairing is nothing like that. Well, OK, it’s a little bit like that sometimes, but learning how to be professional about dealing with those little interpersonal stresses is key to working in any kind of programming team. Which we want all our grads to do.
By self-imposing a structure on pairing, we can leverage so much from both parties. Weaker partners should feel like they can look dumb in front of stronger partners. Stronger partners are challenged to analyse and identify topic misunderstandings in weaker partners, and use their superior topic knowledge to explain things in just the right way. Pairing is about getting two people into the same headspace around a problem, feeling great, and levelling each other up. Plus, it develops those critical skills in articulating and discussing tech problems that our hiring partners love so much. From an educational perspective, it keeps both parties in their Zones of Proximal Development — take a peek at the Wikipedia article on Lev Vygotsky, another educational theorist, for more on that.
Keeping it real, from day one. Our hiring partners are constantly all “we love your grads because they know how to actually be developers” and “we hired x to work in C#, a language you guys don’t even do, and they picked it up in 3 weeks” (for real). It’s a pleasure to hear these sorts of things, because it’s a massive validation of something deep in our bones at Makers Academy: authenticity.
Authenticity means real projects. It means real problems. It means real-life professional developers guiding and reviewing your code, and helping to get you out of a bind. It means lunchtime talks from higher-ups in top tech companies like Tesla and IBM. It means using full-on development tools from day one, both as a means to learn them and as a way to stay in-sync with the rest of your cohort. Authenticity — the idea that we should keep the Makers Academy experience as much like an actual dev job as possible, with some extra support — is what guides pretty much every major curriculum decision we make, how our coaches operate, and where we’re headed as an educational institution. Our students tell us they “wish [they]’d known ten percent of this education theory before going to Uni” so they could have accelerated their learning. They tell us “you’ve got to get stuck, to get frustrated, because that’s how you learn”. They tell us how fun, how exciting, how memorable, their time is here. We credit that to authenticity. To being a Maker as soon as you step through our doors (or, if you’re on our online course, as soon as you log on to your first hangout). To feeling less like a school, and more like an apprenticeship.
Thanks for reading
Whew, that was a long one. Hopefully I’ve put paid to some of those concerns about teacher time at Makers by elaborating on our contextual coaching, our ‘do-do’ ethos, and our focus on authenticity. If you want to read any more about the visionary academics who’ve informed the structure of what we do, check out Jerome Bruner, Jean Piaget, Benjamin Bloom, and Lev Vygotsky. Otherwise, feel free to drop me a line any time at firstname.lastname@example.org. I look forward to hearing from you.
Originally published at blog.makersacademy.com on August 11, 2015.