Drawing the Invisible: React Explained in Five Visual Metaphors

Maggie Appleton: [0:00] Hello, and welcome to "Drawing the Invisible." This is going to be a talk about React explained in five visual metaphors. First of first, I am Maggie. I work here at egghead.io. If you're watching this, you're hopefully or a little bit familiar with Egghead and what we do.

[0:15] We teach all kinds of web development skills, but we especially teach a lot of React. We sometimes joke we're just a React training company. I'm the Resident Art Director and Lead Illustrator here, which means I spend most of my time creating visuals that help people who are in web development, which in reality is mostly being a metaphor designer.

[0:34] My background is actually in code anthropology, which is undercurrent of everything I make. Some [inaudible] look me at programing well on a cultural and symbolic level. This is a very odd bundle of jobs.

[0:47] When I introduce myself at the imaginary cocktail parties that I don't go to, I like to summarize it is that I make illustrations that help explain the invisible abstract world of programming.

[1:00] Just to give you a more tangible sense of what I mean by illustrations of programming concepts, this is some of my work that you might have seen around this Egghead site. These are all illustrations for courses that we teach, so they work a little bit like album artwork covers.

[1:16] When I begin making these, I'm usually faced with titles like, "Use TypeScript to Develop React Applications," or "Build Composable Gatsby Things," which on the face of them, they don't have immediate images spring to mind.

[1:29] Then it's my job to dig around in the concepts and understand what they're fundamentally about, and then build up meaningful visual metaphors around them. I also do a fan number of illustrated diagrams and articles that explain all sorts of programming topics.

[1:45] For example, here's one I made that shows all the various parts and systems of Gatsby JS, which is a popular static site generator. Here's one that's more of a long-form piece of work that explains how APIs work for newer web developers. It's based around the metaphor that they're like tiny robot waiters that serve us some data.

[2:07] Here's another one of the long-form ones, that's about GraphQL query language. This form was based around material from a course that Eve Porcello teaches. If you're into using React with GraphQL, definitely check her out. She's wonderful.

[2:24] I make a lot of these. You can see plenty of them on the Egghead site itself as part of the courses, but I also post a lot of them on my personal website. I have a section of the site that's called a digital garden, which is where I publish notes and sketches and ideas.

[2:40] It's essentially just a blog that is always being revised and updated and grown. If you're a visual learner and you're looking for more of this kind of material, that's a good spot to find more of that work. That's more than enough about me, myself and I, for a minute.

[2:57] I want to talk to you about the common theme that's tying all of this work together. It's that I'm quite obsessed with how to make the abstract invisible world of programming more visible. It's that I wanted to figure out how to make it easier to understand for people like you, for web developers, who are constantly trying to learn new material and wrap their heads around these difficult concepts.

[3:22] In essence, all of my work is about making visual metaphors. I find visual metaphors an especially powerful tool for explaining and understanding programming in particular, because it's already such an abstract discipline. Creating meaningful comparisons can go a long way in helping people grasp new programming concepts.

[3:41] However, I do want to give a quick disclaimer about metaphors before we jump in. They do not do the same thing that an in-depth code demo will do, because that's not what they're for. The superpower of metaphors is they give us a big picture introduction to things.

[3:57] They're about building storytelling and they're about highlighting specific qualities of otherwise very complex concepts, which means by design, they don't explain every last detail of how a system works.

[4:10] I'm not going to do a deep dive into the technical details of how React works. If you do want a nuts and bolts code-and text-based introduction, the whole rest of the Internet has you covered. I'm going to dive in here.

[4:24] I want to show you my five favorite metaphors for the fundamentals of React. I developed these at the very beginning of my React learning journey. My learning process always involves making tons of illustrated notes and building metaphors to wrap my head around concepts.

[4:40] There was, of course, a lot to learn. I came to React with very minimal JavaScript experience and not a lot of big picture context around how the web development ecosystem works, which is certainly not ideal. It led to a lot of very entertaining and enlightening misunderstanding.

[4:59] Even if you are a grandmaster React expert and you already know all the ins and outs of it, hopefully, this will at least help you look at it with fresh eyes. It might give you some ideas about how to explain React to other people.

[5:14] One of my first challenges was figuring out what the big picture physical landscape of React app looked like. My first question was, where are we? As in, where in time and space is this React event happening? Are we in the cloud? Are we on my desktop? What's this thing connected to?

[5:34] Those were the questions that I needed to establish first. This is my first pass at drawing a diagram of it. I was figuring out where React sits in relationship to the backend servers and to the DOM.

[5:48] Our React zone in the middle here is where React takes in information and data from all-knowing Gods in the clouds and mixes it with our app's logic, and then creates our own version of what it thinks the DOM should look like, which is essentially a tree of UI elements.

[6:03] Then it sends that version to the actual DOM, which is, of course, what the user sees. Then when users click buttons or type text, those events are sent back to React, and it gets to React to whatever happened by updating its personal tree developments. We go around in a magical loop.

[6:22] Even just understanding that the data is up in the clouds, and React and the DOM, these are all distinct and separate things, it's one of those huge unspoken assumptions that a lot of beginner courses don't always point out.

[6:35] I had my map where React sits in relationship to the rest of the system, but I'm still wrapping my head around the visual structure of how a single React file breaks down. This is where we will start. This is the index of a create-react-app. This is one of my first stumbling blocks, since I didn't already have a lot of experience in JavaScript and web development.

[6:54] It helped me to break it down into four separate parts. The first was to realize there were two distinct kinds of input statements going on here. From just looking at the syntax, there are no obvious visual clues that React and ReactDOM are coming from our Node modules folder.

[7:11] I kept trying to figure out where in my folder structure the React and ReactDOM files were. There were no clues, I needed to go look in Node modules. I assumed their import statements would include the words Node modules, if so.

[7:24] Then from a very different location, we get a lot of component files like header, articles, and footer that we create ourselves. Learning to unconsciously distinguish between these two is something that we all internalize, and then immediately forget that we might need to explain it to others.

[7:41] This third chunk in the middle made the most sense to me, at least. I knew this was my domain where I was supposed to write and structure the app. Then this last line with ReactDOM.render was such a confusing mystery. I had to break it apart into its own little illustration.

[7:57] This is my translation of how I finally figured out what that line was saying. It's just saying, here ReactDOM which is an object in the ReactDOM library, can you please use your render method to render this component onto this part of the DOM?

[8:12] This was my home app. It just helped me to internalize the way our React files are organized. Next up, was learning what JSX was and how it related to React and JavaScript and browser, and possibly why I needed to care.

[8:28] Since JSX isn't fundamentally different to JavaScript, but more of an extension off the top, it felt right to call it the cherry on top of a vanilla ice cream cone stack. We write React in a special flavor of JavaScript called JSX.

[8:42] I like to imagine that whoever named it, added the extra extreme, extreme sports, extreme programming. While some parts of JSX can look quite different to JavaScript, it's just the extension of the language.

[8:56] We say it adds syntactic sugar on top of JavaScript, which means that it looks nice, and then it's easier to read. It's just the cherry and sprinkles on top of what is mostly a vanilla JavaScript ice cream cone. I liked the ice cream vibe going on, but it didn't quite explain enough of the key qualities of JSX I wanted to get at, so I expanded the metaphor.

[9:19] Since one of the main benefits of writing JSX syntax is that it lets us write markup inside our JavaScript file, I decided we need to swirl some mockup repo in 12 vanilla JS cone here. Usually, we have two separate files. We have one for JavaScript, and the other for HTML, and the need to link to one another.

[9:39] With JSX, we can manage our markup and logic side-by-side in one file. Of course, not everyone likes combining logic and data in one place. There's a long-standing debate about separation of concerns, just like not everyone likes Raspbian chocolate swirl together, but some of us do.

[9:59] Then I learnt about Babel, which is a compiler that takes our JSX swirl flavor and turns it into a simpler version of JavaScript that all browsers can read. All the main browsers like Chrome and Firefox and IE, whatever, are incredibly picky about their ice cream flavors. They will only accept pure vanilla JS flavor.

[10:18] Not only that, it has to specifically be ES5, which is a slightly older version of JavaScript. Our most up to date version right now is ES10. Babel is like an ice cream filtration machine that removes all that strange markup from our JavaScript files and translates it back into very plain old vanilla JavaScript.

[10:38] Once Babel has made that ice cream palatable for everyone to enjoy, it feeds it into a browser engine, which then runs a bunch of complicated systems -- I'm not going to pretend I understand -- and eventually, it spits out all the DOM elements that our users can see and interact with.

[10:54] We still get to write our React code in this lovely mockup rippled flavor of JSX, without being limited by what browsers are going to accept.

[11:04] Now, we get to the meat of React with our two leading components and props. When I'm thinking in visual metaphors, I usually find it helpful to step back and simplify concepts to their more fundamental categories.

[11:18] For components it felt clear to me, that this was simply a container. Containers are one of those lovely universal categories of the world. They hold things, they have boundaries, things go into and out of them. I always like to draw containers as boxes, first.

[11:34] It's an easy thing to draw before you have any better metaphor ideas and when you're drawing, almost everything starts as a box anyway. We have our box container, but then we need to add in the UI elements that make up our components.

[11:48] These felt to me that the front face of a component, the thing I'll use as seats. I always imagine the elements project off the front of the container. In my head, the component box is more like a tiny box theater with a stage, and the elements are performing on the stage to their audience and users.

[12:06] This backstage area is where we run logic and set things up to pass to the onstage elements. Then we have to add props into this theater scene. To me, they're very clearly a transport system. They carry data into the component.

[12:21] Because maybe I was in a theatrical mindset and I had some image of the Western performance of Aladdin in my head, I thought props made the most sense to ride in on a magic carpet carrying the data. I figured components were separated in space and they needed something with flight power to move between them, so we got carpets.

[12:43] When we add all of these theatrical metaphors together, we can see that we, first, set the stage for our component by writing a structure and then we can reuse that stage design multiple times and simply pass different data into each one, using the magical carpet transportation system of props. It's having one stage that can host multiple play performances.

[13:06] I had components and props down, and it was time to add in how they relate to one another and how data moves between them. Initially, I was expecting to draw my component boxes nested inside one another like this, and then have the props flowing down from the higher components into the nested components, because that's how they appear in code. We always nest component tags inside one another.

[13:29] Then I kept reading articles and tutorials where people would talk about how components are structured as a tree of elements. I switched to a visual that's a lot more like our family tree, you have your parent components may pass their data down to child components.

[13:45] It turns out it's better to imagine them as separate objects above and below one another, and then props can flow from the parents to the children. I want to focus on in this tree metaphor for a minute, because it's a good example of how much our metaphorical understanding of a system can influence how we think the code is going to work.

[14:05] This React component tree idea, it initially tripped me up, because obviously, I drew it like this. It's a tree, it goes upwards. Then I learned about the principle in React that data only flows one way, downwards. If I pass a prop to this fetter and I need it to go up to this child component, how is that going to work? Things were not adding up.

[14:34] Then I started looking around at diagrams that other people were drawing of their React component trees, and I realized that everyone else had their trees upside down, which explains a lot of my confusion. Which fine, this isn't a huge problem, but it is a little weird and counterintuitive.

[14:53] In my head, rather than use trees, it makes much more sense for us to just turn it into a potato plant. I liked this, and I started fleshing about it a bit more. We have our potato components and they're connected by the proxy root network, and then data is like water, it flows down the plant into all of our component potatoes.

[15:16] We can also explain how events work in React through this metaphor. Events are a little like nutrients that move up the plant, because in React events go up, well, at least most of the time.

[15:30] Let's say, we have a button down here that's an add button and in the bottom of our potato root plant, and it's going to be connected to a potato capture that adds potatoes every time we click it, and our button has an onclick event that calls in add handler function.

[15:48] That add handler function isn't inside this button component. If our users click on add and then we're going to go up the tree into nav and we find that our function isn't there, so we go up into app where we find our function declaration, and when we execute this function, it call setCount and that adds one to our count variable.

[16:11] Here, our piece of count data has been updated and now is a drop of water, and it's being rendered down here in a paragraph element, which currently shows we have three potatoes in our counter. It passes that new data down the plant, and it updates our count to become four.

[16:31] Let's move onto metaphor five. The confusion around props and state, which is a very common one among React beginners, including me. I ended up developing a metaphor based on spaceship fleets led by commanders that helped me understand difference between these two.

[16:49] Our components have now transformed from potatoes into spaceships, and they're flying in formation, but still in our classic upside down tree-shaped structure. Just like any good forward-thinking team, this fleet has a distributed system of leadership.

[17:05] Some ships have their own commander inside them and this is our state commander. Each commander is responsible for a piece of state data. This data might be a true/false Boolean, or it might be a numeric counter.

[17:19] All these commanders are in charge of keeping track of that state data and updating it when needed. If any of the props in their child components need to change based upon that state data, the commander sends a message to those children to update any of their props.

[17:36] Let's watch how this might play out in action. Let's say this player component in the middle owns a piece of state data and it's a variable code is playing. It controls those little music player that shows images while it plays bass tunes.

[17:52] The current state is set to false, and the pause button is highlighted. If the state of the is playing variable changes to true, which might happen if the user clicked the play button, then the commander sends the message down to its child components, they need to update their props.

[18:10] The image knows to change its display, and the play button knows to highlight, and the pause button knows to fade. The main difference is that state is data lives inside a particular component, and props are data that live outside the component and are passed in.

[18:26] Obviously, we want to make sure we don't have multiple commanders trying to control the same state data. They'll end up sending conflicting messages to their children, and we'll end up in some horrendous power struggle when no one knows who to listen to.

[18:40] We only need to add commanders to our app if data is going to change after launch, and by launch, I mean our fewer components have rendered to the DOM. When we're writing React in the code that's pre-launch, it's like the flight mission hasn't begun yet.

[18:55] Then there's this moment where you run npm run or yarn start, and your ships launch onto the DOM. Having a commander in charge or a piece of state is the only way to make changes to your apps data after that point.

[19:10] We've been through all five React metaphors, which were hopefully entertaining. Even if none of that React information was new to you, I hope you, at least, learnt something about thinking in visual metaphors.

[19:22] This entire talk is a ruse. It's not about React at all. It's mostly just about visual metaphors. The whole thing with the potatoes was an elaborate excuse to talk about this. I just want to stand on a soapbox for a moment and talk to you about visual metaphors and why the programming community desperately needs them.

[19:45] Here's the problem, programming documentation and tutorials are always walls of text. We are drowning in these long written explanations that are only willing to state things in official jargon-laden terms. They're slow to get through, so most of us don't. There's a reason that read the docs has become a judgmental reprimand on Twitter.

[20:07] Perhaps, we should be thinking about why the docs are so hard to read. Because documentation tutorials are usually a visual desert, you see very few diagrams, and you see even fewer animations or illustrations.

[20:21] Almost nothing is explained through metaphor or analogy. It's always seen as too playful or too imprecise or too unprofessional, but I am not the only visual learner in this virtual room. There are many others like me, and when they are faced with walls of text and documentation and blog posts that don't include any relatable comparisons, they get a bit sad and lost.

[20:44] Obviously, this isn't the fault of the developers writing documentation tutorials. That job is already hard, and making metaphors and visually representing them isn't a skill set most developers have cultivated.

[20:57] However, we're also aware there's a slight diversity problem in the React community and the greater web development community as a whole. I don't just mean race and socioeconomic status, gender. The way web development is currently explained and taught limits what kinds of thinkers and creators can join the community.

[21:16] Demystifying the discipline is going to be a huge part of fixing that. While web development has become much more inclusive lately, all learning materials and explanations are still lagging behind, and metaphor can help here.

[21:32] It gives us big picture stories that newer programmers can relate to, framed in familiar terms like food and plants and physical objects. It creates more accessible entry points into this fortress.

[21:45] Now, quickly, because I'm trying to sell you on the metaphors, I just want to make sure all on the same page about what metaphor is. A very basic definition is that, it's one we understand one thing in terms of another.

[22:00] Here, we have thing A that we understand and thing B which we don't. A Node will help us understand thing B and get a general idea about what it's like and what it can do, we map the qualities of thing A onto it.

[22:14] In the academic study of metaphors, they call thing A, the source, and thing B, the target. We source qualities from thing A and target them at thing B. I personally like to think of the source as a window frame.

[22:28] We look through it, and it frames the way we see our target concept. Something that would otherwise be foreign and abstract, suddenly, has familiar aspects that we can latch onto. This is essentially the human mind doing what it does best. It's pattern matching to adapt to an unfamiliar situation.

[22:47] Just like a window frame, the source frame also gives us a limited view of the world. Anything outside the frame, so qualities that these source and the target don't share, they get hidden away, and then qualities that they do share inside the frame, those get highlighted.

[23:03] Once we understand this system, we can strategically pick our metaphors depending on what qualities we want to highlight or hide. It allows us to focus on what's important and downplay any irrelevant details.

[23:17] I'm sure a few people are thinking, "Aren't metaphors just a frivolous distraction?" Why would I want to pollute my pure mathematical programming concepts with these fuzzy misleading stories, comparing them to completely unrelated ideas?

[23:32] This fans for poetic metaphor that you might be imagining is a very specific metaphor that we call figurative. This is the sort that appears in films and poetry and literature and mythology. It's your classic creative off the wall concepts like React precipitated plot.

[23:51] You're absolutely right, that it is very easy to let figurative metaphor get completely out of hand, to the point where it's more confusing than helpful. There is a way to be strategic about how we create figurative metaphors, because good figurative metaphor is built on top of a much deeper set of metaphorical structures.

[24:13] These deeper metaphors are known as cognitive or conceptual metaphors. They're called cognitive because it's a metaphorical system that structures our entire way of thinking. It's, essentially, our entire cognitive world. These metaphors are the basis of all human thought.

[24:32] This theory of cognitive metaphor was first presented by two researchers called George Lakoff and Mark Johnson, who were linguists and cognitive scientists in the 1980s, and they wrote this book called, "Metaphors We Live By."

[24:45] Some people might have heard of it. It has been enormously influential in linguistics and cognitive studies ever since, and it spurred a whole world of all this extra research into how metaphors structure the way we think.

[24:58] Their main argument was that we use metaphor all day, every day, in just our normal ways of thinking and acting in the world. Everything we say and perceive and do is built around a set of metaphorical frames.

[25:12] We can see this most easily in our language. For example, we will often talk about time in terms of money. We say, "I spent three hours refactoring that component, but it will save us weeks of debugging later on," or we'll say, "We've invested a lot of time in this feature, but I'm not sure it's worth the cost."

[25:33] When you start looking for these invisible metaphors, you'll suddenly find they're absolutely everywhere. This is powerful because it points out that all of our abstract thinking is built off metaphor.

[25:45] We have all these non-physical things that we'd communicate to each other, like emotions and thoughts and ideas and programming concepts. In order to talk about them, we have to use language that is based in the physical world around us.

[26:00] To give you a few more examples, we often associate being happy with the direction up. We say, "Things are looking up. I'm in high spirits. I'm on cloud nine." We're mapping emotions to physical space. We can also talk about ideas in terms of light. We'll say, "That's a bright idea, that illuminates the problem." We're connecting light with ideas.

[26:24] We can also say, "I found your talk moving, it touched me." That's touch and emotion being part of physical touch, or we can say, "Let's get deep into the code." We're mapping programming ideas to physical space.

[26:39] All of these physical expressions are based in our bodies. Embodiment is at the core of this. As humans, our bodies are our primary way of interacting with the world, so it's a logical starting point for building these metaphors. It give us a shared physical language with every other human. They immediately have that same reference point.

[26:58] I like to think of these as ingredients to build our metaphors with. We can explain our programming concepts through all the elements of physical space -- up, down, left, right, in, out, in front, behind.

[27:11] We can also use what we perceive through our five senses -- heavy, light, rough, smooth, big, small, warm, cold. We're able to use these to build more complex metaphors off this space, knowing that it's from a more fundamental way of thinking about the world.

[27:28] How we speak and use the Internet and computers is all a perfect example of this. Our interactions with computers are all based in physical metaphors, too. We think the Internet is above us, it's in the cloud, we're sitting below it, so we upload files to it and download from it. It's clear websites are locations we go to, we visit them.

[27:49] We have been to the React docs page and past pages are to the left, and future pages are to the right. They flow through our screens in time and space. We will unconsciously know this, but we rarely call attention to it.

[28:06] Of course, this applies to programming. The reality of what we're doing when we fire up a React app is you're making a bunch of tiny electrical pulses fire inside a microscopic piece of hardware that we can't see.

[28:19] We require an elaborate metaphorical system to do any programming at all. We're just moving imaginary objects around in the imaginary world of JavaScript. This shows up in the way we speak about it, too. We say React has a hierarchical order of components. They're layers of imagined objects.

[28:37] We pass data downwards, it has direction, we have hot reloading in our React apps or we get frustrated when our pages freeze, and if our codebase gets dirty, we need to clean it up. It's a physical route.

[28:51] TLDR is you're all already metaphor makers, which is great news, because it means you can use this system of shared cognitive metaphors to explain tools like React and web development in general, to people in a language they can already understand.

[29:08] Visuals are one of the best ways to communicate these fundamental metaphors. Since visual is all about creating representations of the physical world around us, there's no better tool. Words can also be a little bit lossy, but when you have a diagram or a drawing, you can't be vague about the relationships between elements in your image.

[29:27] Especially when you want to expand the metaphor into specific comparisons to realize things like plumbing pipes or kitchen equipment, then you're able to communicate both the spatial relationships and also, the key qualities with an image much fast than you would be able to with a giant block of text.

[29:45] Now, I soldier on the metaphors, and here's a humble request I have. I would like to see the programming community make more content that is both more visual and more metaphorical.

[29:57] If you are someone who writes blog posts, tutorials, contributes to documentation, or if you want to be one of those people, I want you to find ways to add metaphors and visuals into your work. This could look like making diagrams and contributing them to open source documentation, it could be drawing sketches into your next blog post.

[30:16] This is where any quality level is perfectly acceptable, as long as it helps explain the idea, or it could be making or sharing educational animations with GIFs, or using a combination of CSS and SVG.

[30:28] We just want to make sure we're rolling out the welcome mat when people need an introduction to a certain feature of React. Giving people familiar concepts with a little bit of storytelling to help get them hooked, and then we can dive into the deep code examples right afterwards, but we don't always need to leave with the textbook version.

[30:49] I already know what you're thinking, you're like, "I can't draw." Well, the good news is, it is not just about drawing. There are plenty of other mediums on offer in order to make visuals.

[31:00] You can make diagrams, or you can take photos or you stock photography, you can use icons, emoji to build visual stories, or you can make simple animations, or even just sketching at the level of simple stick figures with boxes and arrows can still lead to plenty of very meaningful visual metaphor.

[31:17] There are lots of wonderful tools available to help you do this as well. I, personally draw most of my work on an iPad in Procreate, but there are a lot of tools that don't require iPads. There's apps like Figma, Miro, Whimsical and Excalibur, which are all free. They'll help you create diagrams and visuals with very basic vector shapes.

[31:37] There are apps like Keynote and PowerPoint, which are amazing tools for just making simple animations. Then, of course, there's native web tools like CSS and SVG. For more advanced animations, I love GreenSock. Then we all know there is a ton of React animation libraries that I don't even need to be mentioning. Just Google a bit, you'll find them.

[31:58] For those of you who do want to go the drawing route though, I do have a whole page of resources up on my website at maggieappleton.com/resources, which has all my favorite books and courses and things that I personally use to help when I was studying illustration.

[32:15] I'm imagining some of you might be wondering, though, how are we supposed to come up with these metaphors, which is quite a good question. Metaphor design is not always intuitive and doing it well does require a bit of a tactical approach.

[32:30] I want to give you a bit of insight into how I personally develop my metaphors. This is going to be a very quick cheat sheet, going through my step-by-step process.

[32:41] First, I always want to identify the nouns and verbs that I'm going to need to build a metaphor around. This is laying out the ingredients for what you need to explain. These are all the literal things and actions that are going to go on at the scene.

[32:53] With our React potato plant metaphor, the nouns were components, props, data and events, and the verbs were passing data downwards, passing events up, running a function, updating data. When you map these out, it just helps you get clear on what you need to explain before you can try different metaphors on for size and see if they match up.

[33:14] Second, I will always state what I need to explain in very simple high-level terms. I'm looking for ways to frame it in those physical embodied properties we talked about, and getting it simple helps you get down to what you want to say.

[33:28] When we say components are containers, that's a great starting point, because a container is one of those high-level categories that anyone with a human body who lives in the physical world can understand.

[33:39] Third, you want to make sure you focus on the key qualities and functions that you want to highlight about the concept. This when we decide to design a metaphor for something, we're not going to try and explain everything about it. We need to pick what we think is important and focus on amplifying that bit with a metaphor.

[33:56] If we look back at our JSX world ice cream cone, the point here was just to communicate JSX is about combining markup with JavaScript. Nowhere in this visual are we trying to explain the inner workings of Babel's compile system, because that's not the point of it.

[34:12] The metaphor is only about combining two distinct things. We're not trying to pack too many details about the system into the metaphor. Fourth, is that in order to find interesting metaphors, you're going to need to think laterally.

[34:26] Lateral thinking simply means thinking sideways into seemingly unrelated fields, rather than thinking linearly, which is usually a logical step-by-step approach. Use the higher order concepts that you've already identified, and then find other examples of where they show up in the world.

[34:43] With our container component, again, this could become a vase or a bucket or a bowl or spaceship, anything that acts as a container turns out to be a potential metaphor. None of these things are related to the world of React. They are common touchpoints for all the humans in the world who don't know React yet, but not might want to learn it.

[35:03] Lastly, you always want to make sure you add in specific storytelling elements that make your metaphor worth paying attention to. You want to think of it as a tiny story. You want to hook people in with emotion, detail, and originality.

[35:17] You all liked this potato plant way more than you would have liked this gray bunch of boxes, even though they both demonstrate the exact same hierarchical tree structure. It's because humans are storytelling creatures. That's our entire evolutionary advantage.

[35:32] We invent these absurdly elaborate symbolic worlds and then communicate them to one another in stories, in order to influence how other people think and behave. Essentially, you just need to think in human terms and not in computer terms.

[35:46] Just to summarize those, you want to make sure you find your nouns and verbs, you want to state one main concept in simple terms, you want to pick functions and key qualities that you're going to highlight, you want to think laterally to find alternatives, and then you always want to make sure you add in storytelling.

[36:03] I want to leave you with this one quote that beautifully captures what I've been trying to say here, is from Tim Rohrer, who's one of my absolute favorite thinkers in this field around metaphors and their relationship to programming and machines.

[36:15] He says that, "Metaphor is just a conduit for the transportation of ideas between minds." Please help us transport our wonderful world of React to other people's minds. Now, go forth and make metaphors. Thank you very much.