How I learned to code

10 years ago, I was starting my career of being a professional graphic designer. By professional, I mean that I got paid to do computer graphics stuff - not that I was spectacularly amazing at it (at the time anyway). Growing up, I wasn't like the many developers you hear about these days. You know, the ones that coded their first program when they were 5 years old on the shared family computer in the living room. Nope. I was a kid who loved to doodle and dreamed to one day work for The Walt Disney company as an animator - perhaps on the next Lion King, Aladdin, or Mulan.

During my early design days... I distinctly remember the feeling of handing off my work for a developer to build. It's this interesting and unique feeling of powerlessness. Afterwards, we'd have the usual back and forth between Designer and Developer. And in the end, it wasn't ever really build quite right.

(In hindsight, there were many things I could have done to improve the communication aspect of these exchanges that were independent to the craft of visual design.)

Back in the day, I knew enough HTML and CSS to help with stylistic and structural things. That allowed me to roll up my sleeves and get in the code to fix and refinement. But for anything logical... Anything that required "real code" (JavaScript and PHP)... Those were the forbidden things that I didn't feel like I was capable of contributing or even handling.

Code was something that I didn't really "get" - regardless of how hard I tried. It was like for years. That is, until the day I discovered jQuery. jQuery took something dauntingly complex and inaccessible and somehow made it I approachable for me. With it, I could actually make things, interesting things, beyond the bare bone basics of HTML and CSS. jQuery made me feel powerful. It was a computer language that I, as a designer who was terrified of code and command lines, could actually understand. It wasn't before long that I was able to make the typical things that people did with jQuery back in the day - scroll triggered interactions, image sliders and carousels, lightbox models, etc...

There was a media company that I was working for at the time. My newfound jQuery experience enabled me to progressively do more front-end things. One day, I was helping them build what eventually became an ad-scheduling/targeting system (powered by DoubleClick, now Google Marketing Platform). The ads needed to have all the code and assets within a single bundle. The trouble was, in order for me to do anything, I needed to include jQuery - even for simple logical JavaScript things. Not only that, but every single ad that was scheduled (and there were many) included a bundle of jQuery in it. The result was degradation of the performance and usability of the website.

With this project, I felt the limitations of my dependency on this library. I felt the pain of users who's browsing experience was hijacked by a slow-loading website. I felt incomplete (and perhaps incompetent) because I could only do jQuery and not the "real code" that it sat on top of. It was at that moment that I was determined to bite the bullet, put on my big boy boots, and learn JavaScript - a language that has taunted me since I began making things for the web.

I tried books. I tried tutorials. I tried (free) online courses. But none of those stuck with me. The basics of if/else conditions and for loops made my eyes glaze. To be fair, structured learning like this always did - regardless of the topic.

I knew that I learned best by taking what little I knew of something, then jumping into the deep end. There, I'd make a mess of things and then figure out how the mess came to be as I tidied the mess up. Since I knew jQuery... I decided to go to the source - literally. I read through the entire source code (yes, every line) of jQuery as a means to understand JavaScript. I studied how my favourite little big library was made. And it worked!

The next step was, as a (massive) challenge for myself, I wanted to see if I could rebuild jQuery from-scratch. Not only that... I wanted to make it better - specifically with some performance things and adding some nicities to it's APIs. And I did! It was this 2000+ line library I created called Zest. I made a custom logo for it any everything. I was so proud of it and I was excited to share it to the world. I naively thought, "Who knows, maybe it could be the next jQuery!". Spoiler alert... It didn't. No one used it. And that was okay with me! I was and am still immensely proud of that project.

It has been a decade since I deconstructed jQuery. And I can say that, without a doubt, it was the most transformative and important decision and event in my web design x development career. I was not only able to understand the fundamentals and patterns of programming, but in deconstructing jQuery, I was also able to better understand why code was written the way it was, and how you could make code understandable and therefore accessible to other people. The art and science of simplification is something that I've carried with me for my entire career, and still continue to work on.

As I progressed through my career, I transitioned to from doing purely UX/Design work to doing progressively more front-end things. And just like jQuery, I repeated this process of studying source code for Backbone/Underscores to better understand how front-end MVC (model/view/controller) worked. I studied the source code of various jQuery libraries like Masonry, Isotope, and basically a lot of things by David Desandro to understand how complex interactions and performance considerations worked. I studied Foundations then Bootstrap to better understand how to put together CSS frameworks that could power a great many websites and applications. I studied React (and Preact) to better understand how more modern declarative UI programming worked. And most recently, as it relates to my Design System/component library work, I studied the many open source component libraries from Shopify's Polaris to the widely renowned Chakra to understand UI component construction and adaptation to accommodate real-world business needs and real-world several year-old codebases.

It's worth nothing that what works for me may not work for you. In fact, I'd say for most folks, my preferred style of learning is probably the most challenging, unwieldy, and difficult way to learn something. It is literally diving into the deep end of a pool with limited knowledge of how to swim and just... figuring it out by watching how others swim as you flail around.

Anyhow. That is the story of how I learned how to code. Unconventional. Just like many other things I do I suppose.

‍