Redux manufacturing: learning by analogy

This is part one, “Learning by analogy”, of Redux manufacturing, an introductory series to the JavaScript library Redux.

Learning by analogy

I spend a lot of time thinking about how best to learn. There are plenty of different ways to learn more effectively–for instance, how you spend your time or your attention. Taking the law of vital few into account, there are many situations where identifying the invaluable 20% of information can save you 80% of the time–knowing what to study. How you study can be important, too: a tool like Anki can help you reflect and review on material in a way that helps promote retention and understanding.

Learning by analogy has proven to be an incredibly effective method I’ve used to learn a variety of new things. The reason for this is simple: it is tangibly easier to connect pieces you already have over discovering and remembering entirely new pieces. After all, when building anything, it’s necessary to first take stock of what you have, before determining what new things that you need.

I try and tie all kinds of things together via analogies. Sometimes, it doesn’t really work, and the results sound like a bad startup pitch: “React.js is like a toaster” (but props to you if you find any coherent comparisons between the two). When they do work, you can almost feel your brain connecting the dots in a satisfying and memorable way. Here’s one of my favorite analogies, one that I’ve been come back to regularly over the years.

Disclaimer: the next part is a bit of a tangent for those of us interested in the art of learning. Just here for the React and Redux goodness? Skip ahead by clicking here.

Amplitude and frequency

As I began to learn music production, it took me a short amount of time to understand what amplitude and frequency were, but why they were important eluded me for a long time. I had Ableton Live, a wonderfully interactive music production application, so the tools for discovery were there, but I just wasn’t getting it.

For instance, I would look at a kick drum inside of an equalizer. I know now that an equalizer allows you to modify the frequency of a sound, but when I first saw this in the equalizer interface, I had no idea what was happening.

Amplitude and frequency work together to produce every sound that we hear (and even the ones that we don’t hear). A “sound” has an amplitude, better thought of volume, and a frequency, which we often refer to as pitch. A dog whistle, for instance, is a high frequency, low amplitude sound. The sound of a car engine and a drummer’s kick drum at a stadium rock concert are both low frequency, but their amplitudes are radically different: more interestingly, they could both be considered high amplitude, but only in relationship to what is currently around them.

So amplitude and frequency map to volume and pitch, more or less. Why do they matter?

In making music, musicians are able to write with almost no constraints. Any frequency within hearing range is fair game; given an agreeable audience, most amplitudes are OK too. But there are some constraints that musicians are intuitively aware of: sound itself––more specifically, how we hear it. Imagine two different sounds of similar frequencies played at the same time. Which sound would you hear? You might guess both, and that’s true to an extent. Your ear will, however, focus on whichever sound is louder: the sound with higher amplitude.

Music production, then, is a battle of trying to fit your concepts into the small space we’re given with our hearing range. Coming back to our equalizer, we can apply our new knowledge of frequency and amplitude as the X and Y axes of the equalizer graph. The X axis indicates frequency, and the Y axis indicates amplitude. A kick drum, like all sounds, includes frequencies across the entire spectrum––it’s not surprising, however, to see that the loudest part of the kick drum is in the low frequencies.

Frequency and amplitude as a graph; a decent analogy, but we can do better.

Music production is like filling a storage unit with boxes. Boxes can be different sizes, from small, medium, and large. The size of the box corresponds to amplitude: a loud sound is a large box, and a quiet sound is a small box. To produce a song, you must find a way to fit all your boxes (drums, bass, guitar, vocals) into the storage unit. A really large guitar box might make it impossible for the bass and vocals to also fit in the unit; to fix this, you might need to get a smaller guitar box, or forego the box entirely.

It turns out that with this analogy in mind, equalizers make complete sense: they allow you to make certain boxes smaller. In the below example, we use a tool called a high-pass filter inside of Ableton’s equalizer, to remove all the low frequencies from a sound.

It’s safe to say that most people are familiar with boxes, and with the concept of physical space. Analogies are incredible powerful–we can “remix” that fairly basic knowledge as a way to learn frequencies, amplitude, and equalizers. In fact, I’ve used the same analogy before to explain other music production concepts: compressors and limiters can fairly easily be explained using similar concepts. A good analogy can outlast its initial comparison and become a wonderful tool to deeply understand another topic.

The warehouse floor

With this in mind, we now turn our attention to Redux, the popular open-source JavaScript library, often used with React.js. For better or worse, Redux is almost always expected to be introduced as React applications grow in complexity, especially as it relates to application state.

I’ve worked with Redux since 2015, shortly after the first version of it was released. In my experience since then, working on applications of wildly different scale, and with a variety of developers at different experience levels, a single conclusion has come front and center: learning Redux is hard.

I haven’t yet encountered a developer on any software team I’ve worked on that has intuitively picked up Redux. There’s a learning curve––the primary reason, in my opinion, is because it is all new. The concept of data flow is usually handled for you (such as in Ember.js), and managing it yourself and defining such strict logic around it can be really uncomfortable to pick up.

When you do learn Redux, it seems so simple in retrospect: it becomes difficult to remember just why it was so complicated to begin with. This is because while the concepts themselves are straightforward, they’re radically different in many ways from what “conventional” web development has looked like in the past.

Luckily, we know what to do with things that are all new or different, right? You guessed it–analogies. In this series, we’re going to introduce Redux using the analogy of an active warehouse floor, where manufacturing, supplying, and management are all happening at a rapid pace. This analogy is a nod to the Lean manufacturing revolution of the 80s and 90s–manufacturing systems provide a wonderful lab to test new processes and systems. Our heroes of the manufacturing floor are saddled with too much work, not enough organization, and that sense of impending doom that some of us are too familiar with in stressful work situations.

In the next part of this series, I’ll introduce the players of the warehouse floor. We’ll understand how they work, and more importantly, where they conflict in problematic ways. We’ll also begin to model a React application to show how the different pieces of our warehouse will be represented with data.

Bytesized offers technical training for companies. Contact us to schedule Redux training for your team today.

Read the next post in this series, “Introducing the warehouse floor”.

Leave a Reply

Your email address will not be published. Required fields are marked *