#427: 10 Tips and Ideas for the Beginner to Expert Python Journey Transcript

00:00 Getting started in Python is pretty easy.

00:02 There's even a t-shirt that jokes about it.

00:04 I learned Python, it was a good weekend.

00:06 But to go from knowing how to create variables and writing loops, to building amazing things like FastAPI and Instagram, well, there's this little gap in between those two things, don't you think?

00:17 On this episode, we welcome Eric Matthews to the show.

00:20 He has thought a lot about teaching Python and comes to share his 10 tips for going from Python beginner to expert.

00:26 This is Talk Python to Me, episode 427, recorded July 19th, 2023.

00:33 [music]

00:45 Welcome to Talk Python to Me, a weekly podcast on Python.

00:49 This is your host, Michael Kennedy.

00:51 on Mastodon where I'm @mkennedy and follow the podcast using @talkpython both on fosstodon.org.

00:58 Be careful with impersonating accounts on other instances, there are many. Keep up with the show and listen to over seven years of past episodes at talkpython.fm. We've started streaming most of our episodes live on YouTube. Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode. This episode is brought to you by by GlareDB.

01:23 GlareDB is an open source database for querying distributed and disparate data.

01:29 Connect your data sources and use the Python tools you already know to ask questions and integrate data across data sources.

01:36 Get started today at talkbython.fm/glareDB.

01:39 And it's brought to you by Sentry.

01:42 Don't let those errors go unnoticed.

01:44 Use Sentry.

01:45 Get started at talkpython.fm/sentry.

01:48 Eric, welcome to Talk Python to me.

01:50 - Thank you.

01:51 >> It is very nice to have you here.

01:53 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.

02:03 Not a bad place to wrap that up.

02:04 >> No, it was very nice.

02:05 >> What a fun event. We're going to talk about how people go from being a beginner-ish, that's a pretty broad term of what a beginner is in Python and programming, and moving towards how do you take that journey, maybe with more deliberately, a little more quickly, to the expert side of the software developer spectrum.

02:27 It's going to be a lot of fun.

02:28 >> Yes.

02:28 >> Yeah. Before we get into that though, let's just start with your story.

02:33 How did you get into programming Python?

02:35 How did you end up writing books? All those things.

02:37 >> Oh boy. I had to be careful because it's a long story and I like telling it.

02:41 I was fortunate in that my father was a software engineer in the '70s and '80s.

02:47 When I was growing up, we had a kit computer in our basement before most people had home computers.

02:53 So I got to write my first program as a basic number guessing game.

02:57 >> Back when it was all about the go-to's.

02:59 >> Yes, line 10.

03:01 >> Go to 10.

03:01 >> What is your number?

03:02 >> Yeah.

03:03 >> Yeah.

03:04 >> I always had an interest in programming.

03:05 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.

03:16 My journey into Python was I was using Java in the early 2000s, and I thought I'd be a Java programmer for life.

03:24 A friend told me that, "Hey, you should check out Python.

03:27 Your Java programs will be about a third as long as they are in Java." I couldn't really believe that because it's a pretty big claim.

03:37 >> Yeah, that's a bold claim.

03:39 >> Yeah, and it worked, and I was amazed.

03:41 People talk about this, but it was just plain fun.

03:44 there was something more fun for me about writing Python code than Java.

03:48 And I have never really looked back.

03:50 That's a bit of an exaggeration.

03:52 I do keep my eye out for other languages.

03:54 I don't always assume that Python is always going to be the best for me.

03:57 And I certainly use other languages as appropriate.

04:00 But my core, I need to do something.

04:02 I don't have a particular reason to choose another language.

04:04 I do everything in Python.

04:05 Yeah, I'm very similar in a lot of ways, actually.

04:08 My background was in C# and C++, not Java.

04:13 So a little bit different, but more similar than different.

04:16 I recall coming to Python thinking at first, it's a weird, interesting, but weird language, it's white space stuff.

04:24 Curly braces are pretty tried and true, what are we doing with all this?

04:28 Before I really became super comfortable with Python and just like, yeah, that looks at it, it feels great, it feels right from how I perceived programming should be.

04:38 I worked with it for a while, went back and why are all these symbols on the page?

04:43 It's just in the way of reading.

04:46 I used to thought I had to have the parentheses on the if statement, but it turns out you don't.

04:50 Why does this language make you write the parentheses?

04:53 All those things, you're just like, "What a hassle." Not even the static typing, just the syntax is more syntaxy.

05:00 I'm interested in how your experience with that was.

05:04 >> Yeah. I'm going to save that for a little bit because it's going to come up in the points that we go over.

05:09 >> Okay.

05:09 I'll share though that for my background, there's one of the big piece that plays into all this.

05:14 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.

05:26 In my intro chemical engineering classes, we were doing problems about running nuclear power plants.

05:30 And I was like, gosh, I don't want to run a nuclear power plant.

05:33 And I really enjoyed my physics classes because they were just playing about understanding how the world works.

05:38 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.

05:48 And I found that most people who struggled, it was because of how they were taught, not the subject material itself.

05:54 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.

06:00 I could get on the PhD track right away.

06:02 So I started teaching, and I loved teaching.

06:04 I found that the challenge of reaching every person in a classroom was as hard and satisfying as hard science.

06:12 And so I just stayed in teaching.

06:14 So I taught public school, fifth grade through high school for about 20 years.

06:19 And I was a hobbyist programmer throughout all of that.

06:22 And so I taught intro programming classes whenever I could.

06:24 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 and let them go at their own pace.

06:34 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.

06:42 And so that's how I ended up writing a book 'cause the book I wished to teach from did not exist.

06:47 - Sure know how that feels.

06:48 - Yeah, yeah.

06:49 - What's the title of the book?

06:49 Share that with everyone.

06:50 - That is "Python Crash Course." - No starch, right?

06:52 - Yes, from no starch.

06:54 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 'cause I kind of had a 10-year vision.

07:04 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.

07:11 And it was two and a half years instead of that.

07:15 So I had a 10-year vision.

07:16 I thought if I'm gonna do all this work, then I should support the book for 10-year period.

07:21 So it's been very satisfying to see it be meaningful to so many people over that time.

07:25 - That's really awesome.

07:26 So your book is in LTS, long-term support.

07:29 - Say that again?

07:29 - It's an LTS release of the book, a long-term support, not one of those off-brand releases.

07:35 - Right, right.

07:36 - No, that's really great.

07:37 And it's cool to connect with so many people.

07:40 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.

07:46 - Yeah, it was amazing.

07:48 You go to PyCon or any of these conferences and you see a bunch of booths with people hiring or selling something.

07:53 And I used to go to those booths and just have conversations.

07:57 And a year or two after the book came out, those people started telling me, "Oh, hey, I learned Python from your book." I was amazed at how quickly people could learn Python and then start to work at these companies and organizations.

08:08 Yeah. It's interesting.

08:10 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.

08:16 Interesting. Got it.

08:17 >> Yeah.

08:17 >> Right in the eye.

08:18 >> As a teacher.

08:18 >> This new says, "I'm glad to say I've read that book and learned a lot from it." Yeah. Very cool.

08:23 >> Yeah. I'm glad I work for you.

08:25 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.

08:32 My focus has been on teaching for a long time, and so I learned my subject well enough to be able to do whatever I need to with them.

08:39 But anybody who chooses to focus on one area over a lifetime is going to be better than I am at it.

08:44 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.

08:51 >> Yeah.

08:52 >> So along this idea of how do you go from beginner, just starting Python to whatever we call intermediate or advanced or expert.

08:59 It's an interesting topic, and I think it's one that really deserves some attention.

09:03 >> I think it does too. I hear it for so many times from beginners, like I'm learning the language, I'm learning this, I'm learning that, and now I just don't really know what to do to keep making progress.

09:15 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.

09:28 those are really different ways you spend your day, right?

09:31 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 gotta work at this crazy scale, and also that it's something you can focus your entire effort on all day, right?

09:47 'Cause you're teaching or you're doing other things besides that, right, as a hobbyist.

09:51 - Yeah, and I think that when we label ourselves or others, beginner, intermediate, expert.

09:58 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.

10:05 Although even that, if you're experienced in another language, it's hard to call yourself a beginner again.

10:09 >> Exactly.

10:10 >> Then when I've looked at say intermediate resources, it's a hard world to classify and categorize, because what is intermediate?

10:18 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.

10:30 I know everything that there is in Python.

10:32 The 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.

10:41 What does that even mean? It really is about-

10:43 Relative statement.

10:44 How do you get out of those, I'm just learning the language and now I'm using it.

10:48 That evaluation is interesting.

10:50 >> Yeah, it is. I think one, it's a good point you bring up about when Python was smaller.

10:55 There's this teacher that was a joke.

10:57 It says, "I learned Python.

10:58 It was a good weekend." There's a truth to that and it's also cute.

11:03 But at the same time, I've been doing this for many years and I'm still learning Python all the time.

11:09 How do you square those two things?

11:11 How can those both be true?

11:13 Part of what the difference is, that's not obvious I think to beginners, but it's obvious to you.

11:19 When that person said, I learned Python, it was a good weekend.

11:22 They meant they rocked the for loop.

11:24 They can create a class and they can create a function.

11:27 You know, that's, they can do if statements and they now write and instead of double ampersand.

11:32 That is one interpretation of what Python is.

11:35 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 a million packages.

11:43 If you completely, truly learned a new package every day, you're still falling behind, right?

11:50 >> Yes.

11:51 >> Continuously, every day, just non-stop for the rest of your life, you're like, "Ah, Molly, I'm more behind than I started 20 years ago," in a sense.

11:59 What is Python?

12:00 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.

12:13 You can be focused on one or another, but when people are comparing, I've done this much and I'm an expert at Python.

12:22 Well, are you an expert at the language?

12:23 Are you an expert in FastAPI?

12:25 What are you an expert in?

12:27 I think just setting the stage with there's different meanings to what I'm good at Python is.

12:33 >> Yeah. I'll say right now that I have a hard time classifying myself.

12:37 I'm definitely not a beginner.

12:39 I wouldn't necessarily call myself an expert, but I don't even know about intermediate.

12:43 >> Yeah.

12:43 >> Somewhere between intermediate and expert.

12:46 I've been writing a weekly newsletter at mostly Python, it's on Substack.

12:51 I started writing a newsletter because I wanted to get out of that LTS you're mentioning about the book, where all my writing is about a book.

12:59 It's always about the same material.

13:01 Writing a weekly newsletter forces me to pick a topic each week and then be able to explain that well.

13:07 I think a lot of people think that somebody in my position just knows all this stuff and just write something up each week.

13:14 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.

13:22 But it's really enjoyable to fill out that understanding and then explain it well to other people.

13:26 >> Yeah, it really is.

13:28 Maybe final thought on this.

13:29 >> Sure.

13:30 >> 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.

13:38 So I was going to add basically something similar, that I would consider myself an expert in web development, and API stuff, and those kind of things.

13:48 I've been running production Python apps for a long time, and really just polishing them.

13:53 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." Those are both also called Python.

14:05 There's just all these different contexts and spheres of relevance that I think people got to keep in mind.

14:13 Probably good to hear them say, "You're an expert in some things," but it's not like you just know it all.

14:18 >> Right. It's good to recognize that expertise in one area is oftentimes transferable.

14:23 You aren't immediately an expert in the new domain, but what you've learned in one domain is often times making it easier to gain expertise in another one.

14:32 Absolutely. Like if the data science side, right, you're still good at Git.

14:35 That's not a new thing for you, right? You're not like, wow, what is this source control thing? Like you can still completely rock that. But, but maybe you're not embracing the vectorization of style of programming and so on.

14:47 This portion of talk Python to me is brought to you by Glare DB. Glare DB is an open source database for querying distributed data. Here's how it works.

14:57 First, you connect your data sources.

14:58 GlareDB makes it easy to connect to your data, no matter where it's stored, with integrations into many popular databases, data warehouses, and more.

15:06 This includes Snowflake, Postgres, MongoDB, BigQuery, and Object Storage.

15:12 Now you can query everything.

15:14 You use the full power of SQL to query your data across these many different data sources, join data across production databases and analytical warehouses without limits.

15:24 Finally, you can use the tools you already know and love.

15:27 Visualize and query your data using tools you know from Python's data science stack.

15:32 With just a single import, you can query Pandas and Polars data frames using just SQL.

15:37 You'll be asking questions, extracting insights, and driving decisions with your data without waiting for an ETL pipeline to move data around.

15:45 So if you have distributed data and disparate data sources and you love open source, you owe it to yourself to give GlareDB a try.

15:53 Visit talkpython.fm/glaredb to get started.

15:56 The link is in your podcast player show notes, and please use the link to let them know that you came from us.

16:02 Thank you to the team at Glare DB for sponsoring the show.

16:05 Maybe this is a good time to start talking about the ideas.

16:10 So what I did is I said, you know, Eric, you've got this cool book.

16:14 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.

16:25 So let's go through the list.

16:27 Sure.

16:27 I like, first of all, I like that structuring.

16:29 I kind of forced me to think specifically about what I can say.

16:32 I want to clarify this isn't a countdown.

16:35 A lot of times lists are like, here's the top 10 things you should know about Python.

16:38 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.

16:47 And be comfortable with justifying that.

16:49 So for this kind of list, I start with the most important things first, because everything else builds on that.

16:55 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, when able to solve a variety of problems, the first thing is when you're learning, know your goals, why are you learning a program?

17:09 And so we see this all the time.

17:11 If you follow conversations about learning Python, I want to learn Python.

17:14 Okay.

17:15 What should I focus on?

17:16 Well, what are your goals?

17:17 Why are you learning it?

17:18 What do you want to do?

17:19 I mean, I think the answers to that tend to be, I just like programming, I'm curious.

17:25 For a lot of people, it is about money.

17:27 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.

17:37 >> 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.

17:44 If I could just have the same money, but actually work on programming all day, That would be awesome, right?

17:50 >> Yes. The money thing comes up for me because I'll say, one of the things I'm proud of as an author is I've replied to pretty much every single e-mail anybody has ever written to me about the book.

18:00 I think that's part of why the book has done well, because I look for patterns.

18:05 If people start to write about the same thing, then I adjust the book a little bit to address that.

18:10 It keeps my e-mail volume reasonable, but also means it's still meeting the needs of readers.

18:15 But it also means I've had interactions with thousands of readers.

18:19 And one of the things that comes up in anything that goes beyond a, can you help me fix this one problem?

18:24 I often times ask, what are you learning this for?

18:26 What's your story?

18:28 And a lot of those people are doing career transitions.

18:31 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.

18:40 It's never, I wanna be rich.

18:41 It's always, I want to live a reasonable life.

18:44 And what you say, people being tired a different line of work and looking for something where they can have more power, more independence, more control.

18:52 When you say know your goals, for most people, their goals is not one goal.

18:57 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.

19:04 >> Yeah, it absolutely does.

19:06 >> Somebody who's just plain curious. Go ahead, sorry.

19:08 >> Well, yeah. 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.

19:19 In fact, they would maybe start out by saying, I don't want to be a software developer.

19:23 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, magic happens way better than if I had to force it through Excel or something.

19:37 I think a lot of the beginners are in that realm of, well, I'm here now.

19:42 I'm still not a programmer.

19:44 Don't call me one of those, but I use programming for my thing.

19:48 That's also a pretty interesting angle, I think.

19:50 >> Yeah, and I think that's a really, really good thing for people to recognize.

19:54 It is interesting to have this conversation about labels and beginners and intermediate, because how do you know when you're no longer a beginner?

20:01 One of the clearest signs is when you have used programming to solve a real problem that you have.

20:07 You can throw in with a level of understanding rather than copy-pasting.

20:11 >> But for a lot of people-

20:12 >> Or now, ChatGPTing also.

20:15 >> Yeah. That's a super interesting dynamic to throw into all of this.

20:19 But that is the end goal.

20:20 It should be the end goal for most people.

20:22 Not just to know how programming works, but to use it to solve a real world problem that you or somebody else has.

20:29 As soon as you're doing that, you can start to consider yourself moving out of the beginner place.

20:34 >> Yeah. You might still feel awkward, but you're doing it.

20:37 Really interesting comment that I think is worth highlighting.

20:39 Foxo says, "I'm an anesthesiologist.

20:42 You cannot imagine how much Python has helped me with different tasks." Amazing. That's really cool.

20:47 >> Yeah.

20:48 >> Thank you for sharing that.

20:48 >> Yeah.

20:48 >> Yeah.

20:49 >> Okay. So tip number one, know your goals.

20:53 Why are you here? Because that'll help guide you somewhat. Yes?

20:56 >> Yes. I'm taking a few notes about throwing things in there later in the list.

21:01 >> Beautiful. All right. I agree.

21:02 I think it's important to know your goals and there's a lot of reasons why people get into programming.

21:08 >> Yeah, the 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 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.

21:30 >> Well, and you also might look out and say, "Okay, what framework do I need to choose?

21:34 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?

21:46 You're like, I need to start checking the big boxes.

21:48 Let's check those boxes so I can get a job in six weeks.

21:50 >> Yeah. All right. Tip number 2.

21:52 >> Yeah. Tip number 2. What do you got?

21:53 >> Have a project in mind.

21:55 Whatever your goals are, having a specific project in mind, helps put everything else in context.

22:01 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.

22:08 I live in Southeast Alaska.

22:09 And one of the impacts of climate change here is an increasing frequency and severity of landslides.

22:15 And so Southeast Alaska is a rainforest.

22:18 For anybody who isn't aware of that, it's not all snow in Southeast because we're right next to the ocean.

22:23 And so we're still getting as much rain as we always have.

22:26 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.

22:32 We just had two or three weeks of no rain, which was really unusual here.

22:36 But we'll get heavier fall storms that can lead to landslides.

22:41 And so I had a project that monitored a local river's level to correlate that with landslide risk and helped develop a warning system.

22:51 And so a project like that in mind, that's a big project.

22:55 And so if somebody is just learning Python, that's hard to say, like, here's everything you need to know to build that project.

23:01 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.

23:12 >> Yeah, absolutely. 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.

23:26 >> Yeah. There's an infinite number of projects.

23:30 If you have a project in mind, being clear about that with yourself and with any way that you're learning with or from is really helpful as far as tailoring what you're learning to your purposes.

23:41 >> I'm curious.

23:42 >> It's always easier to teach somebody who has a specific goal in mind than somebody who is just vague.

23:46 Just teach me something.

23:47 >> Yeah. Well, because it's focused.

23:49 >> Yeah.

23:49 >> Right? I find a lot of people try to boil the ocean metaphorically when they're trying to learn these things.

23:54 Like, well, I saw somebody saying, "Well, all these CS topics are really hard for me.

23:59 People keep telling me all these CS things I need to know, and do I really need to know them?

24:03 Well, maybe eventually, but not all at once.

24:07 What are you doing now?

24:09 How big is your program?

24:11 You really need testing.

24:12 Maybe you do, maybe you don't.

24:13 Do you really need classes?

24:14 Maybe you do, maybe you don't.

24:16 Do you need generators? Do you need anything?

24:17 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, then I'll be motivated to learn them.

24:25 When you have these projects, You could say, I need these five things or I need these four things.

24:30 I need to know them and then my project is working, instead of trying to say, well, what do I start with even?

24:36 >> Yeah. One of the criticisms of many learning resources, and I'm a little sensitive to this because I've written many of these examples is when people do a for loop and the for loop is about kinds of pizza or something, or toppings of pizza, and people look at that and say, "Why do I need this?

24:51 I don't care about pizza toppings." You need that because the person creating the resource has to have some kind of context for the example.

24:59 When I'm teaching a class in person, I don't come up with, "All right, we're going to do pizza toppings." I ask people in the class, "Hey, what are you interested in?" Then we pick something that somebody in the class that day mentions and then there's relevance right there.

25:13 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.

25:25 So knowing that project is really helpful regardless of how you're learning.

25:30 >> Yeah. Let me pull up another comment.

25:31 I think this is worth covering for people as well.

25:33 So Bishnyadar says, "For me, it was all good while I was learning programming Python.

25:38 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.

25:43 Suggestions. What do you think?" >> Oh boy. I don't think there's an easy answer to that.

25:48 I think it's important to be honest about that.

25:50 Personally, I have never worked as a full-time programmer.

25:55 That puts me in a weird spot for talking about things like career transitions.

25:59 I've helped thousands of people make career transitions, but I don't sit in the interviewee chair.

26:05 >> Yes, I hear you.

26:06 >> Not very often. 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.

26:16 >> Yeah. The time frame of teaching jobs is so weird.

26:19 It's like there's a time once a year often that you can apply or change jobs and otherwise you can't.

26:26 It's not exactly true, but generally true.

26:28 >> Yeah. I'm in an interesting position now where I'd like to work as a professional programmer.

26:32 But honestly, I have to spend 10-20 hours a week supporting the book that LTS stuff is hard-coding.

26:39 >> I know. I got a bunch of courses and stuff.

26:41 I know. I was just redoing some videos that had a mistake and then somebody noticed.

26:46 >> Anything I do is on top of that work.

26:49 I can really only consider part-time work and then it becomes a, is this worth it?

26:53 So to be more direct, I don't think there's an easy answer to the grind of looking for work.

27:00 And as that network thing of once you have a job, it can be easier to find the next job.

27:04 The couple of things I'll share for people is, if you, so we talked about solving real world problems.

27:10 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.

27:20 You can pass whatever LeetCode tests or screenings are necessary, but also have you used what you've learned about programming to solve something.

27:28 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.

27:39 And that becomes a huge selling point in interviews.

27:42 My favorite story is a guy who was working for, I believe it was UPS, and this was quite a while ago, and I feel comfortable telling that story, partly based on time.

27:49 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.

27:58 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.

28:12 That was really interesting story because the people being fired were not the people who are causing the damage.

28:18 They caused a physical damage, but it was-

28:20 >> Right, but it was more systemic.

28:23 >> Yeah. That person save their company millions of dollars and they got a $5,000 a year raise.

28:28 What they really did was they used that story in interviews to gain an actual programming position at a different company.

28:37 It's hard when you're starting out.

28:40 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.

28:49 >> I have one more thing to add.

28:50 A lot of times when people are looking for their first programming job, they have experience somewhere else.

28:55 I realized some people are young, they learn programming and that's their totality of work experience.

29:01 But a lot of people maybe studied something else and became a programmer, like you studied physics, embrace that.

29:06 So imagine you studied logistics.

29:10 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.

29:16 Because then you can say, I have programming skills plus I have an expertise in your area of specialization.

29:22 Once you intersect those things, you earn a much smaller set of editors.

29:27 I'm looking for a biology job, there's a ton of people doing biology.

29:30 If I'm looking for a programming job, there's a ton of people doing programming.

29:33 How many are doing biology and programming, maybe in the specific area that you're focused in?

29:40 That all of a sudden gives you an opportunity, But it also means you need to look somewhat differently for jobs, right?

29:46 You don't go apply to FANG the same way that everyone else thinks they should apply to FANG.

29:51 Look for these small companies because not only will they appreciate it more, you'll get a better chance to grow because you'll get a bigger responsibility to write more broad software.

30:00 The interviewing process is not nearly as terrible, I think, for small companies, right?

30:05 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, they've got these pretty horrible.

30:16 Here's your take-home exercise, write it.

30:18 We'll consider it if it works out well, maybe amongst the other thousands.

30:22 It's like a really different experience.

30:24 I think that first step in the door, that first job is the one that is hard to get.

30:28 >> Yeah. I'll throw one more piece in there and it's a quick thought, and that is contributing to open-source projects is something we need to be careful about, because oftentimes it's privileged work.

30:37 You have some extra time and you can do that.

30:40 But one of the real benefits of making meaningful contributions to establish open-source projects is it throws you all the way into professional workflows of managing, using source control and just the bigger piece communicating with a larger team.

30:56 >> Yeah.

30:56 >> As I've gotten more into open-source, for me that scratches that itch of wanting to work as a professional programmer.

31:04 >> Sure.

31:04 >> I can clearly see.

31:05 >> It's hard to simulate.

31:06 Yeah, it's hard to simulate proper CI/CD merge conflict, PR discussions on your own little hobby project, that's for sure.

31:17 This portion of Talk Python to Me is brought to you by Sentry.

31:20 You know Sentry for their error tracking service, but did you know you can take that all the way through your multi-tiered and distributed app with their distributed tracing feature?

31:29 Distributed tracing is a debugging technique that involves tracking requests of your system starting from the very beginning like a user action, all the way to the backend, database, and third-party services.

31:40 This can help you identify if the cause of an error in one project is due to the error in another.

31:45 Every system can benefit from distributed tracing, but they're especially useful for microservices.

31:50 In this architecture, logs won't give you the full picture, so you can't debug every request in full just by reading the logs.

31:57 Distributed tracing with a platform like Sentry gives you a visual overview about which services or called during the execution of certain requests.

32:06 Aside from debugging and visualizing your architecture, distributed tracing also helps you identify performance bottlenecks.

32:12 Through a visual like a Gantt chart, you can see if a particular span in your stack took longer than expected and how it could be causing slowdowns in other parts of your app.

32:21 Learn more and see some examples in the tracing section at docs.sentry.io.

32:26 To take advantage of all the features of the Sentry platform, just create your free account.

32:31 And for all of you, talk, Python listeners use the code talk, Python, all one word, and you'll activate a free month of their premium paid features.

32:39 Get started today at talkpython.fm/sentry-trace.

32:44 That link is in your podcast player show notes and the episode page.

32:47 Thank you to Sentry for supporting Talk Python to me.

32:50 So we're number two, we'll cover, get a project.

32:55 Yeah, we can go through some of these a little faster.

32:57 Yeah, no, of course we can.

32:58 I got what's number three.

32:59 Number three is don't limit your learning to what's needed for your project.

33:02 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 like 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.

33:20 And learning is fun.

33:21 Learning in good ways is fun.

33:22 Learning with good resources, with good people.

33:25 You want to learn, you want to learn FastAPI.

33:27 Here's your FastAPI worksheet.

33:28 The answers are in the back.

33:29 Yay.

33:30 Jeez.

33:31 I have a kid in middle school, so we shouldn't talk about worksheets.

33:36 But a quick example is I'm working on a project called Django Simple Deploy that automates deployment for projects in Django.

33:43 It's not just for beginners.

33:45 When Heroku collapsed its free tier a couple years ago, we saw a bunch of very experienced Python web people en masse go look at other platforms.

33:54 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.

34:03 And so this tool is a core command, manage.py simple deploy, and then you name the platform and it configures your project for that platform, and then you can push it.

34:14 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.

34:23 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.

34:33 And so when this project is becoming, 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.

34:44 And so if I hadn't, or I should say this 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.

34:59 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.

35:06 >> Sure. One of the ideas I think is really powerful is that inspiration is perishable.

35:13 If you are inspired about something, you might not be that inspired in a couple of weeks.

35:18 That doesn't mean it's not cool anymore, that just means you moved on, your focus is elsewhere or whatever.

35:24 Yeah, sure, you need to learn the things you need to learn to do your project or to check some boxes.

35:30 But if you find something like, I am really interested in that, leverage that inspiration.

35:36 I don't know about other people, but for me, I'm two or three times more productive in learning and writing code and all sorts of things, if I'm really on fire about something versus like, guess I'll get in there and like fix that bug and like something that I'm not inspired about as MailChimp just changed their API and deprecated their, you know, shut off their old one. So now I have people on my mailing list, I got to go rewrite that. There's no, I, 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 like, oh, there's this new feature in Python 3.12, or there's this new package that I found on PyPI, that's awesome. Like, I just really want to like, leverage that, right. But while it's, while it's there, Take advantage of it.

36:18 >> All right. Number 4.

36:19 >> Yeah, number 4. What do we got?

36:21 >> Read good code.

36:22 This is one of those things that I wish I had been told a lot earlier in my programming career than I was.

36:29 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.

36:41 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.

36:48 I think it's probably around the time when a lot of code became very visible through platforms like GitHub.

36:53 But if you're using a library like say, pandas, that is out in the open.

36:58 Rather than just using pandas functions, you can go look at the code that runs that function.

37:06 I shouldn't say pandas because I'm just starting to get more fluent with that, more comfortable.

37:11 I'll say like Matplotlib.

37:13 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.

37:19 You see the full set of arguments that it can take.

37:22 You see all of its capabilities.

37:24 And you see how the people writing and maintaining matplotlib take your information and turn it into a plot.

37:30 And when you look at that code, you're seeing professional quality code.

37:34 It can be overwhelming.

37:35 There's probably going to be parts that you understand and parts that you don't.

37:39 But the more you look at it, the more you understand and you start, your code becomes better because you're seeing high quality code.

37:44 It's good to recognize that those people writing that did not write that polished code the first time they wrote the scatter function.

37:51 So don't think I'm a bad programmer because my code doesn't look like this.

37:55 The polished code that we look at from large popular well-established frameworks has been well-refined.

38:01 So it's something to aim for.

38:02 >> Yeah, it totally is.

38:04 It's one of those things that's hard to get experience with if you're not yet working as a professional developer or even if you are, but you're a one to two person shop or you don't collaborate a lot.

38:16 >> Right.

38:17 >> It doesn't have to be that you're not working as a pro, working as part of your job in that.

38:23 It could be that you just don't have enough collaboration or enough people.

38:27 >> Yeah.

38:27 >> Yeah.

38:27 >> A good thing.

38:28 >> So good advice.

38:29 >> It could be hard to know where to look.

38:30 All right. So if I look at the Python source code, giant, I have no idea where to look.

38:34 Look at the most recent commits.

38:35 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.

38:44 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.

38:53 What are the hardest problems that people are wrestling within in some of these projects that we all use?

38:58 >> 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 percent faster, and people will appreciate that.

39:18 We're going to do that.

39:20 Whereas, there's a tier below that of open-source things that are professional level, but not yet beyond approachable.

39:27 >> Yeah. I did two newsletter posts recently about exploring recent Python repositories to get at this exact issue.

39:35 The idea if you're looking at contributing to Django, it's hard. 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 code bases. 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.

40:00 Yeah, don't have all this, this long term stuff. And so I ended up actually contributing to one of those projects, because it's just what you described earlier, just pulled me in and fascinated me.

40:10 It's so nice to have some concrete contributions to a project that is in that fresh stage.

40:14 >> Yeah, that's fantastic. All right, what's the next one?

40:17 >> Know your tools.

40:19 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.

40:28 I used to, my priority was 98 percent teaching and 2 percent programming, Now I'm probably 60 percent program, 40 percent teaching.

40:37 Tools for teachers are terrible.

40:39 Teachers, public school teachers still write most of their lesson plans in Microsoft Word.

40:44 That sounds like, oh gosh, they just have to write out onto a blank page.

40:48 But what it really means is we as programmers are used to working with structured data.

40:53 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.

41:02 We have tools that manage restructuring projects.

41:05 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.

41:14 I'm grateful as a programmer to have things like IDEs, formatters, linters, Git, any version control system, GitHub, hosting platforms.

41:24 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 then just take a little time to focus on that tool itself.

41:44 So if you've been using VS Code for six months, spend three days and just read about configuring VS Code.

41:50 You'll almost certainly come up with some things that make your day-to-day work more efficient, more effective, more enjoyable.

41:57 Every time I've taken time to do this, I've come out better for it.

42:00 >> Yeah, whether it's VS Code or PyCharm, they both have a ton of options that you can pick from.

42:06 They're discoverable or less discoverable in different ways.

42:09 PyCharm makes it obvious what all the things it can do, but there's so many things that people are like, "Well, I'm just going to stick to my lane, 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 because it's like the Command-Shift-P to pull up the palette and then like, "Well, it's a huge list. What I do with this?" >> Yes.

42:30 But they're being really good with your editor.

42:33 I know some of the things that are coming as well in your list, this adds on top of it, but it makes a huge difference.

42:39 It makes things like being comfortable navigating your code, feel better, testing your code, changing your code, doing some of these workflows you talked about, like Git and PRs, all of that stuff.

42:51 All of those things are in those tools plus way more.

42:54 That's not even talking about the extensions or plugins that you might go after.

42:58 But it's easy to see, well, I've fired it up and now it's an editor.

43:04 It's a thing and it has cool autocomplete, and then just forget about the 100 other things that it can help you with.

43:10 >> Yeah. Particularly with IDEs, they do a lot for us.

43:13 That can be a good thing and it can be a bad thing.

43:16 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.

43:24 Because the tools like VS Code, PyCharm and whatnot, when everything's working, what they do for us is fantastic.

43:31 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.

43:37 Particularly, that comes down to things like tools that build virtual environment for a new project for you.

43:42 If you understand what that's doing, and it stops working, you can go troubleshoot it.

43:46 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.

43:53 >> Virtual environment seems to be just like, >> They just go wrong so often.

43:58 >> Yeah.

43:59 >> I'm not in the pure, I've created one on the terminal and I've acted, that's solid.

44:04 >> Yeah.

44:05 >> In the tooling, it's like sometimes it finds it, sometimes it doesn't, sometimes it really doesn't want to find it.

44:11 It's nuts.

44:12 >> Yeah. I'm glad you brought that up.

44:14 The core advice there for me has always been, people have a tendency to want to go find another editor or IDE that's going to manage that better.

44:22 When I tell them, it's no, it's going to manage it differently and you're going to run it to the same issue and then you're going to need to solve it.

44:27 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.

44:36 >> All right. What's next?

44:37 >> Learn how to test your code.

44:39 I wrote here, you won't sleep more, but your sleep will be more restful.

44:44 I went probably 20 years programming without ever writing a test.

44:48 I always had this notion that it was difficult, it was separate from programming.

44:52 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.

45:00 I love testing.

45:01 It's probably my biggest interest these days beyond deploying Django projects.

45:06 I love it because when we write code, we want it to work.

45:09 When we have a project, we want our project to be successful.

45:14 Testing validates that.

45:16 Testing gives you confidence that your project is working correctly, and if you fix a bug, you just fix it once.

45:22 So testing is its own podcast for some people.

45:26 So I'll just say that testing is easier than a lot of people think it is.

45:29 Go use pytest.

45:30 I used to teach unit tests because it's in the standard library, but pytest has become well-established enough.

45:36 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.

45:44 It's the best way to be introduced to testing, and if you're testing professionally, there's no tool better than that.

45:51 the zen of Python, right? That it's really serves beginners well, but also experts well.

45:55 I think that's one of its special capabilities.

45:58 Yeah, I will encourage people and Michael, I'd be curious if you agree with this or not.

46:03 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.

46:20 That's just saying, does your project work?

46:22 And so the project I've been pulled into recently is one called git sim, git hyphen sim, and you run it against your own project and it gives you a visualization of all your commits.

46:32 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.

46:42 And so that project is newer and it had no tests.

46:44 And so I helped write the initial test suite.

46:47 And I said to the person, like we shouldn't test your implementation 'cause 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 gonna see are the ones that you think that you've been seeing and you think they're gonna see.

47:08 And so that's really nice because you can, you don't have to aim for 100% coverage of your code.

47:14 you just start to get that big picture.

47:16 Yes, my project is still doing what I think it's doing.

47:18 That makes for better sleep and all of your non-computer activities are more enjoyable because you have more confidence that things keep working.

47:25 >> Yeah. I'm with you on not going too far down the unit test side.

47:29 I used to write tons and tons of very low-level focus unit tests.

47:34 When I was on a team, I always had a hard time having everybody have buy-in.

47:39 Some people would, some people wouldn't.

47:41 They'd go do something that would break the test.

47:43 You know, like you broke the bill.

47:45 They're like, Oh yeah, I guess, I guess I did.

47:47 You're like, you realize that we don't all participate in this.

47:51 It just becomes a hassle for me, like chasing after trying to like patch up the tests as you, you make these changes.

47:58 And as you're more focused, as you're like lower level in the world, that's just a more constant problem.

48:04 And it also requires more effort, right?

48:07 So maybe that effort is worthwhile, but if, if you're new, maybe it's not.

48:10 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.

48:17 And if that stuff hangs on, we got a real good chance.

48:21 And over time, my experience has been for the most part, it's things blow up hard.

48:26 They don't just like, oh, there's some little subtle problem.

48:29 Generally, not always true, but generally, like if I screw something up, a lot of tests start failing even when they're these high-level things because something's pretty, pretty messed up.

48:38 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.

48:47 They just changed some implementation detail and they weren't being sufficiently rigorous with their software lifecycle.

48:54 So yes, I'm on board.

48:56 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.

49:06 just go get the sitemap and request every page.

49:09 Does it give you a 200 or does it give you a 500 or a 404?

49:12 As 404s and 500s should not be found in your sitemap.

49:16 But that's a really easy test.

49:19 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.

49:27 That's one thing you could do that's in that category.

49:30 >> As an author, I wrote tests for most of the code in Python Crash Course.

49:34 And so Python Crash Course was first written, I think, on Python 3.5.

49:38 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.

49:45 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.

49:51 And it pulls the test, pulls the code from the GitHub repository for the book, and just runs it with the new versions.

49:57 And that's been part of how I've been able to maintain into the upkeep and maintenance on a 500-page book that covers a lot.

50:05 - Yeah, yeah, that's awesome.

50:07 - Yep.

50:08 - Let's keep going.

50:09 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.

50:14 - Yeah, yeah.

50:15 Last comment about testing.

50:16 I love it because I think that when you test your code, you learn things about your code that makes development better as well.

50:22 So it's not just does it work?

50:23 It also gives you insight into how your code is working.

50:27 I'm looking forward to exploring more.

50:29 All right, next point, know what's good enough for any given project.

50:33 As a teacher, students would say like, am I done, am I done, is this good enough?

50:37 And I watch other teachers say, like, don't ask me that, always work harder.

50:42 And I always tell the students, that's a great question.

50:44 What is good enough?

50:46 And so whatever your project is, knowing your benchmark for what's good enough and when it's done, when you can move on to the next thing is really helpful.

50:53 'Cause you'll never write perfect code, but you can certainly write good enough code.

50:56 - 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.

51:07 So it was something along those lines, right?

51:08 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.

51:21 Your app that manages reporting for managers that you're at your company, there's five managers and they do it once a week.

51:29 You don't need global scale out techniques.

51:32 You don't need the zero downtime that containers offer.

51:36 You don't need load balancers.

51:38 Like none of that stuff applies to you.

51:40 And so in fact, I would say, if you start applying those things to it, you make your application harder to deploy.

51:47 You make it harder for other people and your team to work on.

51:51 You make it less good for that situation.

51:53 But at Google scale, the opposite is true.

51:57 It's less good if it doesn't have those things.

51:59 And so it's not just, well, this is a crappy project, so it gets crappy level CS attention.

52:06 It's a small project, so it can be written and managed and worked on in a way that allows for, you know, optimizes for small teams, not worry, not optimize it for uptime and all those kinds of things, so that you can make it work better in that situation.

52:23 And so I totally agree, knowing what is good enough is super important, but what is good enough, it's not like a spectrum.

52:30 Like I'm at the really good level.

52:31 It's like, you've got a, it's a multidimensional thing.

52:34 Like you're at a good level for the context that you're in, the situation you're in.

52:37 - Hey, you're walking right into bullet point, or tip number eight, I think it is.

52:42 - We are.

52:43 - Yeah, and that's embrace refactoring.

52:44 And so my notes about this was that good enough is situational.

52:48 So when a project proves it's 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.

52:59 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.

53:06 But if that product has started to gain interest, now good enough moves.

53:11 And so maybe it needs to be more efficient.

53:13 Maybe it needs more testing.

53:15 Maybe it needs to be deployed in a different way.

53:16 And so refactoring tied in with that idea what is good enough is the road for evolving a project.

53:23 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.

53:36 >> Yeah, I'll say that.

53:36 >> I love refactoring.

53:36 >> I love refactoring your tools.

53:37 >> Yeah, I do too. I think it's fantastic.

53:40 So many people who are getting started will tell me things like, "I'm not sure how to get started.

53:45 I don't know what the best way to do this is.

53:47 I'm thinking about it and I've tried something, but I wasn't sure so I went back to thinking.

53:53 The best way to get started is just give it a shot, just create something.

53:57 You'll learn what of that is working and what is not ideal.

54:01 More importantly, something that's awesome about software is it's plastic.

54:04 You can change it, plastic in the soft plastic way.

54:07 You can evolve it as you learn more about it.

54:10 I go, I thought that should have been separate module, but this should be just part of that class.

54:15 We're just going to 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.

54:23 I think that's maybe it sounds counterintuitive, but I feel like that's an expert perspective.

54:28 It's like, I think I need to go that way.

54:30 We're going to start down the path that way and we're going to evolve and 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?

54:42 >> This is part of why this is not a countdown.

54:44 Because for example, if you have even a small set of tests, the test your final output.

54:49 Refactoring is easy.

54:51 It's fun because if your test break and you don't like the idea, you can go back to where you started.

54:56 >> Another fun thing about refactoring is the whole concept of code smells.

55:00 I think becoming an expert, there's a lot to be learned from the code smells.

55:04 The idea of the code smells is the code works, but there's something a little bit off.

55:09 It makes your nose turn up.

55:10 You're like, "Oh, okay.

55:12 Yeah, I guess it works, but oh, right." It's just an ooh.

55:17 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.

55:23 And having that intuition, I think is great.

55:26 So some of the code smells are like long method, method with too many arguments.

55:31 One, probably my favorite is code comments because you hear you should comment code all the time and there should be places that need a comment, there should be comments or help strings, whatever.

55:42 But a lot of times, Code comments are deodorant for these code smells, right?

55:48 It's like, oh, this is kind of gross.

55:50 Let me make a comment about why it's gross.

55:52 Or this is poorly named.

55:54 People won't know what this is.

55:55 So let me make a comment about what it is.

55:57 And like halfway through that comment, you should realize like, oh, what if I just named it?

56:01 The thing I'm trying to tell people it kind of does.

56:05 Then I don't even need a comment 'cause it has a really good name that is its own thing, right?

56:09 And 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, maybe you could just apply some of these refactoring techniques to make them better.

56:22 Not going into a whole refactoring detail, but I really, really like this idea.

56:27 - Yeah, I write a lot of exploratory code, so you're describing a lot of my work.

56:31 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.

56:38 - Yeah, sure, sure.

56:39 Well, and those things don't necessarily start out that way.

56:42 long method didn't necessarily start out long.

56:44 - Mm-hmm.

56:45 - Grew and grew until it was a monster.

56:47 Same thing with too many arguments.

56:49 It probably started out with one or two, but then now we need this other one.

56:52 And what about that?

56:53 And then all of a sudden it's like, again, a monster.

56:55 Right, and so it's an evolution.

56:57 - And it's long because it works.

56:58 And so at some point you pause and cleaned it up, make sure it still works.

57:02 All right, number nine, write things down.

57:04 - Yeah.

57:05 - Write things down.

57:06 And I don't say that as a writer.

57:07 Writing for me, I started writing when I was young because I saw somebody else write a journal and it's like, oh, I'm going to try writing.

57:13 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.

57:23 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.

57:32 My suggestions are things like keep an ideas notebook.

57:35 Those are, once you know how to build things, ideas come to you and you're like, oh, I could make that at some point.

57:40 If you have a place to record those ideas, when you're not sure what to do, you can go back to it.

57:45 Write comments, despite what Michael said.

57:47 Comments in a professional, well-established project with many collaborators are different than comments for your own new projects.

57:55 Whatever you're doing, write comments.

57:58 Do put the information in that needs to be in there to work, let them be cleaned up.

58:02 >> Yeah. I don't mean to say you shouldn't write comments.

58:04 There's a lot of times where the point of the comment is to-

58:07 >> Yes.

58:08 >> -justify why something's bad.

58:10 If that's the case, it probably doesn't need to be bad.

58:13 But if it's help docs, if it's like, well, here's the different stuff that you can pass and these are what we expect, there's certainly valid comments, no doubt.

58:20 >> 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.

58:26 Learn to write documentation.

58:28 If you write an ideas notebook, if you write comments, documentation flows out of that.

58:32 It just becomes a more polished version of what you're writing.

58:35 Write questions down when you're not sure about something.

58:37 GitHub issues are amazing.

58:39 I haven't used project management software because GitHub issues are so useful.

58:44 >> No Gantt chart, no Microsoft project.

58:48 >> 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.

58:59 >> Writing helps you crystallize your thoughts and make sure you have them all coherent, right?

59:03 >> Right. Last one, big tip, and this is a fun one to close on, go meet people.

59:08 It has long been said that I, about Python, that I came for the language and stayed for the community.

59:13 People have talked about that for years because it's still true.

59:16 Join online communities, go to local, regional, national, international conferences when you can, go to coffee shops, ask questions, tell stories.

59:25 You will meet good people like Michael.

59:27 >> And you, as we met at PyCon.

59:30 So I think this is really good advice.

59:32 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?

59:45 >> Yeah. I lived in New York City for seven years before I moved here.

59:50 >> Right. As a contrast, right?

59:51 >> Yes. But most of my programming work, serious programming work has been done while I've lived here.

59:58 Yet, I don't know anybody else here who programs.

01:00:00 For me going to conferences, I talk about programming the entire time at conferences because I never get to in regular life.

01:00:07 >> Honestly, that's true for me as well.

01:00:08 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.

01:00:15 Because I don't go to a company where I have a team of developers.

01:00:19 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.

01:00:26 I think this is the story of more people than just if you live outside of some big metropolis.

01:00:33 Yeah, yeah. Quick story. First time I went to PyCon, I was intimidated because I was a teacher and not a programmer.

01:00:39 And so I thought I would not find my place.

01:00:41 And I walked into the hotel the first night and people pulled me right into conversation.

01:00:47 And what I found was that roughly half the people who go to PyCon are primarily programmers looking for what to work on.

01:00:53 And roughly half the people are people who care about some other domain than programming.

01:00:57 And they're looking to use Python and programming to solve the problems they care about in their domain.

01:01:02 It's true, everybody has a place in the Python world, if you are respectful and appropriate to other people.

01:01:08 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'll find your place, and it's magic.

01:01:18 >> Yeah. I think, hopefully I'm not misremembering this.

01:01:22 I think almost half the people at PyCon this year were first-time attendees.

01:01:26 If you're thinking, "No, I shouldn't go." >> No, it was like 70.

01:01:29 >> It was over half.

01:01:30 >> It was like 80 percent.

01:01:31 >> Yeah. I was amazed.

01:01:33 >> 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.

01:01:43 So maybe they were more icon curious folks than say the people who had been there for the last 10 years.

01:01:48 Like I still want to skip this one.

01:01:50 I will see where it shapes up, but 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.

01:02:01 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, like probably the opposite.

01:02:09 - Yeah.

01:02:10 - You know?

01:02:11 - Yeah, you end up with lifelong friends.

01:02:13 - Absolutely.

01:02:13 People are in a great mood.

01:02:14 They're on their geek holiday.

01:02:16 It's all good.

01:02:17 - Yes.

01:02:17 - It's pretty easy to make friends and have a good time there.

01:02:20 So that could be PyCon or EuroPython or something like that.

01:02:24 Or it could just be a local.

01:02:26 There's a lot of regional Python meetups like PyCascades here in the Pacific Northwest, PyTexas, PyOhio, all these things.

01:02:33 And none of those work for you.

01:02:35 You know, there's forums like this, to be honest.

01:02:38 Like, part of the reason I created the podcast was to get to know people better in a way that I knew wouldn't be possible for me, right?

01:02:46 My goal was, where do I go find the podcast to listen to to do this?

01:02:50 And then there was none.

01:02:50 So I was like, all right, fine, I'll create the podcast so we can do this.

01:02:53 But my intent was just to listen to a podcast to kind of get to know people like this.

01:02:57 it's a pretty one-way conversation as a podcast listener, not 100% as people have seen in the audience, but it's still valuable to like eavesdrop in a sense on these conversations if you're a new person.

01:03:09 - Right, absolutely.

01:03:11 - Yeah.

01:03:11 All right, Eric.

01:03:12 Well, what a fun conversation.

01:03:13 Thank you for the awesome list.

01:03:16 And hopefully you've inspired a lot of people out there to make forward progress on this journey that they're on.

01:03:23 - Well, thank you for having me.

01:03:24 I've listened to you for a long time and really enjoyed your work and very happy to connect.

01:03:28 - Yeah, same here.

01:03:29 So final call to action.

01:03:30 People are interested, you know, maybe tell them how to check out your book, tell them how to put some of these ideas into action.

01:03:36 - My book is "Python Crash Course" from NoStarchPress.

01:03:39 Third edition came out this year, and so everything works.

01:03:41 It's good, I keep it updated.

01:03:43 If you buy it, you get a copy with the newest updates.

01:03:46 Yes.

01:03:47 I also write weekly at MostlyPython, and that's mostlypython.substack.

01:03:52 There are paid subscriptions, but there are also free subscriptions.

01:03:54 And so the only advantage for paid subscriptions is that some posts are locked for six weeks.

01:04:00 Everything I write, I want to be available to everyone.

01:04:03 And so if you're curious about what I'm thinking about on a weekly basis, mostly Python.

01:04:08 Excellent.

01:04:09 All right.

01:04:10 Well, thanks again for being here.

01:04:11 See you later.

01:04:12 Thanks everyone for listening.

01:04:13 Yes.

01:04:14 Thank you.

01:04:15 This has been another episode of Talk Python to Me.

01:04:18 Thank you to our sponsors.

01:04:19 Be sure to check out what they're offering.

01:04:21 It really helps support the show.

01:04:23 GlareDB is an open source database for querying distributed and disparate data.

01:04:28 Connect your data sources and use the Python tools you already know to ask questions and integrate data across data sources.

01:04:36 Get started today at talkpython.fm/glaredb.

01:04:40 Take some stress out of your life.

01:04:41 Get notified immediately about errors and performance issues in your web or mobile applications with Sentry.

01:04:47 Just visit talkpython.fm/sentry and get started for free.

01:04:52 Be sure to use the promo code Talk Python, all one word.

01:04:56 Want to level up your Python?

01:04:57 We have one of the largest catalogs of Python video courses over at Talk Python.

01:05:01 Our content ranges from true beginners to deeply advanced topics like memory and async.

01:05:06 And best of all, there's not a subscription in sight.

01:05:09 Check it out for yourself at training.talkpython.fm.

01:05:12 Be sure to subscribe to the show, open your favorite podcast app, and search for Python.

01:05:16 We should be right at the top.

01:05:18 You can also find the iTunes feed at /iTunes, the Google Play feed at /play, and the Direct RSS feed at /rss on talkpython.fm.

01:05:27 We're live streaming most of our recordings these days.

01:05:30 If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.

01:05:39 This is your host, Michael Kennedy.

01:05:40 Thanks so much for listening.

01:05:41 I really appreciate it.

01:05:43 Now get out there and write some Python code.

01:05:45 (upbeat music)

01:05:47 [Music]

01:06:02 (upbeat music)

01:06:05 [BLANK_AUDIO]