 the longest, narrowest room I've ever spoken in. And I was just like, if I didn't have a mic in for a jet, but I don't know if I could really project that much. So this is loose, but like, oh, all right. Well, good morning, everyone. Good morning. Oh, okay, I'm sorry. I'm the first one. You're gonna have to do that again. Good morning, everyone. Good morning. Thank you so much, Jeff, for that wonderful introduction. As Jeff mentioned, I'm very excited to be here. I'm a software engineer at a little consultancy based in Portland called Tilda. And at Tilda, I presumably, most of the time, I work on a product called Skylight. That's my predominant, that's why I spend 40 hours a week, basically. And Skylight, if you are not familiar with it, is your favorite Rails profiler. And if you haven't heard Skylight, that's all right. You might have heard of some other things that we're involved with, mainly some of these languages and frameworks. So Ember is a front-end framework that Tilda actually, it was actually created at Tilda. And we use Ember in our product with Skylight. We also use Rails and Ruby and Rust. And there's one little logo that I left out for Java. It's all right. I don't wanna scare anybody, but we also use Java. And we're also heavily involved in the open-source aspect of all of these projects as well. So you might actually recognize some of my coworkers from the core teams of Rails and Rust and obviously Ember. So if any of these technologies sound interesting to you, quick plug, we are actually hiring. So if you're interested in solving very technical, of fun problems, if you're a performance-minded person, if you wanna go to Portland, come talk to me afterwards. But when I'm not working on Skylight, I spend a good chunk of my personal time doing something else, learning new things. And a few years ago, I decided that I wanted to learn something very big, something kinda scary. I decided that I wanna learn computer science and I decided that I was gonna teach myself the fundamentals of computer science. So I created a project called BaseCS, which is the basics of computer science. And it was kind of a scary undertaking because at the time I didn't have a computer science degree and actually I still don't have a computer science degree. So I didn't even know where to begin. Computer science is a huge field that is someone who doesn't have someone leading you through it. You're kind of like the blind leading the blind where you are the person leading yourself. It's very confusing. So I decided to just pick a simple goal in order to start because you have to start somewhere. I decided that I was going to learn one computer science topic every single week and write a blog post about it for an entire year, which if you do some math, it's 52 topics and blog posts. And I actually did do it and yes, it was a very long year. And sometimes it was really fun. As I started learning about things on my own, it was pretty cool to finally put concepts together with terms and all this jargon that I had heard and really get to the point where I wasn't just like nodding at someone talking about red, black trees. I was like, oh, I know what this is now. And I was like, imagine you like all the moji right here next to my head. So it was fun and it was very empowering and liberating but to be completely honest with all of you, a lot of the time it was really, really hard. And as the year went on and the topics that I wanted to learn about got progressively more complex, it was harder to find approachable resources that really would help me understand something when I was learning it on my own. So here's a tweet from one afternoon when I was trying to learn about a concept called redix trees. You can kind of tell that I felt very helpless. And if you're unfamiliar with the owl meme that I'm referencing here, this is what I was talking about. Steps, there's not like a 1A or a 1B, 1C or something but nope, conveniently left that out. But this is what learning computer science kind of felt to me throughout the year. I didn't always voice it, but that there was like this internal struggle of trying to make sense of things that didn't really seem to cater to where I was coming from, where I was in terms of my skill level. And perhaps this meme and that sentiment kind of resonates with you in your own learning journey, whether it's computer science or really anything else. And I think the most frustrating part about the whole thing was that I would find resources that I felt like I shouldn't have been able to make sense of, but once I actually started unpacking them, it was clear that one pass or two passes through it weren't really, it wasn't really gonna help me. I would try to read academic papers or watch lecture videos and find myself really struggling to understand something that I knew I could eventually get but was having a hard time because the resource was really limited. And to be honest, the whole thing was a little bit disheartening, but despite feeling pretty hopeless and not encouraged by the whole thing, I still kept going. And the reason was that I knew that if I felt this way, there had to be at least one other person out there who also felt just as helpless as I did. And I wanted to make it easier for them. So that was kind of a motivating factor. I didn't want anyone else to have to go through this whole process of trying to find resources and then feel really sad when they couldn't understand them. So I pushed myself to just keep going if only to help one other person who was in the same position as me somewhere in the world. And sometimes it's not a lot of late nights for me and even a few tears, but eventually I got through every CS topic that I set out to learn ever week, including Radex Trees, which coincidentally was the hardest topic for me for some reason. So after the end of the year, I decided to turn the base CS written project into an audio format. And I currently am still working on this podcast, the base CS podcast, which I post with my really good friends, Seron, you should check it out if you haven't and you can come find me for a secret that looks like this if you'd like. And from the base CS podcast, I also rushed out to create a video series by the same name created with the team at Dev2. And with each new project and each new medium that I explored, I started to realize that there was a pretty big audience and demand for these kinds of resources. And that kind of made me feel amazing because I was just hoping one other person out there felt the same way that I did, but it turns out a lot of other people did too. And there was such a high interest for approachable computer science resources. And this made me realize throughout this whole struggle that when I was trying to teach myself computer science and when I felt very alone, that was actually part of a much larger problem. It wasn't just me. There were other people who wanted to learn computer science fundamentals, but they were also finding it really hard to find approachable resources. So one of the things that I realized along the way was that learning new things is hard. Actually, correction, it is extremely hard. And if you've ever had to teach yourself something, which I'm sure everyone in this room has at some point, then you know this to be true. And when I was working on base CS and working on these different versions of it, I started wondering if this is such a large problem. Someone else must have taught themselves this before too. So how did they solve this? How did they learn new things? How did other people learn any new thing in general? What was the process like for that? Was there a good technique or were people just kind of like grasping in the dark to understand concepts that were completely foreign to them? So I set out to try to answer this question and not just because I wanted to get better at my own learning, but also because I really wanted to understand this on a broader level. And the reason was that I really wanted to make the best resources for the most people. So I did some research. Actually, I did a lot of research. I read a lot of papers on psychology and science and the history of learning. And along the way, I stumbled upon the work of this guy. I recognize him. And if you don't recognize him, you might have heard of him. His name is Richard Feynman. So he was an American theoretical physicist who actually created the field of quantum electrodynamics. So a lot of words. And you might know him from his work on helping develop the atomic bomb and I don't know, maybe that Nobel Prize he won once. But he's also the person who was responsible for figuring out what went wrong with the NASA Space Shuttle Challenger disaster. So he's done a lot of interesting things that have had a lot of impact. So you'd probably interact with him with his work at some point. But aside from all those things, I found out that he was also an author, a philosopher, an amateur artist, a lot bigger and my favorite, a bongo player, because of course. I mean, talk about him learning new things. If you spend some time learning about Feynman and his extraordinary life, you see that he actually accomplished so many things during his 70 years on Earth. But one of the things I think that is a thread across all of his achievements, whether professional or personal, it's not physics or science or math, really. It was his desire to learn and understand things. Richard Feynman had a nickname. He was often called the great explainer. And he got this nickname from his fellow colleagues and students. And the reason he, the reason this nickname kind of stuck was that he had a unique way of explaining concepts and teaching and communicating new ideas. And yes, he made like a lasting impact in one Nobel Prize, but I think it was his work as a teacher and explainer that arguably left a far greater impact on the world than anything else. He had such a great reputation for being a great explainer that when he was a grad student at Princeton, Albert Einstein, who was toward the end of his life at the time, actually attended his first lecture at Princeton because he heard about this guy and his reputation. And many years after he was a graduate student when he was actually teaching, he created some lectures that were recorded. And many years later, Bill Gates watched those recordings of those lectures. And Bill Gates referred to him as the best teacher I've never had. And in fact, he was so inspired by these lectures that he, you know, towards later on in his career, he actually found funding to be able to open source all these lectures and you can still watch them online today, which is pretty cool. So all of my reading on Feynman led me to wonder, why did he become such a great explainer? It's interesting to think about how people learn new things, but he was also a great teacher. So how did he learn new things before he taught them to other people? Well, in order to answer that question, we have to go back in time to Feynman's tenure as a graduate student at Princeton. So during the second year, he was preparing for something called his oral exams, which all the students had to take. And most of the other students were just looking at textbooks and kind of wrote memorizing and trying to cram things because they really wanted to pass these exams. Feynman did not do that. Rather than memorizing formulas or poring over textbooks, he did something different. He bought a blank, fresh notebook. And then on the top of the notebook, he wrote this. Notebook of things I don't know about. At least he's like honest and concise, I guess. So in this notebook, he wrote down the things that he didn't understand, the things he understood partly, things he understood very little about. And once he kind of outlined all the topics and his understanding of them, he set to work. James Glike wrote a biography on Feynman called Genius. And in that biography, he describes Feynman's process of going through this notebook pretty well. He says that in his notebook of things to learn, Feynman tried to find the essential kernels of every subject. Ironically, however, his notebook technique wasn't super impactful. I mean, it was good, but it was perfect because he didn't ace his oral examination. He actually got one question wrong. But at the end of each of these intense learning sessions, he had this notebook filled with things that he had learned along the way. And if you started at the beginning, you saw all the things that he knew very little about. And as he worked through each of these topics, you saw his knowledge and his rapport begin to grow and blossom. And by the end of each of these intense notebook study sessions, he had empirical evidence for how far he could come in his own learning. So you might be wondering, I feel fine, but none of us are like Nobel winning physicists unless you are, in which case, wow, that's cool. Well, I'm not. But I do actually think it's pretty interesting because we all have things that we wanna learn. We all have things we wanna learn more about and we each learn in different ways. So even though our topics might not be the same as Feynman, what would happen if we used the same approach to our own learnings? Even if we don't end up playing the bongos or picking locks like he did, there is still something we can learn from Feynman. We can learn how to learn. Throughout the course of his life, Feynman developed this technique that he really honed and started using for all sorts of topics. So it started in grad school, but he continued it throughout the course of his life. And these days, psychologists and educators and scientists refer to this technique. They refer to it as a mental model of the Feynman technique. And it's actually surprisingly simple. It's derived directly from his time at Princeton. And if you think about it, it makes sense how his empty notebook technique turned into this. So what is the Feynman technique? Great question. First of all, don't be worried, it's not too hard, it's only four steps. So let's walk through those steps together. First and foremost, we have to understand and identify what on earth it is that we're learning about. We have to identify the subject of our learning. We have to understand what is the topic that we're trying to pick apart, that we're trying to learn about before we can go about studying it further. And the best way to do this is to write down everything we know about the topic. It's great if it's in a fresh blank notebook, but it doesn't even have to be. The more that we learn about the topic, we can add to our repository of knowledge. And by having it written down, you can always reference it and we have that same empirical evidence that Feynman had when he was a grad student. So once we've identified the topic, we're on step two, explaining it to someone who knows nothing about it. Notice that I haven't said that we should learn new things, all we're trying to do is explain our pre-existing knowledge. And the reason that we should try to explain it to someone who knows nothing, like for our best results, try a child. Explaining something, explaining a topic as though the person you're talking to would know nothing about it is actually a really good tool for our own learning. It might seem strange at first, but the reason behind this is because it forces you to speak in plain and simple terms. Take a second and think about how you would explain a web request for caching or distributed systems to five-year-olds. What words would you use? What words could you use and what words could you not use? The interesting thing about this is that Feynman realized that children aren't likely to understand jargon and complexity of terminology. And as adults, we tend to lean on that. So if we strip that away, how much do we really know about a topic? Feynman once said that when we speak without jargon, it frees us from hiding behind knowledge that we don't have. And by forcing himself to explain things in the simplest way possible, he realized that complicated words and jargon are often a crutch, a crutch that many of us, especially in this industry, tend to use. Jargon can lead us to think that we understand some things just because we know the words for it. But just because you know the word for something does not mean that you actually understand the underlying concept behind it. So by explaining things simply, we force ourselves to get to the heart of a concept. By being able to explain something without leaning on terminology, you very quickly realize whether or not you really understand what's going on and whether you understand the idea that you're trying to describe or whether you just know words to help you describe it. Another benefit to explaining things the way you would to a child is that it forces us to be brief. You have to use brevity. And if you've ever hung out with children, then you probably know they don't have the longest attention span. So you have to learn how to explain and communicate your idea in very, very concise. Being brief pushes us also to be creative because you have to be concise but also understandable. And this is actually sometimes where words can be intimidating. We can actually reach for other things in our tool belt and Feynman realizes too. One of the things that he did was he started using drawings and diagrams to explain complex ideas simply. The most famous of these you might actually recognize it is the Feynman diagram. And he used this to describe the interaction between electrons as well as particle movements. And at the time, this was pretty revolutionary in the field of science. People were kind of like raising eyebrows at his Feynman diagrams and what he was trying to do with them. But now Feynman diagrams are probably some of the most well-known explanations for part of the physics. A quick side note, while I was researching Feynman, I learned that he actually, I think my clicker just died. That's all right. He actually had Feynman diagrams painted on the side of his van. He had this old van that he would drive around. I think it was cow tech, maybe at the time. He would drive around campus and he would always know like, oh, there it comes. Dr. Feynman in his van with his diagrams. And in case you didn't know it was him, his license plate was quantum. So that probably tells you a lot about what kind of person he was. Big narrative. But back to the Feynman technique. Once we've used simple terms to explain our concept, it's likely that we're gonna realize, oh, I actually can't explain this simply without using jargon or without using long sentences. Oh, I don't actually know this topic as well as I thought I did. And that brings us to step three, identifying any gaps in our knowledge. And I think this is the most important step in the whole process because this is where the actual learning happens. When you realize what you don't know, you can actually go back and do a more focused study on that aspect of the topic. And it's pretty cool because when you strip away all of these crutches, you very clearly see what you need to learn about. Next, in order to grow your understanding of any subject that you're studying. Once we've finally filled in the gaps, we've looked at resources and blog posts and we've figured out how to understand a concept deeply enough that we don't need jargon to explain it. Well, we're ready for the last step of the Feynman technique. Taking all of our knowledge and organizing is and simplifying it into a narrative. Organizing our accumulated knowledge and simplifying it is actually the most planned part in my opinion because you get to take your understanding of the topic and your ideas of how you think it works and sort of create something new. You get to explain it in your own words with your own perspective. And constructing a story out of it is actually a great way to teach too. When Feynman uses this technique, he actually used simple sentences to help him achieve the goal of storytelling. He once described the concept of atoms and how they interact and he did it in a single sentence. He said, all things are made of atoms, little particles that move around in perpetual motion attracting each other when they are little students apart but repelling upon being squeezed into one. Now this is not a super long sentence. And if we read it again, we can actually see that it adheres to all of the steps of the Feynman technique. He's explaining very specifically one topic and he's using no complex terms or jargon really and he's concisely telling you a story about how these characters, how these subjects, the atoms interact. But this is actually a really complex topic that he's explaining. Like this is probably more than one semester of physics. Someone out here probably doesn't know physics. You can correct me if I'm wrong. But I think it's a great example of his own technique at work. And he also used analogies to help turn abstract concepts into something more concrete by relating it to something that he knew his audience or his students would know. So it wasn't just particle physics that he explained so concisely. There's a great series of lectures from the early 80s called the Computer Heuristics Lectures. And actually, I think you can watch one of them on YouTube. And in it, he uses an analogy of how a filing cabinet and a filing clerk is basically how a computer works. And this is, keep in mind, this is the early 80s. So most people are not interacting to that much with computers and very few of them actually know what they are. So he's trying to explain this new technology in a simple way. And he basically just filled it down. I think this is probably the best explanation of what a computer is ever. He called the computer the glorified, high-class, very fast, but very stupid filing system. Which if you're ever gonna upset with your computer, just remember, the glorified, high-class, very fast, but very stupid filing system. And he did this at a time when people were having, very few people were having the resources to understand what these new technologies were. And he was kind of breaking it down for them, in a really approachable way. And the filing technique, I think, is awesome for a lot of reasons. But I think for programmers and people in the tech industry in particular, it's really important for us to think about it and consider how we can actually use it in our industry. It forces us to test our own understanding. And it challenges our assumptions. And when I say challenge our assumptions, what I mean is not just what we think about the topic, but also what we know about it and what we think we know but don't actually know and write it down. In software and in computer science, probably the hardest hurdle to overcome is the limits and bounds of understanding what you're dealing with. In other words, understanding the constraints of a problem are very difficult. And the same goes for learning new topics. You don't know what you don't know. And the filing technique sort of forces you to confront that head on. Because the filing technique forces you to approach your own gaps and your own knowledge, you start to see where you are more well equipped and where you need to fill in the gaps in your knowledge. Finan famously once said, I'm smart enough to know that I'm done. And I think this attitude towards learning and his technique in general is kind of the heart at what he did his whole life. His technique makes it a little bit easier for us to be self-compassionate and kind when we're learning something new because you're constantly reinforcing what you do know along the way. It's a cyclical process. Every time you find a gap in your knowledge, you go back and fill it in. And when you go back and fill it in, you realize, oh, I know this much more this time around. So you're not just feeling down about yourself because you realize I don't know all these things. You actually see your growth along the way. And as your understanding of something broadens, you start to feel pretty good about yourself. And I think the violin technique is important for programmers because it teaches us how to become better explainers. It's centered around improving our own learning by including others along the way. By reframing our own mental model to teaching as a part of your own personal growth. I think we actually improve not just our understanding of a topic, but also our teaching abilities. And we can help pass that on to other people too. Finally, it was known as a great explainer because while teaching any topic, he would distill it down to his simplest parts. If he couldn't explain it simply, he would start over and go more deeply into a topic. And this is pretty rare for academia. And I think this is still the case today. He didn't just keep his knowledge for himself in a little ivory tower up on a hill somewhere. He actually took these simple explanations and complex ideas into the masses. And he was trying to make it accessible to everyone. Some of his most well-known lectures are ones that he gave at Caltech. So at the time he decided he was gonna teach an intro-level physics class for students not majoring in physics. Which if you think about it for someone who's awarded a Nobel Prize and who could be just doing research and teaching advanced topics, that's a pretty amazing thing to do. And he decided that he couldn't explain his research and his field super simply to students who did not have backgrounds in physics, that he wasn't really doing his job and he didn't really understand the things he was studying and teaching. And he actually ended up going beyond students in university. In 1964, he delivered a series of seven-hour lectures on all topics in the whole realm of science. But if you watch these lectures, you'll notice he's not using complex terminology and he's not trying to make you feel like he's super smart and putting you down. Instead, he's using his own technique to explain scientific concepts to people who are sitting at home on their couch and who might think, oh, I'm not good at math or I'm not good at science. And that's, again, a pretty phenomenal thing for someone with so much knowledge to do. He made people feel like these topics were not just understandable, but also fun. And today you can watch these videos for free and you can see the technique in action and you can still take advantage of all of his knowledge, even though he's no longer here. So more than his contributions to physics and math and science, I think his life's work and his technique show us that making knowledge accessible for other people actually opens a lot of doors. His lectures started to change the way people viewed these topics. And when it was broadcast on television, a lot of people were probably inspired by watching this incredibly intelligent person share his knowledge so openly. And he kind of had a rock star reputation similar to like Neil deGrasse Tyson does today. And he kind of served as an example for his entire field. And I think we can actually use him as an example for our whole industry because tech really needs more great explainers. If Feynman did this for physics and science, what would it look like if we did this for technology? Well, if we had more great explainers, I think we'd be making knowledge more accessible and we'd be opening up this industry to people who might currently think that they aren't good enough or don't know enough math and science to work in this industry. We can reach people who are traditionally underrepresented and help bring new unique voices into the field and through accessible resources, people who might not have computer science degrees or might not have an understanding of one tool or one technology might feel more empowered to actually try to learn more. It would also mean that we'd reach people who are in the industry who want to learn something more and are struggling to find the right resources. If everyone in our field worked towards making a better explainer, we'd have a whole wide range of explanations. And you never know with whom that resource and that explanation will resonate with. For example, if I could have an explanation of great histories, I might not have spent an entire afternoon in tears trying to understand it. Hopefully now that I've written about it, someone else out there will not ever have to go through that too. If everyone made teaching a part of the learning process, learning new concepts would be easier for so many more of us. It's not all selfless. There are personal benefits too. First of all, learning becomes easier, I think if you use the timing technique and learning good things is empowering. Not only does it make you feel good about yourself, but you start to be in the loop about what's happening in the field and you're less afraid is one day you have to learn a new tool or technology or framework or language because you know how to learn, so you'll figure it out. For me, learning the fundamentals of computer science, through writing ACS was pretty liberated. I think I see things in a different way. I'm less afraid to dig into source code and how things work. I'm more willing to try and use things out and I think I'm a better programmer for it. So how do each of us become great explainers? Well, I think the manifestation of the timing technique can be a lot of different things. For some of us it might be writing a blog post or for others they might be adding some much needed documentation. So the next person who's trying to look up something has that resource right there available for them. Or maybe it's working with someone at your company who's newer so that you can actually explain something to them and you'll probably learn that you have something else to learn in the process. I record hours of lectures. You can apply this to meet so many different things and see an immediate impact. And I love to think that if all of us were great explainers and we actually tried to strike towards this, we'd see a lasting impact just like I did. We might introduce new people to the field who would have never entered it and we might retain and keep some people from the field who are kind of feeling like they wanna leave it. I think if we were all great explainers ultimately, we'd leave the industry a little bit better than when we found it. And to be honest, I don't think I can come up with a much better contribution than that. Thank you. If you're interested in learning about computer science, you can go to basecs.org. What was that? Basecs.org? Yeah. Basecs.org? Yeah. B-A-S-G-C-S.org, got it. Oh, you wanna be repeated again, is that what? I was just, I was just echoing. All right. You wanna echo this too? I wasn't working on a new project this year. This is Game Boy related. Like Game Boy, CS. No, it's about distributed systems. Oh. Yeah. That's hard. Um, I'm working on a new project this year, about basecs, basecs.org, where the GS answers are distributed systems, you can go to basecs.org. Basecs.org? You know what would be great about basecs.org? Is if you use this to convince other people to make the materials and then you just aggregated them, that would be true. So I would just buy the domains and be like, do you wanna write a project about this thing? Well, you motivated by basecs. Now come be the distributed systems of basecs. Yeah, I thought it was really key that you highlighted Rich Feynman using a notebook to learn things. And then, boom, oh my God, there's blank notebooks that you got today. So I saw lots of people who was up here, writing stuff down. Not Tampa. Other people up here are writing stuff down. That's right. What stands out like why distributed systems as the second big domain to tackle. Oh, that's a good question. I think distributed systems is a good second step because computer science is a lot of concepts and you're kind of operating as though you're in a little silo. And the minute you add other machines or other people, you have to throw all of that out the window because things that algorithms you would have used and assumptions you would have made with a single system, like that computer science introduces to you, that just does not work in distributed systems. So I'm throwing everything I know out the window is what I'm saying. That's what I wanted to do. Oh, I might ask a second question, which is when you were working on the BCS project, like did you ever get the feeling of, I'm just saying the same thing somebody else said? Yes, I think sometimes when people look at like technical logging documentation, right? It's like it's already there. They could already read about radix on Wikipedia. So what's the point? Oh, I don't want anyone to read about radix on Wikipedia. That's the thing. If you're already, as you said, if you're already a doctorate level expert in this topic, then you can get a lot of video articles. Yeah, it's just like if you, there's a couple years ago I Googled directed acyclic graph and I went to Google images and I saw the first page and I was like, ah, and I just closed the panel. I don't know what this is. So I was like, there's gotta be like a nice intro version to that and so like I try to add images to it and I try to write about it from the concept, from the context of which I approach that concept. So you could read the Wikipedia article, but you don't have to. There's no option stones. Sorry, I mentioned before, you need to make your, when you teach things, did you run more blog posts by like, so I don't know if you know anybody who's like, not familiar at all with that, just gonna test out how effective those posts were. Did I ever tie it out on children? Not necessarily children, but like just like people who are reading might not be familiar with those stuff. I guess the closest is probably people who can, so people who are like, I don't know, a month or two into coding who were like, I wanna learn about this computer science stuff. I've heard it's important. I don't know where to start. I like share it with them. Sometimes I feel like it's impactful. I'm sure for some people it doesn't work because everybody learns in a good way. So that's why I was like, oh, I'll create the podcast. I think the podcast is way more impactful for some people because you guys do a lot more explaining and back and forth when you're just having a conversation with someone. For other people, written is just like not, I don't know, it's just that people like, you know, videos, because they like the visual walking through. So I think different forms are probably profitable for different people. I should try it out on people who have a good tech industry to see what happens. That's a good experience. So when you were making these things, obviously we didn't have the things we're making. So when you're making these things, you had things we're making and you had to, presumably go read Wikipedia or go read things that were hard to look at. What was your strategy there? Say you live in a world where these resources don't exist yet. How did you approach it? So your question is, if I didn't have Wikipedia and those resources, or what did I do when I didn't have FaceCS? For a second. Yeah, what did you do when you didn't have FaceCS? I basically would look for a whole range of resources, pick out things I did understand from that. And what I didn't understand, I would go to another resource and see if I could explain it. So like with algorithms, people will talk about bigger notation and you know, space time complexity, but not everyone explains it well. So I'd be like, okay, I understand how this works. I don't know why they're talking about, I don't understand the space time complexity. This post, I'm gonna watch this hour and a half long MIT lecture. Hopefully they explain it here. So it's just like a lot of going through many versions of people explaining different concepts. So that's kind of when I realized, oh, there's a lot of people creating resources. Not all of them, you know, make a lot of sense because it's not like you can't Google these things and find them. They're just not all going to cater to where you are. So I had to look at a lot of resources and I'm just still at that point. Hi, this is Stefania. Thank you so much for the talk. I wanted to build on the previous question and ask you what were role models for you in terms of video, blogs, podcasts, teach and are great explainers in the tech domain and how is your process because I watch your videos and you're awesome. And you know, like I would love to learn how to think about your experience of creating these videos, the blog posts, like how do you get better at making these explanations in these videos for you so great. Thanks. That's a great question. I have a lot of people that I love their resources. Obviously, how many I can remember. Julia Evans has a lot of great blog posts. She has so many. Some of them I'm just like, I don't know anything about what this topic is. And I'm still not scared to read the post because I know you're gonna be, you know, make it approachable. I think Lynn Clark has amazing resources on, she does code cartoons and she's in like React, Flux, and I think she's in a recent one on Waslam, WebAssembly. And I guess to answer your second question, there are a lot more I just can't answer if you follow it right now. There's a bit too much at the top of my head right now. But to answer your second question, I think the more that you iterate on it, you start to understand what's lacking in your explanation. So for me, when I wrote the blog series, and then I turned each blog post into a, I'm still in the process of turning it into an episode from each podcast. And I turned some blog posts into videos. So by the third time of going around and revisiting the same concept, I realized, oh, this is actually the hard part of this concept. I should spend more time on this. The first time around, I didn't know that that was gonna be the difficult part. And there are other times where I'm like, oh, you should really explain this step by step because I've now gone through this concept, say for example, binary search. You explain it the first time, and you explain it the second time. You explain it third time by third time. You understand what problem there are a few questions. What are the easy things that you probably don't need to go over? And so I think that's probably why teachers are so good at what they do, and they've been doing it for a while because they understand the concept of the topic so well that they've been doing it for 10 years, 20 years. They're like, all right, today's algebra. I know the hard question is like, this is what we need to spend more time on. This is what I think they'll understand quickly. So I think revisiting a topic more and more will make you better at explaining that topic. And I think those should make you better at teaching in general, the more you do it. When you look back at those early XCS articles, is it painful after like 46 later, did you look back at number five or six or whatever? You know, why did I do it that way? Mostly it's the quality of the images. I got better with the quality of the images. And so the first five, you can skip those if you want, because like I scanned them and I was like, oh my God, this is not the iris. This is like, you can see the text behind it. So that's that way to be better, but yeah. At the beginning, like, what's your initial like, let's say this week or so, how much time we go into one article. Okay, so we're reading maybe two to three hours every evening. For a second, it was about four weeks. Well, a couple hours every evening on the weekdays, and then I would draw, the drawings would take like four hours probably, five, because I messed up a lot. And then I used ink. And then I realized, oh, you can use pencil and go over it and get this will be better. It's a long process. And then writing it is actually not hard by the time, like if you spent a week thinking about a topic and you've gone and created drawings, like the drawings will be right there. So the writing takes two hours. It's the learning of how to create the drawings that takes six days. Yeah, so ballpark, like 22 work hours through and through. It's interesting with getting into a harder or more nuanced complex topics over the year, although your systems were faster, your topic was more difficult. Did it stay the same like 22 hours through the year or was it actually longer? I think sometimes it got longer. Sometimes I would be a day or two late. What? I know. I was paid, logged in. Which my free content, I was like, I'm so sorry, it's not coming out, I'm okay. I should have posted that person on Twitter that I was like, man, published yesterday. And it's real quick, I hope they have to. But I do think that's an interesting question because I'm working on the podcast now and Seron and I are about halfway through. And now we used to be able to record an episode in about like half an hour. And now it takes us like a full hour to go through the topic, make sure we have the algorithm correct, make sure we're not making any mistakes. And it's just like, because it is getting harder as you go throughout the series. Because it builds on itself, which is cool. But also, thank you very much for your time. Thank you. Thank you. Thank you.