Getting started in Python is pretty easy.
There's even a t-shirt that jokes about it.
I learned Python. It was a good weekend.
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?
On this episode, we welcome Eric Matthews to the show.
He has thought a lot about teaching Python
and comes to share his 10 tips for going from Python beginner to expert.
This is Talk Python to Me, episode 427, recorded July 19th, 2023.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy,
and follow the podcast using @talkpython.
Both on fosstodon.org.
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 GlareDB.
GlareDB is an open source database for querying distributed and disparate data.
Connect your data sources and use the Python tools you already know to ask questions and
integrate data across data sources.
Get started today at talkpython.fm/GlareDB.
And it's brought to you by Sentry.
Don't let those errors go unnoticed.
Use Sentry.
Get started at talkpython.fm/sentry.
Eric, 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.
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 sort of moving towards, you know, 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.
When it was all about the go-tos?
Yes.
Line 10.
Go to 10.
What is your number?
Yeah.
Exactly.
Yeah.
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 big claim.
But I tried to end 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.
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 and thinking at first, like, it's kind of a weird, interesting,
but weird language.
It's white space 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.
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 how 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 parentheses?
And, you know, all those things, you're just like, what?
What a hassle.
Not even the static typing, just the, just the syntax is more syntaxy.
And I'm kind of 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,
in the points that we go over.
I'll share though that for my background, that's one of the big piece that, that plays
into all this.
I, I went into college, into undergrad, focus 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 want to 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 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 would, 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 and 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 because the book I wished to teach from did not
exist.
Sure.
I know how that feels.
Yeah.
What's the title of the book?
Share that with everyone.
That is Python Crash Course.
No starts, right?
Yes.
From no starts.
And it's been the bestselling introduction.
It's been the bestselling 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'm going to do all this work, then I should support the book for 10 year period.
And so it's been very satisfying to see it be meaningful to so many people over that.
Yeah.
That's really awesome.
So your book is in like LTS, long-term support.
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.
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 it really, you know, probably have stories to tell you about it.
Yeah.
It was amazing.
You know, 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.
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.
And as a teacher says, I'm glad to say I've read that book and learned a lot from
it.
Yeah.
Very cool.
Yeah.
I'm glad I worked for you.
Yeah.
I was going to say, you know, as a teacher.
Yeah.
I have always been happy for my students to end up better at whatever I introduced them
to than I am.
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.
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
are 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, interesting topic.
And I think it's one that really deserves some attention.
I think it does too.
I think I hear for so many times from beginners, like I'm learning the language or I'm learning
this or I'm learning that.
And now I just don't really know what to do to keep making progress.
Right.
And you mentioned your situation where you are sort of a hobbyist programmer to some degree.
Right.
And you just compared it against people who are, you know, maybe scaling out some DevOps
thing at like a huge tech company.
Right.
Those are really different ways you spend your day.
Right.
As a hobbyist programmer, you have something you're interested in.
Maybe you, you poke at it a little bit, you work at it, but you don't have the, the real
demands of it's, it's got to work at this crazy scale.
And also that it something you can, can you focus your entire effort on all day.
Right.
Cause you're, you're teaching or you're, you're doing other things besides that.
Right.
As a hobbyist.
Yeah.
And I think that, you know, 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.
Exactly.
And then, you know, when I've looked at say intermediate resources, it's a hard world
to classify and categorize because what is intermediate?
And I think it's good to recognize that in the early days of a language, say like mid nineties
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 and 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.
Those, 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 teacher 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, 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.
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, Molly, 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, you can be focused on one or another.
But right, it's, it's 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 FastAPI?
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, 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 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're 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 write 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.
I mean, 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, and I was going to 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, you know, 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
got to keep in mind, right?
And it's probably good to hear them say like, you're an expert in some things, but not, it's
not like you just know it all, right?
Right.
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?
Like you can still completely rock that.
But maybe you're not embracing the vectorization of style of programming and so on.
This portion of Talk Python to Me is brought to you by GlareDB.
GlareDB is an open source database for querying distributed data.
Here's how it works.
First, you connect your data sources.
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.
This includes Snowflake, Postgres, MongoDB, BigQuery, and object storage.
Now you can query everything.
You use the full power SQL to query your data across these many different data sources, join
data across production databases and analytical warehouses without limits.
Finally, you can use the tools you already know and love.
Visualize and query your data using tools you know from Python's data science stack.
With just a single import, you can query Pandas and Polar's data frames using just
SQL.
You'll be asking questions, extracting insights, and driving decisions with your data without
waiting for an ETL pipeline to move data around.
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.
Visit talkpython.fm/GlareDB to get started.
The link is in your podcast player show notes.
And please use the link to let them know that you came from us.
Thank you to the team at GlareDB for sponsoring the show.
Maybe this is a good time to start talking about the ideas.
So what I did is I said, you know, 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 through the list.
Sure.
I like, first of all, I like that structuring.
I 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 in a program?
And so we see this all the time.
If you follow conversations about learning Python, I want to learn Python.
Okay.
But 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.
And also 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.
Yeah.
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 email anybody has ever written to me about the book.
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 it 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, what's your story?
And a lot of those people are doing career transitions.
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, to live reasonable life.
And what you say, people being tired of a different line of work and looking for something where
they can have more power, more, more independence, more control.
You know, when you say know your goals for most people, their goals, it's 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.
Yeah, it absolutely does.
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 want to 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 is 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 like with a level of understanding rather than copy pasting.
But for a lot of people...
Or now ChatGPT also.
Yeah.
That's a super interesting dynamic to throw into all of this.
But that is the end goal.
It 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.
And Foxo says, I'm an anesthesiologist.
You cannot imagine how much Python has helped me with different tasks.
Amazing.
That's really cool.
Thank you for sharing that.
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.
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?
And 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 you present to them and the pace at which you present material, as opposed
to somebody who says, you know, 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, 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, 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 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 helped 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, that's hard to say, like, 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 you can, it's pretty good at the IoT thing as well,
which opens up a lot of, you know, 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.
I'm curious.
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.
Like 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.
You know, like, what are you doing now?
How big is your program?
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 anything?
Like there's all these things that you probably could say, don't need them now.
Maybe in a year or two, I can.
I will need them.
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
because 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 something, 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 going
to 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 that knowing that project is really helpful, regardless of how you're, you're learning.
Yeah.
Let me pull up another comment.
I think this is worth covering for people as well.
So Bishnielder 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.
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 timeframe of teacher teaching jobs is so weird.
It's like, yes, 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 supporting the book.
That LDS stuff is ongoing.
I know.
I got a bunch of courses and stuff.
I know.
Yeah.
I was just redoing some videos that had a mistake in them that 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 a, 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 as a 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, you have made something better
through programming, what employers are looking for is that yes, you have capability for programming.
You can pass whatever lead code tests or screenings are necessary, but also have you use 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.
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, but 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 really interesting story because the people being fired were not the people who
are causing the damage.
They caused the physical damage, but it was more systemic.
Yeah.
And so that person saved their company millions of dollars and they got like a $5,000 a year
raise.
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 realized 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 like you studied
physics.
Embrace that, right?
So imagine you studied, I don't know, 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 are in a much smaller set of competitors, right?
Like 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, right?
That all of a sudden gives you an opportunity.
But it also means you need to look somewhat differently for jobs, right?
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 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?
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, here's your take-home exercise, write it.
We'll consider it 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.
So as I've gotten more into open source, for me, that scratches that itch of wanting to work
as a professional programmer.
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.
This portion of Talk Python to Me is brought to you by Sentry.
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?
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.
This can help you identify if the cause of an error in one project is due to the error in
another.
Every system can benefit from distributed tracing, but they're especially useful for microservices.
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.
Distributed tracing with a platform like Sentry gives you a visual overview about which services
were called during the execution of certain requests.
Aside from debugging and visualizing your architecture, distributed tracing also helps you identify
performance bottlenecks.
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.
Learn more and see some examples in the tracing section at docs.sentry.io.
To take advantage of all the features of the Sentry platform, just create your free account.
And for all of you Talk Python listeners, use the code TALKPYTHON, all one word, and you'll
activate a free month of their premium paid features.
Get started today at talkpython.fm/sentry-trace.
That link is in your podcast player show notes and the episode page.
Thank you to Sentry for supporting Talk Python to me.
So we're number two.
We'll cover, 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 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.
And learning is fun.
Learning in good ways is fun.
Learning with good resources, with good people.
You want to learn FastAPI, here's your FastAPI worksheet.
The answers are in the back.
Yeah.
I have a kid in middle school, so we shouldn't talk about worksheets.
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 years ago, we 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 simple 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 work together
because I wrote them and they're all nice.
But I had learned about abstract-based classes but never had a purpose for using one.
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.
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.
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, right?
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 know, you moved on, your focus is elsewhere, 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.
Like, you know, 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 is MailChimp just changed their API and deprecated their, you know, shut off their old one.
So now to have people on my mailing list, I got to go rewrite that.
There's no, 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, and I just really want to like leverage that.
Right.
But while it's, 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 scatterplot, 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 you start, 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.
And a good thing.
So good advice.
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 are wrestling with in some of these projects that we all use?
All good advice.
I would say the larger the open source project and the more popular, maybe harder it is to read, you know, because it has to be more polished and more optimized and more, you know, it's just 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, 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.
We don't have all 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.
And 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.
Teachers, public school teachers still write most of their lesson plans in Microsoft Word.
And that sounds like, oh gosh, they just have to like 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 then 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 PyCharm 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 going to 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 because it's like the command shift P to pull up the palette and then like, well, there's a huge list.
What'd I do with this?
Yes, yes.
But they're 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 feel 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 then, 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 like 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.
Yeah.
I'm not in the pure, I've created one on the terminal and like I've acted, like 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.
You know, like it's nuts.
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 going to manage that better.
And what I tell them is, no, it's going to manage it differently and you're going to 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.
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 have the output validated.
I love testing.
It's probably my biggest interest these days beyond deploying Django projects.
And I love it because, you know, when we write code, we want it to work.
When we have a project, we want our project 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 told the person, like, we shouldn't test your implementation because you should
be free to change how you're building this new project, but we should absolutely 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.
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 side.
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're like, you broke the bill.
They're like, oh, yeah, I guess I did.
You're like, you realize that we don't all participate in this.
It just becomes a hassle for me, chasing after, trying to patch up the tests as you make these
changes.
And as you're 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 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, 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.
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?
Because 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, you know, 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, the, the upkeep and maintenance
on a 500 page book that covers a lot.
Yeah.
That's awesome.
Yeah.
Let's keep going.
There's a couple of good comments and questions in the audience, but I think we're on, we're on
a schedule.
So let's keep going.
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's also gives you insight into, into how your code is working.
I'm 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.
Always work harder.
And I always tell the 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 when
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.
And 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.
Right.
And the admonishment or the advice there was, you might read about how somebody like Google
has this, all these containers doing all this scale out and failover and geo location.
Your app that manages like reporting for managers at your app, 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, you know, optimizes
for small teams, not worrying, 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, it's not like a spectrum.
Like I'm at the really good level.
It's like you've got a, 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.
We are.
Yeah.
And 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 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 it didn't, 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 a separate module, but this should be just
part of that class.
So 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.
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 going to 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.
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, it's just kind of an ooh.
And that's, 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.
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, help strings, whatever.
But a lot of times code comments are deodorant for these code smells, right?
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 like halfway through that comment, you should realize like, oh, what if I just named it?
The thing I'm trying to tell people, it kind of does.
Then I don't even need a comment because it has a really good name that is its own thing,
right?
And so four names, too many parameters, all these things are deodorant.
And you're trying to like justify how gross this part of your code is.
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 write 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.
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 pause and clean 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 going to 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 talked 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.
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.
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, let them be cleaned up.
Yeah, I don't mean to say you shouldn't write comments, right?
I just, 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 expect, there's certainly valid comments, no doubt.
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 questions down 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 even if you...
No Gantt chart.
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?
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, yeah, 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 like 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?
So...
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.
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, right?
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, right?
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 I'm 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, no.
It was like 78.
It was over half.
It was like 80%.
Yeah.
I was amazed.
Yeah.
I'm not sure how much of that's a COVID hangover sort of thing, because not there were not
as many people who came as say in 2019.
So maybe they were more icon curious folks than say the people who had been there for the
last 10 years.
Like, I still want to skip this one.
I will see where it shapes up.
But there's a really high number, whatever that that number turned out to be.
And 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, like probably the opposite.
Yeah.
You know?
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 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 knew wouldn't be possible for me.
Right.
My goal was, 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 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.
Right.
Absolutely.
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, you know, 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.
You know, 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.
Well, thanks again for being here.
See you later.
Thanks everyone for listening.
Yes.
Thank you.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
GlareDB is an open source database for querying distributed and disparate data.
Connect your data sources and use the Python tools you already know to ask questions and
integrate data across data sources.
Get started today at talkpython.fm/GlareDB.
Take some stress out of your life.
Get notified immediately about errors and performance issues in your web or mobile applications with
Sentry.
Just visit talkpython.fm/sentry and get started for free.
And be sure to use the promo code talkpython, all one word.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
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.
We're live streaming most of our recordings these days.
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.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
We'll see you next time.
Thank you.