#195: Teaching Python at Apple Transcript

00:00 Michael Kennedy: 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 @talkpython. Hey everyone, I want to tell you about a new course we just launched, Introduction to Ansible. This one was created by Matthew Makai 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.

01:43 Ron Hayden: Thanks, glad to be here.

01:44 Michael Kennedy: Ha, it's great to have you here. I'm really lookin' forward to this peek inside how Apple teaches their internal folks Python. I think that's going to be a lot of fun.

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

02:01 Michael Kennedy: 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 and Python?

02:16 Ron Hayden: It started actually pretty much in the beginning. So I've been at Apple about 25 years, and early on when we started creating a, 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 a 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.

02:59 Michael Kennedy: I'm not doin' this.

03:00 Ron Hayden: Exactly. Eventually I learned, as a number of things I learned being a 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 some of it.

03:14 Michael Kennedy: How good do you think you have to be? Did 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's uses too much memory, use this other technique, or this other library, what's the level when you say that?

03:29 Ron Hayden: 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 awhile 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 when, I 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, he 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 .

04:36 Michael Kennedy: And here's a small example on how it's going to work, right?

04:40 Ron Hayden: Yeah, exactly, exactly.

04:41 Michael Kennedy: 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, go, but this does it. Here it does.

05:00 Ron Hayden: Exactly, yeah.

05:01 Michael Kennedy: 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?

05:07 Ron Hayden: And the theme for me, and I think we'll probably talk about it a couple 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? But getting to the actual Python part, 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.

06:01 Michael Kennedy: Like a brown bag lunch type thing, where just, it's sort of an internal education thing. Nothing formal.

06:06 Ron Hayden: Yeah, yeah, except being Apple, it's really high production value, and 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 Apple. We have Swift, we have Objective C. That's what our engineers need. This is going to be really niched, but hey, we're, 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's goin' 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, in 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. In fact, by the time I left, I never had less than 2,000 to 3,000 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 is some of the reason that I'm here talking to you now, was that 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 have 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.

08:12 Michael Kennedy: 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. 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, 'cause this seems like it's being way more important, and it's going to have a bigger impact than the perception of a lot of people around me you know?

08:44 Ron Hayden: Right.

08:45 Michael Kennedy: And 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? Like what are you workin' on?

08:57 Ron Hayden: To my surprise, I ended up getting a book contract, 'cause once I had resigned, and there was a couple 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, 'cause 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.

10:10 Michael Kennedy: 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, sounds like you've done quite a bit.

10:20 Ron Hayden: Oh yeah, yeah.

10:20 Michael Kennedy: That's cool. So that's going to be a lot of fun. You can't talk about it yet?

10:24 Ron Hayden: Unfortunately not, but I look forward to being able to in a few months.

10:28 Michael Kennedy: That's really great. So right now you're working on a book, and you just left Apple. I guess maybe to give some folks little perspective, 'cause a lot of what we're talkin' about is the stuff that you did at the time when 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.

10:45 Ron Hayden: 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. Overtime, I ended up running developer publications at Apple for awhile, 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 the, and put that all together into the documentation. So I was an engineering manager, then I was running developer publications, which is really interesting and tense experience at a place like Apple, because basically everything comin' 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 100% 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 Lattner, who originally created Swift, came to me two, three years before it launched, and said, we're workin' 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, saying, 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, 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 'em on the project. That's the kind of thing I was doing from day-to-day.

13:21 Michael Kennedy: 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. And that kind of surprised me, but I think it's a positive one more or less. Why do you think that was?

14:03 Ron Hayden: Well I'll also say at least for me, and I think for us in general, the immediate adoption and the level of adoption was a surprise to us. You can think, oh, a company like Apple, we're going to say do X and everyone's going to do X. No, we could've 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. And in terms of why it was successful, I think that a simple answer is it simply works and 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. And if it hadn't been for Swift, they might not have done that.

15:44 Michael Kennedy: 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 this, 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?

16:51 Ron Hayden: I've run into this too. I went to my first PyCon this year, and I was talkin' 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 start, are dropping support.

17:29 Michael Kennedy: Yeah, Panda's just announced that they're dropping support, like soon. So, I mean, these things are happening, right?

17:36 Ron Hayden: I think in the data science field 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, and

18:03 Michael Kennedy: The shackles are off do whatever they want.

18:06 Ron Hayden: 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 they're 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, that's interesting. It's an interesting problem. When you have let's say, 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 find the time? When are you going to put someone on that to spend you know, significant amounts of time to do that? And well, kind of gets to my call to action. I think what I would encourage in any organization at this point is don't let yourself get in that trap. You know, if you are an engineer, or especially an engineering manager, and you are 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 your 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 creek.

19:32 Michael Kennedy: 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 2 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 companies? 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. It's deep and it takes a long time to get out of it.

20:33 Ron Hayden: Here's the funny thing in all the, in the teaching I would do. I would talk about here's how it works in 3, here's what we don't get if you don't move to 3, etc. I actually think one of the features most likely to get people personally motivated is f-strings. They love them, they're great. I actually have a theory that if that feature had been rolled out early on in 3 and not put into 2, they would've had more conversion. 'Cause, 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?

21:04 Michael Kennedy: Yeah, it's definitely really much more concise and it's faster, right? 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's 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.

21:31 Ron Hayden: 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.

21:40 Michael Kennedy: 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 and the team there? Tell us what it is, and then how you got started on it.

21:50 Ron Hayden: Well, I, 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. 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 is 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 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, 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% or 30%, 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 focused topics on that, and had real experts across the company doing it, and we put out white papers, with each one of their talks to help out. And that was so impactful, that I was then able to say, well, you know, we can keep doing this kind of stuff if you gave us some head count. And that became Software University. So a very small team, huge impact across the organization. You know teaching, 'cause one of the funny things for a few years after Swift came out, and still true in the 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 longtime to begin that transition. So we were actually in a situation where before each Worldwide Developers Conference, we would run special boot camps to teach the people who were 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 was something.

24:18 Michael Kennedy: That really blows my mind. I've seen that before, but it, you think about it, it makes sense, but just from the outside, it doesn't really. Like I've seen that other big tech companies that you know, have similar technology stacks and whatnot, 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 just like, how could this possibly be, that you work at company X, and you know, someone's comin' in to teach you about the premiere technology. That'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.

25:00 Ron Hayden: And you also had to realize they're not necessarily all bought in right? Like so something like Swift comes along, a small group of people did it. 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.

25:22 Michael Kennedy: 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 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.

25:39 Ron Hayden: Um hmm.

25:41 Michael Kennedy: So what was that experience like?

25:42 Ron Hayden: 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.

26:23 Michael Kennedy: Almost with a script and a checklist, right?

26:25 Ron Hayden: Yeah, exactly, and for a long time, that was okay because there weren't that many features. But now that it's Cloud, and this and that, and five zillion apps, and your whole life is in it, and there are many different models of the phone, you, 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 experienced, 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 nope, 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 about for loops, now we move on to the next topic. Well, no, you know they needed it three, four, five times to understand what a for loop was.

27:39 Michael Kennedy: Because there's different levels to that, right? Like if you are 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 this syntax work, and what are the gotchas? And 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. 'Cause maybe you take one slice of that onion each time through and eventually you get the whole concept.

28:20 Ron Hayden: 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 of new programmers 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? Any, or I would even start to teach one of the experienced topics or something, 'cause some of them would ask like 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, 'cause 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.

29:32 Michael Kennedy: Yeah, I think that's a good point. In basically, in any presentation and teaching, training, it's like a really long presentation right? Leaving some room for a little bit of, 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, and 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? Like well, actually, import, you know.

30:08 Ron Hayden: Right, right.

30:08 Michael Kennedy: DictReader, right? So, things like that. I think that's a huge value that often gets lost 'cause you're like, we'll we've got to cover all these things

30:15 Ron Hayden: Yup, yup 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 and this. 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've been using Python for awhile 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. So that was my goal 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 where they came from.

31:11 Michael Kennedy: Right, if you don't change your mindset, yeah you don't even know now this is a tool in your toolbox when it applies, right?

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

31:37 Michael Kennedy: I think generators and generator expressions and all that they're just like magic. And people who haven't taken the time to get to know them you know, like you say if they're doing anything with lots of data coming off of the network, it's coming off of disk. I 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 that. But anyway, it's out there some other places but it definitely is really well embraced in the Python language right? I think that's right.

32:08 Ron Hayden: Yup.

32:09 Michael Kennedy: There was a recent article, blog post whatever you call it by somebody who said, I can't remember what the name was. So what to the affect of like eight reasons I hate Python. And I'm just going to say it, I hate Python. Something like this and it was basically the prototypical example of the person that you described not going through the process, right?

32:30 Ron Hayden: Right.

32:30 Michael Kennedy: They had to work in Python and they really just like, 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 learn very much about any of those features. So they're like this thing completely sucks. They 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 from this import star. There's other options right? But 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 a weekend. I'm going to learn it really quickly but soon as I get it to work I'm going to stop investigating. Soon as I get something that works. And I think that's actually a little bit of the languages 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.

33:31 Ron Hayden: Right, and I would say for myself the feature that I really just started using more and more and the more understood it, the more problems it solved is the exception handling. I wish there was a different phrase then 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.

34:17 Michael Kennedy: 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 to question for you, have you been outsourcing your bug recovery 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 Rollball 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 dollar 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. Want to tell people a little bit about how that works?

35:52 Ron Hayden: Yeah, I actually this came out of going to the PyCon. I knew about Jupyter, IPython, etc but I 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. 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 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 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. 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. It 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 'cause if 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 like you look inside a Jupyter file and see that it's just 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.

38:13 Michael Kennedy: Right, they didn't try to write Word for Python.

38:15 Ron Hayden: Yeah, exactly

38:16 Michael Kennedy: 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. 'Cause you know it's great to have like a pdf of the slides. Like okay, super, I can type that back in or get it somewhere. But you know, the Jupyter version you get to explore.

38:40 Ron Hayden: 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 either BBEdit or somethings 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 have 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 solved so many problems. So it's really elegant for teaching.

39:30 Michael Kennedy: Yeah, it definitely seems like it. I mentioned 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 and 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?

39:51 Ron Hayden: 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 there were various influences on Playgrounds. I guess they way I'll answer your question is I would say if I had known about Jupyter at the time. And 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's simplicity research. 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.

40:53 Michael Kennedy: 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 2 and 3 divide and some of that technical debt. You had story about converting from one language to another back in the publishing days. Tell us a little bit about that.

41:13 Ron Hayden: Well, so we had this whole publication work flow. 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 that you know that you have when you have a big thing that's been running for a longtime.

41:30 Michael Kennedy: You just think if we can just write this from scratch it would be, all the problems would be gone, it be perfect. Famous last words.

41:35 Ron Hayden: 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 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 everyday, 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. What happens is when you have an enterprise level production work flow that's been around for a longtime there are hundreds or thousands of edge cases and 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 'cause some new feature will come along and you have to put into your old production work flow, 'cause you're still using that. And you have to put it in your new one, or you have to do something. And so at the end of the day, we had this great new version of our work flow that 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 forth 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 what I think a lot of people have learned this, is if you have a large enterprise level work flow accept it, you have it. You're 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 work flows 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.

43:47 Michael Kennedy: 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?

43:57 Ron Hayden: 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.

44:03 Michael Kennedy: But if that one got canceled did you just go back to the Perl one? Or is there now something new?

44:08 Ron Hayden: Well I haven't been dealing with that for a longtime. And I know, I think they finally did do a whole new production work flow. 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. 'Cause 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 doing this classic joke, you've heard this. This guy is a COBOL programmer and he's so sick of everybody hiring from 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?

45:03 Michael Kennedy: Exactly, yeah I can totally see that. And there are so many projects that are stuck in these these old languages you know, VB6, even. There's so much in the enterprise space that people have put together really complicated. And it's, there's better paths forward. But I think it is all these little, tiny details right? It's one thing to say 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, 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 maybe Spring 2020 or after the first really bad security problem found in 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.

46:05 Ron Hayden: In the meantime what people can do, and I started pushing this really heavily in my experienced classes, is start using Python 2 like 3. You know use the features that were back ported. Especially for dictionaries and such. As near as I could tell, I could rarely find a tutorial or 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 the, 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.

46:39 Michael Kennedy: Right. Like x range and that kind of stuff right?

46:43 Ron Hayden: Yeah, and in the dictionaries, 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 'cause 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.

47:10 Michael Kennedy: 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?

47:30 Ron Hayden: 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. So for every single feature of that I would put in tests. Then my parser wasn't very fast so my team got annoyed about that and one of did to me what I did to people. Which was go 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.

48:07 Michael Kennedy: Right, run it, does it pass? Good.

48:09 Ron Hayden: Yup, but I would argue 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.

48:22 Michael Kennedy: Yeah, that's probably true. Alright 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. You may decided to, start from scratch with Python 3 and rewrite the thing because it's both tempting and sometimes the right way to go. But at least it's more of a upgrade. Like it's a really big upgrade to your project rather than you can't add Python to Perl progressively to it right?

48:59 Ron Hayden: I think there's this same risk which is if you don't spend sometime truly learning what's different about 3 and the philosophical changes to deal with. You know, memory usage and such, 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.

49:22 Michael Kennedy: Yeah, that's a good point. It's very similar there. Alright well you've done all this cool stuff at Apple. You've been there for a longtime and you know you hear a lot of good things about the company. But leaving and breaking out on your own, that's a pretty big step I know from personal experience it's a big deal. What was the decision think, making there?

49:41 Ron Hayden: 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 you know 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 you were smart. And it's like no, no no actually if anything that would make me want to stay because as one of the people whose been around a longtime, you know I have experience with the ups and downs of things.

50:08 Michael Kennedy: It's been a lot lower historically at some points.

50:10 Ron Hayden: Oh yeah. So every once in a awhile in your job something comes up that's a little annoying and you think about things. And I realized oh it's 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 wannabe 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 just 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. So you combine all those things and it's like, yup this is the right time to do this.

51:30 Michael Kennedy: Yeah it's definitely a good time to switch into Python. It's so much energy and it's definitely building. 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 everyday 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.

51:55 Ron Hayden: Right, right.

51:56 Michael Kennedy: I just thought is that kind of stuff that I want to put energy into everyday? Like what if I could wake up everyday and work on what I think is going to be most valuable to the community or people or customer, whatever right? 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

52:17 Ron Hayden: right, right.

52:18 Michael Kennedy: 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?

52:25 Ron Hayden: Yup, exactly.

52:26 Michael Kennedy: Yeah, interesting. Okay so you're starting off on this journey to do training, teaching and sort of own thing. How can people, you already have some classes that you're teaching right?

52:36 Ron Hayden: Yeah, I'm 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. With experienced programmers it's really teaching them how to be Pythonic and how to use the language the right way.

53:00 Michael Kennedy: Nice, and where can people find out about it?

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

53:21 Michael Kennedy: Nice, okay yeah so people can check that out if they're interested, that's great. Alright 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, what editor do you use, for Python anyway?

53:42 Ron Hayden: 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, by 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 can interact live with what's going on.

54:12 Michael Kennedy: It's like a super debugger right? You can just go, what is x?

54:16 Ron Hayden: 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 on screenshots to show what it is that you're dealing with say on a webpage or something like that. And then if necessary just export it to Python to be run on day to day basis. But do the actual source in Jupyter. So I know that there then challenges about importing things and other stuff so there'd be things to figure out. And I know that there's these Jupyter Lab and other stuff that I haven't played with yet. But that's definitely where I'm at.

54:53 Michael Kennedy: That's an interesting idea. Okay, notable PyPI package?

54:57 Ron Hayden: 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 so you didn't have to have three different libraries and different API's. 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. 'Cause it just cleans up your code a lot and it's a much nicer way to deal with things.

55:32 Michael Kennedy: Yeah, that's a good recommendation and way to grab one out of the standard library, that also works.

55:36 Ron Hayden: So the other thing that I've started pushing in my experience classes, 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 dataframe 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 text 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 other notable thing.

56:25 Michael Kennedy: Yeah, yeah very interesting. I definitely like the pathlib stuff these days. I'm starting to really appreciate it and think about ditching os.path and all that because of the fluent API, the chaining right? Like create a path. Rename. Ensure the parents stuff. All that kind of, like all on one line. It seems really, really clean. So yeah, I like that recommendation as well. Alright, final call to action. People are out there learning Python. Whether they want to teach Python, you know, what advice do you have for them?

56:54 Ron Hayden: Well I think I'm going to comeback to the 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.

58:12 Michael Kennedy: Yeah, unless you're committed to it, like 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, like that's not reasonable for most people. Especially you know if it's a week long class or something online for a few hours or something like that. I totally agree. Alright Ron, well thank you for sharing your experience and your story. It's really interesting, I appreciate you being on the show.

58:38 Ron Hayden: Thank you very much.

58:40 Michael Kennedy: 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 Jinja 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/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. This is your host Michael Kennedy. Thanks so much for listening, I really appreciate it. Now get out there and write some Python code.