Walk, Don’t Run – InApps 2022

Before kicking off my career as a web developer, I did a lot of other things: journalism, professional photography, foraging wild foods. Somehow I always segued into teaching these things. In part to earn money — as a freelancer, you’re always scrambling for new income generating gigs — but mainly because I really like teaching. I enjoy the interaction with other people, and teaching a subject undeniably forces you to learn it really well. You need to understand how something works, both thoroughly and deeply, in order to teach it. Especially if you don’t want to look like an idiot in front of your students. Which I don’t.

So it surprised no one when, six months or so after boot camp, I started teaching at the same academy where I had so recently been a student. At the time I didn’t know nearly enough to work as a senior developer, but I did have by then enough knowledge and practical experience building simple projects to start pulling others up into the junior web dev lifeboat with me. A big reason I started first TA’ing courses and workshops at Betamore was to get free access to continued learning opportunities — this is how I got started with React, for example — and also to solidify my existing knowledge.

During last night’s Front End Web Development class (week five — the summer is rushing by) it struck me that I’ve now advanced far enough in my own knowledge to see when students are making mistakes. Not just any mistakes, but the very same mistakes I happened to also stumble through two years ago when I was in that seat. Like any proud, hopeful, helpful and above all willing to be ignored mentor-slash-materfamilias, I hope to save them from making the same mistakes I did — just as I do with my own two kiddos.  And, just like my own two offspring, they ignore my helpful “Don’t do what I did!” advice.

Not that I’m trying to prevent them from making mistakes altogether — I’ve learned a shit ton from screwing up code, then figuring out what I did wrong, then fixing it. Making mistakes is a part of all of us learn how to do anything: We literally stumble around, and even fall down, while we are learning how to walk during toddlerhood. Learning to code is the same process: stumble around trying our best, falling down hard on our asses at times, but always getting up and trying again. Until it becomes second nature, and we can do it without thinking about it, and maybe even forget this thing we do all day every day is something we ever had to learn in the first place…but that is a topic for another time.

In coding, making mistakes and breaking things are a spectacularly effective learning process. So when I say I see my students making the same mistakes I made, I don’t mean the learning-curve type like forgetting one semicolon or closing curly brace so that every single line of hard-wrought JavaScript that comes after is broken. Banging your head on your laptop until you find that tiny bug is an essential part of the process of learning how to write better code.

The kind of mistakes I’m talking about are more macro — more, I guess, about the procedure. My main mistake as a brand new dev was trying to do too much. Like every new programmer in love with the code, I was super excited about everything I was learning and I wanted to play with all my shiny new toys all at once. Yes, things were a trainwreck. And, yes, I learned a lot from fixing said trainwrecks. However, in the process, I also wasted a lot of time. I realize now, both looking back at how I learned and looking ahead to doing better for my students, that the best way for many of us is to build lots of small, simple things until it’s like muscle memory. And then, once those concepts are starting to really sink in, then start mixing things together.

In other words, walk. Don’t run.

Last night I had to challenge a student about why she had not done the homework as assigned. It was to build a simple, single-page website (the kind of “tribute page” project that is a popular project for super-n00b front-enders). The purpose of the assignment was to give them practice wiring up HTML with CSS and then applying styles. And, since all the code goes on GitHub, I get to see how they go about it, where they start and where they end up and how many iterations it takes. I can check whether they’re using good semantic markup, that they’ve grasped and internalized basic layout and positioning.

Five of the six students did the homework as assigned. Some really floundered with it — this was the first time they had to create code from scratch, and I think we’ve all felt that moment of panic when staring at a blank text editor page with the cursor blinking at line one. But they all managed to put together reasonable facsimiles of the work as intended.

Number six, though. Hoo boy. She tried to build an entire multi-page, multi-featured website. And not just a practice, lorem ipsum page, but a full-on public product for a real person. Unsurprisingly, it was a total mess. The ambition is admirable, but the running before she could walk created a huge tangle of ugly code, mistakes cascading into other mistakes. Which she then presented as evidence she had done the homework. When I confronted her about skipping the assignment to build a simple project, she answered, “I didn’t just want to do the book report. I want to write the book.”

An emotion I totally, completely, utterly understand, because I did exactly the same thing when I was at exactly the same point in my own learning curve. And it cost me time, and lots of frustration, fixing the same project over and over trying to get it finally right,  instead of moving on to new things. I gave my impassioned pitch about learning to walk before you run, doing the small modular assignments that might feel beneath you but actually are part of a carefully thought-out curriculum designed to iterate concept upon concept for an effective and efficient learning curve.

I could tell by her expression that she was waiting for me to just stop talking so she could dig back into her chaotic jumble of a project and figure out how to make it do what she wanted. So I stepped back and gave her room to dig.

Not because I changed my mind that it’s OK to run before you even can reliably place one foot in front of the other as a confident and steady walker. I will keep preaching walk don’t run to my students. Also my kids. And some will listen, others will not. And I won’t be upset.

Because I am a runner, too. Shhh, don’t tell my 11-year-old.

Catch Code n00B every other Friday, here on InApps. 

Feature image by Andy Beales on Unsplash.