January 10, 2016

bottom up, not top down: a different approach to teaching code


“And when you’re done, this is what you should have.”

I was helping to teach at an introductory HTML/CSS course when I heard the instructor say the above words, which immediately gave me pause. The instructor pointed to the example that they had created, up on the projector, that the students were expected to copy.

The aim of the course was, in one day, to teach women the basics of creating a single-page HTML and CSS website. It was ambitious, but I had high hopes. In order to accommodate this ambition, though, the students weren’t creating their own page, but replicating the one that they saw on the projector as they went along (they were given the source files for it later on, but I’d be willing to wager that nobody would look at them). They were taught a basic HTML or CSS concept, and then applied it on this example, usually a copy/paste exercise.

I hadn’t written the course material— I was just assisting if the students had questions— so perhaps it’s easy for me to be critical, but I couldn’t help but think that this was the wrong way to go about it. This is because, whatever we build on the web, it doesn’t work this way. This isn’t how we approach code, and teaching this approach to students lays the wrong foundations. We don’t usually have code to replicate, but something we’ve generated ourselves (or been given by someone with more visual design chops). We have to apply code to that design or problem. There may be tutorials to follow, but they still need to be adapted to our particular situation. There is never a one-size-fits-all, copy-paste problem.

The problem, then, with this course, is its narrowness. If the material is taught only from one particular lens, that is the only lens through which they will be able to remember or apply it. If the students are taught to make one specific portfolio site, with a header, footer, and two content sections with a few images in them, with a particular CSS makeup, that is all they will know how to create. Nothing else. They haven’t been taught, but spoon-fed, and often don’t know where to go from there. It’s this second step that is always the most difficult.

If the material is taught only from one particular lens, that is the only lens through which they will be able to remember or apply it.

This is a danger I feel we’re running into with many coding classes these days. They overreach, and approach from the wrong side— top down rather than bottom up. As a result, we realize at some point during the middle of the course that students are overwhelmed, that the instructor is behind, and end up rushing through the rest of the material. That rushing is then justified by giving students source code, assuming they’ll be able to look at it in their own time with anything other than confusion, if they look at it at all.

Of course, it’s easy to say that something doesn’t work without offering a viable alternative, so I’m going to try to do that. Whenever I’ve taught others (my coding classroom experience is limited, but I’ve been both teacher and student, and believe that offers me a decent enough perspective on both sides), a more open approach has always been more helpful. This is harder at the start, but more beneficial in the long run. Eight hours in a one-day course doesn’t offer much of a “long run,” but that’s why we should focus on doing less— not covering as much HTML and CSS as possible, for one— and not promising a polished website in <8 hours. This sets unrealistic expectations for everyone.

Instead, we could start with giving basic, example-based knowledge of HTML and CSS, perhaps with CodePen or JSBin examples to play with first (without worrying about box models or file structures or any of that). This introduces students to messing with code and breaking it, and isolating mistakes. Encourage these mistakes, tell them it’s okay, and ask them to make more. Then, after introducing this material and alleviating the crippling fear of code breakage, we could give students a pre-made site and tell them to play with it, its content, and its code. Avoid terms like “pass a value” and “application” and “attribute”— they’re unnecessary now.

This could manifest in a plan like the following:

1) Offer the aforementioned HTML and CSS basics in a code editor, stripped down as much as possible. No need to talk about doctype or charset or any of that, or anything that isn’t strictly relevant. This can be hard, but it is absolutely imperative— as a learner, you don’t know what’s relevant, and when you try to remember it all just to be safe, you get overwhelmed.
2) Give the students some pre-made site files. Get them to customize the site a bit, so they get comfortable with code in the wild. They can see what the smallest of changes do. We can demonstrate a few changes on the projector at first, and then set the students loose. Give them time, and lots of it— those missing semi-colons take much longer to find when you’re not used to looking for them.

Then, when it’s time to make something of their own:

3) Ask them what kind of website they want to create (with the idea of it being as simple as possible), rather than giving them a specific project. To save time, we could ask them to arrive with this in mind.
4) Work with them to pare this concept down into something that can be executed (even partially) in a few hours. Make sure they know that we’re setting foundations, not building the whole house.
5) Iterate through the basic concepts again, helping them to apply them to these new ideas. This might take the form of more CodePen or JSBin examples, with some live coding by the instructor. Sure, it can be a bit harrowing, but seeing problems solved live is part of that fun. It should be a little dangerous.
6) Then, give students lots of time to execute these concepts. This is crucial. More time should be spent playing with the code than should be spent listening to or watching the instructor(s). We’re there to facilitate their ideas, not give them ours.
7) Repeat 5-6, as long as time allows.

Now, there are likely many flaws in this plan. But the idea is to replace “And when you’re done, this is what you should have,” with “What have you made, and where are you going to take it?” We’re never finished, and we shouldn’t pressure students by prescribing deadlines to what they’re creating. We can’t expect a finished product, and we shouldn’t teach them to, either. Now is the time to have fun, not worry about finishing something to an arbitrary standard, just so we can get on with teaching the box model. We should encourage that fun more.

Give them time, and lots of it— those missing semi-colons take much longer to find when you’re not used to looking for them.

This is a case where less will definitely be more, in many ways. The students will definitely leave with less of a ‘tangible’ thing— it won’t look like they have done a lot, but they will have understood a lot, and this is by far more valuable. The end product won’t be as flashy— they may not have had the time to get to grips with a large amount of CSS. A bare-bones HTML page with a couple of styles and a basic layout might be all they have to show for a day’s work. But this is fine— great, even. I’d rather they create that bare-bones page with intention and thoughtfulness than copy some CSS and have more to show for it.

Another caveat is that we would likely have to reduce class sizes or increase assistants, in order to deal with the myriad problems that arise as part of having everyone creating something individual. There will be different problems, different questions, and it takes an instructor time to look at the code and figure out what’s wrong. But this, too, is part of the process, and introduces them to the concept(s) of pair programming before they even know what it is. It will teach them how to take that second step I mentioned earlier by introducing them to things like pairing, Stackoverflow-ing a problem, reaching out to someone else, and just not knowing something.

Overall, using a process such as this one, bottom up rather than top down, students might learn less by volume, but they know how to do far more with what they have learned. It opens their eyes to the magic of code, rather than overwhelming them with its terminology. Having them copy something else is the antithesis of what building on the web is and should be, and it shouldn’t be taught that way.

If you teach code (or are learning it) and want to discuss the merits/pitfalls of this approach or any other, give me a shout on e-mail or Twitter! I’d love to talk more about this.

Share on FacebookTweet about this on TwitterShare on Google+