Trial and error learning

In 2015, when I joined Campaign Monitor, my background with Javascript was primarily marketing-style sites, and my own fun experiments using jQuery or plain old Javascript. I was put on a team where the product was written entirely in AngularJS. It was a daunting experience, but I was eager for the challenge. I went to learn AngularJS through tutorials and documentation, but when I actually had to do it in practice I struggled for longer than I care to admit. I’ve since learned a number of UI libraries and frameworks, some out of curiosity, others to be used in a production environment.

I recognized I have a very specific learning style. I like to prod things, make mistakes, get stuck and make discoveries, that’s how I remember everything I learn. I also value examples that are real or fun rather than dry and tutorial-like. I understand why todo-list editors make for a good tutorial technically, but I tend to find that it all just blurs together and doesn’t stick in my mind.

I don’t believe learning is fun, I actually find it really frustrating most of the time. Learning new things is hard. The fun comes from the accomplishment of having made it through to the other side of being stuck, and the discovery of possibility around what you could do.

Knowing how I feel about learning things, I designed my own process around learning just enough of a UI library to be effective, while having a little fun at the same time. The aim isn’t to be comprehensive, it is to be able to work in an environment where a library is already set up and be able to build or work on an existing feature and have some idea about what you’re actually doing. The other parts can be learned later.

Remove the yak shave

You know what’s not helpful for me to learn how to work with an already set up project? Setting up a project from scratch, adding technical overhead like CSS frameworks, preprocessors, typescript, and auth with APIs - when I stick to the singular purpose of learning how to get by and actually build stuff I tend to make it through and enjoy my time.

Reduce the setup burden

There are a number of ways you can reduce the setup burden so you can get straight into code with only a little friction. Some of these include playgrounds on docs website, which are great because they’re set up exactly as the authors intend; sandbox environments like CodePen, CodeSandbox, or jsFiddle - these usually do require a little bit of setup; and lastly generated installable setups like create-react-app which I tend to find are the most useful for me - I can save the code locally, I can commit it to git and have a future reference if I ever want to continue with the same project.

Finding reference sites

I’ve stated I’m not big on stepping through tutorials, but that doesn’t mean I don’t use them at all. If my goal is to find how to hide or show something in the DOM - I might skip through a tutorial until I see an example of that. Sometimes I find it easier to find the answer this way than the actual docs. Another avenue I sometimes take is to find a few examples on github of sites people have built with a library, so if I need to look at how someone solved a particular problem I have something to look at, like “view source” for a modern UI library.

Starting with the idea

To give myself a starting point I like to visit the public apis github - I’ll make a quick shortlist of a few public APIs that don’t require any auth (remember I said auth is a yak shave) where I can fetch some data and build some kind of small app around.

Technical goals

Thinking with the end in mind, I’m primarily trying to get myself in a position where I am capable of building most UIs. To do so I break it down into five main areas:

• I want to learn how the library fetches and handles data
• I want to know how the library typically renders a list of items
• I want to learn how the library handles state for the data, and how I can manage transitional states like pending/disabled
• I want to learn how the library binds events to form elements
• I want to know how the library works with browser APIs

Actually build something

Once I’ve picked an API, I’ll work out how to get the data into the app, then how to render the UI based on that data - usually in some kind of gallery or list format. In doing so, I have to handle what happens when the app is loading. The next thing I’ll do is add some editing capabilities with form elements that control visibility or filtering the data somehow. Then I’ll pick one of the easier browser APIs to add and see how it deals with it. The Clipboard API is usually a good choice for this because I can usually work in ‘copying some text’ into most apps without too much difficulty. Once I’ve given myself the space and time to get through these tasks, I’ve bought myself the freedom to experiment and play beyond that.

Given we have so many different UI libraries today, learning to chop and change easily means I don’t get anchored to one specific library and its techniques - and that’s why I feel so much more comfortable today than I did in 2015 when I have to learn something new.