10 Lessons Learned from 100 Weeks of Teaching FEWD

Towards the tail end of 2015, I achieved a personal milestone: I completed teaching my 10th iteration of GA’s 10 week long Front End Web Development course.

After taking some time to reflect, I’ve decided I’d like to take this opportunity to illuminate some observations I made along the way from 0 to 100.

TL;DR:

Teaching isn’t easy. Practicing (ie: teaching a lot, and often) helps. So does candy.

Ok let’s do this.

10. Power Points are the devil.

In general, slides are lame. Like, really, really lame. Admittedly, when used well, they can be the central backbone of the class — but typically they are not used well. Typically they start out with the best of intentions and devolve into a cluster — ahem — (starts with f and rhymes with duck) of text heavy walls of awful.

As such, I stay far away from Keynote, powerpoint, even RevealJS (which is awesome and beautiful). No one wants to sit in class and watch slides click by. I try my best to treat class as a conversation. It keeps energy flowing — for the students and the instructor.

9. Never stick to plan.

I should emphasize: always have a plan. Just don’t insist on sticking to it. Classes should be dynamic. If they are conversational, they will be dynamic. So go with the flow. If you’re discussing topic A and certain students have great questions that steer the conversation towards topic B, don’t steer away. Instead, delve deep into topic B.

Delve as deep as needed in order to close the discussion thread. Obviously, temper this a little bit, getting sidetracked helps no one. But more often than not, if the conversation is informed (ie: students are clearly up to date with course material and are asking relevant questions), chances are topic B can in some form or another be merged back to the topic at hand — and probably illuminate an aspect of topic A that the students had not necessarily considered (and perhaps you had not considered bringing up).

8. Move around!

Another problem with slide decks: you are prisoner to your podium. This is no way to live. And certainly not how one should teach. The blackboard, as obsolete as it may seem given today’s technology, still has it’s use cases.

Whenever I need to sidestep into a topic B-esque situation, or if a student asks a particularly good question, I step away from the machine, pick up a dry erase marker, and get my Picasso on.

Diagramming things out helps all types of learners reason about the task at hand. It’s a good strategy to increase in-class engagement + get a few chuckles in (I draw really, really terribly. My lack of real talent always helps lighten the mood, especially when we are covering difficult topics).

7. Challenge relentlessly.

One happy side-effect of moving around is it tends to dissipate a good amount of energy. This is a good thing, because:

var student = null, isClassEngaged = false;
/*
 * ... something, something mutate student ref ...
 *
 */
if ( student === "alert" ) {
    isClassEngaged = true;
} // #facts

A surefire way to keep folks awake and alert aside from zipping around from corner to corner of the room (sometimes, for the lulz, I’ll randomly jump over to the back corner while lecturing…but I digress) is to make them think! Hard.

I’m always trying to think up ways to push the envelope when it comes to explaining concepts. Often times — in my experience — two things are required in order to help guide the class as a whole to properly grasp the subject matter:

• a good analogy to set the stage for the concept and,
• a good challenge to force students to think about the discussion beyond the classroom.

Typically, after I introduce a challenge to the students, I’ll ask them to form groups and tackle the issue. I’ve heard this technique described by various course producers as a “We Do”; in my classes, we do’s are an invaluable tool for keeping everyone engaged and alert.

6. Cover comprehension, not concepts

What do a library archivist, a pizza hut, and ducks in a pond all have in common? They’re all instrumental in explaining concepts in javascript!

Analogies, especially unorthodox or ridiculous ones, do super well in aiding overall class comprehension. Coding is abstract and complex, but in my experience, comparing a return statement to a pizza delivery or ducks in a pond to the scope chain go a long way in helping solidify in a student’s mind the what, the how, and most importantly the why of a particular concept.

Also, concepts have two distinct properties in most core curriculums: there are a lot of them and they tend to build on one another. As such, I would argue that a solid foundation on the basic principles of programming will go a long way in helping students learn the more advanced stuff faster — and with more ease.

5. Think hard about retention initiatives

Coding is hard to teach. It’s like riding a bike: you can read all you want about the gears and the brakes. You can understand how a bike works inside and out from a materials science and physics perspective (L=Iw, amirite?), but until you jump on one IRL and scrape your knees a few times, you’ll never actually know how to ride a bike.

The same goes for coding. We can talk about scope chains and duck ponds, we can discuss the pizza delivery effect and return statements till dawn — but until a student sits down and writes a method that returns a computed value (and screws it up a few ways and back), that aha! moment will remain elusive.

For this reason, retention of complex concepts, especially in the adult classroom setting, is a tough problem. Typically, night classes meet a few times a week. Almost everyone has an actual life with obligations and activities that make it difficult to sit down on a daily basis and practice. But, just as with riding a bike, practice is essential to learning how to code.

So what’s the fix?

I haven’t figured this out completely yet, but I’ve a few ideas.

Practice, Practice, Practice…in class.

My lectures have changed significantly since I first started teaching in a classroom setting. Nowadays, I’ll speak to a concept for at most 30 minutes. Usually, that’s all I need to establish my analogy + challenge approach to the class conversation. Immediately afterwards, I’ll ask the class to solve a problem or two that apply the concepts covered. They start off dirt simple — nothing short of finger warmers, as I refer to them. The point is to guide students and build their confidence. This way, when the training wheels are off (at home on an off night let’s say), they won’t shy away from trying a thing or two on their own.

Mid-week checkins.

This really depends on the class schedule, but I always make a point to follow up with students at some point between lectures. Typically I’ll share an article or two related to the material that was covered. Although this doesn’t necessarily push them towards working / practicing the concept on their own, it helps to refresh minds and start discussions with the entire class that can eventually lead to code examples or a sense of where to start the next lecture.

4. Confidence, confidence, confidence

I should point out that 3 confidences !== over confidence, or swagger. That being said, when I talk about topics I am confident I am well versed in, my entire presentation demeanor changes. I tend to make more eye contact with students and I feel way more at ease and conversational. Furthermore, when I am confident about a topic, I feel more secure about fielding questions on that topic — after all, I am confident in my grasp of the concept.

Ideally, I’d want to be confident about all the topics that are covered in the course. However, and quite understandably, I will be more sure of myself in some concepts than others. (For example, I can tell you that for a fact that there are javascript events that fire when a CSS transition completes, but I couldn’t list all the vendor prefixed permutations of this event without a documentation reference). In my view, it is important to be able to confidently talk about all relevant class topics and field questions on those class topics. However, it is also just as important to be able to confidently tell students when you are not sure about something.

Being comfortable enough to admit uncertainty is a big deal — you can use it to illustrate to students that even experts in a subject matter are not all knowing. And that google is a thing that exists and is used by everyone, even content experts. It can be a great way to engage students in a socratic manner to try and reason about a solution to the question (which helps reinforce problem solving principles). Finally, it can help students understand that it’s okay to not know things sometimes. If a teacher can falter from time to time on certain topics, it’s certainly ok for a student to falter as well. This can help create an environment that enables students to feel confident enough to ask questions they are ensure about.

3. Be genuine

Picture this: it’s lecture time. I am standing in front of a class of 25 students. They are all watching me fail miserably at getting a jQuery slideshow plugin to work.

Not a oh teehee I forgot how spelling works kind of fail. More like a full on holy sh-t how is this even possible what is life?! kind of fail.

In other words, class is going exactly as intended.

Every 7 weeks (roughly), I stand in front of my class — having completed an introduction to DOM manipulation with jQuery (as spec’d in the curriculum) — and I introduce our friends to the concept of jQuery plugins.

I purposely make a point to choose a plugin that I’ve never used or seen before. I usually tend to ask the class to pick and we go with something topical (ie: we’ll get our inspiration for which plugin to use from an interesting lunch conversation about pandas from two weeks ago…or something).

As is typical with programming, nothing ever really works the first time. So the whole failing miserably thing? That’s generally just an average Tuesday for me. Except in this case my entire thought process is on display for the whole class to see.

For obvious reasons, this is a Good Thing. But the other, more interesting side effect is this: the students see me fail. And this is wonderful!

Think of it this way: to a student, an instructor can seem kind of infallible (even if s/he has to google around for stuff sometimes). This makes sense, we prepare for class in some capacity before lecture and largely control what content and topics (and yes, examples) are covered.

In other words, and in varying degrees, we rehearse our lectures. This is good because rehearsing ensures class goes smoothly and without a hitch. This is bad because more often then not, class goes smoothly and without a hitch.

It paints a rather grim picture to the students: while coding, nothing ever goes wrong for the instructor, but everything always goes wrong for the student (from forgetting a comma to misspelling a variable name).

This can lead to all sorts of sad from “It always just works when you do it Taq!” to “maybe I’m just not cut out for this sort of thing”.

But more importantly, it paints an inaccurate picture, one where the world of programming is just fun and giggles. (And clearly this is not even close to true, see re: my average Tuesday).

It is very important to let the students see you fail (and not just the hmm let’s google and find out! kind of fail). It will help them see you persist, problem solve, emerge triumphant (as you do, always), and make meaningful conclusions after you get past the bug. These conclusions can be anything from “and that’s why it’s super important to RTFM” to “and that’s why it’s important to live the IIFE lifestyle so that your random variables don’t pollute the global namespace and override the plugin code LOL!”.

And in general, it’s important to bitch about code in front of class once in a while. It’s not a glamorous life — if you’re a programmer, you know that. The students might not. Sharing the trials, tribulations, and especially the triumphs of life as a coder can highlight interesting problem solving techniques, gotchas to watch out for, and the fact that you — the instructor — is just as fallible as everyone else in the classroom.

Something, something, misery, company, as they say.

2. Inspire by example

This one is actually super straight forward. You’re a coder right? You probably enjoy it? (I sure hope so, if you’re teaching it!). Chances are, you probably built something one day that wasn’t today and also isn’t in the future (and I’ll bet it’s super awesome).

Usually, I use projects I’ve worked on (either the latest release of my sideHustle2.0 app OR a recently deployed feature for work) as a starting point to create context for the next topic we are to cover in class. Sharing tangible things that you’ve built, things that directly relate to the topics being discussed in class will go a long way to inspire folks to start building stuff on their own (and thus, practicing class concepts).

1. Bring candy

And that brings us to our final and most important point: bring candy. Like, everyday. But especially the first day.

In my head it goes something like this:

Taq on first day:

Hi guys, I’m Taqqui. I bring free candy because candy is awesome and you probably enjoy consuming it.

Student A (who’s name is actually Arnold but I don’t know this yet because it is the first like moment of the first day of class so we haven’t technically met yet) on first day:

Wow, this person called Taqqui who is also my instructor brought candy. He must be awesome because why would a non-awesome person bring candy? I bet this class will be a Good Class now that I have created an arbitrary (but let’s face it, pretty accurate) belief this this instructor is an awesome person.

In other words, on the first day of class, candy === peace offering.

On days of class that are not the first day, it is still important to bring candy because sugar will keep everyone awake. Trust me, it will help immensely when you cover floats. Or flexbox. Or hoisting. Or scope in general. And definitely when covering jQuery plugins.

Final thoughts

Good luck + thanks for reading!

<!-- By day, Taq Karim builds out the front-end of Honey. By weekend, he teaches javascript and web development at various institutions around NYC (including GA and OM). By night, he builds teaching tools to make it easier for folks to learn code. 

Taq will never sit on the Iron Throne; he is neither Stark nor Targaryen. Sometimes, Taq writes malformed XML tags that are clearly not valid or even defined...he's workin' on it. -->

</TaqKarim>