I am a brand new beginner to coding. What should I do? This is a question I get perhaps more than any other question about this job and in today's episode I'm going to be interviewing. Perhaps the best person to answer that question. His name is Quincy Larson. Quincy is the creator of Free Code Camp, which is a nonprofit that teaches people how to code. And not only beginners, but also Quincy has been investing in developing curriculum for people that are well beyond that beginner status for people like me who are as much as 10 years into their career or more. So I'm really excited to talk to Quincy. If you want to support Free Code Camp and brand new engineers who are learning how to code, you can head over to freecodecamp.org slash donate. That's freecodecamp.org slash donate. $5 will provide 250 hours of learning to people around the world. Thank you so much for listening to Developer Tea. My name is Jonathan Cutrell. And we're going to get straight into the interview with Quincy Larson. Quincy, welcome to Developer Tea. Hey, thank you, Jonathan, for having me. I'm excited to have you for a handful of reasons. One is because we've been trying to do this for a long time. The second reason is because you're going to be this episode, it's very likely going to be a very common answer to an extremely common question of where do I start? Or do you recommend anything? This is what I'm going to recommend for people who are at the very beginning of this journey of becoming a software engineer, whether they're doing that as a hobby, or if they're interested in actually going down this as a career path, this is where I'm going to send them most likely, is to this episode. So thank you for giving me that perfect answer to that very common question. Absolutely. So I'd love for you to take a moment and just kind of explain your 30-second elevator pitch for anybody who's listening to this for the first time. Those people that I'm sending here, I'm speaking from the future, I suppose. But if you can answer the question, what exactly is FreeCode Camp? Just the elevator pitch for his perfect. Yeah, we're a global community of people who are learning the code together. And we have FreeCode Camp itself is a 501-C3 donor-supported nonprofit. It's a public charity. And we have a whole lot of learning resources. We have a curriculum you can work through. We have a publication where you can read lots of tutorials on very specific programming-related questions. We have a forum where you can get help if you're stuck, or if you just want feedback on a project, and we have a YouTube channel that also has lots of full-length courses. That's a great pitch. Most people, when I ask them to give their elevator pitch, we'll talk for quite a while about what they do. And it seems that you have given this pitch a handful of times, I imagine. Yes, those are the four pillars of our community. And I think about them deeply every day when I'm in the shower, like how we can further simplify and refine. Because things have to be simple. People are busy people are in the hurry. Yeah, that's true. It's one of the genesis kind of seed ideas for this show is, hey, what people don't want to spend a lot of time listening to me pontificate. They want short and to the point episodes. And if they want to skip them, they can. And I think that that is, I've gotten some criticism on this idea, which is, that sometimes people do want a little bit longer of an experience. They want to talk. They want to hear somebody talk about their opinions a little bit more. And I think that's okay. But I do believe that the people who are listening to this show, they probably get that kind of content elsewhere. And so I try to keep it focused and tight for that reason. But I want to ask you, you know, when you first started this, when you first started free code camp, what was your, what would you say is kind of the final thing that pushed you over the edge, the experience, the belief, the moment, whatever that was. And you said, I have to do this. I have no other choice but to take this step. Yeah, well, this answer may be a little bit longer. So I learned to code when I was 30. And I don't have like a formal background in programming. I studied the arts and I worked as a journalist and then as a teacher, both in the US and in China and eventually as a school director. So I was, you know, a 30 something office worker who wanted to optimize some of the back office processes at our school so that our teachers and our staff could spend more time actually hanging out with the students and actually teaching instead of being chained to their desk with paperwork. And that was the, that was what really spurred me to learn to code. And I just kind of Googled some things and put a few things together and wrote some basic scripts and it was profoundly powerful. And I think at that moment that I saw how some random guy could just, you know, make things more efficient with even the most cursory knowledge of programming. That's when I was like, wow, this is really powerful. And you know, I've been teaching people English. That was my background is teaching international students English so they could go to grad school or they could go to medical school. And I wanted to shift and teach people how technology worked. So that was probably the big revelation. And then of course, I still need to learn how to code myself. So I plunged into the long process of learning the code and found it was extremely ambiguous and lonely for the most part. And I was able, I was very lucky. I lived in California in Santa Barbara and we had like a big hacker space. We had hackathons and I could just take the Amtrak up to San Francisco or down to San Diego or over to LA, you know, and meet with people and go to, you know, hackathons and I ended up doing that every weekend. And that sustained me, that sustained my motivation because at the time I was basically just reading textbooks on programming and like that I got from the library and using like MIT Open and courseware and things like that. So I would say that discovering how opaque and ambiguous the process it was and how isolating how process it was, that was what spurred me to want to create a community around learning to code. Wow, that's so interesting. I have, there's going to be a lot of questions that come out of what, you know, what you just laid out. One of my first questions is, you know, with your background as an instructor in a secondary language, right? The second language, English as a second language specifically. I heard this question recently and I didn't know how to answer it. I know what I think about it, but I'm not sure how to answer it authoritatively and I think you'll be able to answer it better than I can. The question is, is learning how to code like learning a new language? And you know, I'm sure you've been asked this before and I can share what my thoughts are by. I want you to share your thoughts first. Yeah, well, you know, programming languages aren't real languages. They're not world languages where like you can express every abstract idea, at least not without doing a whole lot of mental gymnastics, right? So I think it's not the greatest analogy. Like I wouldn't have called programming languages languages. If I were, you know, some foundational computer science father, I would definitely call it something else because it is a confusing analogy, but the process of learning a world language is quite similar to the process of learning programming in the sense that there's a huge amount of basic knowledge like foundations that you have to take in before you can really start to apply and do anything productive. Like, you know, babies spend years just basically muttering phonemes and trying to like memorize very basic usage patterns and make sounds with their mouths, right? Before they're actually able to converse with you. And same thing with, you know, adult learners who like, yes, they can memorize a few set phrases and potentially go in and order something at a French restaurant, for example. But to actually get really good at a foreign language takes a tremendous amount of time and energy focusing on the fundamentals. And I think to get really good at programming is similar in that respect. I agree. It seems like it's a bad metaphor. There are some similarities, of course there are, right? You're learning something new that's some kind of expressive infrastructure, you know, components that you might put together that kind of thing. But it diverges from there in a lot of ways. One of the ways is the grammar. And I guess the structure of language is typically essentially linear. And you could argue that not all literature is necessarily linear. But in terms of speaking a language, it's relatively linear. But programs are not linear. They're systematic kind of constructions. They're more referenceable. It's not like something that you would read straight through and understand. It's something that jumps around. There's much more to kind of hang your logic on. And I think that's a critical component that a lot of people don't understand about software is that it's not something that gets executed top to bottom. It's something that gets loaded into memory and then referenced over time in the vast majority of cases. Yeah. I mean, in terms of like video game development, there's like a core gameplay loop that is just, it starts running when you boot up the system and that loop is just running continuously until you power it off. And there are different events and stuff. It's a very different from like if you look like a novel, it's linear. You read it from the front of the back. Learning the language, I think much more so than programming. People will progress in a linear manner. People seem to learn certain types of phrases and prepositions and pronouns and things like that and then early age. And then they keep advancing. And it's to the point where the SAT has this SAT words that you should know for the SAT. It's just like a thousand words that are used in high frequency but not usually learned by people until they get into university. So yeah. I mean, you could argue that perhaps they're the same analogous aspects of programming languages. But I think the analogy falls apart pretty quickly when you really start to think about it. Yeah, I agree. And there's a lot more that we can look at when it comes to these analogies or ways of getting a handle on, you know, for somebody who has no experience coding at all. I'm interested to know because I, again, I've seen a lot of different perceptions but I'm interested to know what is the most common misperception that you've noticed with people coming into the program or people who ask you questions about, I'm sure you've talked to more beginners possibly than anybody that I've talked to so far on this show certainly. So what do you think is, or what are the kind of the patterns that you see of misconceptions or maybe cultural perceptions of what it means to learn to code? One of the biggest obstacles I think a lot of, certainly I encountered and I think a lot of people from like a traditional kind of like Western mentality, individualism, you know, diving in and you're like, okay, I need to achieve a certain level of expertise in this skill and then I can move on to the next one is like kind of putting a whole bunch of keywords on your LinkedIn profile essentially like, oh, okay, I did a Python tutorial. Now I know Python and there's this illusion that like going through a whole bunch of introductory tutorials is actually going to lead you somewhere where it's, you're just going to be kind of a jack of all trades but not really even a jack maybe like, you know, a two of all trades or three of all trades, right? So I think that if people can understand that like most programming languages use the exact same data structures, some of them are slightly different. Most programs use just a certain small set of design patterns over and over and recombine them and then of course they're increasingly esoteric design patterns for like very specific situations. But if people can approach it instead of thinking about like, oh, I'm a Python developer or I'm a JavaScript developer, if they can instead think like, I'm a developer and I'm learning how to use this tool and I'm focused on this part of the entire, you know, application and then I'm going to keep stepping up and learning more. I think that if people approach it that way and instead of assuming that they're somehow at some point going to just be like done because they're never really going to be done, there's always little refinements, little optimizations you can make and entirely new paradigm, you know, new paradigms that you can apply that you haven't applied before. Like that was a big thing when I was giving in programming as so many people were using object-oriented programming and then functional programming. Oh, what's functional programming? Let's get really into that and just kind of like this toggle war between that and different paradigms. So it is, you have to be comfortable with ambiguity and knowing that you're never going to know everything and that you're always going to be looking things up. And I think if we get people into that mindset, like the traditional US education system and definitely overseas, like I can say from having lived in China for about six years, like the Chinese education system is very much about like, okay, you learn these facts, you learn this topic, you're done, move to the next grade and then, okay, you're done with high school and then go to college, okay, you're done with college, you know college level stuff and it's, it's seen as kind of like checkpoints and but really it's a continuous ongoing process and the way that the brain is constantly forgetting things and having to like remember things and kind of re-uquaint with things. It's just an over-ending process. So one of the big things that I would drive home to people is look, lifelong learning is not just anything, it is the thing and you're going to be spending a huge amount of the rest of your career learning, especially if you go into a field like software development. It will be right back to continue our interview with Quincy Larsson right after we talk about today's sponsor square. With square, you can build a custom point of sale that connects to square terminal. This is an all-in-one credit card service and device, built by square for contactless and card payments. Square terminal has a five and a half inch corner to corner touch screen that's easy to disinfect and here's the thing, it makes for safe, distanced payments. That's really important. It's going to be important for a little while at least. Square terminals sync seamlessly with your app via terminal API to accept Apple Pay, Google Pay and other NFC payment methods. Plus, MagStripe and chip cards for a smooth checkout experience and they have the terminal API which is compatible with basically every web and mobile platform that you could possibly be using. So it's easy to integrate with your iOS, Android, Flutter, React Native or your Windows applications and Square has your back. You can build with terminal API and take advantage of Square's end-to-end encryption. It's pretty important for payment stuff, dispute management and even fraud detection. Connect your app to the all-in-one payments device margins, love with a simple, rest API. Start building using square terminal API by visiting developertea.com slash square. That's developertea.com slash square. Thanks again to Square for sponsoring today's episode of developert. Now let's get back to our interview with Crensy Larson. I think you're right in that, especially when we were talking about this idea that I'm a JavaScript developer, I'm a front-end developer. These are tools that we use and front-end might be a little bit of a different thing. But these are tools that we use. It would be like a carpenter saying, well, I'm a hammer user. I'm a board aligner. That doesn't make a lot of sense. You need to understand a lot more around what you're doing to be able to do it effectively. So you're short-changing yourselves if you're imagining that the tool is what defines your skill set. The tool is so important that don't give me wrong. I mean, it's very important. But the tool is not all-encompassing of what you do. Even more now. I'm curious about this for your perspective, Crensy. Even more now than before, it seems that even saying software engineer, there's so many ways that this can apply. It continues to expand. If you know how to code, there's so many jobs now that have consumed that as it's not similar in mechanics, but it's similar in culture as typing used to be in some ways. The skill that only some people had because you had to be a typist. That was really the vast majority of your job was typing. Well now everybody types. It's not even considered a skill per se. At one point, it was considered a skill. It was considered something that you could hone. It was a craft almost. And now it's become a lot more generalized. So I'm curious. How does this play out into the future where even saying software engineer, really you need more qualifiers of what industry because good software engineers tend to also consume information about their industry so they can solve problems in that industry. So I'm curious about that. What do you think the future of that kind of is software engineer as a title becoming too generalized? That's an excellent question. And I want to touch on typing because you can get extremely good at typing. You could be like the world's fastest typist. Wow, I can type 150 words per minute or so on like that. I know that's probably not the world's fastest, but that's still very fast, much faster than I type. But there's diminishing returns to continuing to try to get your typing faster and faster. You can only think so fast unless you're literally in a courtroom trying to transcribe things. And they have special tools for that. They don't even use a traditional query keyboard for that. But it's kind of the same thing with driving. Back in the day, if you had a driver's license, you were basically one of the rare people who could drive ice trucks around the city or drop off milk or things like that. And it was like the killer app was I'm a driver. And then it was a typist. And then in the 90s, it was like I can use Microsoft Excel. I can use spreadsheets. That was very powerful. This still is today. But what we're seeing is it's just kind of understood that people can type. If people can use Microsoft Excel, that in cities where driving is necessary, that you can drive. And there are many cities in the United States where you would be hard pressed to get around using public transit. So, and if you reach back, you know, basic numeracy, basic literacy, at some point, like farmers weren't expecting to know those things. Now farmers probably need to know a lot about computers, for example. And they need to know all those other skills I mentioned too. So I do believe that it's just kind of like an ever rising bar that people need to clear. And basic, you know, scripting language skills and basic database skills in SQL are the next kind of like the bar has been raised or run. I don't meet many graduate students who don't know how to program. Even if they're in like the life sciences, they're using programming to do their research. Right? They're using Python and you for a notebook to be able to understand numbers. So I do think that at some point, programming is going to become so generic as skill that you're really going to have to lay around some domain expertise or some experience with very specific tool chains in order to be able to differentiate yourself. And you could argue that that's already come to pass. Which is one of the reasons why I'm so bullish on people who are mid-career like myself, who already have experience like running schools, for example, as my background in teaching English, like being able to learn developer skills and then being able to immediately turn around and like apply them to whatever field they're in to, you know, make things more efficient or to build tools for their peers. So yeah, I think programming is yet another key skill. And I see the same thing coming on the horizon with data science skills. I think that at some point, data science is not going to be a meaningful differentiator because everybody knows how to work with Keras and TensorFlow and everybody knows how to create visualizations with Matplotlib or G3 or something like that. Right? I do think that those are going to become commodities in like a hyper-skilled talent, you know, pool that especially when you think from a globalistic perspective, like in the US, I think only like maybe five or 10% of high schoolers take programming courses during high school. And China is almost 100% and India is probably close to that as well. I mean, it's like it or not, like programming has already arrived and it's something you need to know. I agree with this and I think people who are listening need to understand the time horizon that we're talking about here. We're not talking about 50 years talking about five or maybe 10, right? It accelerates very quickly. Now, that's not to say that you need to know TensorFlow, like the back of your hands in five years. That's not what we're suggesting, but rather that this is changing and most likely being a software engineer that moves around to different companies or moves around to different industries, that is probably going to change. Having a software engineer in an industry, it's likely that you're going to start specializing in an industry rather than specializing at a skill that is generalized to any industry. Would you agree with that? Yes. And I think people who have like PhDs in physics and stuff, like if you sprinkle on some programming skills on top of that, if you happen to have graduated before program was a critical aspect of getting a PhD in physics or people who get MBAs, for example, like that's another professional certification that doctors or lawyers, like all these people would probably benefit from having at least some programming skills and it's almost like the more programming skills you have, it only helps you. It's like being more literate, being able to read more and more technical documentation, like being able to pick up the actual law books and read and see like, oh, am I in compliance here with this startup that I'm trying to do or if I attempt to do this with my body, am I going to suffer health consequences? Being able to figure things out for yourself, I think those are important skills and programming, it's going to be the same thing. Like, okay, I've got this business idea. How can I assess how much it will cost to run the servers to power the machine learning model, to generate it? I mean, there are very real world costs associated with training models, for example. Yeah. Yeah. It is a fast-changing field, for sure, but I want to kind of flip around, instead of talking about the future, I want to kind of go back, go back into your past again. We talked about the moment that you decided that this was important, that it was something that you had to do. I want to ask a little bit more about your experiences that before the show, we talked just briefly, you mentioned that you spent some time in China, and I'm curious, you know, what were some of the most important lessons or activities while you were in China that kind of shaped your world view now? Well, China is very different than the US, but it's also culturally pretty similar in my opinion. I think it's not that different. Americans in Chinese, if you tease up the fact that they speak different languages and have different national histories and stuff, they are similarly pragmatic in many respects. More so than a lot of European countries would be with the United States or a lot of other Asian countries with the United States. Some of the things I learned from China are just like they are not afraid. And I speak in extreme generality because there's 1.3 billion people over there. But many of the university educated people that I hung out with, like that I went to grad school with, or that I worked with, were just very excited about technology and thus technologies adopted very quickly. And to some extent, you could argue they're not skeptical enough about certain technologies and the potential for abuse, but because they are trying to recover, essentially. The story of China is kind of like the 20th century's biggest economic miracle in the sense that the biggest comeback story. In 1970, virtually all Chinese people were subsistence farmers. In 2021, a big chunk of them, like maybe 400, 500 million of them are working in manufacturing and service sectors. And that's dramatic change to move that many people into kind of like a traditional middle class. Now their middle class is not nearly as wealthy as the US middle class. But I just want to point out that that's the context for their adoption of technology is they don't have a lot of the, I guess baggage that we have in terms of like people were already trained to use like traditional telephones, for example, or SMS, like China, it just jumps with leaps and bounds and even the older people, they're quickly, you know, drop what they're doing and pick up the latest and greatest thing. So that aspect is really impressive. Also the companies don't necessarily have the same culture as the US. Like when I went to China, like I would walk through offices where like half the people had gone through free co-camp. You know, like it's, yes, they're also university graduates generally. But it's like they could have studied a lot of different things and still used free co-campus still been able to productively contribute to the project, for example. Also China has perhaps the detriment of other topics. They have a very hard core focus on mathematics engineering skills. And here in the United States, computer science is the 10th most popular university major, which is odd because it's by far the best paying. It's still like, and I think this is a relic of the system where like universities kind of weed out people through like the first programming course you take is not like some friendly course that's like Harvard CS50 in most universities. CS50 being like a very friendly like well taught course. It's probably some course where you're doing Java development and you know the teacher in many cases like might just say, well, if you can't handle this, you're not going to be able to handle the more advanced stuff. And as a result, here in the US, most university students are white males who come from middle class backgrounds like most computer science graduates are anyway. So I'm very optimistic about China from the respect that like they seem to be much more ready to embrace kind of the technological changes that are coming down the road. So yeah, that's it. I'm trying to stay positive. I'm not going to say anything I get about China. Just to be clear, like I'm not like go China, but those are some positive things I can definitely talk about. Sure. Well, and I think something you mentioned there, which is more generalizable lesson, I suppose, is the idea that the people who have been exposed to, you know, for example, technology for a long time, it's, it creates a schema in our minds. And to your point, it might create this resistance. Whereas somebody who hasn't been exposed, there's kind of this license to naively adopt. And I'm curious about why that, why do, so I'll give you a better example of this in my personal life. I come from the background of the generation of front-end engineers that learned jQuery and, you know, div-based HTML and CSS, that was the rage, you know, CSS3 was not, you know, totally supported everywhere, still had to do cross-browser stuff, right? That's about where my training came from. And so I have this mental model. This is the schema that I approach front-end engineering with. Now if I were to start today, then cross-browser would be well down the road in terms of what I'm like aware of, right? It doesn't, it doesn't cross my mind to think about cross-browser testing until I'm a little bit more advanced in my learning process. Whereas cross-browser 10 years ago was, it was kind of a core part of the front-end engineers job, so much so that it was almost a meme to talk about Internet Explorer. And so with that in mind, you know, a front-end engineer might come in and naively and correctly not care so much about cross-browser. And so they may have a little bit more, I guess, boldness, right, to use some of these more edge things that are in the spec that are actually very well supported by the vast majority of browsers. And so I haven't really had the chance to update my schema perfectly, you know, theoretically. And they never had that restriction to begin with. They never had to think about it the same way that I had to think about it, which gives them a freedom that I don't have. And it gives them perhaps the gumption or, you know, I guess the abstraction level, right, that I didn't start with. And so I'm kind of strapped by not having started with an abstraction that they had on day one. And I'm curious, do you see this in students that are starting? Do you see this kind of like, I don't know, hyper growth of the new being able to start at a higher abstraction level? Yeah, and I think that is a good thing. But I see what you're saying. I mean, a good analog might be like traditionally like if you wanted to be like in communications or something like that, you would want to learn how to use a ham radio. You'd want to learn more code and you want to have all these fallback things. And now it's almost like cartoonish, the notion of learning more code in 2021. Like, what could you possibly need that for when we've got broad ban and all this stuff? But I mean, there's something to be said for if things really break down, you've got like all these kind of fallback systems where people would be using ham radio. And there might be strain to be using more code, right? So I do think that like all that experience that you have working with cross browser compatibility issues could come in handy again at some point. I mean, who knows, you know, there might be this big explosion of new browsers coming out or new devices that consume the web in new ways, right? Definitely with like mobile responsive, but also with like audio focused just that mindset of thinking in terms of and certainly in terms of accessibility. Good accessibility is just good usability. And a lot of people may take a lot of things for granted, whereas you having gone through this whole kind of analytical, deliberate process of designing with cross browser compatibility in mind, you may be better equipped to be able to put on your kind of accessibility hat and think about, okay, how can we make this as accessible as possible for people with these specific, with these specific disabilities? Yeah. Yeah, it does strike me. The more I think about it, you know, this idea, when I first started, I imagine that people who had five years on me, right, that they could learn a new technology exponentially faster than I could. Now it's probably true that they learn it a little bit faster because they have some background knowledge, they have maybe some basis or whatever, but it's not exponential. It's more like maybe they learn it's 10% faster than I do. And that probably stops, right, that as you gain experience, you might go from 10 to 20, it's like a logarithmic curve rather than a linear curve and certainly not an exponential curve. And I imagined when I was earlier in my career that as you begin learning and learning and learning, that it speeds up, right, that I'll be able to kind of consume all of this information in the blink of an eye and be able to use a new framework overnight, right? That's, I think that's a false picture and it's probably one that has led people to feel deterred even late in their careers, feeling inadequate. We'll pick up with our interview with Quincy Larson in the next episode of Developer Tea. We'll continue talking about that feeling of inadequacy and a whole lot more with Quincy in the next episode. Thanks so much for listening to today's episode of Developer Tea. Thank you again to square for sponsoring today's episode head over to developertea.com slash square to get started today with the terminal API. This episode and every other episode can be found on pretty much any podcast platform, but you can also find them at developertea.com. Also a reminder if you would like to be a part of the Developer Tea Discord community, you can reach out to me directly on Twitter and I will send you an invite head over to twitter.com slash developert. You can also email me at developertea.com and request an invite. Additionally, if you have questions or if you have ideas for the show, you can send those along to the same email address as developertea.com. Thanks so much for listening and until next time, enjoy your tea.