Looking for more podcasts? Tune in to the Salesforce Developer podcast to hear short and insightful stories for developers, from developers.
10. How to Learn Something New
Hosted by Jonan Scheffler, with guest Vaidehi Joshi.
There's programming, and then there's computer science. As developers, we may understand how to code a solution to a problem, but we may not know some of the fundamentals of how software actually works. Unable to find direct answers herself, Vaidehi Joshi started BaseCS, a blog that explains (with pictures!) everything from counting in binary to analyzing algorithms and data structures in memory.
Vaidehi Joshi found that many resources on the web about core computer science concepts she wanted to know more about were either too obtuse or too academic. She started a blog, basecs, where she wrote down something she had learned that week--every week--for an entire year. While learning something new in and of itself was a delight, her curiosity led her to question how people learn best.
She discusses the Feynman Technique, which, through a processes of iteratively explaining a concept to someone who doesn't know anything about it, strengthens the knowledge for both the student and the teacher. The best way to do this is by telling a narrative. It keeps the listener engaged, while also serving as a way of identifying gaps in ones' own understanding, as new questions arise.
Links from this episode
- basecs and baseds are two of Vaidehi's websites which teach concepts about computer science and distributed systems
- The Feynman Technique: The Best Way to Learn Anything
Jonan Scheffler: Welcome back to Code[ish]. My name is Jonan Scheffler. I am a developer advocate here at Heroku, and I am joined today by a very special guest. I'm out here for Traversal Conference, or TraversalConf ... Is it just Traversal?
Vaidehi Joshi: TraversalConf.
Jonan Scheffler: TraversalConf, I think is good or just ... I don't know. In any case, I'm out here for this one conference that goes by Traversal-
Vaidehi Joshi: We don't know where we are. It's fine.
Jonan Scheffler: ... or TraversalConf. And I am joined by my good friend, Vaidehi Joshi. Introduce yourself, if you wouldn't mind.
Jonan Scheffler: The best one. I used to work at New Relic. I worked at New Relic when Skylight was released, so I don't know. We were watching you very carefully when you came along. I think they're actually kind of complimentary products. They provide different things at this point. If I bought a new Rails app, I want both.
Vaidehi Joshi: Yeah, I think they actually do kind of different things, so interesting when we get lumped in together, but we also do some open source work.
Jonan Scheffler: A little bit of that Ember stuff.
Vaidehi Joshi: Yeah, we made that little thing called Ember.
Jonan Scheffler: And EmberConf.
Vaidehi Joshi: Yeah, we're pretty active in the Rails community. Some of my co-workers are on the Rust core team, they used to be on the Rails core team. So yeah, we're big on open source, and we're generally performance minded as people.
Jonan Scheffler: People who like to get down to the nitty gritty and benchmark things. If you are someone who finds yourself benchmarking everything, maybe you'd like to go work at Tilde. Does Tilde have any open positions?
Vaidehi Joshi: That's so funny you mentioned that. We are actually hiring. Yeah, we're looking for some staff engineers. And we're really open to people who maybe went to a bootcamp, people who are performance minded, people who are interested in ops stuff, because we really care about our product and we take it in different directions. And we're a very small team so we do all the different parts of-
Jonan Scheffler: You wear a lot of hats.
Vaidehi Joshi: Yes. So if you are someone who likes hats-
Jonan Scheffler: Come along. I think though this is important because what you're describing to me is that you're trying to cast a wide net. And I think anyone when they're trying to get people into a pipeline to hire onto their team, they cast a wider net as they possibly are able, and yet people go and they read those job descriptions and they're like, "Oh no, it said blue hair. I don't have blue hair, so I'm out." Right?
Vaidehi Joshi: Yeah.
Jonan Scheffler: You eliminate yourself. I think what you're asking really is, "Please don't eliminate yourself. Look at our job description, if it doesn't describe you exactly, assume it's a mistake and apply anyway."
Vaidehi Joshi: Yeah, I don't even think it can describe everyone exactly. That's what we want. We want lots of people to feel like, "Hey, I like what they're doing, and I could maybe see myself there."
Jonan Scheffler: Exactly.
Vaidehi Joshi: Don't shy away from it.
Jonan Scheffler: But I'm sure it's going to work out great and you'll love working there. You get to work with brilliant people. Speaking of brilliant people, tell me about basecs. What is basecs?
Vaidehi Joshi: So basecs is ... Well, it's kind of taken on a life of its own. It's grown into a much bigger thing than it was originally. So what it started off as was a personal project for me, where I decided that I wanted to learn computer science, because I don't have a CS degree. And this was probably a couple years into my career as a developer, and I would hear people reference computer science and things, and I would nod and smile, and then in my head, I'd be like, "No idea what that means, I should put a pin in that, one day I should learn it." And then I just realized, "Oh, there are a lot of things in this category I should learn. This is a big gap." So at some point, I was just like, "I want to challenge myself this year. This is a big gap, why don't I try to fill that gap this year?"
Vaidehi Joshi: And I'm a person who makes lists and I like schedules. So for me, having a project that aligns to a calendar year really works well.
Jonan Scheffler: This was immediately obvious to me. As soon as I heard that you're taking on this project. I was like, "This is a person who likes to check boxes and lists," because it was intense. Tell people about this project you started. It was 52 weeks in a row, you wrote a blog post, about what?
Vaidehi Joshi: Yes. So I decided I was going to write a blog post about one computer science topic every week for a year. I actually think I skipped two weeks, so it's technically 50 weeks.
Jonan Scheffler: Oh, was it around the holidays? That's fine. We'll forgive you.
Vaidehi Joshi: No, it was just like two weeks where I was like, "I'm not gonna be near WiFi or a computer." And this was early on, so I don't think anybody noticed. But sometimes-
Jonan Scheffler: Sounds like a lovely two weeks.
Vaidehi Joshi: It was so early though that I didn't realize how nice it was, and then by the time December rolled around, I was like, "I've been writing every week for so long."
Jonan Scheffler: Yep. And when you get down to like the 35th episode, if you're a couple days late, people start to email. They're like "Where is my fix?"
Vaidehi Joshi: Yeah, they started paying attention. I was like, "Oh, good thing I didn't miss any posts at the end of the year."
Jonan Scheffler: So you started out teaching yourself these computer science concepts, because it was a hole in your own learning, you realized about yourself. You wanted to be able to have these things. Honestly, I have a pretty non-traditional background as well. I was a poker dealer and many other things in a former life, but eventually found my way into software. Coming through the Hungry Academy Program, which was created by Jeff Casimir, who now runs Turing Academy here in Denver. And Turing is heavily involved with the production of TraversalConf, and of course many other events and activities around the Denver area. Great, great code school to be a part of. It's the one that I recommend to people today still. When someone comes to me and asks me what code school they should attend in the country, Turing is the top of my list. I'm curious to know about yours.
Vaidehi Joshi: Yeah, I think when I was applying to ... I also went to coding bootcamp. I applied to the Flatiron School, and Turing, I think was my second. And I think the big reason I put Flatiron first was I was like, "Oh, it's in New York City. I want to be in New York." And I think it was a shorter amount of time. But yeah, Turing was up there for me too, because I think the thing that really drew me to those two bootcamps was the fact that they both were kind of pretty transparent about the fact that they wanted applicants from diverse backgrounds.
Jonan Scheffler: Right.
Vaidehi Joshi: And I don't just mean diverse in terms of where you're from, but like what-
Jonan Scheffler: You don't mean like someone puts star diversity on their homepage?
Vaidehi Joshi: No, I think it was cool as they were both like, "We want artists and musicians and writers and teachers." And I think by creating this level playing field, it made me feel like if I go to this coding boot camp, no one's going to look at me like I'm stupid.
Jonan Scheffler: Or you don't belong.
Vaidehi Joshi: Yeah, because everyone else is also coming with different things to the table.
Jonan Scheffler: Right.
Vaidehi Joshi: And no one there is going to expect that I have the certain level. And it was kind of amazing, because everybody was extremely talented, but I think all of us were like, "Oh, maybe I don't belong here." But everyone else says that it's okay for us to be here, but we're all talented.
Jonan Scheffler: We're all going to be imposters together, right?
Vaidehi Joshi: Yeah.
Jonan Scheffler: And that's the thing. I talk about this often to people coming into software, that if you were to study as hard and as fast, if you could replicate what Vaidehi has done with this 52, that's crazy. It was a crazy amount of work. You were talking about it, I think it was like eight hours or 10 hours a week, you were putting in 20 hours. 22, I think, was the number you hear for [inaudible 00:06:58]. I remember now.
Vaidehi Joshi: I think Jeff did the math for me, because at some point, I was like, "I don't want to think about it."
Jonan Scheffler: You were like, "I don't even ..." So it was four hours to do the images and yeah. So a lot of work every week for a whole year. So if you learn to study like you can, obviously you have learned to learn at this point, and you spend the rest of your life studying software concepts, you may get 1% competent at what is out there. But it's going to be a different 1% than the person sitting next to you and every other person you meet in software. So early on, it's easy to look around and feel like you're looking uphill all the time. Everyone is better than you at something, but you're better than some people at a lot of things, even fresh out of a code school. And I think that's the hardest thing to convey.
Vaidehi Joshi: And there are going to be hills no matter what, that's the thing. You could be doing it for 20 years, and then you could be super competent at Ruby, for example, or like React, which it's not even been 20 years of React, so who knows what battle will be-
Jonan Scheffler: Although, I've seen people looking for 20 years experience, React [crosstalk 00:07:52].
Vaidehi Joshi: Yeah, that's always interesting. But you could be super good at that, and then you could turn around one day and be like, "Oh, I have to learn about, oh, ops. I've been doing it for so long. This is a hill that I don't know about. I'm very good at ..." And I'm standing at the top of my hill, but there's going to be probably multiple times where you're going to have to-
Jonan Scheffler: Start again.
Vaidehi Joshi: ... look up and ascend. As long as you know how to learn, and you're like, "All right, I've seen this before. I'm tackling a different subject, but I know how to go up the hill." That's the most important thing in my opinion.
Jonan Scheffler: Exactly what I tell people is that we are professional learners. We joke a lot about how we Google things, that like, "All I do all day as a senior software engineer at Google is Google things." Right?
Vaidehi Joshi: Mm-hmm (affirmative).
Jonan Scheffler: Well, true, but moreover, you know what to Google, and you know how to quickly assimilate that information and take action on it. So speaking of learning, and how you became such a good learner, this was in fact the topic of your talk, how to learn.
Vaidehi Joshi: Yeah.
Jonan Scheffler: So tell us a little bit about it.
Vaidehi Joshi: So basically what I learned through doing basecs, the written version, which I didn't mention earlier, but that actually spun off into a podcast, and then there's a video series. So I basically take in this computer science content and developed it for different mediums, but in the process of writing the original version, I realized that I had a specific way of learning. And I started wondering, first of all, am I learning correctly? Which now that I think about it, it's a silly question, because if you're learning-
Jonan Scheffler: Are you learning correctly? Yeah.
Vaidehi Joshi: If you're learning then you're doing it the right way for you.
Jonan Scheffler: You've already achieved the goal. If you're doing a goal based assessment, then yes, you were doing it. But could you be doing it more efficiently maybe?
Vaidehi Joshi: Yeah, and I guess the question I was trying to answer as I thought about it was like, how do people learn? Because this feels like a very big task, because I don't even have anywhere to really start. I don't have a good foothold. I'm kind of starting out in the middle of nowhere. So I was wondering like, "Okay, well, how do you learn a new thing in general?" And I started reading about the psychology of learning and the science behind it and reading books on education, and there was one name that popped up a lot, which is, you might have heard of him, this guy named Richard Feynman.
Jonan Scheffler: Richard Feynman, the Feynman technique. This I love actually. I love Richard Feynman and reading about ... He had a very interesting life.
Vaidehi Joshi: Yes, he did.
Jonan Scheffler: And he was a very eccentric and interesting man. I took notes from your presentation, you'll be so proud of me, teach. I was taking careful notes and-
Vaidehi Joshi: Which is what I told everyone. I was like, "Write it down."
Jonan Scheffler: "Write it down, it makes you remember." All right, so the four steps to the Feynman method. I'm going to teach you again, because I'm trying to cement this knowledge, and I want you to correct me if I'm wrong. But I understand it to be that I identify the subject that I'm trying to learn about. That's my first step, just identify and scoping, right? We're scoping this software project. I explain what I know, or what I think I know about that subject to a casual third-party, you used the example of explaining it to a child. If you can explain it to a five-year-old, you really know it, right?
Vaidehi Joshi: Yeah. And there's some caveats to how you're going to explain it to a five year old, because you cannot rely on a lot of things you might rely on if you're explaining it to your teammate or somebody who knows all the terms.
Jonan Scheffler: Okay.
Vaidehi Joshi: You explain it to someone like they're a five-year-old or they're new or they don't have any context of the field, which is, I think, step two or step three.
Jonan Scheffler: In so doing, you hopefully identify any gaps in your own knowledge. Because I think this happens a lot in software when you run into a bug, they call it rubber ducking, I'm sure you're familiar with this term. Many software developers who even have a rubber duck on their desk, because it's a very good way to find problems in your own thinking or assumptions that you were making. It's always just some silly assumption, be like, "Well, I know this variable is being set here." And every time that you actually have to explain that to another developer, when you say the words out loud, be like, "I know this instance variable here has a five in it," and then that developer inevitably says, "How do you know?" "Well, it set to five in the ..." "Well, could you show me? Can you prove it? Why don't we output the value." "Oh, it's three." Yeah, so the assumption you made this whole time, that hour you just wasted, this is why rubber ducking is so valuable.
Jonan Scheffler: But I feel like having to explain a concept that you have just learned to someone else is similar in process, in that you very quickly identify your own shortcomings. When you can't explain it succinctly, you maybe don't understand as much as you thought you did.
Vaidehi Joshi: Yeah, there's the rub. That's the core concept of the Feynman technique, I think.
Jonan Scheffler: I think so too. And I really liked this piece. I wanted to highlight. You talked about jargon in our industry is a big problem, in software. Obviously, we're all throwing around acronyms all the time, and I make a point ... I remember, especially when I first got into software, I had a notepad on my desk, just a Moleskine, and I would write down any time I heard a thing that I didn't know what it was.
Vaidehi Joshi: I did that too. That's awesome.
Jonan Scheffler: So I sidetracked just a little bit here, because I wanted to talk about jargon. And the jargon that I experience as a developer advocate is a little bit different, because I've got one foot in the marketing industry as well. So I thought that developer jargon was intense until I met marketing jargon. My goodness, you all can say a lot of words without saying anything that I understand. So tell me about that, what role jargon plays in this whole Feynman Technique.
Vaidehi Joshi: Yeah. So I think that there's a step in the Feynman Technique where when you explain something to someone who is not in the industry or who's maybe like a newbie, or in the case of the Feynman Technique, explicitly explain it to a five-year-old or a child, you can't use jargon. You have to strip away all those terms, all that terminology that you wouldn't ordinarily use. And the moment you do that, you quickly realize, "Oh, I was using the word for this, but I don't actually know what it means." And I think that is actually where the learning kind of happens. Like I was saying earlier, oh, that's the crux of it, because that's when you realize, "Oh, I have a gap in my knowledge here. I'm using the word caching, but can I explain caching without using the word caching?"
Jonan Scheffler: Yeah, or using the word cache. It's real hard-
Vaidehi Joshi: Yeah, how do you explain what that concept is? And I think the people who really fundamentally understand something, don't have to rely on that, because they've understood it deeply enough that they are like, "No, I can explain the idea to you without using the words." And I think in our industry in particular, we love to use jargon and terminology, sometimes to kind of prove what we know. And it's a little bit of a charade, because just because you know the word for something doesn't mean you know it. So I challenge myself and other people to try to not lean on that as a crutch, because we have a tendency to do that. And it's often especially in tech and in academia and computer science, it's like a very gatekeepery thing to do.
Jonan Scheffler: It is.
Vaidehi Joshi: Like, "I'm going to use this term, and you don't know what it is, so you don't really belong here." Which is a silly thing.
Jonan Scheffler: Right, it's a very exclusionary thing. And it really is just as simple as asking the question and learning a thing, because it turns out, nobody ever knew anything before they were taught it.
Vaidehi Joshi: Yeah.
Jonan Scheffler: Isn't that weird?
Vaidehi Joshi: Yeah.
Jonan Scheffler: Because this is very common. To convince my children that someone else who doesn't know how to ski just because you know how to ski does not mean they're stupid or bad or never going to learn, they have not learned to ski. So the fourth one that I left off here was to organize and simplify back into a narrative, so I identify gaps in my knowledge. In many cases, realizing where I was using jargon to gloss over something I would do this, for example, talking about any Rails app, so a web request comes into the server, something, something Rack, and then you get a web page back, tada. We do this all the time, right?
Vaidehi Joshi: Yeah.
Jonan Scheffler: And you might say like, "Well, and it goes all the way through the middleware layer, of course." Which really, you're not talking about the 18 middlewares that are called and how they might be mutating things or whatever. You use it as a mechanism for abbreviating conversations so you can get work done, but you may also be hiding gaps in your knowledge, and you need to identify those. Once you have, then you organize and you simplify into a narrative. Tell me about that, what do you mean by that?
Vaidehi Joshi: That's basically the way of distilling the information and presenting it back to someone else, and that's kind of where you actually get to do the fun part of teaching someone. And you get to kind of put your own twist on it, your own spin on your understanding, because everybody's going to explain something in a different way. And I like the idea of organize it in maybe the structure that you would have liked to have been taught it, if someone was teaching it to you.
Jonan Scheffler: When you were there, right.
Vaidehi Joshi: Yeah.
Jonan Scheffler: Because a big part of your presentation in the beginning was about how you went to read up on some of these resources, it was a radix matrices?
Vaidehi Joshi: Radix tree.
Jonan Scheffler: Radix trees. You were reading about radix trees. Is a radix matrix even a thing? Did I just make that up? I am sure there is a computer science concept that I don't know about.
Vaidehi Joshi: I don't even know. It might be. It probably is.
Jonan Scheffler: I doubt it very much. Please, someday when I apply at Google, don't judge me for my lack of knowledge on radix matrices. So you were looking at radix trees and the information that was out there was just terrible, because very often you are addressing your target market, when you're talking about radix trees, or other computer scientists who understand. And so the entry level content sometimes is missing on these topics.
Vaidehi Joshi: Yeah.
Jonan Scheffler: And that's where basecs came in.
Vaidehi Joshi: Yeah. And someone, I think, actually asked me, they're like, "So what would you do? How did you learn it?" And I was like, "Well, I would go to the Wikipedia page, and then I would see how far I could get," usually not that far. Then I would try to supplement my own gaps and be like, "Okay, I understand this little piece from this blog post, this piece from this lecture video." And so the step of organize and simplify is kind of like, "Okay, what are the things you really need to know?" That's what I'm going to explain to you first, and then I'll build on that. And the simplify into a narrative is like, "Oh, I can kind of tell a story about this data structure." Or if you're telling someone how a web requests works, you can turn it into a step by step process, rather than just be like, "Oh, it comes in and middleware something, something, controller. Bye." Which is not a story, it's just words.
Jonan Scheffler: Even if you simplify it or humanize it just a little bit and say, all right, let's say you're going to buy some shoes, and you go to a website, and then you keep the rest of the presentation exactly the same, but at the end, you show a picture of shoes, and you say, "Now you got your shoes," then suddenly it's a story. I argue often that teaching is storytelling. If you're not presenting it according to a narrative, then you are rambling off a list of facts, and you only get a couple of minutes of attention for that, but if you tell a story, you have my attention for hours.
Vaidehi Joshi: And I think it applies beyond just like, "Oh, I'm speaking at a conference." If you are with your team and you're like, "I want to pitch this idea, we should use this new add-on or this feature." If you tell it as a story of like, say I wanted to do this, I wanted to debug this problem, but this tool isn't really great, and with this new idea that I'm pitching, if we use this service ... If you tell it as a story, first of all, you have them more hooked. And the humanizing thing is a big thing, I think, because it's not even just like teaching, it's like anytime you want to communicate an idea, you have to have the audience buy into it, and sometimes it's people on your team, sometimes it's students, sometimes it's your boss, your manager, other stakeholders, CEO, CTOs and what have you.
Vaidehi Joshi: You want to make your idea compelling, and being able to present it in a way that's like a narrative or organized or approachable. That changes the whole thing. It's a game changer, really.
Jonan Scheffler: It is, and I think when you realize ultimately that your goal here is to persuade, you're trying to present in a way that keeps people engaged and convince them of something. And sometimes it's hard for me to identify that, because I think, "Well, I'm not trying to convince them everything. I'm just going to try and teach them how TLS works on the inside." I always want developers to know, because I think it's interesting, right? But what I'm actually trying to convince them is that they should also find it interesting, and value it for their careers, that they should like the things that I like. Humans like nothing less than when other people like things they don't. So you started basecs with this blog?
Vaidehi Joshi: Mm-hmm (affirmative).
Jonan Scheffler: And that's been running for a while. We now have another version of the ... I guess it's not a version it's a distinct thing, baseds.
Vaidehi Joshi: Yeah.
Jonan Scheffler: Okay, tell me about that.
Vaidehi Joshi: So basecs, probably I guess, two years ago, that was like the basics of computer science, and that's like one whole fundamental level, but there are other ways that you can kind of fill in gaps that apply to your role as a software engineer. So one of the things that I was personally interested in at my company is like ops, and like how on earth we keep our application running, and like what happens when things go down. And I was like, "I understand computer science, I think, a little bit better. I understand our framework, the tools were using, but I don't know anything about this." And that was kind of when I started reading a bit more about distributed systems and all the complexities that they introduce, and I was like, "Oh, well, this is another gap in my knowledge. I know nothing about this. I just know some of the phrases and the terms."
Vaidehi Joshi: So I decided to try to apply the same strategy that I use with basecs in terms of learning something and then distilling my knowledge, sharing it with other people in the way that I wish that resource had existed, because I've noticed with distributed systems, it's a similar thing. Like there are lots of things you can read, not all of them make sense.
Jonan Scheffler: Right, well because the people working on distributed systems are specialized, you get very specialized. And I think this is true of new fields, because computing is so new. When you start talking about deep learning or neural networks, and now we have a number of neural network experts. We don't have a whole bunch of neural network beginners, probably today, just yet. In five years, we will definitely have an army of neural network beginners, because I don't think that's [crosstalk 00:21:27].
Vaidehi Joshi: And the ones that are out there, I am sure are having not an easy time, because they will be experts eventually, but right now they're probably going through the slog of like, "What does it mean? What are these terms? What are the goals? What are these tools? How do I use them?" And that is a huge hump to get over, and it can be really painful, I know from firsthand experience.
Jonan Scheffler: Hopefully they learn to channel that rage into something productive like improving for other people to come behind.
Vaidehi Joshi: Yeah. So baseds is basically the basics of distributed systems, so that is a project I'm working on this year. It's in written format. I publish every other Wednesday. So it's not as frequent as basecs, which was every Monday for a year.
Jonan Scheffler: Oh, my goodness.
Vaidehi Joshi: But I think this one's a little bit more sustainable, and the quality I hope will continue to be the same.
Jonan Scheffler: That means your Monday's extra bad though, because if you had a busy week, then your Saturday and Sunday we're like, "Oh, I've got to do 15 hours work to get this blog post out the door."
Vaidehi Joshi: Well, I think when you start developing habits, you start realizing that you can't write it on a Sunday night.
Jonan Scheffler: Turns out that pain is a real good impotence for change. When you suffer repeatedly, sometimes you learn. So the final question was if you remember what your first basecs was. What was the very first basecs you did?
Vaidehi Joshi: Oh, yeah. It was binary.
Jonan Scheffler: Binary?
Vaidehi Joshi: Yeah.
Jonan Scheffler: What even is it?
Vaidehi Joshi: Yeah, what is it?
Jonan Scheffler: Why do we care?
Vaidehi Joshi: How do you count in it? Because I didn't know even how to count in it. I was like, "How do I count zeros and ones?" I don't know. And I was like, "Okay, computer science, ones and zeros seem like a good place to start."
Jonan Scheffler: Right, yeah. It really is though.
Vaidehi Joshi: Yeah. But I was just like, "Okay, I'm going to learn how to count in binary. I'm going to learn how to convert between binary and base 10, which is the number system we use." And then it actually was cool, because then I got into bytes, and how many bytes can store things, then you get into like, "Oh, this is what bytes actually mean." When I've been dealing with it for years, but I didn't know what that actually translates to. So as I went on through the series, starting with binary, a lot of lightbulbs started to click, which is cool. But when you start out, you're just like, "I mean, I hope the ones and zeros means something. I hope this is relevant, and this will help me." But I think it all builds on each other, all these posts built on themselves, rather.
Jonan Scheffler: Yeah. So did they occur naturally to you as you moved along? The first one was binary, and the next one you already had lined up as you were writing binary, you were like, "What I should talk about next is definitely this thing."
Vaidehi Joshi: Well, it's interesting, the thing that you were talking about earlier, where you wrote down what you didn't know in a notebook, so I didn't know how do you teach yourself computer science. I didn't have a syllabus. There are computer science programs that have syllabi, and you can look at them, but I was just like, "Is this the order to follow? I don't know." But I think as I started learning one topic after another, I would see it referencing other parts of computer science, so I would be like, "Okay, I'm going to learn about trees," and then something would reference binary search, and then something would reference balanced trees.
Jonan Scheffler: Or radix matrices?
Vaidehi Joshi: Yeah. And it was just all like-
Jonan Scheffler: Those are not a real thing again, yeah.
Vaidehi Joshi: I would just see the connections, and I was like, "I'm not gonna worry about what on earth a radix tree is yet, but I know that it's a type of tree. So I'm going to do trees next week, and then somewhere down the line, I'll get into that." So you know things that are kind of piling up and that you'll investigate in the future, and you're like, "Okay, here's one more thing I don't know, but I know it exists now. I'm going to write it down. I'm going to formulate it into some sort of organic order that I will go through, and-"
Jonan Scheffler: It's like you're trying to make a tree structure of all the information that exists and you build it out as you go.
Vaidehi Joshi: And sometimes you don't even know where it goes, so you just keep it on the side, and then eventually you're like, "Oh, this is where this comes in."
Jonan Scheffler: Ah, and the pieces start to make sense as you build.
Vaidehi Joshi: Yeah.
Jonan Scheffler: So that brought up another question for me, which is how do you know when a topic ... You had a target size for these blog posts, presumably. When you're talking about binary, how do you decide if endianness is relevant, for example? Or do we hold off on talking about endianness till we talk about processor or architecture or whatever, right? How do you decide which pieces fit into which bucket?
Vaidehi Joshi: I think I try to keep each of them somewhat digestible. So if they start to get too long or for example I would start writing about a topic and be like, "Oh, this is actually four topics. You need to first understand what this data structure is before you can understand how to search through it. Before you can understand the big O notation of it, you have to separate them out." And so that's, I think, kind of like the identify what is the thing you're actually trying to learn, and then separate it out. And I think it helps as you go through one topic at a time, because if you're just dealing with one concise thing, you realize, "Oh, this is actually multiple," or, "Oh, this is a good, concise topic in and of itself. Someone can read this, come away with something new and not feel like they need to go learn 65 new things in order to understand what they've just read."
Jonan Scheffler: Exactly.
Vaidehi Joshi: Which is a danger, I think, when you have a lot of content to give them.
Jonan Scheffler: Right, and it's so easy to overstimulate someone who is just learning and keep on learning, because they do get excited when they start to understand and you're doing a good job and you're on a roll and then you keep throwing down and it's exhausting. I think the impulse that you have to make it as small as possible, even if we try to make it as small as possible, it's still probably too big when we're done, whatever the topic matter is. But that distillation process, I think, is really the essence of assembling along a narrative, these new pieces of knowledge. And again, all of the things that you just said you do to follow this process, those are the Feynman learning techniques again, right?
Vaidehi Joshi: Mm-hmm (affirmative).
Jonan Scheffler: Where you're identifying the things that you don't know, as a first step. And I actually realized this in an unrelated topic of procrastination, that I am realizing now as a grown up, and I'm not going to tell you all of it, because it took me way too many years to get here, that almost all of the procrastination I've done in my life is a scoping problem. It's because I was avoiding a task, because I didn't understand the first thing to do to accomplish it. And when I started putting things on my to do list with step one, under them, it really changed things for me, because then I no longer have to think about this monumental task. I've got to release a new episode of basecs next week, what I have to think about is look up radix tree. Google radix tree, and then all I have to do is-
Vaidehi Joshi: And maybe you don't even do radix tree. Maybe you look it up and you're like, "Oh, this is actually not the right starting point. I'll pivot. It's okay." But yeah, the hardest part has got to be starting.
Jonan Scheffler: And once you're started, even if you were wrong with your first step, you transition very naturally. I used to trick my brain sometimes with these time boxes that were absurdly small. I'd be like, "Well, you really don't want to learn React today, because you'd rather play video games. But instead you can play all the video games you want if you do five minutes of React." And of course, five minutes later, I'm really excited about this thing I've just done, and I keep rolling, right?
Vaidehi Joshi: Yeah.
Jonan Scheffler: Getting started is the hardest part, and unfortunately, we have to finish instead. It was really nice talking with you Vaidehi. Thank you for joining me.
Vaidehi Joshi: It was lovely talking to you too. Thank you for having me on.
Jonan Scheffler: And thank you so much for your hard work on basecs and baseds. I will put some links in the show notes, so our users can check them out.
Vaidehi Joshi: Awesome. Thank you. I hope they find it helpful.
Jonan Scheffler: I appreciate it.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
← Previous episode
9. Coordinating Remote Work
Next episode →
11. The Agony and Ecstasy of Maintaining Good Documentation
September 22nd, 89. Saving Lives at Scale: Part One
Developer Advocate, Heroku
Jonan is a developer at Heroku and an aspiring astronaut. He believes in you and your potential and wants to help you build beautiful things.
More episodes from Code[ish]
Yuri Oliveira, Brandon Stewart, and Corey Martin
Along with AI and machine learning, the Internet of Things is a recent evolution in software that has the power to change the way we interact with the world. More than just smart lightbulbs and thermostats, IoT devices are making their way... →
Daniel Klein and Jason Salaz
Digital nomads have the luxury of working remotely from anywhere in the world, but it's still a hassle to actually find an apartment to call one's (temporary) home. Landing is a service that provides fully furnished, lease-free apartments... →
Nick Frandsen and Becky Jaimes
Evolving a startup into a business can be tough, even after you've raised funds and found a few customers. To get to the next level, you'll need strong product design, investments in marketing, and a strategy to execute it all. Dovetail is... →