This Author Spotlight is on Python programmer/educator extraordinaire Eric Matthes, author of the international bestseller (now in its third edition) Python Crash Course. In the following Q&A, we discuss how reader feedback shaped the latest edition of his book, why he chose teaching over a career in physics, the importance of applying new programming concepts to your own projects, and what Eric learned about life—and coding—from riding across the U.S. on a bicycle (five times).
Eric Matthes has been writing computer programs since childhood. For over a decade, he was a high school science and math teacher, as well as a Python programming educator. He now lives in Alaska as a full-time author and informal Python evangelist, making appearances on podcasts and at events like PyCon, where he hopes to meet you in person.
No Starch Press (NSP): Almost eight years ago, you wrote what has become the most popular Python programming book in the world. Even with well over a million readers of your work, you’re known for replying to pretty much every fan who emails you. How has such a high level of audience feedback informed the second and third editions of Python Crash Course?
Eric Matthes (EM): When people decide to read a book like Python Crash Course, they’re making a pretty significant commitment. I want to know that when people start the book, they can make it through everything that interests them. So, when someone writes to me about something that’s not working for them, I want to help them if at all possible. The teacher in me can’t help but answer people’s questions.
When I respond to questions, I look for patterns in what people are asking about. When the book first came out and I noticed multiple people asking about the same parts of the book, I’d look at those sections to see how I might revise them to avoid common points of confusion. That feedback from readers helped shape the second edition in particular. Writing the second edition gave me the chance to bring all the code in the book up to date, but also allowed me to clarify numerous sections that weren’t written as well as they could have been.
I also post resources online to address the kinds of things people ask about. For example, I posted a full set of solutions early on, because having solutions available is a huge help to independent learners. I’ve posted recommendations about what resources might be most useful to people after finishing Python Crash Course, and some thoughts about how to find your first programming job. The cheat sheets that accompany the book have been downloaded millions of times.
Overall, I spend about 10-20 hours a week answering questions and paying attention to updates in Python, and all the libraries that the projects depend on. For example, over the last two weeks, I wrote a fully updated test suite for all the code in the book, that makes it easier to test any section of the book against new versions of Python and other dependencies. It surprises a lot of people to hear about all this ongoing work. I think most people assume that once a book is published, the work is done. But this is what keeps Python Crash Course relevant and effective through each new printing, and each new edition. It’s mostly joyful work that puts me in touch with people from all over the world on a regular basis.
NSP: Would you share a little about how you got to where you are today? Specifically, how did you go from studying chemical engineering in college (with plans of becoming a particle physicist) to becoming a public-school teacher and, later, a full-time author?
EM: I had a really good high school chemistry class, so I started college with a major in chemical engineering. But after a semester I changed my major to physics—I just loved the quest to understand the universe at the most fundamental levels.
I loved math and science, but I also noticed how many of my peers hated those two subjects. I joined a volunteer tutoring program and noticed that most of the people who came to us for help enjoyed the same subjects I did—it was just the way they’d been taught that wasn’t working for them. That tutoring work really opened my eyes to the impact of good (and bad) teaching.
I wanted to be a particle physicist, but I didn’t want to be a student forever. I tried teaching and found that the challenge of trying to reach every student in a class was as satisfying as hard science. I never really looked back from teaching. I taught middle school math and science for seven years in New York City and then transitioned to high school when I moved to Alaska.
My father was a software engineer in the ’70s and ’80s, so I learned the basics of programming as a kid. (That was a time when people were just starting to have computers in their homes.) I was a hobbyist programmer all my life, and I’d teach intro programming classes whenever I could. In the early 2010s, I was looking for a book I could give to my more motivated students so they could work at their own pace. I was frustrated to find, however, that every book available back then was either aimed at little kids or made too many assumptions about what people already knew.
I decided to write a book that reflected the way I teach: a focus on just enough fundamentals to start doing meaningful projects. I wrote Python Crash Course for “anyone old enough to not want a kids’ book.” It has met that goal beyond my wildest hopes. When the book first came out, I got a handwritten letter from a 10-year-old who said thank you for writing a book they could learn so easily from. I regularly get emails from people in their 70s and 80s who are finally learning programming to satisfy their curiosity or to keep their minds active. And I hear from everyone in between: high school students, undergrad and graduate students, and a whole bunch of people who are already working but are looking to make a career change. These emails, and conversations at conferences, are the highlight of my writing career.
NSP: Speaking of teaching, your early career in the field is what led to a chance encounter with No Starch Press's founder, Bill Pollock, following a lightning talk you gave at PyCon in 2013 about improving education by taking ideas from the programming world. (Tough crowd!) How did your appearance at the conference result in a publishing deal, and had you been thinking about writing a book at that point in your life?
EM: I first went to PyCon in 2012 because I wanted to do something meaningful with the programming skills I’d been informally building all my life. I was starting to build some tools that would help students navigate school better, and help teachers focus on teaching well. For example, I wrote a program that ingested students’ text-based transcripts, which were really hard to read, and generated a visual transcript for each student. You could look at one of these transcripts and in 30 seconds see what a student’s strengths and weaknesses were, and what they needed to focus on in order to graduate. That project didn’t just save time—it changed the nature of many conferences with students and their families. Instead of focusing on the frustrating process of trying to decipher a transcript, the focus was on celebrating successes and how to meet ongoing needs.
I gave a lightning talk in 2013 about how we could bring the well-established concept of openness in programming into the education world, in a way that goes beyond free software. Bill was in the audience, and he’d been having his own frustrations with the school system at that time. He said something along the lines of, “I like what you have to say about education. If you ever want to write a book, feel free to submit a proposal.” Some early No Starch books had been really influential in my life, so that invitation was compelling. I got my start on Linux by reading Ubuntu for Non-Geeks.
I didn’t really want to write a book, because I was focused on those educational infrastructure projects. But when I got back from the conference, I saw a handwritten poster I had put up in my classroom. It was titled “What’s the least you need to know about programming in order to work on your own projects?” I had listed out the most fundamental concepts of programming, along with three suggestions for projects: a video game, a data visualization project, and a web app. I realized that the poster was the table of contents of the book I wished I could teach from, and I basically turned that poster into a book proposal.
I naively thought I could write the book during the summer and edit it during the following school year. That turned into two and a half years of early mornings and late nights! But it was very much worthwhile; Python Crash Course has reached a global audience that I could hardly dream of back then. I kept teaching full-time until 2019. But I couldn’t continue to teach well and write well, so I left the classroom to focus full-time on writing and programming.
NSP: While we’re on the subject of conferences, you encourage your fans to go to events like PyCon or local coding meetups—that is, places where they can benefit from taking part in some sort of Pythonista community. Why do you believe it’s important for programmers (of every skill level) to step away from their monitor and go meet people?
EM: As a programmer, especially if you’re new to the field, it’s so easy to get stuck in your own head. It’s tempting to keep telling yourself you’re not good enough yet, that when you just learn a little more you’ll be ready to meet others and talk about programming. But when you step into a Python space—a meetup, a conference, an organized online event—you’ll almost always meet people you have something in common with.
You’ll definitely meet people who know more about Python than you do. But you’ll also probably meet people who are even newer to the field than you are. You’ll find people who are working on problems you’re interested in, and you’ll be inspired in ways you just can’t predict.
Some of what you hear will go over your head, but that’s quite fine. The concepts you hear about but don’t understand yet will be more familiar when you come across them later in your own work. And they won’t be dry concepts then—you’ll have a face you can connect to that topic.
There’s also a fair chance you’ll make some lifelong friends, especially if you end up staying in the Python community for a while.
NSP: Given that PCC has been a bestseller for the better part of a decade, you probably come across people who read the book years ago and are now really advanced and/or professional Python programmers. Got any tips on how to continue making progress for those who only recently finished the book? Put another way: How does someone go from beginner to expert programmer, and is that even necessary in order to have success in the field of programming?
EM: That happened much faster than I thought it would! I remember talking to someone at a booth at the second conference after the book came out. They were explaining something technical about what their company does, and halfway through they realized who I was. They stopped what they were saying to share how much Python Crash Course had helped them get started in programming. Then they continued their explanation of an area of programming I hadn’t used much and didn’t fully understand. As an author, that was a very satisfying experience!
In the early days of Python, it was pretty reasonable to aim for mastery of the entire language. It wasn’t that big, and back then the community was a lot smaller as well. These days, Python is huge; it would be really hard to know every part of the language in depth. There are plenty of Python maintainers who know one part of the language well, but who wouldn’t consider themselves an expert in other areas. It’s just too big and touches too many specialized areas.
We all know what a beginner is because it’s relatively easy to define. But there’s no clear definition of “intermediate” or “advanced.” I would advise people to learn one language well enough that you can use it to solve meaningful, real-world problems without having to follow a step-by-step tutorial. That doesn’t mean you need to be able to write code from memory. It’s perfectly fine to look back at the tutorials and resources you’ve learned from as you’re working on your own projects.
The best advice I can give once you’ve learned the basics is to keep learning fundamental concepts, but make sure you’re applying those concepts in a variety of real-world projects. There are a lot of concepts in programming that you can’t fully make sense of until you’ve had the chance to apply them in a variety of contexts
NSP: Let’s talk about your passion for projects, then. Python Crash Course is peppered with a number of them—including a Space Invaders-–style video game—and these endeavors definitely contribute to the book’s effectiveness. Would you explain your philosophy that programmers should always have a project in mind? Bonus question: Care to share any cool projects that you are working on right now?
EM: Nobody really learns programming just to write lines of code. The code we write is only meaningful if it actually does something we (or someone else) cares about. If you have a project you’re yearning to build, you’re almost certainly going to be a more active, engaged learner. Every time a new concept comes up, you’ll ask yourself how that concept might help you implement your project. This pushes you to think more deeply about each new concept and try using it in different ways, until you start to internalize that concept.
At the same time, you probably shouldn’t just focus on one large project. It’s helpful to take on some smaller projects that you can complete, and practice the art of “finishing” a project. No codebase is perfect, so learning to recognize when a project is “good enough” is a tremendously valuable skill.
I always have a number of projects going on. I write a weekly newsletter called Mostly Python, and it consists of individual, one-off posts and series about specific topics. I’m working on a program that will convert these series into mini-ebooks. I’m working on django-simple-deploy, a project that automates configuration and deployment for Django projects. I’m slowly learning piano, and I had a hard time learning all the notes of the grand staff well enough to focus on actually playing music. I made an old-school JavaScript site that facilitates learning the notes, and after using it for two weeks, I’m now the fastest student at naming all the notes. (That really means I’m faster than a bunch of fifth graders, but it still feels good.) I’m going to polish that a bit more and then share it more widely.
NSP: Last question. A surprising detail about your life is that you’ve bicycled across the US [checks notes] five times—in fact, you quit your job at one point and lived on a bike for an entire year! Are there any lessons you learned during those hundreds (thousands?) of hours of pedaling that can be applied to the world of Python programming?
EM: Yes, it was thousands of hours of pedaling!
When I was in my 20s and had a few years of teaching behind me, everyone was focused on getting master’s degrees. I just wanted to live outside during the summer, so I biked across the US for two summers in a row. I rode across the northern states one summer and then took a southern route the next summer. Those were such good experiences, I quit my job so I could live outside for a full year. I rode from Seattle to Maine, down to Florida, over to California, and up to Alaska. I had a conviction that I’d learn more from that kind of journey than I would from getting a master’s degree, and looking back, it was definitely the right choice for me.
One thing I took away from that trip was a deep reserve of calm from having faced everything that a year of living outside brings: beautiful sunny days in wild places, sleety mountain passes, sleeping in a tent for weeks at a time with bears, and so much more. Another big life lesson was a better understanding of all the different ways people live their lives. When you travel alone for an extended period without an engine, people open up in a different way. This was before social media, smartphones, Google Maps, and photo-sharing sites. I stopped a lot to ask directions, and just talk to people on the side of the road. Mostly, I just listened—people want to tell you about the place they live, and many people want to share their life story when you’re outside and don’t have a schedule. People would say, “I wish I could just take off and live on a bike...” and then they’d open up and tell really honest stories about their lives. I think that happened a lot because people knew I was just passing through, and they’d never see me again.
I learned empathy from listening to so many different people. When I write code, I think about the people who will use what I’m making, and I consider who might be negatively impacted by whatever I contribute to. I enjoy time in front of a computer more because of the time I’ve spent far away from a computer. When I deal with stressful bugs and crashes, I remind myself, At least I’m not facing a bear alone on the side of a gravel road in the far north of British Columbia right now.
I believe most programmers benefit from having nontechnical hobbies. Anything you find meaning in away from a computer helps keep your technical work in perspective. Keeping things in perspective is really helpful in a yearslong technical career.
Finishing that trip made it easier to write a book because I had a sense of how to bring a long-term project to completion. In some sense, a 14,000-mile bike trip is nothing more than a whole bunch of individual pedal strokes. When I feel like I’ll never get to the end of a long project, I often think back to hard days of riding and remind myself that every step forward is meaningful. That’s more than just a passing thought, though. It brings back the feeling of living outside on a daily basis. I miss those days, but I’ll carry them with me for the rest of my life.
For anyone interested in hearing more about those adventures, I wrote a book about the trip a while back. It’s kind of funny to be the author of one book that’s sold over a million copies, and another that’s sold about a hundred copies. But I wrote that book more to solidify the memories than to reach a wide audience.