- Hey, Eric. - Hi, Michael. Hey, everyone. How are you all doing out there? Thank you for being here. We're super excited to be part of kicking this off today. And if you're watching live, please put your comments and thoughts into the live stream. We'll try to make them part of the show if we can. And if you're watching the replay, well, no time travel, but also thanks for being here. All right. So with that, Eric, welcome to Talk Python to Me. Welcome to Talk Python to Me. Thank you. It's very nice to be here. It is very nice to have you here. The last time we were sitting around talking was at a beautiful cocktail bar at the tail end of PyCon 2023 in Salt Lake City. Not a bad place to wrap that up. No, it was very nice. Yeah, so what a fun event. We're going to talk about how people go from from being a beginner-ish, that's a pretty broad term of what a beginner is in Python and programming, and sort of moving towards, how do you take that journey, maybe more deliberately, a little more quickly, to the expert side of the software developer spectrum? It's going to be a lot of fun. - Yes. - Yeah, and so before we get into that, though, let's just start with your story. How did you get into programming Python? How did you end up writing books? All those things. Oh, boy. I have to be careful because it's a long story and I like telling it. I was fortunate in that my father was a software engineer in the '70s and '80s. And so when I was growing up, we had a kit computer in our basement before most people had home computers. So I got to write my first program as a basic number guessing game. And-- That's when it was all about the go-to's? Yes, line 10. Line 20, go to 10, all those. What is your number? Yeah. And so I always had an interest in programming. And so I got to watch in real time the development from basic to logo for teaching kids, to C, to Pascal, Fortran, and all that variety of languages that led up to Python. My journey into Python was I was using Java in the early 2000s. And I thought I'd be a Java programmer for life. And a friend told me that, hey, you should check out Python. Your Java programs would be about a third as long as they are-- your programs would be about a third as long as they are in Java. And I couldn't really believe that because it's a pretty, pretty big claim. But I tried it. Yeah, that's a bold claim. Yeah, and it worked. And I was amazed. And people talk about this, but it was just plain fun. There was something more fun for me about writing Python code than Java. And I have never really looked back. That's a bit of an exaggeration. I do keep my eye out for other languages. I don't always assume that Python is always going to be the best for me. And I certainly use other languages as appropriate. But my core, I need to do something. I don't have a particular reason to choose another language. I do everything in Python. And yeah, I'm very similar in a lot of ways, actually. My background was in C# and C++, not Java. So a little bit different, but more similar than different, right? And I recall coming to Python thinking at first, like, it's kind of a weird-- interesting, but weird language. It's whitespace stuff. I don't know. Curly braces are pretty tried and true. What are we doing with all this? And before I really became super comfortable with Python and just like, yeah, that looks at it feels, it feels great. It feels right from how I perceived programming should be. I went, worked with it for a while, went back and why are all these symbols on the page? Like, it's just in the way of reading. And, you know, I used to thought I had to have the parentheses on the if statement, but it turns out you don't. So why does this language make you write the the parentheses and all those things, you're just like, "What a hassle." Not even the static typing, just the syntax is more syntaxy. I'm interested in how your experience with that was. >> Yeah, I'm going to save that for a little bit because it's going to come up in one of the points that we go over. I'll share though that for my background, there's one of the big piece that plays into all this. I went into college, into undergrad, focused on chemical engineering because I had a really good chemistry teacher in high school and I thought I wanted to apply what I knew about chemistry. In my intro chemical engineering classes, we were doing problems about running nuclear power plants. And I was like, gosh, I don't wanna run a nuclear power plant. And I really enjoyed my physics classes because they were just playing about understanding how the world works. So I ended up doing an undergrad in physics And I tutored throughout undergrad because so many people struggled with math and science, the two subjects that I loved the most. And I found that most people who struggled, it was because of how they were taught, not the subject material itself. And so I got a strong interest in teaching and I wanted to be a particle physicist, but I didn't want to be a student forever and get on the PhD track right away. So I started teaching and I loved teaching. I found that the challenge of reaching every person in a classroom was as hard and satisfying as hard science. And so I just stayed in teaching. So I taught public school, fifth grade through high school for about 20 years. And I was a hobbyist programmer throughout all of that. And so I taught intro programming classes whenever I could. And in the early 2010s-ish, I was looking for a Python book that I could give my more motivated students and just kind of stand on the sidelines and answer their questions, let them go at their own pace, but everything either made too many assumptions about what you already knew, or it was written for kids and kind of spoke down to you. And so that's how I ended up writing a book 'cause the book I wished to teach from did not exist. - Yeah. Sure know how that feels. - Yeah, yeah. - What's the title of the book? Share that with everyone. That is Python Crash Course. No starch, right? Yes, from no starch. And it's been the best-selling introduction-- it's been the best-selling Python book for close to 10 years now, which is really satisfying, because I kind of had a 10-year vision. I had the naive notion that I could write a book in the summertime and then revise it during the school year, and it would be done. And it was two and a half years instead of that. So I had a 10-year vision. I thought, if I want to do all this work, then I should support the book for a 10-year period. And so it's been very satisfying to see it be meaningful to so many people over that time. But that's really awesome. So your book is in LTS, long-term support? Yeah. Say that again? It's an LTS release of the book, a long-term support, right? Not one of those off-brand releases. Right, right. Yeah. - No, that's really great. And it's cool to connect with so many people. You probably go to PyCon and other events and people are like, "Oh, I read your book." And they really probably have stories to tell you about it. - Yeah, it was amazing. You go to PyCon or any of these conferences and you see a bunch of booths with people hiring or selling something. And I used to go to those booths and just have conversations. And a year or two after the book came out, those people started telling me, "Oh, hey, I learned Python from your book." And I was amazed at how quickly people could learn Python and then start to work at these companies and organizations. - Yeah, yeah, it's interesting. So they learn Python through your book and now they're working at Bloomberg or whatever, and now they're talking to you through these booths. Interesting, got it. Yeah, right in the audience. - Yeah, and as a teacher. - A person who says, "I'm glad to say I've read that book "and learned a lot from it." Yeah, very cool. - Yeah, yeah, I'm glad I worked for you. Yeah, I was going to say, as a teacher, yeah, I have always been happy for my students to end up better at whatever I introduce them to than I am. My focus has been on teaching for a long time, and so I learn my subject well enough to be able to do whatever I need to with them. But anybody who chooses to focus on one area over a lifetime is going to be better than I am at it. And so meeting those people at the booths who are honestly now probably better programmers or certainly within their discipline than I am, it's a privilege. Yeah. So along this idea of how do you go from beginner just starting Python to whatever we call intermediate or advanced or expert, it's an interesting topic. And I think it's one that really deserves some attention. I think it does, too. I think I hear it so many times from beginners. like I'm learning the language, or I'm learning this, or I'm learning that. Now, I just don't really know what to do to keep making progress. You mentioned your situation where you are a hobbyist programmer to some degree, and you just compared it against people who are maybe scaling out some DevOps thing at a huge tech company. Those are really different ways you spend your day. as a hobbyist programmer, you have something you're interested in, maybe you poke at it a little bit, you work at it, but you don't have the real demands of it's got to work at this crazy scale. Also, that it's something you can focus your entire effort on all day, because you're teaching or you're doing other things besides that as a hobbyist. Yeah, and I think that when we label ourselves or others, beginner, intermediate, expert, beginner is the one label that is objective, or I've never programmed before, I'm a beginner, or I have never used Python, so I'm a beginner at Python. Although even that, if you're experienced in another language, it's hard to call yourself a beginner again. And then when I've looked at, say, intermediate resources, it's a hard world to classify and categorize because what is intermediate? I think it's good to recognize that in the early days of a language, say like mid '90s to 2000 for Python, the language was small enough that somebody could call themselves an expert at some point. I know everything that there is in Python. A language is so big and the ecosystem is so huge and it covers so many domains, that it's hard for anybody to objectively call themselves an expert in Python. What does that even mean? And so it really is about-- >> Relative statement, yeah. >> How do you get out of those, I'm just learning the language and now I'm using it. That evaluation is interesting. >> Yeah, it is. And I think one, you know, it's a good point you bring up about when Python was smaller. There's this t-shirt that was a joke. It says, "I learned Python, it was a good weekend." You know? Which there's a truth to that and it's also cute. But at the same time, I've been doing this for many years and I'm still learning Python all the time, right? - Yes. - And so how do you square those two things? How can those both be true? And part of what that, the difference is, that's not obvious, I think, to beginners, but it's obvious to you. When that person said, "I learned Python, "it was a good weekend," they meant they rocked the for loop. They can create a class and they can create a function. You know, that's, they can do if statements and they now write and instead of double ampersand. That is one interpretation of what Python is. But then you look at PyPI with its, I haven't read the numbers in a few weeks or something, but it's close to half million packages. If you completely, truly learned a new package every day, you're still falling behind, right? Continuously, every day, just nonstop for the rest of your life, you're like, "Ah, I'm more behind than I started 20 years ago," right, in a sense. And so what is Python? I think when people say, "I want to be good at Python, "I want to learn Python, I want to be an expert in Python," you need to understand that there are these different layers or tiers of what that means. And you can be focused on one or another, but when people are comparing, like I've done this much and I've got, I'm an expert at Python. Like, well, are you an expert at the language? Are you an expert in fast API? What are you an expert in? Right, and so I think just kind of setting the stage with there's different meanings to what I'm good at Python is. - Yeah, and I'll say right now that I have a hard time classifying myself. I'm definitely not a beginner. I wouldn't necessarily call myself an expert, but I don't even know about intermediate. - Yeah. - Somewhere between intermediate and expert. And I've been writing a weekly newsletter at Mostly Python. It's on Substack. And I started writing a newsletter because I wanted to get out of that LTS you were mentioning about the book, where all my writing is about a book. It's always about the same material. And so writing a weekly newsletter forces me to pick a topic each week and then be able to explain that well. And I think a lot of people think that somebody in my position just knows all this stuff and just writes something up each week. And really, it's a whole bunch of research every time because there's nooks and crannies around every topic in Python that I didn't know about after 20 years in the language. And it's really enjoyable to fill out that understanding and then explain it well to other people. Yeah, it really is. Maybe final thought on this. Tony out there points out and says, adding on to what we were saying, and an expert in Python for data science doesn't necessarily look like an expert in Python for web and so on. Yeah, I was gonna add basically something similar that I would consider myself an expert in web development and API stuff and those kinds of things, right? I've been running production Python apps for a long time and really just polishing them, but put me in front of some machine learning situation or too much advanced pandas, and I'm like, well, I'm a beginner over here. And those are both also called Python, right? So there's just this, all these different contexts and spheres of relevance that I think people gotta keep in mind, right? And it's probably good to hear them say, you're an expert in some things, but it's not like you just know it all, right? >> Right. Yeah. It's good to recognize that expertise in one area is oftentimes transferable. You aren't immediately an expert in the new domain, but what you've learned in one domain is oftentimes makes it easier to gain expertise in another one. >> Absolutely. Like if the data science side, right? You're still good at Git. That's not a new thing for you, right? You're not like, "Why? What is this source control thing?" You can still completely rock that, but maybe you're not embracing the vectorization of style of programming and so on. All right, so maybe this is a good time to start talking about the ideas. So what I did is I said, Eric, you've got this cool book. How about you try to extract some ideas that you've learned from writing the book and working with people for this whole topic of transitioning from beginners towards the expert side of programming. So let's go to the list. - Sure. First of all, I like that structuring. It kind of forced me to think specifically about what I can say. I want to clarify, this isn't a countdown. A lot of times lists are like, here's the top 10 things you should know about Python. So these are ideas for specific things that people can do to move away from wherever you were as a beginner and more into that intermediate and expert, and be comfortable with justifying that. So for this kind of list, I start with the most important things first because everything else builds on that. And so when I think about what do people need to do to move away from beginner and towards being fluent and comfortable and competent and able to solve a variety of problems, the first thing is, when you're learning, know your goals. Why are you learning a program? And so we see this all the time if you follow conversations about learning Python. I want to learn Python. OK, what should I focus on? Well, what are your goals? Why are you learning it? What do you want to do? And I think the answers to that tend to be, I just like programming. I'm curious. For a lot of people, it is about money. People know that software development jobs can pay well. And I think it's quite appropriate and reasonable and important to name that if that is one of your goals and there's nothing wrong with that. - Right, it could be career but not money in the sense that I have a decent paying job now but I don't like my job. If I could just have the same money but actually work on programming all day, that would be awesome, right? - Yes. I think the money thing comes up for me because, all right, I'll say one of the things I'm proud of as an author is I've replied to pretty much every single email anybody has ever written to me about the book. And I think that's part of why the book has done well. Because I notice, I look for patterns. And so if people start to write about the same thing, then I adjust the book a little bit to address that. And so it keeps my email volume reasonable, but also means it's still meeting the needs of readers. But it also means I've had interactions with thousands of readers. And one of the things that comes up, in anything that goes beyond a, can you help me fix this one problem?" I oftentimes ask like, "What are you learning this for? What's your story?" And a lot of those people are doing career transitions. And it's a mix of people looking for better pay, and oftentimes that's tied in with to support my family, those larger life decisions other than just, you know, it's never greed. It's never, "I want to be rich." It's always, "I want to live a reasonable life." And what you say, people being tired of a of a different line of work and looking for something where they can have more power, more independence, more control. And so when you say know your goals, for most people, their goals is not one goal. It's a balance of those and recognizing where your balance sits is really important because it guides the rest of your learning and what you do. Somebody who's just plain curious. Go ahead, sorry. Well, yeah, and I think when we're talking about beginners, there's a lot of people who get pulled into Python without an explicit intent of becoming a software developer. In fact, like they would maybe start out by saying, "I don't wanna be a software developer. "I'm a biologist, I'm an economist, "I'm a philosopher," or whatever, but I need a little bit of programming because I learned that if I do these six lines of Python, like magic happens way better than if I had to force it through Excel or something, right? And I think a lot of the beginners are in that realm of, like, well, I'm here now. I'm still not a programmer. Don't call me one of those, but I use programming for my thing. And that's also a pretty interesting angle, I think. - Yeah, and I think that's a really, really good thing for people to recognize. It's interesting to have this conversation about labels and beginners and intermediate, Because how do you know when you're no longer a beginner? One of the clearest signs is when you have used programming to solve a real problem that you have. And you can throw in with a level of understanding rather than copy-pasting. But for a lot of people-- [INTERPOSING VOICES] Yeah. Yeah, and that's a super interesting dynamic to throw into all of this. But that is the end goal. should be the end goal for most people, not just to know how programming works, but to use it to solve a real world problem that you or somebody else has. And so as soon as you're doing that, you can start to consider yourself moving out of the beginner place. - Yeah, you might still feel awkward, but you're doing it. Really interesting comment that I think is worth highlighting. Foxo says, "I'm an anesthesiologist and you cannot imagine how much Python has helped me with different tasks." Amazing. That's really cool. Thank you for sharing that. - Yep. - Yeah, yeah, yeah. Okay, so tip number one, know your goals. Like why are you here? Because that'll help guide you somewhat, yes? - Yes, I'm taking a few notes about throwing things in there later in the list. - All right, beautiful, all right. I agree, I think it's important to know your goals and there's a lot of reasons why people get into programming, right? So-- Yeah, last thing on that is if somebody is just plain curious as far as teaching and learning, if somebody is just plain curious, that's their main goal, you have a lot more flexibility in the examples that you present to them and the pace at which you present material as opposed to somebody who says, I really want to do a career transition as soon as possible. That person needs a much more grounded and practical and timely approach. - Well, and you also might look out and say, okay, what web framework do I need to choose? What database experience do I need to get? Because I'm looking at Indeed job listings and I'm trying to hit the largest set of those rather than what project am I trying to work on or what am I curious about? You're like, I need to start checking the big boxes. Let's check those boxes so I can get a job in six weeks. - Yep. All right, tip number two. Yeah, tip number two. What do you got? Have a project in mind. And so whatever your goals are, having a specific project in mind helps put everything else in context. If you are learning about a for loop and you have a project-- I'm going to name one of the projects that I've worked on. I live in Southeast Alaska. And one of the impacts of climate change here is an increasing frequency and severity of landslides. And so Southeast Alaska is a rainforest. For anybody who isn't aware of that, it's not all snow in Southeast because we're right next to the ocean. And so we're still getting as much rain as we always have. But it's coming-- instead of light rain throughout the year with some periods of heavy rain, we're getting a lot more nice weather. We just had two or three weeks of no rain, which was really unusual here. But we'll get heavier fall storms. And that can lead to landslides. And so I had a project that monitored a local river's level to correlate that with landslide risk and help develop a warning system. And so a project like that in mind, that's a big project. And so if somebody is just learning Python, it's hard to say, here's everything you need to know to build that project. But if you're teaching a for loop, and you know that somebody is interested in a project about monitoring climate, then you can make your for loops about processing data related to rainfall, river levels, things like that. Yeah, absolutely. And Python is really interesting in that it's pretty good at the IoT thing as well, which opens up a lot of-- We've got CircuitPython and Adafruit and all those areas to play with as well, which is a whole different kind of project. Yeah. Yeah, and so there's an infinite number of projects. And so if you have a project in mind, being clear about that with yourself and with anybody that you're learning with or from is really helpful as far as tailoring what you're learning to your purposes. It's always easier to teach somebody-- sorry, I'll finish that. It's always easier to teach somebody who has a specific goal in mind than somebody who is just vague, just teach me something. Yeah, well, because it's focused. Yeah. Right? I find a lot of people try to boil the ocean metaphorically when they're trying to learn these things. Like, well, I saw somebody saying, well, all these CS topics are really hard for me. People keep telling me all these CS things I need to know. And do I really need to know them? Well, maybe eventually, but not all at once. What are you doing now? How big is your program? Do you really need testing? Maybe you do, maybe you don't. Do you really need classes? Maybe you do, maybe you don't. Do you need generators? Do you need async? There's all these things that you probably could say, don't need them now. Maybe in a year or two, I will need them. and then I'll be motivated to learn them. And so when you have these projects, you can say, I need these five things or I need these four things, I need to know them. And then my project is working, right? Instead of trying to say, well, what do I start with even? - Yeah, and one of the criticisms of many learning resources, and I'm a little sensitive to this 'cause I've written many of these examples, is when people do a for loop and the for loop is about like kinds of pizza or something or toppings of pizza. And people look at that and say, why do I need this? I don't care about pizza toppings. Okay, you need that because the person creating the resource has to have some kind of context for the example. And so when I'm teaching a class in person, I don't come up with, all right, we're gonna do pizza toppings. I ask people in the class, hey, what are you interested in? And then we pick something that somebody in the class that day mentions, and then there's relevance right there. You don't have that if you're learning on your own, But what you can do if you do know your own project, you work through the example about pizza toppings, but then you write a loop that relates to the project that you want to work on. And so knowing that project is really helpful, regardless of how you're learning. Yeah. Let me pull up another comment. I think this is worth covering for people as well. So Bishnyadar says, for me, it was all good while I was learning programming Python. But as soon as I was out there in real life looking for jobs and looking at the requirements, it drained a lot of energy out of me, suggestions. What do you think? Oh, boy. I don't think there's an easy answer to that. And I think it's important to be honest about that. Personally, I have never worked as a full-time programmer. And that puts me in a weird spot for talking about things like career transitions. I have helped thousands of people make career transitions, but I don't sit in the interviewee chair not very often. - Yes, I hear you, yeah. - And having spent a good part of my life as a teacher, teacher hiring and teacher, the structure of employment for teachers is so vastly different than programming. - Yeah, the time frame of teaching jobs is so weird. It's like, there's a time sort of once a year often that you can apply or change jobs and otherwise you can't. It's not exactly true, but generally true. - Yeah, I'm in an interesting position now where I'd kind of like to work as a professional programmer, but honestly, I have to spend 10 to 20 hours a week on supporting the book. That LTS stuff is hard. - I know, I got a bunch of courses and stuff, I know it. I was just redoing some videos that had a mistake and then somebody noticed. So anything I do is on top of that work. And so I can really only consider part-time work, and then it becomes, is this worth it? So to be more direct, I don't think there's an easy answer to the grind of looking for work. And it's that network thing of once you have a job, it can be easier to find the next job. The couple of things I'll share for people is if you-- so we talked about solving real-world problems. If you have a story that you can tell about how you have made something better through programming, what employers are looking for is that, yes, you have capability for programming. You can pass whatever leet code tests or screenings are necessary, but also have you used what you've learned about programming to solve something. And so the stories I always come back to are people who are working non-programming jobs and start to learn programming and then use that to solve something in their work that they weren't expected to solve. And that becomes a huge selling point in interviews. And my favorite story is a guy who was working for, I believe it was UPS, and this was quite a while ago. I feel comfortable telling that story partly based on time. They were working for one of these large delivery companies, and they were aware of people getting fired in warehouses for damage to the goods that were supposed to be delivered. And so the person was learning Python and they wrote some data analysis and they were able to pinpoint that the damage was coming from a manager or management group that was not training end line employees well enough. And so that was a really interesting story because the people being fired, but not the people who are causing the damage. They caused the physical damage, but it was right, but it was more systemic. Yeah. Yeah. And so that person saved their company millions of dollars. And they got like a $5,000 a year raise. But what they really did was they used that story in interviews to gain an actual programming position at a different company. And so it's hard when you're starting out. And so all I can say is look for the selling point for yourself and know that once you do get your first break, it becomes easier to stay on that path. I have one more thing to add. A lot of times when people are looking for their first programming job, they have experience somewhere else. I realize some people are young. They learn programming. That's kind of their totality of work experience. But a lot of people maybe studied something else and became a programmer. you studied physics, embrace that. So imagine you studied logistics. Instead of trying to look for a programming job, because you don't want to do logistics, look for a programming job at a logistics company. Because then you could say, I have programming skills, plus I have an expertise in your area of specialization. And once you intersect those things, you earn a much smaller set of competitors. I'm looking for a biology job, there's a ton of people doing biology. If I'm looking for a programming job, there's a ton of people doing programming. How many are doing biology and programming, maybe in the specific area that you're focused in? That all of a sudden gives you an opportunity. But it also means you need to look somewhat differently for jobs. You don't go apply to FANG the same way that everyone else thinks they should apply to FANG. Look for these small companies because not only will they appreciate it more, you'll you'll get a better chance to grow because you'll get a bigger responsibility to write more broad software. And the interviewing process is not nearly as terrible, I think, for small companies, right? It's a chat with a couple of people and they're like, we think you can do it. Give it a try for a week. Whereas places like the large tech companies, right? They've got these pretty horrible, you know, here's your take home exercise, write it. considered if it works out well, maybe amongst the other thousands, right? It's like a really different experience. I think that first step in the door, that first job is the one that is hard to get. Yeah, I'll throw one more piece in there and it's a quick thought. And that is, you know, contributing to open source projects is something we need to be careful about because oftentimes it's privileged work. You have some extra time and you can do that. But one of the real benefits of making meaningful contributions to established open source projects is it throws you all the way into professional workflows of managing, you know, using source control and just the bigger piece, communicating with a larger team. Yeah. So, yeah, as I've gotten more into open source, for me, that scratches that itch of wanting to work as a professional programmer. because I don't clearly see-- >>It's hard to simulate. Yeah, it's hard to simulate proper CI/CD merge conflict PR discussions on your own little hobby project, that's for sure. >>Right. >>All right. Yeah, so we're-- number two, we'll get a project. >>Yeah, we can go through some of these a little faster. >>Yeah, no, of course we can. What's number three? >>Number three is don't limit your learning to what's needed for your project. So it's important to have a specific project in mind to give context for what you're learning, and give purpose, and steer you towards feeling success and knowing what's good enough. But always be ready to expand your toolbox and your understanding. And it'll serve all your projects in the end. And learning is fun. Learning in good ways is fun. Learning with good resources, with good people. You want to learn fast API, here's your fast API worksheet. The answers are in the back. Yay. Sheesh. I have a kid in middle school, so we shouldn't talk about worksheets. Oof. But a quick example is I'm working on a project called Django Simple Deploy that automates deployment for projects in Django. It's not just for beginners. When Heroku collapsed its free tier a couple of years ago, saw a bunch of very experienced Python web people en masse go look at other platforms. And we saw them talking about how difficult it is to go through each platform's documentation and get a simple app deployed just to see the process. And so this tool is a core command manage.py sample deploy. And then you name the platform and it configures your project for that platform, and then you can push it. And so it's set up as a core command that then calls out to a platform-specific command and configures your project for those commands. And so when I first wrote it, my first pass was just a bunch of classes that they worked together because I wrote them, and they're all nice. But I had learned about abstract base classes but never had a purpose for using one. And so as this project is becoming more refined, I need to enforce a structure so that the platform-specific code works with the platform-agnostic code. And so if I hadn't-- or I should say this in the positive way-- because I had done some general learning about more advanced object-oriented principles, I have some sense of how to enforce that structure as the need arises. So it's good to have a project in mind, But don't limit what you're learning just to that project because you'll become a better programmer and you'll do your projects better. >> Sure. One of the ideas I think is really powerful is that inspiration is perishable. If you are inspired about something, you might not be that inspired in a couple of weeks. And that doesn't mean it's not cool anymore. That just means you moved on, your focus is elsewhere, or whatever. And so, yeah, sure, you need to learn the things you need to learn to do your project or to check some boxes. But if you find something, you're like, "I am really interested in that." Leverage that inspiration. I don't know about other people, but for me, I'm like two or three times more productive in learning and writing code and all sorts of things if I'm like really on fire about something versus like, "Ah, I guess I'll get in there "and like fix that bug." And like something that I'm not inspired about MailChimp just changed their API and deprecated, shut off their old one. Now I have people on my mailing list, I got to go rewrite that. What I get in the end is I get to just keep having them on my mailing list. There's zero inspiration there. But if I ran across, "Oh, there's this new feature in Python 3.12, or there's this new package that I found on PyPI that's awesome." And I just really want to leverage that. But while it's there, take advantage of it. All right, number four. Yeah, number four. What do we got? Read good code. And this is one of those things that I wish I had been told a lot earlier in my programming career than I was. I went a long time, decades, just looking at code that was presented in the classes and books I read, and then writing my own code and then only reading what I needed to in order to do my projects. And then at some point, I forget if I saw a suggestion to do this or if I just started to do it out of curiosity. I think it was probably around the time when a lot of code became very visible through platforms like GitHub. But if you're using a library like say Pandas, that is out in the open. And so rather than just using Pandas functions, you can go look at the code that runs that function. So Pandas has-- I shouldn't say Pandas because I'm just starting to get more fluent with that, more comfortable. So I'll say, like, matplotlib. So if you're making a scatter plot, fig.scatter or something like that, you can go look at that scatter function and see what it does. You see the full set of arguments that it can take. You see all of its capabilities. And you see how the people writing and maintaining Matplotlib take your information and turn it into a plot. And when you look at that code, you're seeing professional quality code. It can be overwhelming. There's probably going to be parts that you understand and parts that you don't. But the more you look at it, the more you understand. And your code becomes better because you're seeing high quality code. It's good to recognize that those people writing that did not write that polished code the first time they wrote the scatter function. So don't think, I'm a bad programmer because my code doesn't look like this. The polished code that we look at from large, popular, well-established frameworks has been well-refined. And so it's something to aim for. Yeah, it totally is. It's one of those things that's hard to get experience with. if you're kind of not yet working as a professional developer, or even if you are, but you're a one- to two-person shop, where you don't collaborate a lot. Right. It doesn't have to be that you're not working as a pro, you know, working as part of your job in that, right? It could be that you just don't have enough collaboration or enough people. Yeah. Yeah, and I think it could be hard to know where to look. All right, so if I look at the Python source code, giant. I have no idea where to look. Look at the most recent commits. So just pick a commit, look at the files that were changed, and get some sense of what people are doing to modify the language and these larger libraries. Look at the newest issues. What are people discussing about what they're trying to work on and how they're trying to solve that? And maybe look at some of the longest open issues. What are the hardest problems that people wrestling with in some of these projects that we all use. >> Yeah. All good advice. I would say the larger the open source project and the more popular, maybe harder it is to read. Because it has to be more polished and more optimized and more-- it's got that extra layer of, well, it's going to make it harder to read, but it'll make it 2% faster and people will appreciate that. So we're going to do that. Whereas there's a tier below that of open source things that are professional level, but not yet kind of beyond approachable. Yeah, I did two newsletter posts recently about exploring recent Python repositories to get at this exact issue. So the idea of you're looking at contributing to Django, it's hard. The Django community is doing a lot of work to make it more approachable for people wanting to contribute. But it's absolutely true that it's hard to contribute to and get into larger, well-established codebases. So I use the GitHub API to find, say, all the Python projects that have pushed to GitHub in the last three weeks that have at least 10 stars. And those are the fresh projects that are getting attention and don't have all this long-term stuff. And so I ended up actually contributing to one of those projects because it just-- what you described earlier just pulled me in and fascinated me in. It's so nice to have some concrete contributions to a project that is in that fresh stage. Yeah, that's fantastic. All right, what's the next one? Know your tools. I laugh at this one because I think about-- this is one of the reasons I transitioned into an equal focus between programming and teaching. I used to, my priority was 98% teaching and 2% programming. And now I'm probably 60% program, 40% teaching. Tools for teachers are terrible. Public school teachers still write most of their lesson plans in Microsoft Word. And that sounds like, oh, gosh, they just have to write out onto a blank page. But what it really means is we, as programmers, are used to working with structured data. And so if we have a workflow and we're writing something, and then we update the structure of our information, we don't have to go back and rewrite everything. We have tools that manage restructuring projects. If you write three years of lesson plans in Word, and then you figure out how to teach better, and you want to restructure all your lessons, there's no automated way to do that. It's a mess. And so I'm grateful as a programmer to have things like IDEs, formatters, linters, Git, any version control system, GitHub hosting platforms. And so my core advice here is to, as you're becoming more established as a programmer and as a Python programmer, start to recognize what are the tools that you personally find value in. What is your favorite IDE? What is your preferred formatter? What's your preferred linter version control system? And this just take a little time to focus on that tool itself. So if you've been using VS code for six months, spend three days and just read about configuring VS code. You'll almost certainly come up with some things that make your day-to-day work more efficient, more effective, more enjoyable. Every time I've taken time to do this, I've come out better for it. Yeah, whether it's VS code or PyCharm, They both have a ton of options that you can pick from. They're discoverable or less discoverable in different ways. Like iCharm makes it kind of obvious what all the things it can do, but there's so many things that people are like, well, I'm just gonna stick to my lane and just stay over here and do the thing. VS Code is a little less discoverable, but maybe it makes it even harder to take full advantage of it 'cause it's like the Command + Shift + P to pull up the palette and then like, well, it's a huge list, what do I do with this? - Yes, yes. - But being really good with your editor, I know some of the things that are coming as well on your list, this adds on top of it, but it makes a huge difference. It makes things like being comfortable navigating your code go better, testing your code, changing your code, right? Doing some of these workflows you talked about, like Git and PRs, all of that stuff. All of those things are in those tools, plus way more. That's not even talking about the extensions or plugins that you might go after, right? And so, but it's easy to see like, well, I've fired it up and then now it's an editor, right? It's a thing and it, oh, it has cool autocomplete. And then just kind of forget about the hundred other things that it can help you with. Yeah, and particularly with IDEs, they do a lot for us. And that can be a good thing and it can be a bad thing. I have steered a lot of people back towards simpler editors like Sublime Text and even Genie is a fantastic one that a lot of people don't know about because the tools like VS Code, PyCharm, whatnot, when everything's working, what they do for us is fantastic. When things stop working, if you don't know what it's trying to do for you, it can just make things much more confusing. And particularly, that comes down to things like tools that build virtual environment for a new project for you. So if you understand what that's doing, and it stops working, you can go troubleshoot it. But if you don't know what it did for you, and now it says this module is not found, it can be a mess. And so yeah, you can-- >> Virtual environments seem to be just like-- they just go wrong so often. I'm not in the pure, I've created one on the terminal and I've acted, that's solid. But in the tooling, it's like, sometimes it finds it, sometimes it doesn't, sometimes it really doesn't want to find it. It's nuts, yeah. - Yeah, and so I'm glad you brought that up. So the core advice there for me has always been, people have a tendency to want to go find another editor or IDE that's gonna manage that better. And what I tell them is, no, it's gonna manage it differently and you're gonna run into the same issue and then you're going to need to solve it. So when that stuff happens, taking the time to learn what your editor is doing for you and then be able to troubleshoot that, that's going to serve you well in the long run. Yep. All right, what's next? Learn how to test your code. And I wrote here, you won't sleep more, but your sleep will be more restful. I went probably 20 years programming without ever writing a test. And I always had this notion that it was difficult, it was separate from programming. And the first time I wrote a test, it was so much easier than I thought. And so cool to see my program run automatically and had the output validated. I love testing. It's probably my biggest interest these days beyond deploying Django projects. And I love it because when we write code, we want it to work. When we have a project, we want our product to be successful. And so testing validates that. Testing gives you confidence that your project is working correctly. And if you fix a bug, you just fix it once. So testing is its own podcast for some people. So I'll just say that testing is easier than a lot of people think it is. Go use pytest. I used to teach unit tests because it's in the standard library. but pytest has become well-established enough. It's one of my favorite Python packages of all because it's one of those few that serves pure beginners and experts equally well. It's the best way to be introduced to testing. And if you're testing professionally, there's no tool better than that. - That's the Zen of Python, right? That it's really serves beginners well, but also experts well. I think that's one of its special capabilities. Yeah, I will encourage people-- and Michael, I'd be curious if you agree with this or not. I'd encourage people to not necessarily look at unit tests right away, because unit tests are brittle for newer projects. I really like end-to-end testing. And that is where you run your project, you get some output, and then you run tests against that output. And that is not testing the implementation of your project. That's just saying, does your project work? And so the project I've been pulled into recently is one called git-sim, git-sim. And you run it against your own project, and it gives you a visualization of all your commits. And so for people trying to understand how Git works or how Git is working for their particular project, you run git-sim merge, and it shows you visualization of what that merge would look like. And so that project is newer, and it had no tests. And so I helped write the initial test suite. And I said to the person, we shouldn't test your implementation because you should be free to change how you're building this new project. But we should actually start to test the images that you're generating so that when you do change your implementation, you know whether the images that your users are going to see are the ones that you think-- that you've been seeing and you think they're going to see. And so that's really nice because you don't have to aim for 100% coverage of your code. you just start to get that big picture. Yes, my project is still doing what I think it's doing. And that makes for better sleep. And all of your non-computer activities are more enjoyable because you have more confidence that things keep working. Yeah, I'm with you on not going too far down the unit test. I used to write tons and tons of very low-level focus unit tests. And when I was on a team, I always had a hard time having everybody have buy-in. Some people would, some people wouldn't. They'd go do something that would break the test. You know, like you broke the build. They're like, "Oh, yeah, I guess I did." You're like, "You realize that if we don't all participate in this, it just becomes a hassle for me, like chasing after trying to like patch up the tests as you make these changes. And as you're more focused, as you're like lower level in the world, that's just a more constant problem. And it also requires more effort, right? So maybe that effort is worthwhile. But if you're new, maybe it's not. And so I'm a little bit more on board with just like, let's do the main things at like kind of top to bottom in the app. And if that stuff hangs on, we got a real good chance. And over time, my experience has been, for the most part, things blow up hard. They don't just like, oh, there's some little subtle problem. Generally, not always true, but generally, if I screw something up, a lot of tests start failing, even when they're these high-level things, because something's pretty messed up. And in that regard, that other person probably didn't intend to change the output or the overall behavior of the app in well-known ways. They just changed some implementation detail, and they weren't being sufficiently rigorous with their software lifecycle. So yes, I'm on board. The web equivalent, the easiest web equivalent that I can think of is if you've got a website and it has a sitemap, your website should have a sitemap for all of your data-driven pages. just go get the sitemap and request every page. Does it give you a 200 or does it give you a 500 or a 404? 'Cause 404s and 500s should not be found in your sitemap. Right, but that's a really easy test, right? Like loop over that, call every one of those with your self.client.get or whatever your HTTP test thing looks like and just call all of them. That's one thing you could do that's in that category. And as an author, I wrote tests for most of the code in Python Crash Course. And so Python Crash Course was first written, I think, on Python 3.5. And so it's been through, like, what, six or seven iterations of Python and all kinds of iterations of the libraries that the projects use. And so whenever a new issue comes out, or new, sorry, version comes out, I just run tests on most of the code in the book. And it pulls the, the test pulls the code from the GitHub repository for the book and just runs it with the new versions. And that's been part of how I've been able to maintain the upkeep and maintenance on a 500 page book that covers a lot. - Yeah, yeah, that's awesome. - Yep. - Let's keep going. There's a couple of good comments and questions in the audience, but I think we're on a schedule. So let's keep going. - Yeah, yeah. Last comment about testing. I love it because I think that When you test your code, you learn things about your code that makes development better as well. So it's not just, does it work? It also gives you insight into how your code is working. Then looking forward to exploring more. All right, next point. Know what's good enough for any given project. As a teacher, students would say like, am I done? Am I done? Is this good enough? And I watch other teachers say, like, don't ask me that, I always work harder. And I always tell students, that's a great question. What is good enough? And so whatever your project is, knowing your benchmark for what's good enough and what it's done, when you can move on to the next thing, is really helpful because you'll never write perfect code. But you can certainly write good enough code. Yeah, there was a really popular article, blog post, something like that, that was you're not Facebook, you're not Google, you're not Microsoft, you're not LinkedIn, something along those lines. And the admonishment or the advice there was, you might read about how somebody like Google has all these containers doing all this scale out and failover and geo location. Your app that manages reporting for managers at your company, there's five managers and they do it once a week. You don't need global scale out techniques. You don't need the zero downtime that containers offer. You don't need load balancers. Like none of that stuff applies to you. And so, in fact, I would say if you start applying those things to it, you make your application harder to deploy, you make it harder for other people and your team to work on, you make it less good for that situation. But at Google scale, the opposite is true. It's less good if it doesn't have those things. And so it's not just, "Well, this is a crappy project, so it gets crappy level CS attention." It's a small project, so it can be written and managed and worked on in a way that allows for, optimizes for small teams, not optimize it for uptime, and all those kinds of things, so that you can make it work better in that situation. And so I totally agree, knowing what is good enough is super important, but what is good enough is not like a spectrum. Like I'm at the really good level. It's like you've got to-- it's a multidimensional thing. Like you're at a good level for the context that you're in, the situation you're in. Hey, you're walking right into bullet point-- or tip number eight, I think it is. Yeah, you are. Yeah, that's embrace refactoring. And so my notes about this was that good enough is situational. So when a project proves its worth, like say you have an idea for a project, you build it out, you get an MVP functional, and you've reached your good enough to see whether the idea works, if nobody ever uses it, it doesn't catch on, it worked, it was interesting, but it's just not catching on, you move on, move on to something else. But if that product has started to gain interest, now good enough moves. And so maybe it needs to be more efficient. Maybe it needs more testing. Maybe it needs to be deployed in a different way. And so refactoring, tied in with that idea of what is good enough, is the road for evolving a project. And all of these projects that we're talking about, the well-established ones, the Googles, the Fangs, those projects are constantly shifting bars of what is good enough. And they're constantly being refactored in very careful ways to reach those new goals. - Yeah, I love that. - I love refactoring your tools. - Yeah, I do too. I think it's fantastic. So many people who are getting started will tell me things like, I'm not sure how to get started. I don't know what the best way to do this is. I'm thinking about it and I've tried something, but I wasn't sure. So I went back to thinking and the best way to get started is just give it a shot. just create something. You'll learn what of that is working and what is not ideal. And more importantly, something that's awesome about software is it's plastic, right? You can change it, plastic in the soft plastic way. You can evolve it as you learn more about it. You're like, oh, I thought that should have been separate module, but this should be just part of that class. So we're just gonna move that in through refactoring and not feeling like you have to have a full visibility of what you're working on to get started, I think that that's, maybe it sounds counterintuitive, but I feel like that's kind of an expert perspective. It's like, I think I need to go that way. We're gonna start down the path that way, and we're going to evolve and sort of course correct as we go rather than completely stressing about how do I get started? How do I see the whole end line before I start writing it? And this is part of why this is not a countdown. Because, for example, if you have even a small set of tests that test your final output, refactoring is easy. It's fun. Because if your tests break and you don't like the idea, you can go back to where you started. Yeah. Yeah. Another fun thing about refactoring is the whole concept of code smells. And I think becoming an expert, there's a lot to be learned from the code smells. And the idea of the code smells is the code works, but there's something a little bit off. It kind of makes your nose turn up. You're like, oh, oh, okay. Yeah, I guess it works, but oh, right. You know, it's just kind of an ooh. And there's a lot of lessons of how things get out of control and they get into a bad state and how do you fix them. And having that intuition, I think is great. So some of the code smells are like long method, method with too many arguments. Probably my favorite is code comments because you hear you should comment code all the time and there should be for places that need a comment, there should be comments or help strings, whatever. But a lot of times, code comments are deodorant for these code smells. It's like, "Oh, this is kind of gross. Let me make a comment about why it's gross." or this is poorly named, people won't know what this is, so let me make a comment about what it is. And halfway through that comment, you should realize, "Oh, what if I just named it the thing I'm trying to tell people it does?" Then I don't even need a comment because it has a really good name that is its own thing. So, poor names, too many parameters, all these things are deodorant, and you're trying to justify how gross this part of your code is. Like maybe you could just apply some of these refactoring techniques to make them better. Not going into a whole refactoring detail, but I really, really like this idea. >>Yeah, I read a lot of exploratory code, so you're describing a lot of my work. But because I'm fine with refactoring and enjoy it, and I'm comfortable with tests, that workflow works. And I think it can work for a lot of people. >>Yeah, sure, sure. Well, and those things don't necessarily start out that way. The long method didn't necessarily start out long. It grew and grew until it was a monster. Same thing with too many arguments. It probably started out with one or two, but then now we need this other one. And what about that? And then all of a sudden it's like, again, a monster. Right, and so it's an evolution. - And it's long because it works. And so at some point you paused and cleaned it up, make sure it still works. All right, number nine, write things down. Yeah, write things down. And I don't say that as a writer. Writing for me, I started writing when I was young because I saw somebody else write a journal and I was like, "Oh, I'm gonna try writing." And so I've just written things all my life and most of it is messy and some of it, very small amount of what I've written has been polished and put out in the public world. But I have found that almost everybody I talk to who writes in some way, not for public, but writes in some way, enjoys their work a little more and does a little better. My suggestions are things like keep an ideas notebook. Once you know how to build things, ideas come to you and you're like, "Oh, I could make that at some point." And if you have a place to record those ideas, when you're not sure what to do, you can go back to it. Write comments, despite what Michael said. Comments in a professional, well-established project with many collaborators are different than comments for your own new projects. So whatever you're doing, write comments. So do put the information in that needs to be in there to work and let them be cleaned up. [INTERPOSING VOICES] Yeah, I don't mean to say you shouldn't write comments. There's a lot of times where the point of the comment is to justify why something's bad. If that's the case, it probably doesn't need to be bad. But if it's help docs, if it's like, well, here's the different stuff that you could pass, and these are what we-- there's certainly valid comments, no doubt. Yeah. So write comments to yourself and others. And even if nobody else is using your project, if it's something that might be shared at some point, those are good. Learn to write documentation. If you write an ideas notebook, if you write comments, documentation kind of flows out of that. It just becomes a more polished version of what you're writing. Write question sound when you're not sure about something. GitHub issues are amazing. I haven't used project management software because GitHub issues are so useful. And so-- [INTERPOSING VOICES] No Microsoft project. Yeah, yeah. Even if you don't ever plan to write anything public, write about the code that you're working on. and write for yourself. And it will almost certainly benefit the work that you do. Writing helps you crystallize your thoughts and make sure you have them all coherent, right? Right. All right, last one. Big tip, and this is a fun one to close on. Go meet people. It has long been said about Python that I came for the language and stayed for the community. People have talked about that for years because it's still true. Join online communities, go to local, regional, national, international conferences when you can, go to coffee shops, ask questions, tell stories. You will meet good people like Michael. - And you, as we met at PyCon. So I think this is really good advice. I was thinking as I looked at your list that you are somebody who is not particularly metropolitan in terms of tons of user groups and meetups, I'm guessing, where you live. It's probably a little bit of an extra challenge being in Alaska, right? Yeah, it's actually-- I mean, I lived in New York City for seven years before I moved here. Right, as a contrast, right? Yes, yes. But most of my programming work, serious programming work, has been done while I've lived here. And yeah, I don't know anybody else here who programs. And so for me going to conferences, I talk about programming the entire time at conferences because I never get to in regular life. But yeah, the -- >> Honestly, that's true for me as well. Even though I'm here in Portland and we have user groups and there are plenty of people who do programming, it's not that different for me. Because I don't go to a company where I have a team of developers. Like the people I work with, it's as real as this meeting with you and me here on a video screen share sort of thing. And I think this is the story of more people than just if you live outside of some big metropolis. >> Yeah, yeah. Quick story. First time I went to PyCon, I was intimidated because I was a teacher and not a programmer. And so I thought I would not find my place. And I walked into the hotel the first night. And people pulled me right into conversation. And what I found was that roughly half the people who go to PyCon are primarily programmers looking for what to work on. And roughly half the people are people who care about some other domain than programming. And they're looking to use Python and programming to solve the problems they care about in their domain. And so it's true. Everybody has a place in the Python world. if you are respectful and appropriate to other people. And so if you're shy or intimidated about going out to meet people because you're not sure of your place, just go meet people and you will find your place. And it's magic. - Yeah. I think, hopefully I'm not misremembering this. I think almost half the people at PyCon this year were first time attendees. So if you're thinking, oh, I shouldn't go. - It was like 78. It was over half. It was like 80%. Yeah. Yeah. I was amazed. Yeah. I'm not sure how much of that's a COVID hangover sort of thing because there were not as many people who came as say in 2019. So maybe there were more PyCon curious folks than say the people who had been there for the last 10 years. Like, "I still want to skip this one." We'll see where it shapes up. there's a really high number, whatever that number turned out to be in the equilibrium, is that there's a ton of people at these types of events who are like, this is my first time here. So if you're concerned about going to these events and feeling like, oh, I'm going to be the one newbie and feel out of place, probably it's the opposite. Yeah, yep. Yeah, you end up with lifelong friends. Absolutely. People are in a great mood. They're on their geek holiday. It's all good. - Yes. - It's pretty easy to make friends and have a good time there. So that could be PyCon or EuroPython or something like that. Or it could just be a local. There's a lot of regional Python meetups like PyCascades here in the Pacific Northwest, PyTexas, PyOhio, all these things. And if none of those work for you, you know, there's forums like this, to be honest. like part of the reason I created the podcast was to kind of get to know people better in a way that I guess I knew wouldn't be possible for me, right? My goal was, well, where do I go find the podcast to listen to to do this? And then there was none. I was like, all right, fine, I'll create the podcast so we can do this. But my intent was just to listen to a podcast to kind of get to know people like this. It's a pretty one-way conversation as a podcast listener, not 100% as people seem in in the audience, but it's still valuable to like eavesdrop in a sense on these conversations if you're a new person. - Right, absolutely. - Yeah, yeah. All right, Eric. Well, what a fun conversation. Thank you for the awesome list. And hopefully you've inspired a lot of people out there to make forward progress on this journey that they're on. - Well, thank you for having me. I've listened to you for a long time and really enjoyed your work and very happy to connect. - Yeah, same here. So final call to action, people are interested, maybe tell them how to check out your book, tell them how to put some of these ideas into action. - My book is "Python Crash Course" from No Starch Press. Third edition came out this year, and so everything works, it's good, I keep it updated. If you buy it, you get a copy with the newest updates. Yes. I also write weekly at MostlyPython, and that's mostlypython.substack. There are paid subscriptions, but there are also free subscriptions. And so the only advantage for paid subscriptions is that some posts are locked for six weeks. Everything I write, I want to be available to everyone. And so if you're curious about what I'm thinking about on a weekly basis, MostlyPython. Excellent. All right. - All right. - Well, thanks again for being here. See you later. Thanks everyone for listening. - Yes, thank you.
