Tough Act To Follow…

By David Rogers, Orlando Front End Engineering Instructor

First off, lemme say, if you haven’t read Let Harrison Ford Be Your Spirit Animal by my fellow instructor, Brian Gates (get a webpage, bro), you should. It’s far better than this post is gonna be. Y’know, unless you’re into learning experiences.

“Start with JavaScript,” he said, “Teach programming,” he said…

I’ll be the first to admit that I did this to myself… And the dozen or so students who took my class this time around. Our Founding Father, Mason Stewart, typically teaches Front End Engineering (FEE, sounds like “whee!”) by starting with HTML and CSS and quickly weaving in JavaScript through DOM traversal and manipulation, some Constructor Madness(!!), working his way up to Backbone and the whole client-side MVC pattern. Being my first cohort at TIY, naturally I chose a completely different path. What can I say? I like to start on Expert…

Well, really, I was gathering resources from the previous classes and couldn’t help but notice how Back End Engineering (read: Ruby-on-Rails) was so very different from the JS path. The Rails class tends to start with Ruby concepts, move into HTML and CSS as kind of a breather, and then jump into Rails development for the server-side MVC. As a pure programmer myself (read: artistically deficient), that approach really appealed to me, and it felt closer to what I had developed for Valencia College. Start with an intro to programming with pure JavaScript, move into HTML and CSS for a breather, reintroduce JavaScript while building towards Angular JS as the client-side MVC. So I tried it…

So then what happened?

Turns out, it worked about as well as I expected it to… We’re now into our second week of HTML after three weeks of JavaScript. There’s only so much programming you can pack into a couple of weeks, but the test subjects… I mean, the students have shown remarkable understanding of programming concepts now that I’m reintroducing JavaScript into HTML. Since we spent time with Constructors, prototypes and Object literals in pure JavaScript, I feel they have an easier time understanding the DOM objects like HTMLElement and NodeCollection… It’s just less for them to swallow along the way, it seems.

I still have yet to introduce jQuery or any of the automated build kits — Gulp and Bower are on deck this week — but I anticipate a faster uptake since they already understand require()-ing modules and chaining commands from our test-driven romp through Node. Of course, I’ve also learned something important about my teaching style from this little diversion.

Talk Less; Build More

What I’ve learned over the last few weeks of teaching these folks at this crazy-stupid-ridiculously-fast pace is that building is better. Every time I’ve tried to explain a subject with words and pictures and analogies, the students stare back at me numbly as if to say, “Hunh?”

Instead, when I just build stuff on the screen with them watching, narrating my decisions as I go, I get lightbulbs going off, questions firing, interaction, occasional comprehension, and looks of “Keep going…!” This last week, the differences became so palpable that I finally gave up on explaining anything with lecture. I’ve just built stuff for them, live coding, asked and answered questions, and assigned lots of “now you try” for homework.

We call it “lecture”, but it feels like me doing homework problems in front of them for three hours. I’m still a little conflicted about it, but I can’t argue with the results. The lights are coming on much faster now.

Moral: Break Stuff

See, had I stuck exactly to the material I had developed for Valencia, I’d be lecturing from a slide deck, which helps me keep pace and stay on topic. I tend to ramble down side-tracks and rabbit-trails of history or trivia when I’m speaking. While interesting and (usually) entertaining, that only caters to a specific learning style, and it’s not very flexible when the class doesn’t grok some key concept, y’know, in a single day.

Further, had I stuck to the format long-established by Mason and the other FEE instructors (no offense, y’all), I would have ended up heavily regurgitating the lessons as presented by them, which are nicely documented (for the eyes of other TIY instructors only), instead of improvising through necessity. I’m lazy; I know it. Given a cornucopia of Things That Work(tm), I expect my brain to ride the coat tails of reasonably smarter other brains.

Finally, this was the last cohort of FEE classes to go “out of order” for a while. All the campuses are seriously sync-ing up next year. If ever there was a chance to experiment with the curriculum, this was it, ‘cause the urge to lock-step with everyone next year will be much harder to resist. Not that anyone’s coming down with a hammer, just that there’s safety (and efficiency!) in numbers.

I’m glad for the learning experience, and I’m taking lots of notes on what to do next time to improve on the format, the pacing, and the learning objectives. I’m honestly looking forward to my second cohort with every mistake, recovery, and redirection. I’m grateful to have a place where I can experiment in this fashion and students who give terrific feedback about what’s working, what’s not, and how we can all improve.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About theironyard

The Iron Yard exists to create exceptional growth and mentorship for people, their companies and their ideas through code education and startup accelerators.