What's it like to be a beginner in software development? How about learning Python for the
first time? This episode is a special panel episode and is the first of a two-part series
we are doing on the podcast called Beginners and Experts. On this first episode, we have a
conversation between the beginners and the experts and how we can close the gap to help the beginners
get up to speed as quickly as possible. Our panelists are Carly Cindy, Joy Dayton May,
Cece Flora Muniqua, and Ned Batchelder. And this is Talk Python to Me, episode 203, recorded January 30th, 2019.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem,
and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm at,
mkennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the show on
Twitter via at talkpython. This episode is brought to you by Linode and Ting. Check out what they're
offering during their segments. It really helps support the show. Cece, Joy, Carly, and Ned,
welcome all of you to the podcast.
Hey, thank you.
Thanks. Glad to be here.
Thank you, Mike.
You're welcome. You're welcome. It's great to have you all here. People love the panel shows
with lots of different perspectives. So I'm excited to put this together for everyone. So let's start
with just who you are and maybe where you are in this beginner expert side of things and what you do
day to day so people have a perspective. And Cece, let's begin with you.
Thank you for having me, Mike. I'm really excited to be doing this with all of you. So I'm a student
in Zimbabwe at Terraro Institute of Technology and I'm studying information security. I started
programming in 2016 and I started with C when we were doing a module for the degree program that I'm doing.
Eventually, we started learning Python. I have a lecturer who is very passionate about Python. He's the one who introduced Python to us. He had to change the curriculum a bit. Instead, we would have learned Java, but he changed the curriculum so that he can introduce Python to us.
And so my first hello out in Python, I did in class. And after that, I just started going on and on learning Python.
Yeah, that's really great. I'm so glad that person changed it from Java to Python. That's happened in a lot of education spaces.
Yeah, I love that guy.
Definitely, because I don't think I would have continued with Java. It's not very favorable for me.
For sure. All right. That's wonderful. And what do you do day to day? You're still a student. Are you a grad student at the school there?
I'm still a student. I'm going for my senior year next year, but currently I've been interning at Dimension Data and I've been with them for a few months now.
My main work task at Dimension Data includes automating tasks and developing learning hubs.
So what we do is write Python scripts. All of the work that I've been doing today is as done in Python. So it's great.
We also do a lot of integrating with APIs, which is a new technology for me.
And I've been learning a lot from Dimension Data and everything that we do there.
Yeah. How exciting. Dimension Data is doing amazing stuff with getting people into programming.
And that's how I know you. You and I work together a little bit on some of those projects.
So that's great. Joy, yeah. How about you? Tell us about yourself.
Thanks for having me. And my name is Joy, Joy Ma.
I'm a product manager at the Paulson Institute in Chicago.
So we're a think tank focused on international economics.
And when you think about think tanks, the stereotype of a think tank is usually in D.C.
As a matter of fact, there are over 400 think tanks in D.C.
They have a lot of former politicians.
They have a lot of former diplomats.
And they have amazing experiences.
And based on their personal experiences of sometimes 60 years, they make policy recommendations for other policymakers on the Capitol Hill.
But our think tank is pretty young.
We were established in 2012 by former Treasury Secretary Hank Paulson.
And we're trying to think of a new way to establish a name in this already very crowded field.
And that's when I started to venture out and look at all of the different options to do policy analysis.
Back in 2016, when I first started looking at international trade policy and international investment policy,
that was a moment I saw they are just half a decade of data freely, publicly accessible out there.
But nobody has ever done any sort of research into it.
So I thought, you know, being a relatively younger person without a 60-year diplomatic experience on my belt,
I would just look into 60 years' worth of data and see what I can come up with.
And that's how we conducted our research at Paulson Institute and has been pretty successful, I would say, by institute, by think tank standard.
A lot of our research did get published on Wall Street Journal, New York Times.
And we certainly also made our fair share of contribution to policymaking recommendation.
That's really great.
So it sounds like a lot of data science, probably a lot of Jupyter notebooks and analysis like that, yeah?
A lot of pandas, a lot of cleaning, a lot of days.
Sometimes it's pretty painful.
I can imagine.
Cool, cool.
That's excellent.
Welcome.
Carly, how about you?
Yeah.
Hey, thanks again so much for having me on the show.
I'm excited to be here.
I'm representing part of the beginner side of this conversation.
I have my master's in molecular biology, and I worked doing scientific research for about 10 years.
And I was working in an epigenetics lab and generating a lot of sequencing data, which are essentially flat files with a lot of strings,
or sequences composed of AT, Cs, and Gs, and some metadata.
And I needed a way to analyze all of this data I was generating.
And there are public websites, but they can be super slow when you're trying to run these files when they get really large or a lot of these files.
So you really need to run them at the command line, run these tools.
And generally, while you're SSH'd onto a larger machine than you have on your personal machine.
So that introduced me to a whole lot of bash and some scripting.
And then we started designing experiments that are a little bit more complex.
So it required a lot of modifications to these files before we sent them in to the command line tools.
And so that's when I started looking into Python.
And I took a class called Python for Biologists.
And this is what really opened my eyes to how many problems Python could solve that I was faced every day.
Just like little problems.
So I started building tools for the lab where people could like drop Excel sheets into it.
And it would just like parse and figure out and do some things that we just would make our life easier day to day.
And so after building some of these tools and doing these analyses at scale, I decided that I wanted to do that full time.
And so for the past two years, I've been working full time at a company that makes software for life science researchers and for their daily workflow.
So it's kind of a perfect fit there.
So in being in a really small startup, I feel like I do a bit of everything day to day.
I look at code and improve merger busts and write code, modify code, test code.
Also wear a bit of a product project management manager hat and define projects and research potential tools.
And if they're out there, maybe we can, you know, containerize them or maybe build our own.
I mean, I also even talk to customers and see where we can be meeting their needs with the code that we're writing.
Well, it sounds really interesting.
I think this is one of the situations where people have some skill already, like really solid skill, like you have molecular biology, right?
And programming makes that better.
It's not like, oh, forget this biology.
I'm just going to go become a programmer, right?
I want to do React with, you know, JavaScript, right?
It's just like, how do I do what I'm doing better?
Yeah.
Yeah, absolutely.
I was trying to be affirmative, assertive.
Yeah.
I think, I mean, same thing.
I think that joy, like you were coming, you know, from the economy side of things where it's like being able to integrate the knowledge you already have and just enhance the knowledge you already have and just make, see those problems that you've seen in the past, however many years you've been in that field.
And then all of a sudden be able to solve them with some code is really exciting.
Absolutely.
You know, I was trained as an economist in undergrad and graduate level studies for, God, almost a decade.
And the most valuable part of the training is to help you identify questions that needs to be answered.
And it's with Python for the first time, I feel I have so many tools to answer those questions.
But as you said, Carly, sometimes you're wearing the product manager head and you need to identify what is the need of your client.
And in my case, I need to identify what is the pain point for a policymaking and use the domain knowledge we have.
We can identify those points very specifically and then use the tools such as Python.
We can solve it so much more efficiently.
Yeah.
Absolutely.
Ned, you want to introduce yourself as well?
Yeah.
So let me just start off by saying that as a beginner in both molecular biology and policy analysis, I am a little intimidated to be on this panel with all these experts.
Absolutely.
So I'm a software engineer with a long career.
I'm deeply embedded in the Python world.
I organize the Boston Python user group.
I've given PyCon talks at, I think, 10 different PyCons.
I'm a maintainer for coverage.py.
I hang out in the Python IRC channel.
I really need to find another hobby in my life of some sort.
I do everything with Python.
Yeah.
You and me both.
I'm not going to introduce myself, but I'm both a beginner and expert, just as you said, Ned.
Exactly.
Certainly in the biology and the policy side of things.
So I want to start this conversation off by talking about something that you wrote, Ned.
Yeah.
Highlighting the beginners and experts perspective from somebody who's been doing it a long time, right?
When somebody's a beginner, they are just always bumping into sharp edges of the technology.
Oh, why does this not work?
Oh, why is this, you know, why won't this thing install on this machine and all that kind of stuff, right?
But you talk about how, well, in some ways, those sort of feelings and those challenges don't go away.
So maybe you want to quickly summarize your beginners and experts article or essay.
This got started almost two years ago when I was working on a side project.
And as I talked about various aspects of that side project, first at a lightning talk at work,
and then I wrote a blog post about something I was struggling with about it.
And I realized that over the course of that summer, as I was working on that project,
that I was feeling like a beginner in lots of ways.
There are aspects of it that I knew exactly what to do, but there were aspects of it where,
you know, I was Googling on Stack Overflow to figure out, you know,
how do I make this thing do a thing?
And that beginners often feel like that they are having trouble because they are a beginner
and that their plan is I will learn everything and eventually I will be an expert.
And once I am an expert, like all these other experts I see,
then I won't have those problems anymore.
I, you know, I will know what to do.
And I won't have these confusing mornings where everything seems wrong and backwards
and I can't make anything work.
Just nothing works.
Why does this not work?
Right.
Michael, what you just described, right?
The sharp edges and why doesn't this install on that machine?
I don't know how you knew what I did this Monday, but yes, that's the way my days often are.
So beginners think experts know everything and there's no friction in their development tool
chain and cycles and all that stuff.
But what you'll know once you become an expert is that experts don't know everything.
Experts are constantly encountering new things.
Joy, you just mentioned that you do a lot of pandas.
I have done maybe two things with pandas.
And one of them was literally last night.
And I was Googling on Stack Overflow to ask, how do I know what the names of the columns in a pandas data frame are?
Right.
Which is super basic because I don't know anything about pandas.
Oh, Nat.
I've done countless nights of mine spent looking at Stack Overflow.
Yes, exactly.
And the thing I was trying to drive home with, I eventually wrote this blog post and I did a talk at Boston Python about it.
And the point I was trying to drive home was that although I stand before you as a sort of acknowledged expert in Python, I often have no idea what I'm doing.
And the real difference between beginners and experts isn't that beginners know nothing and experts know everything.
But that beginners think that this feeling is either going to last forever because they're dumb or it's going to eventually go away because they've learned everything.
Whereas experts know this is a very familiar feeling.
I have been in situations lots of times where I don't understand what's going on.
And because I've been in that situation lots of times, I know I'm going to get through it.
I have some tools.
I have some strategies that I can use to get through this difficult part and end up back again in a place where I know how to do things.
Either because I've put that problem behind me or because I've learned the solution to that problem and I can now apply that solution.
And one of the bumper sticker slogans that I'm thinking of using about this is that an expert is just someone who's been a beginner many, many, many times.
Over and over again.
The expert goes back to being a beginner and comes out of it and so has cycled through that learning curve over and over again.
That's super interesting.
And it's basically you get really good at, all right, how do I interpret this error message?
What places was I able to Google or search or arrive?
What the answer is?
Where did I find an example that I could borrow and adapt?
Like those are the kinds of things you get better at.
And then the calmness of like, yeah, this is really frustrating, but it's just like last week.
And I know by lunchtime it'll be fine.
We'll figure this out.
But right, it doesn't go away.
Right.
Or I know that this is a thing that I really do have to master.
So I'm going to use my good learning strategies for it.
Or I know this is a problem that I just need to put some duct tape over right now and then I can forget about it.
So I'll just use my quick hack strategies for this.
There you go.
Stack Overflow for that one.
Yeah, I never use Stack Overflow for the real learning strategies.
No, I would never do that.
Never.
Of course not.
That would be wrong, Ned.
Cece, let me ask you, how do you look at experts?
Do you feel like all these people who have been doing this for a long time, like Ned, they've just got it all figured out?
Or do you connect a little bit more with his perspective of what he's writing here?
Yes, I do understand what Ned is talking about.
In my perspective, sometimes I feel like experts do know everything.
There are some people who have started coding at like nine years old.
It's hard to believe that that person still has those frustrations when you started coding when you were nine years old.
In my view, I'll be seeing you as someone who knows everything about coding you.
Every error you come across, you'll be able to fix it in a minute.
But as I've been growing in coding, I'm seeing that as I learn more, as I learn new things every day, those frustrations keep coming back.
And I keep going through the same process again of encountering an error and then having to fix it, getting the frustration and everything.
So experts and beginners, we are more on the same level if we try to look at it.
Just like Ned said, experts are beginners who have been going through the frustrations over and over and over again.
That's true.
Yeah, I think like not unique either just to like developers.
I feel like scientists make good programmers because we're so familiar with failure.
Because like when you set up experiments in the lab, like, you know, a negative result is still a result.
But you're getting so many negative results is so infrequent that you have a eureka moment.
And so, but I feel like that kind of helped me a little bit with programming too.
It's like, I try something and it doesn't work.
It's like, all right, well, that's, you know, just check that off.
I'll move on to the next thing.
Like a negative result is still a result.
That's right.
It's kind of like the Thomas Edison, I've learned 3,000 ways not to build a light bulb.
That's where you're going, right?
That is really interesting when you say how you know the learning strategy and the tools so that you're confident that you're going to be able to solve the problem either today or tomorrow.
And for me, you know, in data science, we talk about this black box.
For me, the path to gaining that confidence is almost like a black box to me.
As a beginner, we learn very practical skills.
We learn all commands in pandas here and there.
But from here to having the confidence to solve a problem that's never been encountered by us before,
gaining that confidence for me is definitely something very interesting to learning more about.
It's hard to get to that point, right?
To feel like you will be able to tackle whatever problem you encounter, whether it's a molehill or a mountain.
And honestly, I think one of the good strategies is to not try to solve everything.
I've seen some beginning learners who, they'll put it this way, they want to understand everything.
Everything, they either mean very, very broad, right?
I want to read the entire Python standard library.
I want to know all of it, which it's just too big.
You can't do it.
Or they mean very, very deep.
I want to know how Python's implemented, like what's really down under there.
And sometimes I've seen people get taunted, like, so you want to know how transistors are made?
Like, how deep down are you really talking about here?
And beginners, I love that optimism and hunger and veracity that a beginner like that can have.
But they're going to have to realize that they're not going to be able to do that.
And at some point, they're just going to have to say, there's a thing right over there I could learn about.
And I'm just not going to learn about it because I have to go and do this other thing over here.
That's another kind of strategy.
I know enough to solve this problem.
We're good.
Yeah.
What you just said is both very reassuring to a beginner like myself, but also very intimidating.
Weirdly.
Yes.
It's the same time.
One of the things I said in the blog post is, you know, the good news for beginners is that, you know, experts aren't significantly different than you.
They've just had a lot more experience.
But the bad news for beginners is this bad feeling you have where you're confused and mystified and frustrated.
You're going to have that for the rest of your career.
I mean, I've already run into that.
I feel like even I've been doing this, I guess, for two years officially.
And I've run into that many times.
And each time I hit that where I'm like, I've started coding something and I'm like, oh, no, I don't know if I can actually do this.
But then somehow, you know, like I take a step back, I go back and then actually getting beyond that feeling.
Like the next time I hit it, I'm like, all right, I already had this terrible feeling before.
I know I can get past this.
So I think maybe just the like kind of dulling your senses to that feeling of like, oh, my gosh, you know, like this is a huge, huge hill to climb.
Right.
Yeah, that's really interesting, Carly.
I remember when I was first, the first couple years I was working as a professional developer, I didn't have much experience before.
So it was both awesome and super frustrating and scary at the same time.
And I remember often taking 15 minute walks around the office park.
I'm just like, you know what?
I just I just got to step away for a minute.
It's sunny outside.
I'll be back and I can just I can clear my mind and do this.
And I guess I don't really do that that much anymore.
But yeah, I think you get less emotionally frustrated, but you still are bumping into these sharp edges.
You're just like, why does this not work?
Like, it's I've done this for a year and it's the same.
Why is it not?
You know, just like, what is going on today?
Right.
Yeah.
One of the big challenges, I think that Ned, I'd love to hear your thoughts on this, but I'm going to ask the ladies first.
One of the really big differences, I think, is the beginners have a harder time deciding how to start to solve a problem.
As an expert, you can look at something and go, oh, that needs we got to parse this file type and we're going to use the database and probably we're going to use an ORM and we're going to wire it together like this.
And then, you know, we go and bump into the sharp edges of those things.
But we kind of know roughly how to attack the problem.
And I think that a lot of beginners are like, I don't know how to start.
I see what you did.
This was amazing.
I have no idea how I would ever come up with that idea to get there.
Like, how does that like, does that resonate with you all?
Definitely.
I mean, this is just kind of when you're given a problem and you're just like, oh, okay.
Now, where do I start?
You know, like when you're taking an introductory class or any of those, it's like, this is what we're going to do and this is how we're going to solve it.
You know, or I mean, I know that like last week I had, I was trying to solve a problem and I ended up coding probably like 200 lines of code.
And then I was going to set up kind of a sanity check with a colleague.
And I was thinking about how to explain this problem to that person.
I realized a much simpler solution.
So I basically got rid of all that and then just was able to solve it with a few lines of code.
And I think kind of having that perspective like of stepping back and like knowing like the tools to solve it, you know, like if you've already kind of solved something indirectly that's similar to it.
And I think that was my issue last week was I had never solved anything similar to that problem before.
So I didn't know like the tools to be able to solve it in the most efficient way.
So I kind of spent a long time making a really long solution to it.
And then realizing that there was a much more direct route.
And I think, yeah, I think that familiarity with like seeing things done one way and then just dealing with the little details is definitely tough being a beginner because you haven't seen a lot of examples of the way a problem is solved.
This portion of talk Python to me is brought to you by Linode.
Are you looking for hosting that's fast, simple, and incredibly affordable?
Well, look past that bookstore and check out Linode at talkpython.fm/Linode.
That's L I N O D E.
Plans start at just $5 a month for a dedicated server with a gig of RAM.
They have 10 data centers across the globe.
So no matter where you are or where your users are, there's a data center for you.
Whether you want to run a Python web app, host a private Git server, or just a file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24 seven friendly support, even on holidays, and a seven day money back guarantee.
Need a little help with your infrastructure?
They even offer professional services to help you with architecture, migrations, and more.
Do you want a dedicated server for free for the next four months?
Just visit talkpython.fm/Linode.
From my experiences, when I first started learning Python about two years ago, it's relatively easy to learn about the specific tools, to learn about pandas, to learn about object-oriented programming, to be able to write a couple of lines of code and make it up and running.
But the real problem for me, and this might be just beginners' ignorance at this point, I think the tools are relatively easier to acquire and there are concrete examples out there.
And if you run into a very specific problem, there are people out there, you can ask them, there is stack overflow.
But the real problem comes in for me when it comes to the structure.
How do I arrange the tools in my toolbox to identify, solve, and reassess my own solution to a specific problem?
And that's when, I think it was roughly two years into learning Python by myself, I started to realize,
okay, right now the real problem for me is not to solve one specific problem to get the name of the column,
but to actually identify the problem and put it in a framework that I know how to extract the features and how to solve it.
And that's when I started.
For the first time, I was just taking a lot of online classes.
For the first time, I joined, I don't know if I'm supposed to say this, but I joined data science training at General Assembly,
which gives you a much deeper understanding about just ideology.
From structurally speaking, how to think about the problem as a data science problem,
as opposed to economics problem, which I'm very comfortable with,
but it's not the best way to solve, to get answers that we are looking for.
Joy, that's exactly, I think being able to become familiar with the tools is something that is really helpful,
because knowing the tools that can help solve your problems is really important.
Because if you don't know a general idea of what some libraries or tools can do,
then you might, like me, start writing it from scratch.
And then be like, oh, there's something that I can do.
Why did I just keep installing the magic?
So, like, I think that that's, you know, like, and the more you're around and you have, like,
those water cooler conversations and you hear about, like, tools that other people are using,
and then you can kind of apply those tools to problems that you have.
I think it's kind of exposure to the domain, I think, can really help speed up answering problems.
But that's, I mean, it's tough as a beginner because you don't have that exposure yet.
Yeah, and it's super hard to learn.
It's not very well taught anywhere, I would say.
Cece, how do you feel about this idea of, like, how do I even get started solving a problem?
I can relate to what you're saying, Mike.
There are times that I come across challenges that I do not know where exactly to start solving the challenge.
When I started working at Dimension Data, I came across this site, the PyBytes site, where they have challenges.
Their challenges are so awesome.
And I started taking those challenges.
I started with the beginner challenges, of course.
And when I read the challenges, some of them are so simple that I can think, I can do this in, like, one minute.
But when I go into the editor and try to write some code, my brain freezes, and then I have nothing.
Yes, that's how I feel sometimes.
But as I continue taking the challenges on PyBytes, I realize that after some period of time, and I can relate to other challenges that I've done before and be like, oh, last week I did less combinations.
I think I can apply that to this challenge.
That's how experts feel like they have exposure, just like Joy said.
They have exposure to more tools to use and what you can do to solve challenges, which I think the first step of deciding what to use when solving a challenge is the most important.
When you're facing a challenge, rather than just jumping in to try and solve the challenge without even thinking through what tools you can use to solve the challenge.
That's really interesting.
And I think you doing the PyBytes challenge makes a lot of sense.
Bob and Julian are doing great stuff with their Code Challenges platform.
So I think that practice helps.
I do want to say I feel, I totally agree with Ned that we, as experts, we run into these things where it's like, wow, this is so frustrating.
Why doesn't this work?
Why can't I make this silly thing?
You just do whatever it's supposed to.
And it feels very similar.
But what I think is very different is when you approach a problem, you're like, I see, I've solved this kind of before.
And we did this major thing, this major thing, and that major thing.
And it kind of clicked.
And you can sort of break the problem down into these smaller bits.
And you have this history of I've kind of solved this data problem like four or five times like this.
It's probably like that.
Let me try that first.
I think those building blocks are a huge differentiator.
And that gets way, way easier.
Ned, what do you think about my idea here?
No, definitely.
As someone with a long career, I've been in lots of different projects and written lots of different code.
So I have sort of a long tail of patterns that I can match against, right?
We get a new problem.
This reminds me of something.
I can either just remember what I did before.
I can literally go and find the code.
Often, I can do something quickly at work because previously in a side project, I had to solve that problem.
And I could do it at my leisure on a side project.
But then I've got the code in place that I can just go and grab for a work thing.
But I have to say, Titi just said that she would read Python bytes, think, oh, I can do this.
And then she gets in her editor and her brain freezes.
That happens to me too.
Exactly that feeling.
I can't tell you how many times I'm waking up in the morning and I think, I know what I'm going to hack on before breakfast.
This is going to be great.
And then I get into Vim and I'm like, you know what?
This is actually hard.
I don't know what to do right here.
Like, maybe I was just still in kind of that foggy dream state and I thought it was easy.
But right now, it's actually hard.
And I'm not going to make the kind of progress over this cereal bowl that I thought I was going to make.
And that's just programming.
It's really hard to be specific enough to tell a computer exactly what to do.
It just is.
And so, sometimes you think it's going to be a thing and it turns out to be harder than that.
I think a lot of it, the pattern matching is really the way I think of it in terms of going back into your experience.
I was working with an intern last summer and we were debugging a problem.
And I said, I think it's going to be, this is the solution.
And he asked me, like, how did you know that was the solution?
And I felt like, well, in the logs, there was a zero.
And over here, there was a none.
And zero and none are kind of the same.
And they were both kind of out of place in each niche.
And so, I kind of put those two things together and what would make that happen.
And so, there's a lot of pattern matching in solving problems,
either to decide how to get started on a thing or to debug a thing.
And just being, going through it a number of times over the years gives you more of a sense of sort of like,
what's the anomaly in this environment that I should be focusing on to debug the problem?
Or how do I break this big problem into smaller chunks, two of which are familiar and one of which is unfamiliar,
so that I can just do the familiar ones quickly and then focus on the unfamiliar.
And that kind of cognitive pattern matching, I think, is a skill that you develop over time.
You definitely develop it over time.
What I've been wondering and kind of searching for the last six months is how can you fast track that?
What I've been wanting to do is build a class that basically says, here are a bunch of problems.
How, as an experienced person, do you go through the idea of even starting to attack the problem?
You know, almost forget, like, here's the details of an ORM or an API.
It's just like, how do I even begin to put this into parts that then I can attack with code?
What do you think?
Like, how would you do that?
For instance, what I just said was, oh, this is the anomaly that I'll focus on.
Well, to a beginner, the entire log file is new and different and exotic, right?
So how do you know?
It's a scrambled mess.
How do you know what's the important part?
What's the regular normal part of this gobbledygook?
I don't know.
So, yeah, that is a thorny problem.
How to get that kind of facility with the normal versus the weird in our environments.
I think it can be done, but I don't really quite have a great sense on how it is.
So somebody presents a problem to you, like, hey, I need you to get this data that we got off of our experiment, and I want you to clean it up and analyze it and show it in this way.
You know, something to that effect.
Like, conceptually, that's really easy, but when you try to actually look at what are the actual steps my program has to do?
What are the actual big ideas?
Like, okay, we're going to read this file.
Okay, we're going to, you know, try to transform this data.
Just like those big steps, I feel like, are the challenge to, once you identify them, then it kind of becomes an easier problem to solve.
But how do you help beginners learn to identify those, sort of break the problem down like that, do you think?
One of the problems I think beginners have, just to jump in, is to think like a computer.
We're not used to having to think so specifically about each tiny little step that we can then write the code that does what we need to do, right?
A lot of beginners will, I'll say, well, tell me in English what it is you want this program to do, and they'll give me one sentence of the whole thing.
It's got to browse the web.
Well, there's little bits and pieces in browse the web, right?
So let's break it down.
And that's very difficult for some people to do because we're not used to thinking that way, right?
I can say to a person, go to the store and get the milk.
And they're like, okay, I'll go to the store and get the milk.
I didn't need to break it down into all the little pieces, right?
You can find videos online of people playing with their kids.
I'm a robot.
Tell me how to make a peanut butter and jelly sandwich.
And the kid tries to tell them what to do.
And the dad just literally follows the instruction and makes a total mess of the thing because the kid's not used to explaining how do you get the lid off of a peanut butter jar?
The computer is that dad.
This portion of Talk Python to me is brought to you by Ting.
Let me tell you about Ting, a new mobile service available in the U.S. that's targeted developers and other technically savvy folks.
First of all, their average customer only pays $23 a month, but they're no discount provider.
Their service runs over T-Mobile's and Sprint's fast nationwide network.
If you don't use that much data because you're usually on Wi-Fi, like many of you are, then Ting will save you a ton of cash.
But don't worry, you can still use as much data as you like for just $10 per gig.
One mobile feature I use all the time is tethering.
And with Ting, you get unlimited tethering at the same data rate with your account.
$6 a month for a phone line, $10 a gig, $3 a month for text if you usually chat over iMessage or WhatsApp.
Think about it.
No contracts and super clear and fair billing.
Visit python.ting.com.
That's python.ting.com and check out their savings calculator.
Enter your usage and see exactly what you'd pay.
Use that link and you'll get a $25 credit to try them as well.
That's python.ting.com or just click the link in the show notes.
I mean, that's a really interesting way to put it where you're like, I'm just going to go to the store, but you're like, you know, get in the car and do all these things.
So it's kind of when you say that, it kind of like picture like a flow chart in my head.
Like, so with like a problem, generally, is there some type of data?
Like, is it in a file?
Is it a stream?
Is it like from the web?
Like, so and how do you how do you access that data?
Where is that data going?
So like kind of following the trail of the data and what needs to happen to that data at each point really dictates the way you will program something, whether it's a file or whether it's a stream or, you know.
And so I think kind of following that the trail of data and then kind of making choices on that can help break things down.
Right.
And one of the fundamental characteristics of the software world that we've put ourselves in is that there are unlimited levels of complexity.
And so we deal with abstractions all the time.
And another challenge for beginners is accepting an abstraction and using it.
And in a way, breaking down a problem for a computer is all about setting up those barriers between the two halves of the problem and dealing with them separately rather than thinking of them as a whole.
Right.
So when I said when we said go to the store and get some milk, well, step one is get in the car.
Step two is drive the car to the store.
That step two is awfully complicated.
Right.
Ask the people who are building self-driving cars right now.
So there's an abstraction there that we're willing to deal with.
Right.
You turn the wheel, the car turns.
Right.
Sometimes you have to debug that abstraction.
Sometimes you just have to accept that abstraction.
And moving up and down those levels of abstractions and just ignoring some of them, what's underneath some of them, but debugging what's underneath some other ones.
It's a huge maze of distractions and complexity that beginners can get lost in.
So that's just another skill.
I think it sort of touches upon the point I was talking about before.
The really difficult part for a beginner may come from how to extract structure and abstraction out of a very complex problem.
When we're talking about making a peanut butter sandwich, then for a beginner, he or she doesn't necessarily know what are the steps to do so.
Once you have the steps to do so, you can Google how to open the peanut butter jar.
You can Google how to put a bread into the toaster oven.
And I think the difficult part is actually building that structure, having that mental structure to know which step is after another one.
And for me personally, a lot of the, it was about two years getting to Python studies.
It started to click for me.
To some extent, I feel like the building the structure of to solve, building the structure of a solution to a problem is just like any type of analytical thinking.
You need to identify the problem and then you need to have five to seven steps to resolve a problem.
And then going into each of the every single step to look into the tools, the practical solutions to every single bottleneck that we need to overcome.
And for example, I'm an economist and I was looking at U.S.-China trade war and people keep asking this million dollar question, which is, what is going to be the cost of the trade war?
Is the U.S. economy going to be impact?
And it's such a great question, but it's so complex.
But then once you break it down into how about let's look at the first industry, the second industry and the service industry and look at the impact on all three industries by the trade war.
And then you have a structure to go into there to find the data, to extract information out of the data.
And once you compile them together, you're answering an awfully complex question.
That's a good way to break it down.
You know, Ned, something that came to mind is you were describing these being willing to accept an abstraction, right?
Like you don't actually care how the CPU makes it work.
I just know if I type this and I hit run, it runs, right?
Like I'm willing to just not even worry.
It's like there's a gray layer that I just am willing to kind of accept.
And I think that those layers of abstraction happen a lot in programming at different levels, right?
Like I'm willing to use an ORM and I'm willing to call save and I don't care how the database works.
Or I need to dig in and understand the full third normal form theory of relational data and get obsessed about that, right?
Like there's totally different levels there.
And I think one of the challenges when you're first learning is what is the right level?
When can I ignore the nuanced details of the database?
And when am I going to be like, when is that like critical to make that right?
So choosing the level of abstraction, I think also tells you like what kind of tools and APIs and packages you can use even.
Right. Well, and the fact, I mean, you've already chosen Python, right?
Which means that there's certain kinds of things other programmers and other languages have to worry about that you don't have to worry about.
Right.
Malloc anyone?
Exactly.
Right.
You don't have to allocate and deallocate memory.
And if you're working in data science, like Joy is, then you've got Pandas and Pandas provides you this really high level abstraction of a data frame that does all sorts of things.
You know, that five years ago before Pandas was around, if we wanted to do that analysis, even in Python, we'd be writing 100 lines of code just to sum an average or whatever it is we need to do.
Right.
You try to build it with dictionaries and lists and other more fundamental things.
Right.
Exactly.
Yeah.
You have to decide what level you're going to be working at.
And sometimes you can go down a level just because you're fascinated by it.
Like maybe you want to know how transistors work and how a CPU is made out of transistors.
But if you're trying to write a Python program and you can't get it done because you're obsessed about transistors, you're not going to be able to finish the Python program.
You have to leave that to someone else.
You have to assume that's going to work.
Yeah.
It's fine to be obsessed about some nuanced detail, but you shouldn't conflate it with trying to solve your problem if it's not relevant.
And I think making that distinction is the challenge.
Yeah.
Cece, how about you?
How do you see like trying to find the right level to think about these problems?
You talked about working with APIs, for example.
Like that takes a lot of getting your head around.
And you can either say, I call this function and the data comes back as JSON.
Or you can say, well, there's all this HTTP headers and all this exchange and the right.
Like there's a lot of details you could get into.
Like how did you think about working with those problems?
Well, for me, I think that there really is no problem when you're facing a challenge to write what you're supposed to do down.
Like what you learn when you're learning the basics, the flow charts and how to do algorithms.
I think even when you're an expert, it's okay to just jot down what you're supposed to do and write all the simple steps that you're supposed to do.
And in those simple steps, decide exactly what you're supposed to do.
Like what Joy mentioned.
Those are the steps that will guide you into the challenge that you're facing.
So for me, I've been learning to do that when I face a challenge that I really can't solve within five or ten minutes.
Maybe after some deep thinking, I'll write down what I'm supposed to do.
In those simple steps, work on each one by one.
If we can all adapt on that concept, I think it will be easier for everyone.
Because when you're a beginner, there's an age to go and Google your challenges on Stack Overflow.
And just get in answer straight away from Stack Overflow.
And a piece of code and paste it into your editor.
But then the problem is when you paste code from Stack Overflow, that code is going to bring more bugs.
Rather than going step by step and understanding each step that you're supposed to do, I think it's an easier way.
And I've learned that the hard way myself because I did projects where, after projects where, most of the times, I just need to take code from Stack Overflow.
But at the end of the day, I will still be having a ton of bugs that I have to debug for the code to record.
Yeah, the danger with Stack Overflow can be, you know, it might solve the problem, but then it has all these other issues.
And if you take too many of those pieces together and don't understand what they do, you can end up with something that's really hard to take care of.
Because you're like, if I change this, it breaks, but I just don't really know why.
And that can be super frustrating.
And this, you know, touches a little bit on what Ned talked about earlier, where sometimes, you know, this part doesn't really matter that much.
I just need this to work and I'm going to never worry about it again.
So let me just grab that thing from Stack Overflow, jam it in there and we're good.
And other times it's really important.
Ned, how would you help people make that distinction?
That can be hard too.
I mean, that unfortunately requires predicting the future, which no one knows how to do.
So, I mean, I was dealing with this a few days ago.
I was trying to automate creating AWS instances and I was stuck in like Googling, finding things that didn't work, that didn't seem to go together.
When I thought they'd go together, I didn't understand.
At the time, I knew that I just needed a little thing and if it could just do the thing, it could be crappy.
And I knew exactly who at work I could go and talk to when I wanted to make it nice.
You kind of have to decide what do you want to be an expert in and what don't you want to be an expert in.
I'm personally not, I don't want to be an expert in DevOps.
I don't want to know everything about how to make servers on AWS.
I just need sometimes to have one.
So, I'm not going to dive into that, right?
And it doesn't interest me.
What config setting do I need to put here to make my website run?
Okay, I'm putting that.
Thank you.
So, one of the things I've learned in my long career is that almost everything, when I approach it as a new thing and I've got a mental model of what that thing is going to be like, it's always at least three times more complicated than I thought it was going to be.
Which, it makes sense.
Like, why if I know nothing about a thing, will I have an accurate mental model of that thing?
But I'm constantly surprised at just how much more complex real things can be.
Things generally tend to be way more complicated than you estimate them to be in so many ways.
And you just kind of got to accept that, right?
That's right.
So, we're kind of getting near the end and I want to ask a couple more questions.
So, let me start with this one.
As people who just learned to program are just really getting your feet underneath you as programmers, you know, what advice do you all have for maybe other people who are thinking of getting into programming or they're also close to the same level as you?
Joy, let's start with you.
I think keep going.
Keep going is the number one advice I've gave to anyone who is starting, just started to learn programming.
It's very easy to feel frustrated and just give it up after one try, second try, third try.
I wasn't the only one who started programming two years ago.
And I think, unfortunately, I'm one of the few who are still doing it.
And one thing that really helped me was to join this.
It's called Chipy, Chicago Python user group.
They have a weekly meeting.
And sometimes I go just with a bunch of friends who are full-time developers.
They work on their set projects in a coffee shop.
And I just join them.
You know, not necessarily I'm going to learn.
I'm going to bug them a lot or learn a lot directly from them because we work on a completely different set of problems.
But just having that schedule, having that mental space that every Saturday, one o'clock in the afternoon to five o'clock in the afternoon is data science time, is Python time.
I think for me, that's at moments of frustration and moments of I may, why don't I just give it up already?
Those are really the things that kept me going.
That's an interesting part.
I think having somebody to ask those questions of, even if you don't like bug them a lot, just every now and then be able to go, you know, I've been stuck on this for six hours.
I know it is easy.
Could you just tell me, like, what is the thing I'm doing wrong?
And a lot of times, if you have somebody to ask that question of, I think it can make a big difference.
Because you could go to Stack Overflow.
People are going to be mean that you maybe don't know how to phrase the question quite right.
Like, it can be really frustrating.
But having just a little bit of a community like you talked about is nice.
Cece, how about you?
Advice for people who are getting into programming?
I think the most surprising thing that I learned when I got into programming is how simple it is.
Before I started programming, I thought programmers are people who have some level of IQ or some superpower.
But then I just realized that you can just pass commands to the computer and then it can do exactly what you want it to do.
So, for those who would like to start programming, I think I would just say you should just go for it.
Because anyone can do it.
Anyone can be a programmer as long as you have a passion for it and you really want to achieve something in your life.
Mostly to make time for programming.
Because I think that is the most important factor.
To make time to practice for programming.
It is difficult for most people, I know.
And most people struggle with making time to practice their programming.
So, making time is very important so that you don't forget what you learned yesterday.
And then you have to start all over again.
And I'd like to support Carly as well on joining communities.
That has helped me a lot.
I have a lot of communities that I am a part of.
And I get to ask questions.
And people reply me.
And that is very helpful.
Being a part of a community with like-minded people who are doing the same thing that they are doing is awesome.
Yeah, it makes a huge difference.
And I think I really connect with this idea that you just talked about.
That before I was a programmer, I looked at people who are programmers and I'm like, wow, now that is a smart person right there.
Like, there's no way I can do what they...
There's just no way.
But as you get into it, what I've realized is to be really good at programming.
And Joy, this also touches on what you said.
I feel like persistence.
Like, how did I know to do this thing to make the program work?
Well, because I tried 15 other things.
And this was the 16th.
And now it worked.
And so problem solved, right?
Like, if you just go, well, I tried it and it didn't work.
So I quit.
Like, that is not...
It just doesn't work that way.
Like you said, Carly, it's kind of like an experiment.
You have to try a bunch of stuff.
And eventually, something will work.
But it really requires persistence.
And I think that that's more important than being super smart.
It's okay.
Yeah, Carly?
Yeah, I definitely agree with all of that, for sure.
Just kind of ripping the bandaid off and solving a problem that you're interested in and just
kind of just start jumping in on it.
And also going to, like, groups, like, meetups or...
Because I went to a Python meetup a lot and still do.
And that...
Just being around people who are taking, like, their evenings to go and do...
They're going to be really, like, supportive and excited to share and answer questions.
And also, when I kind of related to that, like, when I was started at my job, I know I felt...
Struggled a little bit, feeling like I wasn't contributing and still just, like, trying to get familiar with the code base.
And I ended up just reaching out to one of my colleagues and just, I think, showing genuine interest in what your colleagues are doing and their, like, domain of expertise.
I was...
I think that's really, really helpful for a beginner.
So I specifically worked with our head of security and helped develop, like, static and dynamic code scans that would run, like, at build time.
And this was, like, a win-win because I was able to contribute early on.
And my colleague was able to see progress being made in an area that they were interested in.
And even if it's just for a short time, having that, like, kind of moral support and camaraderie and mentorship, like, with someone at your company can be really, really helpful to kind of get off the ground at a company.
Yeah, absolutely.
So leverage the relationships you already have to kind of get a mentor almost.
So maybe we could round this conversation out.
We're getting long on time here.
We don't have much time.
Maybe a closing thought here, Ned, on one of your other articles.
You talked about toxic experts.
And I don't want to necessarily take all the time to go into too much detail.
But your conclusion was, like, a lot of the experts bemoan the fact that there's a lot of people in the industry that don't know that much.
And, like, that missing knowledge is one of the problems.
But your conclusion was that really empathy is something that we need to make sure we have enough of.
I want to get a chance to answer your question about what beginners should do as they're getting started.
I'll quickly give some advice to beginners.
The first is just know yourself.
And, for instance, how you learn best.
I see beginners come in and say, what's the best way to learn Python?
And that really depends on how you like to learn.
Like, I, as an expert, might say, oh, you definitely have to read a 600-page book from cover to cover.
But maybe you actually like 10-minute videos better.
So just know what works for you and do it.
And if someone gives you advice that you know doesn't work for you, that doesn't mean that you're doing it wrong.
That means that they don't know who you are.
Which kind of gets into the toxic expert idea, which is that there are people who know a lot.
And they can be bad sources of help in a bunch of ways.
One of the risks that in any walk of life, not just programming, is that you know your own insides really well.
And you can look at someone's outsides and make a conclusion about their insides and compare and feel bad.
But that's because you're comparing your insides to their outsides.
So, for instance, there's a lot of stuff I don't know.
But you don't know that I don't know that.
All you see is all my answers on Stack Overflow or all the code I'm maintaining.
And you think, wow, Ned knows everything.
That's because I'm not writing blog posts about all the stuff I don't know.
So, don't compare your insides where you know all the stuff you don't know and all your doubts to my outsides where I'm just like, hey, I'm great.
Look at all my awesome tweets or whatever it is I'm doing on social media.
So, there was a great keynote by Jacob Kaplan Moss.
I forget how many PyCon's ago.
Jacob is one of the benevolent dictators of Django, or at least he was at the time.
He helped create Django and ran the Django project.
So, he was well known for that.
And he did a keynote at PyCon basically entitled, I am a mediocre programmer.
And he talked about all the stuff he doesn't know how to do.
And honestly, it was a little eye-opening.
Like, I thought, wow, Jacob, you don't know how to do that?
Okay.
That's surprising to me because you run the Django project.
But it's just a good demonstration of the idea that experts are not the superpowers that beginners might think they are.
And we are in a culture where we don't expose our failures, right?
To get back to Carly's scientific world, right?
Scientists typically don't publish their failed experiments.
And programmers typically don't.
Michael didn't publish his 15 failed attempts at getting the database to work, right?
So, it's really easy to look at all the successes that people are trumpeting and conclude that your little failed program indicates that you are bad and they are good.
And it's just not true.
So, that's my advice to beginners is know yourself and don't judge your insides by other people's outsides.
Yeah, that's great advice.
Yeah.
Want to make a quick call for empathy to everyone out there listening?
Yes.
So, for empathy, yeah.
A lot of experts are really good at writing complex code and really bad at understanding what beginners know and don't know, caring about the beginner's path that they're on.
This all got started because one of the things that came out of that side project is I wrote a piece explaining the big O notation.
And one of the comments on the piece was, you should be ashamed of this post.
And this guy thought I should be ashamed of the entire post because he had a quibble about one sentence in it, which even after looking into it, I still think he was wrong.
But he thought that, like, I was a bad person because of this one technical detail about algorithmic analysis.
Now, he might have, if he'd had a point, he could have said to me, hey, Ned, I love this piece.
There's one little place where you could have done a little bit better.
But he came in with a huge hammer and hit me over the head with it.
That's not a way to teach people.
Beginners, you are going to encounter these people.
Just walk away from them.
They may know more than you, but they're not going to be able to teach you.
And it doesn't matter that they know more than you.
They're bad people.
Just skip them.
That's pretty good advice for a lot of situations, right?
Yeah, absolutely.
Yeah, exactly.
I think we're over time.
So, let's go ahead and just leave it there.
Carly, Joy, Cece, and Ned, thank you all for being on the show and sharing all of your advice from the different parts of the spectrum you're living on.
It's great.
Yeah, absolutely.
Thank you.
Yes, thank you.
It's good.
Thank you, Mike.
Yeah, thanks.
And bye, everyone.
Bye.
This has been another episode of Talk Python to Me.
Our guests on this episode were Carly Cindy, Joy Dayton May, Cece Flora Muniqua, and Ned Batchelder.
And it's been brought to you by Linode and Ting.
Linode is your go-to hosting for whatever you're building with Python.
Get four months free at talkpython.fm/linode.
That's L-I-N-O-D-E.
Ting is the fast mobile network custom built for technical folks.
Use their savings calculator to see exactly what you'd pay.
Visit python.ting.com to get a $25 credit and get started without a contract.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher 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.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I really appreciate it.