Quincy Larson might be responsible for at least one very important part of your career: the beginning. That's because Quincy is the founder of freeCodeCamp, a non-profit teaching millions of people to code. In this and the next episode we talk all about what it means to be a beginner.
Quincy Larson might be responsible for at least one very important part of your career: the beginning. That's because Quincy is the founder of freeCodeCamp, a non-profit teaching millions of people to code.
In this and the next episode we talk all about what it means to be a beginner.
Square's Terminal API makes payments easy, whether in person, in-app, or both. Process payments on every platform imaginable. Get started today at https://developertea.com/square
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com/contact.
If you would like to join the new experimental DIscord group, reach out at developertea.com/contact, developertea@gmail.com, or @developertea on Twitter.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
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 Cottrell, 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. A second reason is because you're going to be, this episode is 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 through 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, you may want to write your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and your name and 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, will 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. Yeah, because things have to be simple. Busy people are in a hurry. Yeah, that's true. That's one of the genesis kind of seed ideas for this show is, hey, you know 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... 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 hear somebody talk about their opinions a little bit more. And I think that's okay. But I 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, when you first started this, when you first started Free Code Camp, 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, that you said, I have to do this. I have no other choice but to take this step. Yeah. Yeah. Maybe 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 liberal arts. And I worked as a journalist and then as a teacher, both in the U.S. 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... 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 needed to learn how to code myself. So I plunged into the long process of learning to 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 OpenCourseWare and things like that. And I would say that discovering how opaque and ambiguous the process it was and how isolating a process it was, that was what spurred me to want to create a community around learning to code. Wow, that's so interesting. There's going to be a lot of questions that come out of 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, but I want you to share your thoughts. 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 a process of learning a world language. It 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, 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's 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, right? 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, you know, 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 kind of 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, like people progress in a linear manner. Like people learn, seem to learn certain types of phrases and, you know, like prepositions and pronouns and things like that. And then early age. And then, you know, they keep advancing and it's to the point where like the SAT has this like SAT words that you should know for the SAT. And 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, you know, 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, you know, 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 just, you're like, okay, I need to, I need to achieve a certain level of expertise in this skill and then I can move on to the next one. It's 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 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, right? 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 going to do this, 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 entirely new pair, you know, new paradigms that you can apply that you haven't applied before. Like that was a big thing when I was getting into programming is so many people were using object oriented programming and then functional programming. Oh, what's functional programming? Let's get really into that. And it's kind of like this tug of 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, if we get people into that, 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. Now 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, and, and trying to like remember things and kind of reacquaint with things. It's just a never ending process. So one of the big things that I would drive home to people is, look, lifelong learning is not just a thing. 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. We'll be right back to continue our interview with Quincy Larson 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 touchscreen 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 Terminal syncs 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 a pretty good way to get started. It's really important for payment stuff, dispute management, and even fraud detection. Connect your app to the all-in-one payments device merchants love with a simple REST API. Start building using Square Terminal API by visiting developerT.com slash square. That's developerT.com slash square. Thanks again to Square for sponsoring today's episode of Developer T. Now let's get back to our interview with Quincy Larson. I think you're right in that, especially when you 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. So it would be like a carpenter saying, well, I'm a hammer user. Or like, I am a board aligner. Right? 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. And so you're shortchanging yourselves if you're imagining that the tool is what defines kind of your skill set. The tool is so... It is important. Don't get me wrong. It's very important, but the tool is not all-encompassing of what you do. And even more now. Right? And I'm curious about this for your perspective, Quincy. Even more now than before, it seems that even saying software engineer, there's so many ways that this can apply. And it continues to expand. If you know how to code, there's so many jobs now that have kind of consumed that as it's, you know, 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, right? You had... That was really the vast majority of your job was typing. Well, now everybody types. It's not even, you know, 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... More generalized. So I'm curious, you know, how does this play out into the future where even saying software engineer, really you need more qualifiers of, you know, 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, you know, 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, right? Like you could be like the world's fastest typist. Wow, I can type like 150 words per minute or something like that, right? Like 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, right? You can only think so fast unless you're literally like in a courtroom like trying to transcribe things and they have special tools. They don't even use a traditional, you know, QWERTY keyboard for that. But it's kind of the same thing with driving, right? Like back in the day, if you had a driver's license, you were basically, you were one of the rare people who could, you know, drive ice trucks around the city or drop off milk or things like that, right? 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, right? Like that was very powerful and it still is today. But what we're seeing is like, it's just kind of understood that people can type, that people can use Microsoft Excel, that in cities where driving is necessary, you know, 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 these points, at some point, like farmers weren't expected 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 Jupyter Notebook to be able to understand numbers. So I do think that at some point, programming is going to become, so generic a skill that you're really going to have to layer on 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, was my background in teaching English, like being able to learn developer skills and then being able to immediately turn around and like apply to the world. And so I think that's going to drive them to whatever field they're in to 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 D3 or something like that, right? And like, 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. In China, it's almost 100%. In India, it's 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, we're 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 hand 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. Being 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 programming was a critical aspect of getting a PhD in physics, or people who get MBAs, for example, like that's another professional certification that are 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 like 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, you know, if I attempt to do this with my body, am I going to suffer health consequences? You know, like being able to kind of 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, you know, run the servers, to power the, you know, machine learning model that like to generate it, right? Because, I mean, there are very real world costs associated with training models, for example. Yeah. Yeah. And it is, 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 worldview now? Well, China is very different. I think it's more than the US, but it's also culturally pretty similar in my opinion. I think it's, it's not that different. Like Americans and Chinese, if you tease out the fact that they speak different languages and have different like national histories and stuff, like they are similarly pragmatic in many respects, more so than like a lot of European countries would be with the United States or a lot of other Asian countries would be with the United States. And some of the things I learned from China are just like they are not as much of a problem as they are in the United States. And I think that's a really good example of that. I think that's a really good example of that. I think that's a really good example of that. I think that's a really good example of that. At the same time, evolution evolution evolution We're just very excited about technology, and thus technology is 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 of the biggest comeback story. Like in 1970, virtually all Chinese people were subsistence farmers. And in 2021, a big chunk of them, like maybe 400, 500 million of them, are working in manufacturing and service sectors. 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 U.S. middle class. But I just want to point out. 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 U.S. Like when I went to China, like I would walk through, you know, offices where like half the people had gone through Freeco 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 use Freeco Camp and still been able to productively contribute to the project, for example. Also, China has perhaps to the detriment of. Other topics. They have a very hardcore 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. But 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. It'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 gonna be able to handle the more advanced stuff. And as a result here in the U.S., most university students are, you know, 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. Technological changes. That are coming down the road. So, yeah, that's. I'm trying to stay positive. I'm not going to say anything negative about China. Just to be clear, like I'm not like go China. But 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. People who have been exposed to. You know, for example, technology for a long time. It's. It creates a schema in our 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 it. Why do you. So I'll give you. I'll give you a better example of this in my personal life. I come from the background of, you know, 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 browsing. And I was like, I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. 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 engineer's 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. 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 that 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 Morse code. And you'd want to have all these fallback things. And now it's almost like cartoonish. The notion of learning Morse code in 2021. Like what could you possibly need that for when we've got broadband 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 they might be constrained to be using Morse 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 more 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. 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. 10% faster than I do. And that probably stops. Right. That as you gain experience. You might go from 10 to 12. It's like a logarithmic curve. Rather than a linear curve. And certainly not an exponential curve. I imagined when I was. Earlier in my career. That as you begin learning. And 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. Right. 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 developer tea. You can also email me at developertea.gmail.com. And request an invite. Additionally if you have questions. Or if you have ideas for the show. You can send me an email. Or you can send me an email. Or you can send me an email. Or you can send me an email. Or you can send me an email. Or you can send me an email. Or you can send me an email. Or you can send those along to the same email address. That's developertea.gmail.com. Thanks so much for listening. And until next time. Enjoy your tea.