When you think of learning Python, what type of developer or technologist comes to mind?
Is it someone looking for their first job or maybe making a move from something like .NET
over to Python and looking for a shift in their careers? While these are common moves,
you may be surprised how many folks within a tech company learn new languages like Python
just to stay within that company. On this episode, you'll meet Ron Hayden. He founded
the Software University internal training program at Apple and is now doing his own
independent training around Python. I think you'll find his story an interesting element in the mosaic of Python.
This is Talk Python to Me, episode 195, recorded January 9th, 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 @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter via
at talkpython. Hey, everyone. I want to tell you about a new course we just launched, Introduction to
Ansible. This one was created by Matthew Mackay of Full Stack Python. If you're involved with deploying a
web app or managing servers, especially Python web apps, you owe it to yourself to check out Ansible.
It provides a declarative way to provision, configure, and evolve infrastructure and applications. What
makes it even better is it's written in and can be extended in Python. Check out the course over at
training.talkpython.fm. Corporate and team options are available too. Ron, welcome to Talk Python.
Thanks. Glad to be here.
It's great to have you here. I'm really looking forward to this peek inside how Apple teaches
their internal folks Python. I think that's going to be a lot of fun.
This is my very first non-Apple thing in 25 years, so it's also a big new experience for me. And I'm a
big fan of the podcast, so really happy to be here.
Yeah, thanks. And that's really cool. So you've, as we'll get into, you've been at Apple for a really
long time and now you're just starting off to do a more independent thing. And I think that's a super
interesting perspective. So definitely dig into that. But before we get to it, what's your story?
How'd you get into programming in Python?
It started actually pretty much at the beginning. So I've been at Apple about 25 years. And early on,
when we started creating an engineering team and documentation group, I worked in the technical
publications. We went to an O'Reilly conference that was for Perl mostly. And I went to a couple of
Perl things and Perl did not speak to me. And I ended up in the corner with probably the very first
edition of a bunch of the Python books and wanting to use Python. But the problem was the people I was
working with on the team all knew Perl. So we created our entire production pipeline in Perl,
which I refused to learn for like two years. I was so annoyed about it.
I'm not doing this.
Exactly. Eventually, I learned a number of things I learned being an engineering manager.
It doesn't work to be an engineering manager if you don't know the technology your team is using.
So I had to break down and learn it. And I got a lot out of it. And I actually kind of liked something.
How good do you think you have to be? Do you have to be able to kind of read and follow?
Do you have to be able to write basic code? Do you have to be really, really good to understand?
No, when you do this, actually, that uses too much memory. Use this other technique or this
other library. What's the level when you say that?
Also, this is coming from kind of an Apple perspective where the engineering managers are
very technical and involved. You know, there are other companies where that's not so much the case.
What I found was if I couldn't get down to those details you were talking about, things would go off
the rails. In fact, what happened for a while was the team was developing our production pipeline and
things were not working out. And eventually, and this is probably not the greatest engineering manager
thing to do. But eventually, actually, when they went off to the next O'Reilly conference,
I spent the days they were gone learning Perl and rewriting the production pipeline. Once I realized,
oh my God, this is not in good shape. That was a huge lesson for me as an engineering manager.
From then on, I never let myself get out of touch with the technology of the team. And later on,
remember when we were releasing the first iOS SDK and doing a bunch of web stuff related to that. And
they had a web guy. These were good web guys. It was like, oh, it's not possible to do that. And
I was like, well, I was working on my personal website yesterday doing this and I did this. So yeah,
I think it's possible.
And here's a small example on how it's going to work, right? Yeah.
Yeah, exactly. Exactly.
You know, it's so funny. You get into some of these debates of, should we do it this way? Should we do
things that way? Is that going to work? I don't know. It always seems like there's someone that's
like, well, that's, you can't do that. That's not going to work. Or it might work in a simple case,
but not really. But the thing that solves that debate better than any other is to just have,
just go, but this does it.
Here it is.
Like that's something beautiful about programming is you can say, no, click the button and it happens.
And then we can discuss that, right?
And a theme for me, and I think we'll probably talk about it a couple of times today,
is the biggest jumps in my career and where I made the biggest impact have always been when it was that
thing. Oh, this is not possible. And I would go home that night or that weekend and I would figure it
out and I would do it and come back with the solution. And there's nothing more effective,
like you're saying, than that. And if you just sit there and say, well, I guess they're not going to
let me do this. Then you kind of put yourself in a box, you know? Yeah.
Getting to the actual Python part. So Zoom, so I always wanted to use Python. I used it a little
bit personally. That's not what our technology was built on. So Zoom forward, you know, 20 some years
and I'm running a team called Software University, which we'll probably talk a bit more about.
And we had an intern come in who was really into Python. And so he did a presentation. We do a weekly
engineering presentation that gets put on an internal website and the engineers can look at.
Like a brown bag lunch type thing where it's sort of an internal education thing.
Yeah. Yeah. Except being Apple, it's really high production value and, you know, huge amounts of
effort are put into each one. And it's something I'm really proud of that program. But so this intern
comes in and does a Python topic and we're like, well, okay, this is, this is Apple. We have Swift,
we have Objective-C, that's what our interns need. This is going to be really niche, but hey,
we're, you know, we'll let the intern do this. It'll be a good experience for him.
The interest level, just when we announced the talk was off the charts, people were emailing
saying, when is it happening? Can I show up? When are you going to post the video? And we're like,
what, what's going on here? Why does anyone care about this little scripting language?
And then it was a sellout crowd. And, you know, we actually had to turn people away.
And I'm like, hmm, that's interesting. So I started looking into it and it turned out
that everybody who didn't need to be using Swift or Objective-C was either using Python or wanted to
use Python, either just to do daily workflow tasks or more and more to do data science stuff.
So I ended up getting back into Python, developing classes. I spent two, three years just developing
these classes. And one of the great opportunities you get working in a big company like that is I had a
built-in audience. And I could also, I could kind of suck at the beginning because they're getting free
training. So they get whatever I got. And then I got to do it over and over hundreds and hundreds of
times and eventually got to really know my stuff and to get really, really good responses from the
students. And in fact, by the time I left, I never had less than two to three thousand people signed
up to take the class. It turned out that Python actually was really, really in demand. And that
kind of changed the whole trajectory of my career. And it's some of the reason that I'm here talking to
you now was I also, I knew I liked Python, but in the process of developing these classes and doing more
and more work with it, I really fell in love with it. And if it had been some other language, I might've
taught it, but I wouldn't have gotten to where I was. And I wouldn't have gotten so passionate about it
that I really wanted to devote myself to it.
That's a great story. You know, I had a similar experience in that I started learning Python and
we started working with it in the company I was at around a training perspective. And just the initial
demand was so much higher than what I expected compared to what everyone else was doing. Wow,
there's really something to this. I better personally pay more attention to this because this seems like
it's been way more important and it's going to have a bigger impact than the perception of a lot
of people around me, you know? Right. Yeah. That sounds like a little similar for you as well.
So you said you have been at Apple for 25 years, but this is one of the first things you're doing
outside of Apple. So what are you doing day to day now? What are you working on?
To my surprise, I ended up getting a book contract because once I had resigned and there was a couple of
months between me resigning and when I was actually leaving, I happened to see a book publisher on
Twitter say, hey, send us proposals, anybody. Right. And I thought, well, what the heck? And I sent them
a proposal and they accepted it. So I thought I was going to be starting up kind of external training
right now because that's something I passionately want to do. But it turns out for a little while,
I'm writing a book instead. So that's what I'm just starting to do now. And it's really interesting
and a little scary. I mean, I've written many books as being a technical writer and I've edited
many books, you know, over the years, but it's a whole different world to be writing the official
documentation for a technology, to have all the technology experts available to you and to know
that people have to read this, right? If we're documenting the API for iOS, well, if you want to use
iOS, you're going to have to read the documentation. Now I have to write a book that people don't have to
read. So I got to make it really compelling and interesting and, you know, come through on all
that. So it's a really different approach and very interesting challenge.
Yeah. Well, congratulations on the book. That's awesome. I've heard writing a book is a lot of work,
but it's going to be fun too. And you should know, right? It sounds like you've done quite a bit.
Oh yeah. Yeah.
That's cool. So that's going to be a lot of fun. You can't talk about it yet?
Unfortunately not, but I look forward to being able to in a few months.
That's really great. So right now you're working on the book and you just left Apple,
I guess maybe to give some folks a little perspective, because a lot of what we're talking
about is the stuff that you did at the time you were at Apple. Maybe just tell folks what you did
day to day while you were at Apple and then we'll get into the topic.
It changed a lot. I had this kind of weird career. I was a manager almost from day one in Silicon Valley.
It was another one of those things I was mentioning where what happened was I started at Oracle
and two months after I started, the person who hired me left. And I went into the director and said,
I want to run this team. Now I was like 20 something and I had no experience. I had no right.
And he was like, okay, give it a try. And so I became a manager early on. Over time,
I ended up running developer publications at Apple for a while. And that meant as an engineering manager,
first we created the publication workflow. So we needed to take XML and turn it into the websites
and HTML and PDF. And we also needed to parse all the headers and everything and put that all
together into the documentation. So I was an engineering manager. Then I was running developer
publications, which was really interesting, intense experience at a place like Apple, because
basically everything coming down the pipeline for the next couple of years is aimed at you.
And you have a certain amount of resources and you have to figure out what you're going to cover and
how you're going to cover it. One of the things I really appreciated about the way Apple works is
you're expected to know your job. So of course, people have opinions and they may have insights,
but for the most part, you are not told what to do. So let's say there are five really important
projects coming up. And you can't put a hundred percent on every one of those projects. You can't
put your best people on every one of those projects. Part of my job was simply to look at what was
coming, look what the impact on developers would be and decide where the resources were going to go
and how we were going to accomplish that. An interesting case, for example, was Swift.
Chris Latner, who originally created Swift, came to me two, three years before it launched and said,
we're working on this language. There are about 25 people who know about it. It was one of the most
secret projects in all of Apple. And he said, we don't know when or if this thing is ever going to
launch, but I would like you to put one of your best people on it now. And that's an interesting
call, right? Because things, projects like that come up all the time. So I mean, oh, I have a new
idea for a language or whatever. They don't go anywhere or they kind of half go somewhere and
then they drop or whatever. So to decide to put serious resources into something that might never
happen, but if it did happen would be really significant. It was an interesting call. And
fortunately, I had a good relationship with Chris and I trusted him. And so I did it. And we hired some
great people and put them on the project. That's the kind of thing I was doing from day to day.
Yeah. Yeah. That's cool. So let me ask you a little bit about Swift. I think there's a lot
of interesting parallels in that language with Python. You know, the playgrounds feel very much
like a REPL or Jupyter in some sense. The language has a lot of syntactical similarities. The thing I
want to ask you is why do you think it was successful? It's not very common that there's some big company
like Apple that's standardized on a language and says, you know, we're just going to completely
switch our most important stuff to this new API. And I felt like it was an immediate and complete
switch when Swift came along. That kind of surprised me, but I think it's a positive one more or less.
Why do you think that was?
Well, I'll also say, at least for me, and I think for us in general, the immediate adoption and the
language was a surprise to us. You can think, oh, a company like Apple, you know, we're going to say
do X and everyone's going to do X. No, we could have put out Swift and everyone could have said,
we're not going to use it. So we didn't know what would happen. We didn't know if playgrounds would be
good. We didn't know. We just had to put it out. And we also knew that it wasn't ready. But one of the
great things about Chris was he knew that they had to put out the language before it could be technically
completed. Because there was no way on earth we could come out with a 1.0 of Swift without that process of
developers using it and providing feedback. In terms of why it was successful, I think that a simple answer is
it simply works or it looks much more like programming languages that people are used to. And Objective-C
always had that oddness. I mean, back from when I worked at Next before Apple, and so we would go around trying to get
people to use Objective-C. And it was the number one barrier to getting Next Step into businesses,
because the engineers would look at these square brackets and they'd be like, what is this? We can't
possibly teach our engineers this. And it was a huge problem. So I think that when people saw a language
that looked like languages they were familiar with, that was a big, big win. And then the fact that it
incorporated a lot of really modern concepts. Interestingly, Swift actually made Objective-C
better because a lot of the improvements they made to Objective-C were actually in preparation for switching to Swift.
This portion of Talk Python to me is brought to you by Cloudbolt.
Friends don't let friends violate PEP 8, nor do they let them spend their days in an unfulfilling work environment.
Good news. Your friends at Cloudbolt want your help developing their state-of-the-art cloud management software.
Built with Django and ranked as the number one product of its kind, Cloudbolt's looking for talented engineers of all kinds.
Located in beautiful Portland, Oregon, Cloudbolt is an hour from the Pacific Ocean and Mount Hood.
You're not in Portland? Not a problem.
Cloudbolt offers a relocation stipend to the Pacific Northwest and is also hiring solution engineers everywhere.
Whether you're interested in containers, hypervisors, or just writing clean performant Python code,
Cloudbolt would love to hear from you.
Visit talkpython.fm/cloudbolt for more information.
So you were at Apple for a long time.
It sounds like if you wanted to work there, definitely knowing Swift and Objective-C might be worthwhile.
But also, it sounds like there's just quite a rich community of Python programmers there.
What advice would you have for people listening to this show who are really mostly passionate about Python if they want to work there?
I've run into this, too.
I went to my first PyCon this year, and I was talking to someone, and they're like, oh, I had no idea Apple used Python.
I might have applied for a job there if I'd known that.
I think that it is absolutely a big part of things, especially if you're doing any machine learning or data science, you will be using Python going in.
Unfortunately, the big caveat, I have to say, is because macOS ships Python 2.7, that's what's used internally and almost everywhere.
Not everywhere, but almost everywhere.
And that's going to be a challenge, right?
Especially as we hit 2020, especially as pandas and things are dropping support.
Yeah, pandas just announced that they're dropping support soon.
Right, right.
I mean, these things are happening, right?
I think in the data science fields, then, you have a good chance of being able to go to 3.
And if I were continuing there, I would have really been pushing that.
There are a lot of QA people using Python.
There's a lot of internal QA Python libraries.
And unfortunately, in that case, I don't see it changing anytime soon.
And I think part of my discussion today is that I know we're all excited to get to 3.
I'm excited to be using 3 now.
The shackles are off.
Do whatever you want.
And I've been listening to a lot of your recent episodes where people are like, okay, finally, we're there.
I have to say, we still can't forget about the fact that there are going to be thousands and thousands of developers in these large organizations with huge amounts of built up technologies that aren't going to switch anytime soon.
And I think that's interesting.
When you have, let's say, when you have a QA library that is highly specific to what your team does and that has been built up over five plus years and has a huge amount of code in it, we can all say, okay, they're dropping support for Python 2, so you've got to move to 3.
Where are you going to go?
And I think that's a huge amount of time to do that.
I think what I would encourage in any organization at this point is don't let yourself get in that trap.
If you're going to go to 3.5 million.
And if you're dealing with a technology like this, you've got to take responsibility.
It's like those projects I was talking about before.
Like, go home and start it in 3 and say, here it is.
And start, you know, whatever you can do to move it forward.
Don't just accept it.
Because what I fear in some of these cases is you're going to be another five years down the road.
And then you're really not going to have a choice at some point.
You're going to have to switch.
And you're going to be kind of up a crick.
Yeah, you definitely are.
You know, I feel like the two big sticks in this debate.
There's lots of carrots.
But the two sticks.
One is security.
And sometimes it doesn't matter, right?
Like an internal QA testing library probably is not exposed on the internet.
It probably is not a security risk, really.
But then there's also the new shiny things that you don't get.
Right now, the machine learning libraries are Keras, TensorFlow, and so on.
But, you know, wait until either they drop two and come along with some really great feature that you almost have to have.
Or there's something better that's Python 3 only, right?
At some point, there's going to be like, why can't we keep up with this company?
Well, they have all the good tools.
And we're stuck on these tools that are last generation.
But that's not a this week, next week, one year.
That's a by the time you realize it, right?
That technical debt is bad.
Yeah.
It's deep, deep, and it takes a long time to get out of it.
Here's a funny thing.
In the teaching I would do, I would talk about here's how it works in three.
Here's what we don't get if you don't move to three, et cetera.
I actually think one of the features most likely to get people personally motivated is F-strings.
Yeah.
They love them.
They're great.
I actually have a theory that if that feature had been rolled out early on in three and not put into two, they would have had more conversion because it's just one of those things where you're like, I want that.
And then that gets you to start making changes, you know?
Yeah.
It's definitely really much more concise and it's faster, right?
Yeah.
So there's like, it's good just all across the board.
You say faster.
I wonder, you know, in some cases, probably faster is going to be a thing as well, right?
Like Python 3 is starting to be faster in general, right?
So if you can run a quarter fewer servers, you know, 50 instead of 80 servers, I don't know, maybe that starts to add up.
But that's a rare, it's a big company problem, not most people's problems.
Most people aren't, you know, scaled that far out.
In my experience, the scale issues would be mostly in the data space.
And so they've already got lots of reasons, right?
It's just one more big reason for them to do it.
Yeah, for sure.
Okay.
So let's talk a little bit about this software university thing.
You talked a bit about it.
How did you end up founding that, the team there?
Tell us what it is and then how you got started on it.
Yeah.
Well, it's the thing I'm most proud of in my career at Apple.
And I first have to say, it's not Apple University.
There's a thing called Apple University.
And people always confuse them, which is my fault because I worked with Apple University.
I was big fans of the people there.
They teach sort of culture and how to be successful at Apple.
And so when I was coming up with the team, I wanted a way to kind of associate ourselves
with them and kind of make it clear what kind of thing we were.
Unfortunately, then everybody just thought we were Apple University.
But Software University was focused on teaching software skills.
We do onboarding and teach software skills across the company.
And it started out with that weekly program I talked about.
The head of software engineering had asked me to put together this program.
And we ran it for like 10 years.
Literally, me and a colleague, a couple of colleagues in our lunchtimes would do all the work necessary
in addition to our regular job to have this weekly presentation.
It was very popular.
And eventually, you know, after literally 10 years, we I think there was a big performance move.
There was a release where they had to the mandate was to improve performance across the board,
like 20 percent or 30 percent or something like that.
And we said, well, you know what?
We have this mechanism.
We have this way that we're able to broadcast stuff that everybody likes and uses.
We can help you with this.
We can do a special program to educate people about what they need to do to improve performance
across the board.
And so we did a whole bunch of focus topics on that and had real experts across the company
doing it.
And we put out white papers, which each one of their talks to help out.
And that was so impactful that I was then able to say, well, you know, we could keep doing
this kind of stuff if you gave us some headcount.
And that became Software University.
So a very small team, huge impact across the organization, you know, teaching because one of
the funny things for a few years after Swift came out and still true in large part is the
outside world was using Swift.
We were not because we had such a massive, massive code base in Objective-C that, you know, it was
going to take a long time to begin that transition.
So we're actually in a situation where before each worldwide developers conference, we would
run special boot camps to teach the people who are going to be at the conference.
Here's what's going on in Swift.
Here's what you need to know.
Here's the new features.
Because they wouldn't personally have been using it.
So that really blows my mind.
I've seen that before.
But it, you know, you think about it, it makes sense.
But just from the outside, it doesn't really.
Right.
Like I've seen that other big tech companies that, you know, have similar technology stacks
and whatnot.
And what's really surprising is they'll bring in external training companies to teach their
own programming language to their people or their own developer APIs to their people.
And it's like, how can this possibly be that you work at company X and, you know, someone's
coming in to teach you about the premier technology.
It's a big group of people, right?
And they all come with different skill sets and they don't all work on the same thing.
But it's, it sounds like a similar story here.
And you also have to realize they're not necessarily all bought in, right?
Like, so something like Swift comes along, a small group of people did it.
Yeah.
They had, it's a very opinionated language and different people have different opinions.
And since they have the option of using another language, they may be like, eh, I don't
like it.
Our team isn't going to use it.
And then you have a whole kind of, you know, education and process.
Or even if you like it, you might think it won't succeed.
So you're not going to mess up your product and your, your thing by choosing this other
library or language.
All right.
So maybe we talk a little bit about your experience teaching Python at Apple.
So you had, sounds like you've done a lot of classes there internally.
Yeah.
So what was that experience like?
Well, when I started out, I would teach one set of content two ways.
So one was for new programmers and one was for experienced programmers.
It was the same content, but for new programmers, I would go about half the speed.
And over the years, what I learned was that was the entirely wrong approach.
The need of experienced programmers versus new programmers and new programmers, at least
my students, these were people who were probably not trying to get a job programming.
They had stuff in their, in their job that they wanted to solve with programming.
Although for QA people, many QA people came in and did manual, what we call black box testing,
especially on iOS.
Almost with a script and a checklist, right?
Yeah, exactly.
And for a long time, that was okay because, you know, there weren't that many features,
but now that it's cloud and this and that and five zillion apps and, you know, your whole
life is on it.
And there are many different models of the phone.
We could no longer just do manual testing.
So people who had never intended to be programmers were suddenly now being required to be a programmer
as part of their job.
They were also my students.
What I found was the goal for new programmers versus experience is very different.
I originally thought my job was to give them a survey of like, this is what, here's a
little bit of everything in programming.
So you have an idea of what programming is about.
And by the end, I dropped probably 75% of my content.
And I decided, no, the goal is by the time you leave this class, that you're comfortable
with the idea of sitting down, starting a Python file and trying to solve a problem, any problem.
So that's what I just tried to get to.
And so I put a lot more repetition in because I also realized having been programming for
so long and writing about it for so long, I would think, okay, we talked about for loops.
Now we move on to the next topic.
Well, no, you know, they needed it three, four or five times to understand what a for loop
was.
Because there's different levels to that, right?
Like if you're a professional programmer, you just need to learn Python.
So you programmed in C# or Java or whatever, and you've for looped it to death, right?
You know, the concept of the for loop perfectly.
It's just like, okay, well, how does the syntax work?
And what are the gotchas?
You're good, right?
Like you can get that really quick.
But if you're like, well, I got to do this a lot.
And I don't want to just write it over and over.
Like the whole idea even of a loop, that's a different thing.
And that's where the repetition, I think, is super, super important.
Because maybe you take one slice of that onion each time through, and eventually you get the
whole concept.
Yeah, yeah.
So that is where I ended up.
The other thing I started doing right toward the end that was really successful, to my surprise,
is different classes go at very different speeds.
So I would have people who just couldn't even get through all the material because the people
in the class needed a lot of time.
And I would have another class, still a new programmer, that would just zoom through the
material.
And I'd be kind of like, well, okay, we're done for the day.
Go home.
And people are like, well, what?
We've got another hour or two left in the class.
And so what I started doing was saying, okay, we're going to do bonus topics.
Does anyone have a question?
Or I would even start to teach one of the experience topics or something.
Because someone would ask about regular expressions, which I had stopped teaching to new programmers.
And I'd say, okay, let's talk about regular expressions.
And that turned out to be really valuable.
People really appreciated that because they were, first of all, they seemed to really enjoy
the fact they could ask any question and I could answer it because I'd been spending so
long doing this stuff and I'd developed so much content.
And it let them see things that they wouldn't normally see.
So that was interesting.
It's that combination then of repetition and not teaching too much, but also being willing
to satisfy their curiosity and spend a good deal of time just talking about whatever the
students wanted to talk about.
Yeah, I think that's a good point.
Basically, any presentation and teaching training is like a really long presentation, right?
Leaving some room for a little bit of slack for exploration, right?
Like, I'm going to show them all this stuff, but let's leave five minutes here in like a
conference speech or let's leave an hour at the end of this week so that when they say,
that's great, but I want to put that on the web.
How does that work?
Or, you know, I actually need to work with CSV files.
How does, is that possible, right?
Like, well, actually import, you know, dictatorator, right?
So things like that.
I think that's a huge value.
It often gets lost because you're like, well, we've got to cover all these things.
Yep.
And then for experienced programmers, the goal I developed was, of course, a lot of times
they are just coming in wanting to know how does a for loop work in this and how to,
and my goal was to kind of trick them into saying, okay, I'm going to teach you Python.
But what I really focused on was teaching them to be Pythonic and really getting across like,
don't do that thing where you learn a little bit of the language over the weekend and then
you never really know how it works.
And I can't tell you how many times people who had been using Python for a while would
take the class and they'd say, oh my God, I never actually understood what a comprehension
was before.
I was just copying and pasting these things.
I didn't really know what they did.
Now I understand what they do.
And that, so that was my goal was to get them to actually understand it.
And also to use things like comprehensions, which as I'm sure you've experienced non people
who've not immersed themselves in Python don't end up using something like that because it's
not, it doesn't exist in where they came from.
Right.
If you don't, you don't change your mindset.
Yeah.
You don't even know this is now a tool in your toolbox or when it applies, right?
Same with generators.
I have to believe that generators are out there in other languages,
but I never ran into that myself.
And so I would have to spend a lot of time explaining not only what they were and how
they worked, but like why you would want to use these.
And of course, if you're dealing with large amounts of data, that can be a really critical
feature.
I think generators and generate expressions and all that are, they're just like magic and
people haven't taken the time to get to know them.
Like you say, if they're doing anything with lots of data that coming off of the network,
it's coming off of disk, like it, it can just make all the difference.
Yeah.
There's some other languages.
I think maybe even JavaScript is getting it.
I haven't been tracking the new JavaScript that much, but I heard something about, about
that.
But anyway, it's, it's out there some other places, but I, it definitely is really well
embraced in the Python language.
Right.
I think that's great.
Yeah.
There was a recent article blog post, whatever you call it by somebody who said, I can't remember
what the name of it was.
Something to the effect of like eight reasons.
I hate Python and I'm just going to say it.
I hate Python, something like this.
And it was, it was basically the prototypical example of the person that you described not
going through the process.
Right.
They had to work in Python and they really just liked C and some other languages that
were basically C languages and they just learned enough to make it work.
Right.
They're like, okay, well I have to type this to get the library.
I have to type this to, but they didn't actually bother to, to learn.
Learn very much about any of those features.
So they're like, this thing completely sucks.
The way that you import stuff is horrible.
I don't know where stuff comes from.
It's like, well, there's a different way you can do it.
You don't have to do imports, you know, from this import star, there's other options.
Right.
But it was, it was basically, this person was really frustrated with Python because they
had said, well, look, Python is easy.
I'm going to learn it in the weekend.
I'm going to learn it really quickly.
But soon as I get it to work, I'm going to stop investigating.
As soon as I get something that works.
And I think that's actually a little bit of, a little bit of the language is curse of
its success, right?
Like you can get a cursory understanding of it quickly, but then if you don't keep going,
you actually miss why people like it.
Right.
And I would say for myself, the feature that I really just started using more and more,
and the more I understood it, the more problems it solved is the exception handling.
I wish there was a different phrase than even exception handling, because that implies, oh,
this is just what you do to deal with errors.
When the more you absorb the full set of features around exception handling, the more you start
to realize, no, I can really solve code problems and structure my code around this in ways that
other languages just don't allow for, right?
The fact that you can basically return any kind of value in an exception allows you to
do just really great things that if you just think of it as, oh, this is what I have to
do when there's some error that might show up.
You'll never do those things.
Yeah, absolutely.
And the more subtle stuff like with statements and context managers for sort of durability
and all those kinds of things.
Absolutely.
This portion of Talk Python to Me is brought to you by Rollbar.
Got a question for you.
Have you been outsourcing your bug discovery to your users?
Have you been making them send you bug reports?
You know there's two problems with that.
You can't discover all the bugs this way.
And some users don't bother reporting bugs at all.
They just leave, sometimes forever.
The best software teams practice proactive error monitoring.
They detect all the errors in their production apps and services in real time and debug important
errors in minutes or hours, sometimes before users even notice.
Teams from companies like Twilio, Instacart, and CircleCI use Rollbar to do this.
With Rollbar, you get a real-time feed of all the errors so you know exactly what's broken
in production.
And Rollbar automatically collects all the relevant data and metadata you need to debug the errors
so you don't have to sift through logs.
If you aren't using Rollbar yet, they have a special offer for you.
And it's really awesome.
Sign up and install Rollbar at talkpython.fm/Rollbar.
And Rollbar will send you a $100 gift card to use at the Open Collective, where you can
donate to any of the 900 plus projects listed under the Open Source Collective or to the
Women Who Code organization.
Get notified of errors in real time and make a difference in Open Source.
Visit talkpython.fm/Rollbar today.
When you're teaching the class, you said you use Jupyter.
I want to tell people a little bit about how that works.
Yeah, I actually, this came out of going to the PyCon.
I knew about Jupyter, IPython, et cetera, but I'd never really got around to playing with
it.
And then when I saw, I took some tutorials there.
And when I saw how it was being used, I was like, oh my God, I have to use this in class.
And I literally went that evening from the conference and rewrote all my material in Jupyter.
And now I've become obsessed.
I basically, I write my website in Jupyter.
I do my coding in Jupyter.
And I've written my own conversion scripts to produce things in HTML and that sort of thing.
And I've just found it to be this amazing environment.
And I'm also a big fan of Markdown.
And I think that Jupyter is a great way to get more use out of Markdown because what
people would typically do, and this is where you end up with restructured text and all that,
right, is they just keep adding features.
And the brilliance of Markdown is simplicity.
And if you start adding more and more tags to it, you lose the benefit.
Jupyter, because each cell, you can put tags in there and do other things.
You can put a structure on top of the Markdown.
So for example, what I'll do is I will add a tag to a cell that says center.
And then when I output the HTML, I center that content.
Well, I didn't have to add to Markdown some kind of center tag.
And so Markdown does what it does.
Jupyter does what it does.
And I just find the combination to be really brilliant.
And I think one of the reasons I'm so passionate about it is because I spent my career dealing
with documentation formats and creating formats, you know, creating templates in XML and such.
So what I saw how hard it is to do a simple format is almost impossible to design a simple
documentation format because the minute you have customers start using it, they start saying,
oh, well, I want you to add this and I want you to add that.
And I spent a lot of my career saying no to writers.
We're not going to give you that because we give you that.
It's going to cause this problem and this problem later down the track.
So when you look at that combination or you like you look inside a Jupyter file and see
that it's just a JSON file, a very simple JSON format that is extremely easy to parse, you
realize this could only happen by one or two people doing this thing and then not letting
themselves get sucked into adding all these features that would then turn it into a mess.
Right.
They didn't try to write Word for Python.
Yeah, exactly.
They just tried to create this nice little notebook format.
That's cool.
I think, I do think there's a lot of value for using Jupyter notebooks.
It must be nice to have as like class handouts, like here's the notebook that we went through
because it lets, you know, it's great to have like a PDF of the slides, right?
Okay, super.
I can type that back in or get it somewhere.
But, you know, the Jupyter version, you get to explore.
Right.
It solves many class problems for me because I used to, I have the students using Sublime
Text usually.
I like Sublime Text for teaching because in addition to having good syntax coloring and general good
Python support, it shows the results of the script in line, which is most other things
you use, you know, it either a DB editor or something's going to pop up a different window
or people have to look somewhere else for the results.
So Sublime Text is really good for students.
And I was teaching with Sublime Text live, but then someone would ask a question and I'd had
to comment out some of the code and put in some new code.
And then especially for new programmers, they would have no idea what was going on because
I'm changing around everything.
When I moved to Jupyter and someone asked a question and I can just enter a new cell and
put the code in and run it, it solves so many problems.
So it's really elegant for teaching.
Yeah, it definitely seems like it.
I mentioned earlier that I felt that the Playgrounds was something like Jupyter, the Swift Playgrounds.
Do you think if Jupyter had been something that, say, Chris Lattner and folks had been playing
with already and maybe had a little more traction, do you think Swift Playgrounds would not exist?
And there'd just be a Jupyter version that ran Swift?
It's a good question.
And I know that I've seen there's at least a couple of projects out there of people working
to get Swift integrated into Jupyter.
I know, I mean, Chris and company were experts on all sorts of languages.
And I know that there were various influences on Playgrounds.
I guess the way I'll answer your question is I would say if I had known about Jupyter at
the time when our department got to be somewhat involved in the process of designing Playgrounds
because it was in part a documentation feature.
And so we worked with them on all that.
I think if I had been aware of it, I certainly would have pushed for more of that because I
feel that that simplicity would be served.
However, it may not have been the right thing for Apple.
An important thing about something like Playgrounds is that the fact that you can run these really
cool little games and other things and show visually what's going on there, that's a really
helpful thing to promoting the language and promoting the learning aspect of it.
So, you know, you have other concerns that you have to think about.
Yeah, of course.
So you've had a lot of experience at these large tech companies working with Python.
And we talked a little bit about the two and three divide and some of that technical debt.
You had a story about converting from one language to another back in the publishing days.
Tell us a bit about that.
Well, so we had this whole publication workflow and we decided to do the next big jump, right?
And we wanted to get out of Perl and we wanted to fix all the problems, you know, that you
have when you have a big thing that's been running for a long time.
You just think if we could just write this from scratch, it would be all the problems would
be gone.
It'd be perfect.
I made every mistake and I've learned now that this is a pattern, right?
And it's a pattern that I warn people about, which is, okay, well, yeah, we're just going
to write the new thing.
And then what we will do is because in the meantime, we have to keep things publishing every day,
we'll write a bridge script.
So it will bridge from the previous stuff, you know, the previous version of the content,
source content to the new version.
And then at some point, we'll just cut off the bridge and we'll go forward with the new
stuff.
That's not how it works.
And what happens is when you have an enterprise level production workflow that's been around
for a long time, there are hundreds or thousands of edge cases in business cases that have been
built in or bolted on or whatever to fix all sorts of problems.
When you write the new thing from scratch, you're rediscovering all of those.
So what happens is you start saying, well, we'll have the bridge script fix those things.
Well, the bridge script is supposed to go away, but it starts becoming the biggest part of the
project and it starts taking up all of your time.
And now you're doing duplicate work often because some new feature will come along and you have to
put it in your old production workflow because you're still using that.
And you have to put it in your new one or you have to do something.
And so the end of the day, we had this great new version of our workflow.
The HTML output was wonderful.
It was a huge improvement.
And I had to kill the project because every time you clicked around, every third or fourth
link would crash this thing because it couldn't deal with all of those edge cases and everything.
And so at the end of the day, what I learned, and I think a lot of people have learned this,
is if you have a large enterprise level workflow, accept it.
You have it.
Your only option is to gradually convert it piece by piece.
Find ways to isolate certain pieces of functionality and then upgrade that portion of it and do it
piece by piece.
But don't think that you're going to be able to run two different workflows and then switch
from one to the other.
Maybe someone out there has made it work, but I think it's a recipe for disaster.
And it's one of the biggest mistakes I ever made.
That sounds really not so good.
So you had the Perl one before and you tried to switch it over to Python through this bridge
thing, right?
No, we weren't doing Python.
I even forget what it was we were switching it to at the time.
This was before Python was a factor.
Sure.
So, but if that one got canceled, did you just go back to the Perl one or is there now
something new?
Well, I haven't been doing that for a long time and I know, I think they finally did do
a whole new production workflow.
But yeah, we were stuck with the Perl for another five plus years.
And it wouldn't surprise me if there's still a bunch of it in there because, you know, it's
really hard to get rid of all that.
Then you get into the situation.
I think this is where we're headed with Python 2 as well, where you start having to ask engineers
to join your team or join your company to do something like Perl, right?
And you get fewer and fewer people who know how to do it and you get fewer and fewer people
who want to do it.
I'm always going to do this classic joke.
If you've heard this of the guy who's a COBOL programmer and he was so sick of everybody hiring
him for COBOL because there weren't COBOL programmers around that he had himself frozen so that in
the future he could have a different career.
And when he's unfrozen and wakes up, you know, Bill Gates is standing over him and he's like,
oh, Bill, great.
What can I do for you?
And Bill's like, you're the guy who knows COBOL, right?
Exactly.
Yeah, I can totally see that.
And there are so many projects that are stuck in these old languages, you know, BB6 even.
There's so much in the enterprise space that people put together.
Really complicated.
And there's better paths forward.
But I think it is all these little tiny details, right?
You know, it's one thing to say, well, it has to do X, Y, and Z.
It's like, well, but there's like a hundred little bizarre tweaks that we catch it under this
circumstance or we do that differently if it's from that department or whatever, right?
It's crazy.
Yeah.
Well, I definitely think there's going to be some good consulting opportunities for people
that know how to take Python 2 code to Python 3 code.
I don't know when the peak of that opportunity will be, but, you know, maybe spring 2020 or
after the first really bad security problem found, it's Python 2 that's not going to be fixed.
But like this COBOL programmer type person, having those skills and knowing how to do that
switch actually might be really valuable.
In the meantime, what people can do, and I started pushing this really heavily in my experience
classes, is start using Python 2 like 3.
You know, use the features that were backported, especially for dictionaries and such.
As near as I could tell, I could rarely find a tutorial or a book that talked about the features
that had been added, say, to dictionaries after the fact that turned them into the same
thing that they do in 3, right?
So it's where you're getting those different objects.
Instead of getting a list, instead of everything being a list, you're getting the objects back
that don't take up memory and such.
Like X range and that kind of stuff, right?
Yeah.
And in the dictionaries they have, what they have is for each thing, if you ask for values
or keys, there's another method, which at the moment now I'm spacing on it, which will,
instead of giving you a list, will give you what you would get in Python 3.
And so that's an easy way, because I think that's some of the code that is most problematic,
right, are things that are relying on you getting a list back, and it's no longer a list in Python 3.
So some of the easiest ways to future-proof your code is just to use those things when they're
available.
Yeah, for sure.
So on these big projects, do you think you can test your way through that?
Like, if you could imagine every single case that is like one of these weird edge cases,
and you just wrap up the app and you feed it the inputs and you check the output, possible?
Reasonable?
I think it's great if a team has been disciplined enough to do that.
And there are times when I, like anybody, well, I really like unit testing.
I literally like test-driven development.
I fall in and out of it, as I think most engineers do.
But when I was really good, especially on projects like when I created, say, a CSS parser,
and so for every single feature that I would put in tests, then my parser wasn't very fast,
so my team got annoyed about that.
And one of them did to me what I did to people, which is went home and wrote a faster version.
But because I had put a test in for every single feature, we were able to just swap in the new code with no problem.
Right.
Run it.
Does it pass?
Good.
Yeah.
But I would argue it's, I think it's getting more common as people have gotten better about this,
and testing functionality has gotten integrated into the languages and frameworks.
It's relatively rare that people have done that amount of testing.
Yeah.
That's probably true.
All right.
Well, it's definitely an interesting problem.
And I know a lot of people have it both trying to cross languages,
and we're going to have it with this 2 to 3 thing that's coming.
I do think it's less bad with 2 to 3.
It's not like you're starting completely from scratch.
I mean, you may decide to start from scratch with Python 3 and rewrite the thing,
because that's both tempting and sometimes the right way to go.
But at least it's more of an upgrade, like it's a really big upgrade to your project,
rather than you can't add Python to Perl progressively to it, right?
I think there's the same risk, which is if you don't spend some time truly learning
what's different about 3 and the philosophical changes to deal with memory usage
and such more generators everywhere, that kind of stuff.
If you start converting your code without philosophically understanding the differences,
then you're not going to get the benefits from 3.
And you may not even realize some of the stuff that you need to change.
Yeah, that's a good point.
It's very similar there.
All right.
Well, you've done all this cool stuff at Apple, and you've been there for a long time,
and you hear a lot of good things about the company,
but leaving and breaking on your own, that's a pretty big step.
I know from personal experience, it's a big deal.
What was the decision making there?
Yeah.
Well, it was great working at Apple.
I had a great career there, and people were very supportive of me
and let me do all these wonderful different things.
And actually, I feel a little unfortunate that there's been some stock hits recently and stuff.
So people have been saying to me, oh, you're getting out because of that.
And it's like, no, no, no.
Actually, if anything, that would make me want to stay because as one of the people
who's been around a long time, you know, I have experience with the ups and downs of things.
It's been a lot lower historically at some point.
Oh, yeah.
So every once in a while in your job, something comes up that's a little annoying,
and you think about things.
And I realized, oh, it has been 25 years.
And oh, I'm really loving this Python stuff, and I want to be part of the community.
And for all the wonderful things at Apple, the way it works right now is that you kind
of have to be invisible when you work there.
You know, you're not really allowed to speak, or you have to do a lot of work to be able
to speak.
You know, you can't necessarily write articles or write a book or whatever.
So realizing that, okay, I've been here 25 years.
This is a really nice career progression.
I want to be a part of the Python community.
So I want to be able to be on a podcast, for example, and write a book.
And also, honestly, to say, you know, well, if this is what I'm going to spend the next
chunk of my career on, yeah, I want to be working in the latest, greatest stuff.
And I felt personally that my responsibility, if I stayed, would be to put a lot of time and
effort into, you know, some of your other episodes have covered getting the whole organization
to switch.
And I've been through those conversions many times in my career, and it's just not what I
wanted to focus on.
I just wanted to make the jump.
And so you combine all those things, and it's like, yep, this is the right time to
do this.
Yeah, it's definitely a good time to switch into Python.
It's, you know, so much energy, and it's definitely building.
And I can relate to a lot of those things.
You know, I worked at many small companies, but also at a large company.
And I just, for me personally, I just decided, you know, every day I get up and I go to these
meetings and I work on these features and these projects.
And there's a non-trivial chance this project is getting killed.
I'm pretty sure this feature is not actually going to make a difference to anybody, you
know?
And I just thought, well, is that kind of stuff what I want to put my energy into every
day?
Like, what if I could wake up every day and work on what I think is going to be most valuable
to the community or people or customer, whatever, right?
Like, that would be really great, right?
So that's kind of what gave me a similar boost is just like, I feel like maybe I'm giving
like 20% of what I could to the world at my job.
Right, right.
Not because I'm not trying, but because I'm being told to work on X, Y, and Z.
And like, only Z is like partially valuable, right?
Yep, exactly.
Yeah.
Interesting.
Okay, so you're starting off on this journey to do training, teaching, and your sort of own
thing.
How can people, you already have some classes that you're teaching, right?
Yeah, I am definitely set up, as it happens, both in Python 2 and 3, to do the general new
programmers and experienced programmers.
And the same focus I talked about, for new programmers, it's just getting them comfortable
with what programming is and that they can solve problems and kind of setting them up to learn
more.
And with experienced programmers, it's really teaching them how to be Pythonic and how to
use the language the right way.
Nice.
And where can people find out about it?
So I have a site, which I'm still kind of, you know, working on getting up to speed.
But that is conquerprogramming.com.
So I like the concept of conquer programming by learning Python.
And they can go there.
And I'm on Twitter as conquerprogram1.
There was some other conquer program out there.
And that will do it.
Nice.
Okay, yeah.
So people can check that out if they're interested.
That's great.
All right.
Well, I guess we'll probably leave it there for the teaching at Apple topic.
And I'll just ask you the final two questions.
So if you're going to write some code, and based on what we talked about, I may have two good
guesses.
But what editor do you use for Python anyway?
So basically, I have three answers, right?
Sublime Text I use in classes, at least for students.
PyCharm I use if I really am needing to solve some bigger problems and use more of the profiling
and debugging sorts of stuff.
As you can guess, at this point, my day to day coding and what I'm doing all my personal
stuff in is Jupyter.
Because I actually find it to even be a good development environment.
Because everything is in memory, when I'm having a problem, I just, I can interact live with what's
going on.
It's like a super debugger, right?
You can just go, what is X?
And I love the fact that I can have actual documentation and links.
So I think now, if I were doing team development in Python, I would seriously consider having
the source be in Jupyter with actual documentation and actual links, and even things like screenshots.
So you can actually put in screenshots to show what it is that you're dealing with, say, on
a web page or something like that.
And then if necessary, just export it to Python to be run on a day-to-day basis, but do the
actual source in Jupyter.
So I know that there are then challenges about importing things and other stuff.
So there'd be things to figure out.
And I know that there's these JupyterLab and other stuff, which I haven't played with yet.
But that's definitely where I'm at.
And that's an interesting idea.
OK, notable PyPI package?
Well, I was thinking about what made the biggest difference.
And so in Python 2, the biggest difference to me was a package called Unipath, because it
brought all the file functionality under one class.
And so you didn't have to have three different libraries and different APIs.
And it really cleaned up my code.
And I know they proposed it.
There was like a PEP for it at one point.
It got turned down.
And now there's Pathlib, which is part of Python 3.
So I guess I would just say, if you're doing all the file stuff, I really would consider
looking at Pathlib, because it just cleans up your code a lot.
And it's a much nicer way to deal with things.
Yeah, that's a good recommendation.
And way to grab one out of the standard library.
That also works.
So the other thing that I've started pushing in my experience classes when getting to the
data science stuff is in figuring out how to teach pandas, I started splitting out series
and teaching that first as kind of a fancy list and dictionary.
And then a data frame just becomes a dictionary of series.
And it was easy for the students to absorb.
And I started to realize, you know, as far as I'm concerned, I think the series class should
be thought of as more of a general case problem solver, because it's a dictionary and it's
a list and it does things really fast.
And it takes regular expressions, which is huge when you're doing a lot of the tech stuff.
So I've started pushing the idea of, hey, don't think of series as a spreadsheet thing.
Think of it as a really useful list class that you could use for anything.
So that's the other notable thing.
Yeah, very interesting.
I definitely like the Pathlib stuff these days.
I'm starting to really appreciate it and think about, you know, ditching OS.path and all
because of the fluent API, the chaining, right?
Like create a path, dot, rename, you know, dot ensure the parent stuff, all that kind of
like all in one line.
It seems really, really clean.
So yeah, I like that recommendation as well.
All right.
Final call to action.
People are out there learning Python or they want to teach Python.
You know, what advice do you have for them?
Well, I think I'm going to come back to a theme of this whole thing, which is if you're in an
organization that's in Python 2, you've got to take personal responsibility to do something
about it.
Either get your organization to change or think about your own role in that because do you want
to be in a 10-year-old version of the language for the next five years or more?
You know, coming from where I'm coming from, that's sort of the biggest thing for me.
I think the one other thing I would say in terms of teaching is one of the things I'm
evolving towards and working on in this book I'm working on is I kind of think that teaching
new programmers programming is almost the wrong thing.
And for many people, they're not there to become a programmer.
They're there because they have stuff in their work life that they want to improve and they want
a new tool to do it.
And I think that if we focus more of our teaching of new programmers around, hey, here's a problem
you can solve.
And by the way, along the way, you're going to learn some programming.
That's a much more practical way to do it.
One of the books I really like along those lines is the Automate the Boring Stuff with Python,
which is very focused on that and influential to me.
So even though I teach a generic learn how to program class, more and more I'm moving away
from that and I'm going to focus on helping people solve specific problems.
Yeah, unless you're committed to a four-year computer science degree, you need those short
little wins.
It's not like, well, this year I'm going to learn all about loops and data structures.
Next year I'll do something with it, right?
Yeah, exactly.
That's not reasonable for most people, especially if it's a week-long class or something online
for a few hours or something like that.
I totally agree.
All right, Ron.
Well, thank you for sharing your experience and your story.
It's really interesting.
Appreciate you being on the show.
Thank you very much.
This has been another episode of Talk Python to Me.
Our guest on this episode was Ron Hayden, and it's been brought to you by Cloudbolt and Rollbar.
Spend your work time fulfilled.
Write Python and Django code at Cloudbolt, developing their state-of-the-art cloud management software
in beautiful Portland, Oregon.
Visit talkpython.fm/cloudbolt to join the team.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have
gone unnoticed, until users complain, of course.
Track a ridiculous number of errors for free as Talk Python to Me listeners at talkpython.fm slash
rollbar.
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.
Bye.
you
Thank you.