For many of us who came of age in the mid-to-late 2000s, our first exposure to web development came from playing around with code on sites like Neopets and MySpace. You might've even started on Tumblr, Friendster, or another space that allowed for self-expression through code. In my case, it was Xanga—a LiveJournal-like blogging platform—that first pulled me into the world of HTML and CSS. I remember being 12 and humming along to the sweet sounds of dial-up, waiting to be connected to the Internet so I could tinker with my layout for the 100th time that month.

As you might imagine, pre-teen me was less preoccupied with coding standards and best practices and more preoccupied with making my page look cool, which to me at the time meant animated and sparkly. I just wanted to fulfill my ideas, and getting any of them to work after studying a mere crumb of coding made me feel like a god. Unfortunately, this focus on output over process meant I was building bad habits, some of which I didn't even realize I had until I first started studying software engineering in a more formal context. After the second week of #100Devs (and after many years since I last touched code…), I discovered that in order to really learn the fundamentals of coding, I needed to unlearn a few tendencies I picked up as a kid, like:

Not separating concerns

From the very first class, Leon stressed to us the importance of separating code that deals with the content (HTML) from that which handles style (CSS) and interactivity (JavaScript). This seems pretty straightforward; after all, many consider it the golden rule of web development. I’d be lying, however, if I said young me never styled things inline in HTML when I wanted certain text on my blog to be blue or headings to be extra large and bolded. I now know that this is a no-no (say that five times real fast). Separation of concerns exists because it helps keep your projects organized: It makes code easier to read, modify, and update, it allows for better code reusability, and it helps prevent you from being a headache to work with when you’re collaborating on a team.

Blindly copy/pasting code

One of the things I recall applying to my Xanga page was a vanilla JavaScript plug-in for falling cherry blossom petals. Being able to achieve this effect with just a simple Ctrl+C and Ctrl+V of someone else’s code was like magic to me. Before long, though, some edits I made to my page caused the plug-in to break, and I spent more time than necessary to figure out what went wrong because I had no real idea of where to start debugging. This is why it’s important to understand code before you reuse it. Yes, copy/pasting code might solve a problem you have, but in the long run, it can also create more of them if you don’t take the time to read and interpret the code in detail.

Neglecting to ask for help

I don’t know about you, but I was a stubborn kid. I also liked being independent. As a learner, this can be a good thing: you might be a self-starter who is persistent when it comes to nailing down a concept. However, it can also mean that you don’t want to get help when you’re stuck. I used to think that asking for help meant I was failing at what I was doing, but that’s not really the case for most things, especially something as difficult as coding. Now I can appreciate that the right people will recognize my frustration and admission of ignorance as a sign that I am putting in the effort to improve. Lately, I’ve been operating by the #100Devs rule of thumb: If you’ve struggled with a problem for 30 minutes and still haven’t solved it, then it's time to reach out for help.

Inattention to accessibility

As a sighted and hearing person, I grew up with the privilege of being able to see and hear everything around me, including all the sounds, photos, and text on any website I visited. I think about my old Xanga page with its uncaptioned videos and lack of alt text for images and I realize it wasn’t built to be inclusive. After reading about The A11y Project and building digital accessibility through semantic HTML, I am unlearning the tendency to code as if everyone experiences the world as I do. My code is now focused on promoting usability and providing equal access. I've made a note to be deliberate about creating clear layouts, using colors with good contrast, and avoiding “divitis.”

So you see, sometimes the most important step in learning is unlearning. When our intention is to let go of what we already know (or think we know), we open ourselves up to new and often better ways of doing things. Thinking flexibly and critically is a great way to become a strong problem solver—and what is life and coding if not a series of problems to solve?