[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron. And today, we’re talking about how to use different memory techniques to learn coding with Kylo Robinson, Full Stack Developer, Coding Coach, and Creator of the Great Sync JavaScript Mental Model.

[00:00:24] KR: The analogies need hard work. It’s not just the person that comes to mind. You need to really flesh it out and make sure it’s representing the thing that helps you as a developer.

[00:00:33] SY: Kylo talks about how realizing he wasn’t understanding the fundamentals of JavaScript led him to create a world of memory techniques, what some of those memory techniques are, and how he uses them to retain different coding principles after this.

[MUSIC BREAK]

[00:01:00] SY: Thank you so much for being here.

[00:01:02] KR: Thanks, Saron. Yeah, it’s great to be on the show.

[00:01:04] SY: So tell us how you first got into coding.

[00:01:07] KR: Well, yeah, I didn’t actually have a background in computer science. I came from videography and film.

[00:01:14] SY: Oh!

[00:01:15] KR: And the first job I took sort of had some responsibilities in videography, but it also required me to look up to the website. And yeah, that was a whole, like new field for me. I had only done like very basic stuff on the website. And now they wanted me to take charge of the content on the website, which was in the beginning quite a challenge for me. And there was a guy on the team who was pretty much like the guru. He just knew everything about websites and was able to code. And I found myself having to keep going back to him for help. It was fine in the beginning to ask for help, but I had to keep doing it over and over again. And it just got to the point where I thought, “You know what? I’m going to learn this stuff on my own. I’m going to teach myself HTML and CSS.” And as soon as you start learning, you just want to learn more and more, and fast track a few years and I’m a developer.

[00:02:13] SY: So this was post college or when did this happen?

[00:02:16] KR: Yes. So this was post college. I’d already worked a few years as a videographer. I’ve made documentaries, and yeah, sort of took like a content role, which was a mix of media and that sort of got me on the path towards creating websites.

[00:02:33] SY: And in those early days when you were being told to kind of be in charge of these things and you’re building and you’re figuring things out, what was your learning process like? How did you fill in the blanks and figure out what to do?

[00:02:43] KR: Well, it was a lot of trial and error. So I relied heavily on online communities. I used all the free resources there were, and I did ask a ton of questions all the time. And luckily, the environment where I was working at the time had a lot of leeway. There was a lot of room for error. They gave me enough flexibility to try things. And if it didn’t work, it wasn’t the end of the world. So that really gave me a lot of confidence. So I could start building pages in HTML, CSS. And if that didn’t work, then we were just going to go to a contractor or a freelancer, but I was able to start doing it myself and to just try, just give it a shot, give it a crack. And when I couldn’t understand something, like I said I had this guy on my team who was always there to help, and I used online communities like CodeNewbie to help me and support me and just to encourage me. I really relied on that when I started.

[00:03:48] SY: So we have a lot of conversation in the community and on the podcast as well about the value of a computer science degree. Now someone who is working as a successful developer who did not get a computer science degree, what are your thoughts on that? Do you wish that you had one or do you feel like you did find just without one?

[00:04:05] KR: Yeah. I mean, it’s one of those things where sometimes you do find yourself thinking, “Oh, I really wish I just chosen this at university or college because I know I love it now and imagine how many years of experience I would have if I just chosen it from the start.” But whenever I think of that, I remind myself that my perspective is so unique and everyone has a unique perspective. And if we all thought the same way, if we all approached a problem the same way, it wouldn’t be much creative thinking and different approaches to things. I know that my background was very non-technical and I know that that could be a disadvantage in some ways, but because I had to learn the material from scratch and rarely get up and going very fast. I couldn’t have the luxury of a couple of years of slowly working through course material. It was like, “You know what? No, I want to be a developer. So I need to work through this material as fast as I can and get to grips with it as fast as I can.” And that teaches you to learn quickly and to dive in into the deep end and just have a crack at it. And that as a developer is the best skill to have. It’s the best approach to learning as well. I don’t need to be an expert at this. I don’t need a course. I can just go in and figure it out and sort of plunder my way through until it starts to make sense. And I think that’s what’s great for any self-taught developer.

[00:05:38] SY: So in this conversation, we’re going to get into memory techniques, which I’m very fascinated by because when I think of coding, I don’t think of a lot of memorization, right? Like it’s like we’re allowed to cheat, like we’re allowed to look at our old code and code on the internet and kind of put things together. So memorization isn’t something that immediately comes to mind. So I’m really interested to dig into some of these techniques. But before we get into memorization, tell me about your journey. How did you start using these memory techniques? Why did you start using these? Where did that all come from?

[00:06:11] KR: It started with a really long drawn out battle with JavaScript. I struggled with JavaScript. I just found it not nearly as rewarding visually as HTML and CSS. So I could write a line of CSS and you would pretty much see the change on the page instantly. For JavaScript, that’s just not the case. Often you would write something and you’d have no idea what went wrong and you console log, console log, console log, trying to understand what’s happening in the background. And it was almost like this mysterious world like that was going on and I couldn’t visualize it. I did take a sort of part-time bootcamp just on JavaScript to help me get through. And that did, in a sense, in terms of helping me to write JavaScript to get things to work. So I could start writing some Vanilla JavaScript and it introduced me to React. And that gave me some confidence. I was sort of like, “Okay, I can actually build a website. I can start building basic React applications.” But it only dawned on me when I started interviewing for jobs and saying that I knew JavaScript, but I realized that I really, really didn’t know it. I did not understand JavaScript at all. I could get it to work, but as soon as there was something that wasn’t working as I hoped it would, then my sole solution was to go on to Google to see what’s on Stack Overflow and whatnot and copy-paste solutions. And for me, I wanted to be a professional. I wanted to feel confident in the language that I was using. And I just thought this couldn’t go on. So I wanted a way not to memorize JavaScript, because as you mentioned earlier, learning, memorizing stuff in development isn’t it a thing. We don’t need to. But I did want to know the basics without having to Google it all the time. So the concepts I didn’t want to be Googling, but step A, B, C, yes, but not the concepts. So that’s how it started.

[00:08:23] SY: And what made it click for you that the answer to this problem was visual memory techniques specifically? Why was that the answer?

[00:08:33] KR: I’d always had an interest in memory and mnemonics and just visual learning. I was fascinated with the idea that you could turn something that you were trying to learn or remember, turn it into an image that could be very abstract, and you could use that as a way to recall it. Instead of trying to remember the word or trying to work out the concept in your mind, instead of trying to do all of that, you could just think of the image and the image would tell you a lot. So I’d already researched a lot about that and it was an interest of mine, but it wasn’t until I read Eloquent JavaScript, which is just fantastic for anyone trying to wrap their mind around JavaScript. But there is an analogy for variables and it talks about variables being like an octopus, and you have octopus’ tentacles, and what they do is they latch onto values. So they’ll grab it and then they’ll let it go and they might latch onto another value. And that is a good way to think about variables. And for me, I was like, “This is how I wanted in JavaScript.” I want analogies like that which help me to understand, like I said earlier, that mysterious process what’s going on behind the scenes. And I thought to myself, “Well, how far can we take this? How many other analogies can we come up to help explain how things work?”

[00:09:56] SY: And are these analogies and visualizations that you came up with on your own, are these things that you read in a book? Where do these visualization techniques, where do they come from?

[00:10:07] KR: I’ve come up with them on my own. It’s been a long journey of trying to come up with the right images and the right analogies. So actually, pretty much all of the analogies that I started with to explain things I no longer use.

[00:10:24] SY: Oh, interesting.

[00:10:25] KR: I learned a lot about what makes a good analogy and how abstract should you go. So like an example is learning arrays. So if I wanted to learn something about arrays, I was like, “Okay, let me at least memorize all the methods of an array.” And immediately, you might already be thinking this as like you shouldn’t be memorizing all the methods of an array. You can look up that, but I was already down that road. Well, I’m not trying to turn everything into images and analogies. So I was like, “Ah, let me add that in,” and I came up with this whole image of array, like a stingray that you find in the ocean and it’s got this like Swiss army knife full of tools. He’s calling up all the different tools and each tool represented an array method. But I made the image and I worked it out, but I realized that it didn’t help me at all while I was coding. I’ve never actually needed to think about the stingray and picture its tools. I was like, “I just never need to do that.” So yeah, that’s sort of when I realized that, “The analogies need hard work. It’s not just the person that comes to mind. You need to really flesh it out and make sure it’s representing the thing that helps you as a developer.”

[MUSIC BREAK]

[00:12:01] SY: So walk me through an example of when you were either at a job interview or you’re coding for yourself where one of these techniques, one of these visualizations, where they came in handy. Tell me about that moment.

[00:12:15] KR: So quite recently, I had to use it in a job interview. There was a question which needed you to understand what this variable was pointing to. And if that was a few years ago, that would have just completely thrown me because this variable I’m sure that many can relate to this, but it was even the most confusing thing. I could just never understand what this thing is and what it’s meant to do and what it points at. But I had created an analogy to actually picture this as a turtle, a flying turtle, and there’s a story for how this flying turtle needs to find its way to a ship, and a ship in the Great Sync is an object. So it’s really there’s a story about how this turtle needs to find its way to the ship, and turtle actually, the acronym for this is turtle hops in ship, and I was able to, in the job interview, just basically follow the turtle’s path and picture in my mind, “Okay, so where is the turtle now? Where is he headed?” And then work my way back to, “Okay, now that’s the object that the turtle has found.” So that’s the object that is pointing to you. And I was like, “Yay!”

[00:13:35] SY: It worked! That’s awesome. So what makes a good visualization? What makes a good mnemonic device?

[00:13:44] KR: One that ties everything together, I find that too many analogies are just separated. They exist on their own and they don’t tie into each other. A single standing analogy is fine if you are just trying to understand one small thing about something, but when you’re trying to look at the big picture, which is what I was trying to do. I was trying to understand JavaScript and everything. I didn’t want to just look at one aspect and turn that into an analogy. If I’m going to turn that into analogy, well, how does that link then to this other concept? They need to tie into each other. So for me, the first thing that makes a good analogy is that it makes sense in relation to your other analogies that you’ve used, that they aren’t conflicting stories that you’ve created, which just creates confusion and sort of blank areas in your map of what you’re trying to explain. So that was a challenge. And then the second one is how abstract do you go, especially when I’m coaching and using this material to teach others? I can’t just think of the most craziest thing in my mind because that might work for me, but I need analogies that everyone can relate to. And that’s a challenge and it’s still an ongoing challenge and I’m still looking at a lot of my analogies and just questioning, “Is this something that anyone can understand? Is that something that we can relate to and picture, but at the same time, be crazy, weird and funny and make it memorable, which is what makes a good enough?”

[00:15:22] SY: So when you think about all the analogies that you can come up with in the context of JavaScript, right? You’re trying to learn JavaScript, you’re trying to do well in an interview, do well at your job, remember these concepts. Do you have kind of consistent characters and analogies for the world of JavaScript? Or do you really create kind of a series of distinct moments, distinct images that are very different from each other?

[00:15:50] KR: No, they are all tied into each other. So they fit into each other. I really start with the basics to begin with, like, “What is a value? What is an expression?” And I have images for those. And then those images get used in some of the bigger concepts. So an execution context, which is quite a horrible, nasty word when you’re learning JavaScript, but that is a much more complex topic. And that image consists of a lot of the smaller images that we focus on when we learn about what makes up a JavaScript program. So where’s our code running? What are the values? How are values found? How are values stored? And you need to understand all of that first and understand those micro images or small images zoned in images and then apply that in a larger context and you build your way up, which is quite powerful, because then you can look at an image of a closure, which again is another scary topic and a scary thing when you Google it and you’re trying to read a blog post about what a closure is. And you’ll look at an image and there’ll be lots of small elements going on, lots of small stories and characters that might be there, but each character has their own story and their own purpose that is independent of the larger story of what contexts are, if that makes sense. So yeah. I really do try to focus on the small and then grow it from there.

[00:17:32] SY: So what kind of analogies, what kind of visualizations don’t work? What should we try to avoid when we’re trying to come up with our own mnemonic devices for our own concepts?

[00:17:43] KR: You have to be very careful about the analogy itself. And if they are false, like things that you assume, false assumptions based on what your analogy is, which can actually lead to a false mental model or a false understanding of that topic. So the analogy which was meant to explain things more clearer actually created more uncertainty and almost incorrect assumptions about that topic. A common one that we always come across in coding is talking about variables as buckets, variables of buckets, and it stores things, but that image implies that one bucket can contain many values and that how can you have the same value, but in two different buckets, which in coding, you could have two variables pointing at the same value. So inverted commas, speech marks contain that value. But this analogy of using a bucket makes you think that that’s impossible. That’s the biggest thing with analogies is that you want to put time into what that analogy should be, and if it explains it like it should and doesn’t just create more confusion about that topic. The other thing with like bad analogies. Oh, this is definitely in my opinion and it’s from the perspective of mnemonics and memory technique. The analogies that are dry and boring are so forgettable. I don’t know how many analogies we’ve heard of cars and dogs to explain classes. I mean, the number of car analogies I’ve heard of the time is just… and you forget all of them. They’re just not memorable. They’re not exciting. There’s nothing unique about them. Yes, they work in the context of the blog posts that you’re reading or the video that you’re watching about when it’s explaining it and it helps in that moment. But if you’re looking for a resource that lives on in your mind as a way to reference your understanding of that. So if you’re learning something new to compare it to what you already know and to use that knowledge to help you remember what you really know, our analogies just don’t work. There’s just too many of them.

[00:20:05] SY: So what about some mnemonic devices for people who maybe aren’t very visual learners, maybe they’re more auditory, more tactile learners? Any ideas on that?

[00:20:17] KR: Sure. I mean, the thing is with analogy and abstraction is that, of course, it’s not for everyone and this isn’t the only way to make something visual. It’s one way. So instead of creating these visual images, I think just making sure that you use diagrams and squares and circles to understand relationships between things. With the Great Sync, I do actually help, I try to draw the material as well. So you actually sketch, and yes, you use these crazy worlds, fantasy characters and environments in your mind, but to explain it to someone else, you could just be drawing a circle or a square or a line connecting two things. And that is in itself very powerful. That’s taking a text medium and translating it into something that someone else can consume that’s different to the text. It’s another way for them to look at that content to understand it and not have to always try to digest texts or whatever it is. I think whatever way you come up with avoiding, just looking at the code itself is a really like a huge, huge improvement in terms of communication and just trying to look at it from a different angle.

[00:21:42] SY: So tell me a little bit more about visually creating this world, this sketching. What does that process like? Are you kind of sketching the whole world in front of you? How are you building that out?

[00:21:54] KR: Well, let me just say it to begin with that I am a terrible sketcher. Absolutely terrible. And I’ve tried so hard to get good at it. I mean, I spent the majority of my honeymoon trying to practice to draw so that I can sketch out all of these ideas in my mind. And I reached a point where I just had to accept that I’m just not good at this. And all the time that I’m sketching, I could be programming. I could be learning more coding concepts. I then reached out to illustrators. And luckily, I came across a really talented illustrator called Kerry Gregory who has been with me from the start, helping me froth the world of JavaScript. And we have a good workflow now where I send my crazy sketches that only she can really interpret and I explain why you have to have certain elements. If you don’t understand JavaScript, it’s like, “Why are you including that in your image? It’s just so random., like the turtle. I’m adding a wingsuit, because it’s a flying turtle. So it’s got to have a wingsuit.” And now Kerry is like, “Really? You want a wingsuit?” I'm like, “Yeah. Yeah. We need a wingsuit.” And she’s able to interpret that and there’s a bit of back and forth trying to get it to look the way I want and in a form that I can teach that I can use it to coach others. And yeah, that’s it really.

[MUSIC BREAK]

[00:23:30] SY: Coming up next, Kylo talks about a good place to start for people who want to build up their own memory devices to learn to code after this.

[MUSIC BREAK]

[00:23:54] SY: So for people trying to build up their own memory devices to learn to code, trying to implement some of the techniques we talked about today, what’s a good place for them to start?

[00:24:03] KR: Funny enough, when I was in the middle of creating the greatest thing and getting lost in a lot of the analogies, I came across a course that came out by Dan Abramov and Maggie Appleton. So Dan Abramov is basically like a rock star in the JavaScript world. He’s worked on Redux and on the React team. And Maggie Appleton is an illustrator at Egghead and she comes up with these incredible logos and illustrations to represent courses. And they came up with basically a very similar concept to the Great Sync, which was to turn JavaScript into something abstract and make it visual and build a mental model. So they talk a lot about mental models and using these images to build that up. So that is an incredible resource that I encourage anyone to go and have a look at. It’s called Just JavaScript. And it’s just at the point where I was worrying, “Why am I drawing these crazy fantasy worlds? Shouldn’t I be coding like this? Maybe I’m on the wrong path here. Maybe this is just too weird.” And when I saw that material, I was like, “Ah!” I mean, to have these two be talking about these concepts and Dan Abramov is saying, “This helps me as a developer,” and all of his experience, I’m like, “Wow!” Well, there we go. This is useful. This can help people.” So yeah, I would say that’s a good starting point. And Maggie Appleton has a blog called Illustrated.dev. There’s a lot of material there on what it means to come up with these abstract images and illustrations and how to create metaphors to represent concepts, not just in JavaScript, but anything, anything technical. So I would definitely say that that’s the best starting point.

[00:26:11] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Kylo, are you ready to fill in the blanks?

[00:26:18] KR: Yes. Sure.

[00:26:19] SY: Number one, worst advice I’ve ever received is?

[00:26:23] KR: So you have to start at the bottom because that’s what everyone does or that’s the “industry”. So like I said at the start, I came from film and videography. And in the film industry, I definitely had this advice given to me all the time that you need to start at the button. We’ve all had to do it. You’ve got to start at the bottom and suck it up. And that’s just not true at all. We make our own path in life and don’t let anyone tell you what path you should take.

[00:26:56] SY: Number two, best advice I’ve ever received is?

[00:27:00] KR: Stop trying to master everything. Accept the things you don’t understand right now and move on. I mean, this was a really big lesson I had in that part-time bootcamp. We were just racing through so much material. Before we understood one thing, we’d already moved on to the next and then onto the next and onto the next. All of us in the class were really struggling and just trying to keep up and understand what we’ve learned and apply that, just got crazy, but only at the end of it and we look back at what were done, it was like, “Wow! I’ve learned so much stuff that I would never have done if I’d followed my own rules and this desire to understand everything perfectly.” I’m actually in a better place now to go back to a lot of that material and I’ll start to improve it and understand it better. So yeah, stop trying to master everything.

[00:28:00] SY: Number three, my first coding project was about?

[00:28:02] KR: It was a part of a social media campaign where we were using the university mascot for a marketing campaign and this dragon. And I created a landing page, which had this big dragon face on the front, these like big, scary eyes that you landed on the page. And there was a form there that had an input and you could copy the strings of letters and numbers that we posted out on social media, which was meant to represent what dragon speak would be like, like their roles or language or whatever. You could copy that and paste it into the website and it would translate it to English.

[00:28:46] SY: Cool!

[00:28:46] KR: It was a terrible website. It basically consists of about a thousand if statements.

[00:28:52] SY: But it worked.

[00:28:53] KR: It was fun. Yeah, it was fun to make.

[00:28:54] SY: Yeah. Nice. Number four, one thing I wish I knew when I first started to code is?

[00:29:01] KR: I wish I knew the importance of not comparing yourself to others. I started out really trying to gauge how good I was by looking at what other people were putting out on Twitter or on any social media and saying, “Oh, can I do that?” I was like, “No, I can’t. Maybe I’m not really good at this.” And that holds you back. It’s a very easy trap to fall into because you want to be part of these communities and you want to contribute and you want to show your appreciation, but you have to be careful to not compare your work to theirs because you don’t know what journey they’ve been on and you don’t know what challenges they’ve had to face and you’re on your own path and you will start creating the work you want and that you’re happy with as soon as you let go of what it’s like compared to others.

[00:29:54] SY: Very nice. I like that. Well, thank you again so much for joining us, Kylo.

[00:29:57] KR: Thank you. That was really enjoyable.

[00:30:06] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.