Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I have the pleasure of interviewing Pythonista Kenneth Reitz. Kenneth is the author of quite a few open source tools including requests and more recently records, both of which attempt to make the software development process more human. We will talk more about what that means in today's episode as well as the next episode of Developer Tea. If you don't want to miss out on that part of the interview make sure you subscribe to Developer Tea and whatever podcasting app you use. Today's episode is sponsored by Hyrd.com. If you are a designer or a developer and you're looking for a job and you want a little bit of an extra bonus, quite literally, Hyrd may be the perfect place for you to start. We'll talk more about that bonus later on in today's episode. But first I want to jump straight into the interview with Kenneth Reitz. Kenneth, welcome to the show. Thanks for having me. I'm excited to talk to you about all of the open source projects that you have created and later on you mentioned burnout with open source. We're going to talk about that as well. But first I want to hear about how you got into programming and specifically what interested you about Python? Well, I got into programming. I was always fascinated with computers as a kid. One of my favorite toys is a child who is playing with paint on the Windows 3.1 machine my dad had. Sure. And so I was just always trying to get as much time either playing Nintendo or being on a computer as possible. And my old church gave me, I was like in fourth grade. They had this really old. There was an IBM XT machine that was like sitting in there in the corner. And the pastor said I could take it home one day. It's because no one was using it, obviously. So I had my own computer finally and I spent like eight hours a day on that thing for the longest time. He came with DOS 3 and had a 20-meg hard drive. I learned basic. I had a kid's basic book that I had got a hold of and a time itself basic. And how old were you? It was like fourth grade, so probably nine or ten. And then over the years, I always had this antiquated hardware. So I was always learning really old technology. And I learned really basic C, just like functions and printing and doing the PC speaker and stuff like that. And it's great. I got it up on a website that every ISP used to give people a little slot to put a website up on back in the day. And for some reason that account is still online. So I found that recently. And just last night I went and I got the EXC's. I had generated from my like first software package for my friend. I saw that you tweeted this out today. It was called Splashware. And it's running on archive.org and you can run it on your browser. I'm pretty excited about that. I couldn't tell if this was a virus when I ran that. Actually. You know, they recently released the archive of viruses. Oh, yeah, that was excellent. It's like malware that you can go and safely view through your browser somehow. Yes. Yeah, Jason Scott and our archive team, they do incredible work. Yeah, it's pretty cool. So Splashware. Yes. So that was like C. And that was like middle school type stuff. And you know, HTML. I always got books from the library. They would have those CDs in the back when it's where I get my software from. And so and I would teach myself by reading all these books. And I kind of put it down for a long time, but I was still like a computer, like a technical computer user. I was a heavy Linux user. So you know, that comes with the territory. And then I was really torn when it came time to go to college. What I wanted to do. I had spent like 10 years spending most of my time drumming instead of doing computers. I kind of switched. And I was like, I could go in that path or I could like be a photographer or I could do this to that and I sat down and I decided to go with computer science because then I could fund all those other things as hobbies. And you know, the best career choice would be computer science. So I went to school and the first language that they taught me was Python. Wow. What's what schools this? Georgia Mason University. Okay. CS 112 was a Python course that taught it terribly. Like I can't even begin to tell you it was taught by a Java guy. They didn't know what they were doing. Well, and now I was getting ready to say that. Typically these courses, especially the early CS courses are Java. Yeah. Yeah. Typically, there's a trend in the university is to switch to Python now and it's more and more doing it every year. Even MIT is teaching Python now. Yeah. That's why I was asking, you know, what school it was because it seems like a forward thinking switch to move to Python for that early course. No, I'm not much of a school guy. So I went to class maybe five times. And I got really frustrated. I couldn't I couldn't learn what they were teaching. So I just went off and stayed in my dorm and taught myself Python. And I learned it much better than the class taught. They say there's only one way to write a Python program though. No, one one in preferably one way to do it. Yeah. Yeah. It was just a crazy class. I can't even I don't want to go there. All right. So but then I dropped out of school because like I said, school isn't for me. And I just kept programming basically. And I went away from Python because I was using Python to build like command line stuff. And I started doing web stuff. And so I learned PHP and I was doing PHP a lot. And Lorraine had a manager servers with all the Linux knowledge I had and a little bit of Java and a little bit of everything. Then I came back home to Python one day and realized I could do everything in Python. And I was going to say somebody showed you Flask or something. Well, it didn't exist at the time. But it was it was great. There's been being able to like I went from a job where my first tech job was doing like PHP. Yeah, my second one was doing dot net and SharePoint customization. It's very different from Python. Very, very, very. It was it was interestingly fun. But only for like a couple of weeks. C sharp is a cool language. SharePoint is not cool in any way shape or form. I left that job three months later to choose open source technology basically. And it was a job where like they had a bunch of client contracts and it was just written in a bunch of open source stuff. Every project was a different language. And so I just learned a ton of stuff there. And then I was finally able to get a job doing Python full time. And that's when I was finally happy. And was that when you moved to move to Herica? No, I was working at Net app at the time. Working on some migration software. And then I went from there to a company called Readability, which is a competitor to Instapaper. And then from there to Heroku. Tell the listeners what you do at Heroku as the product owner of Python. So I call myself the Python Overlord. And basically that means that everything about Heroku that is involved that relates to Python, I'm responsible for. So when you push up a Python application, all the code that gets executed to run your app, I manage all the documentation, all the customer experience stuff, sport tickets, making sure that we have great presence in the community and that the community needs and needs are being met by the platform as well. Sure. Yeah, so you end up speaking a lot. Yes. So what are some of the conferences that you've been at and are you planning to be at some this year or? So Python every year is my favorite conference. That's my, I like to highlight every, like, you know, have most people measure their years and like the progress that they're making in life by, by new years every year. Sure. For me, it's when Python is. That's when you make your resolutions for the year. Yeah, because it's, it gets a really reflect on like, you know, what have I done in the community since the last time I saw all of these people, you know, are well, but else has changed. It's pretty interesting. That's really cool. So would you say that the Python community is growing or that it's full of a lot of veterans or how does the Python community feel to you as the Python overlord, so to speak? The Python community as a whole is definitely always growing. I do not think it's growing as fast as languages like, like the Node.js community. Sure. And the growth of Node is absolutely tremendous. If you look at everything in that community and Python is a much more steady rigid ecosystem. Sure. Yeah. I would say it's kind of fundamentally different. Well, first of all, it's significantly older than the Node community, right? It's older than Java. Wow. So what was your 94? Is that when Python was written? That sounds about right. It was around the same time that Ruby was released, but the Python community grew early and it was used on so many platforms early and probably gained a lot of popularity as a result of that. Yeah. And now with all the web technology being available, Rails came out and that gave Ruby a tremendous amount of popularity. And Django was released, I believe, shortly thereafter. Yeah. That kind of started a reach surging of interest in the languages from a new set of people. Sure. And there are a lot of similarities. If you're listening to this podcast right now and you tried Ruby and you didn't like it, you may like Python, but they are very similar. There are certain differences that I would say are pretty significant and make a big difference in the way you code. But it's very similar in terms of the utility of the language. The one thing that I think across the board, Python kind of wins is the portability. Python can be deployed on many more machines, for example, than Ruby can in large. Would you agree with that? I think so. So Python is used in robotics, for example, where you don't really hear about Ruby being used in robotics that often. Yeah. It definitely has a much larger application usage base. You can use it for scientific computing. They use it at SERN for the big Hadron Collider satellite stuff. It's used for all kinds of things. And Ruby is technically capable of those things, but it's just not a good fit for a lot of those things. Because Python is. Yeah. And it's an interesting thing as to why. And this actually is a pretty good segue to talk to you a little bit about some of your projects, because a lot of the draw of Ruby is the approachable nature of the syntax. There are a lot of very natural feeling things that are baked right into Ruby core or into a core library. And I'm wondering because you have quite a few projects, most specifically recently you've done records and before that you did requests. These are projects that are focused on this idea. You use the word human a lot in your work. Can you kind of expound on what it means to create more human friendly interfaces to code? Sure. So when I created requests, originally the tagline was HTTP that doesn't suck. And it took many iterations, but I wanted it to be less negative, but still kind of assert that this is something better than or more usable than. So I ended up settling on HTTP for humans. And basically what that means is if you look at the way, so let me explain what request does first. So it has a tremendous amount of functionality. But the basic concept is when you send an HTTP request and Python, if you try to use the standard tools that are available, it is like the worst experience you can possibly have. And especially if you want to do simple things like deal with cookies, set headers, have up medication, follow redirects, all these things can be done, but it is like it's not a good experience by any means, like you're going to spend hours on this. And you'll probably break something in the process that you probably won't do it, right? So for humans is the idea of like, you know, I'm human. This is what I expect to be able to do. Make it do that. So that's, I write a library that does that basically. It does all the crazy stuff in the background so that everything just works properly. So it really encourages the best practices. And it's great. Today's episode is sponsored by Hired. On Hired software engineers and designers can get five or more interview requests in a given week. Each of these offers has salary and equity at front and they have full time and contract opportunities. And you as the user, you can view the interview requests and accept or reject them before you ever even talk to the company. So you avoid any kind of awkward interactions. Hired works with over 3,000 companies from startups to large public companies and they have employers from 13 major tech hubs in North America and Europe. Now the best part for you is that it's totally free. And there's no reason not to try this if you're looking for a job. And if you end up getting a job through Hired, they typically give you a $1,000 thank you bonus. But if you use a special link in the show notes, that bonus doubles to $2,000 when you accept the job. So go and check it out. It's hired.com slash Developer Tea. Of course, that link will be in the show notes at spec.fm. Thanks again to Hired for sponsoring Developer Tea. So I assume based on my limited knowledge of Python but also of your specific tools, I assume that you do a lot of kind of default things to help users accomplish the most common goals because HTTP very often what you want to do is just perform a get request and get something back and do something with it. Same thing with post requests. You may want to post a request with some headers and get something back in a particular format. There are so many other things that you could do with HTTP but 95% of the time, that's what I want to do. So can you kind of speak to the idea of I guess some people call it sensible defaults but this concept of the most common thing, making that the most accessible thing. Definitely. So I do have a rule with the libraries that I write and it's basically is to try to fit the 95% use case and to ignore the rest of the people because there's a lot of people who will come along in a project and be like, I really need to do this thing for my job and use a pull request that adds like 100 lines of code that no one will ever be able to maintain. And so I don't do that basically. Over time the API has become more powerful and I've made it modular so people can augment the code but like the core library itself is like it does what it does. So a few things we do for sensible defaults are so when you grab an HTTP request, let's see you do request.get and you give it a URL and you're going to get back a blob of binary data from the server, right? And that gets stored in the object and there's two ways to access that. There is the dot content which is the bytes representation, the binary representation of the response and then there's a dot text representation which is the unit code representation. Now servers sometimes report the encoding in their headers responding they sometimes don't and sometimes when they do their line, very often when they do their line. So when you have a response object in request, there's a dot encoding attribute which is set automatically based on A the headers. And if that doesn't work then B will actually detect the encoding from the content and see you can set it yourself if you definitely know what it is. And so you just basically never have to worry about content encoding when you're using the library and that like is really hard to do. Yeah, that's if you've ever worked with a HTTP library then you know how frustrating some of these things that you expect to be normal and easy can be. I've gone through so many stack over posts when I'm just trying to write a script to you know go grab some JSON and post a header, right? Even if it's you know, I typically do this with Ruby and we have the net HTTP library which is is relatively approachable. Yes, I actually really like that library. I use it as an example of a good workflow in some of my presentations compared to what you have to do in Python. Right. Sure. And even that still has its quirks, right? Because HTTP is is not a super approachable thing because we don't think about all of these terms naturally, right? With with an HTML document we can kind of understand the idea of the whole the whole document being the unit of HTML and then you have a head which is the head and then you have the body which makes up the bulk of what that thing is and that kind of comes intuitively to us. But when you start talking about post and get and headers and body, none of these things naturally fit together in my mind, right? I have to read something to be able to understand what that is because there's not like a mental model that they're mapping that onto. It's all fundamentally new. Interesting. Maybe you should try a request maybe it'll help out. There you go. And to be fair, I mean there are quite a few good libraries in other spaces as well. So you know, I mean, there are some more natural things once you do understand that language. But making that language more approachable is a task, right? That's not an easy thing. And really if you're going to create an open source library, I think this kind of library, the stuff that you're making that focuses on the human side, which is I see a thing and I have to wrap my brain around it. And there are certain ways that I naturally think and then there are other ways where never in a million years would that come intuitively? I have to read the manual. I have to read the documentation to be able to do that thing and things like requests or records which I want to talk about next. It kind of help us get to that spot where we can make a good guess and a lot of the time we're right. Yes, definitely. So it kind of sets up the rules and your approach from the perspective of, for example, a common grammar, right? Any good Ruby library does this as well where you can do one thing with one class and then you do another thing with another class and you expect it to do the right thing naturally. For example, concatenating strings, you just do a plus between them and then when you do a plus between numbers, you're not getting a string back, you're going to get the numbers added, right? These are natural things. Those are intuitive things. There are some things that we still have yet to solve in software development that are not yet intuitive like that is. Does that make sense? Does it translate to the work that you're doing with these libraries? Definitely, it's all about sensible defaults and just good API design. A lot of times there's APIs available that are just antiquated or they were built for a different time or they're just bad. Yeah, absolutely. Or they fit a different use case. Sometimes the standard library that people are instructed to use is a little too low level because it's trying to fit that 100% use case. Here, in order to use it 95% of the time, you have to do 20 things. If you can build something on top of it that utilizes that functionality, then the world is a better place. I totally agree. I'm interested to know what other types of software have you encountered that don't feel human, that you feel like still need some work? In the Python world, for me, the big one right now is date times. I was going to mention this. You tweeted about this as well today. I've talked about date times being needing improvement for a long time based on feedback from the community. But it's not something I've actually used. I always stick to UTC, everything everywhere in my code. I've just tried to do the simplest little thing last night. I spent four hours on one line of code. I still haven't gotten it to work right. I could have done it manually by just changing a string around. But I'm trying to use the API properly to do this. It's crazy. Yeah. It's crazy. I want to build date times for humans. When I start looking at just the depth of what is going on there, it is absolutely astronomical. I might not touch that. There's some good implementations that are already available. There's a one called Arrow for Python, which is pretty good. The amount of work I'd have to put into this to do it well, it might not be worth my sanity. Yeah. I think this is a ubiquitous problem. I would say everybody makes the list of the hardest problems in computer science. If off by one errors make it to that list, then this is like the epitome of off by one errors. Absolutely. Every case, the issue so often is the server's time is slightly different. You have daylight savings time. What happens if the person is visiting in a community where they are right on the line, where they actually go back and forth between different times or between different time zones rather. Obviously heard somebody say, well, I'm going to write some code that basically takes the time from the International Space Station and applies it universally because that's the only thing that makes sense. It's so true though. Daytime is a difficult one. There are some interesting libraries out there that I've used to try to solve some of these problems in the past. A good one for JavaScript is Moment. Have you written much daytime oriented JavaScript? I haven't written much JavaScript in a while, but I've definitely heard of Moment. It's kind of the go to at this point. I think Ruby really handles daytime decently well in the day class. The daytime part is the easy part. It's the time zone. That's the hard part. Always. Always the hard part. For me, what I'm trying to do is I am parsing it from a string just a simple date. You get a daytime object back. I want to specify that it is a USE Stern time zone. A USE Stern is fine because that means it'll change automatically between daylight savings times. Then I would like to render that string out as ISO. Nothing seems easy, doesn't it? Well, it is easy until you want the code to work anywhere and then I just can't get the tour. When there's a different locale on a different machine, it has different behavior. I can't figure out the proper way to do it. It's probably naivety. I've never used these modules before. It shouldn't take me four hours to figure out how to do this. That's true. I think that's really the key there. Sure, it's a problem and it does take time to solve. There is a limit to how much time is really actually worth it to try to solve this problem. Yes. Exactly. But then it goes a point further. With HTTP, I was able to solve the problem for myself and in doing so, I was able to solve this problem for the whole Python community. With the daytime thing, if I was to try to solve the problem for myself, I think the amount of time involved might be exponentially higher. But I'm not sure yet. I have to do a lot of research. There's just so much consideration because I believe it's designed the way it is today for a reason, to cover all these use cases. That 100% use case. I can try to apply a 95% use case API around it. I'm still going to need to consider because I have a very narrow view of how I'd ever use these libraries. I need to find out how everyone else has. HTTP is much simpler. I know how everyone's going to use the library. Because it's, I mean, requests can be, there is a specification. The specification for time zones is so much more difficult to understand though. Yes. Yes. I really like this moment.js website. How it's auto updating the comments. I actually haven't seen it. It's really cool. It has an example line of code. And then as a comment, it has the output of it. Cool. And it's updating live because it's JavaScript. Very nice. I will actually have to, we'll include that in the show notes. I'll go and take a look at that. That sounds great. Moment.js is super powerful. There's a couple others that I've used in the past. And I've actually thought about creating just a little Heroku install to do time zones as a service. Just time zones as a service. Just kind of like send a post request with your natural string representation of what the time should be. And it will give you back, I don't know, like second. What is the seconds, the time since 1970, the second since 1970. The epoch. Yeah, there you go. The epoch time. If you just send it the string and then it just responds back with that. Obviously, that's a superfluous thing to do just to get a time thing back. But to be fair, if you're including the entire library of moment.js, for example, this would be a smaller request, technically. Definitely. The API I have in my head, and I'm not, I don't, like I haven't done enough research to know if this is proper yet or not. The workflow that I want and I think is ideal for everybody is in your code. All of your times should just always be UTC 100% of the time. Like they don't need any time zone information. This is the time. It's the universal time stamp. This is the time. It's a moment in time. That's a good place to start for sure. Yeah, and then you have to have the ability to import a time from a given time zone and you export to a given time zone. That's kind of the concept that I have in my head. But I really have to sit down and read a lot before I can assert that that's even a good idea. Yeah. So if anyone who is listening to this right now, if you are a functional programmer and you are looking to write a talk about mutability, date times are the perfect case example of mutability gone totally wrong. Because if I create a date on my computer in Chrome with JavaScript and Kenneth creates one on his computer and we do it literally exactly the same time, they could be totally different objects entirely. They should be the same, but they aren't. That's just the way it works. It's very strange. There are some things that fix this problem, but not super well. Yeah, it's neat that creation and should always be from a universal reference point. Right. And then you go from there, basically. I would say that it even makes sense to pull that information in a different way than instantiating an object so that you have to pass in whatever that time is. Maybe that time is available in the environment constantly. I don't know exactly how that would work though. Yeah, the time zone for the machine is available in the locale. And that's what gives you different behaviors for these date time modules, at least in Python. Yeah. To me, I'm trying to do, basically, it's called date time arithmetic. I'm like, I have a date I want to do math with a time zone on it. It shouldn't matter what the server, just ignore the server. My machine does not care. If you've worked with time zones, then you're probably identifying with all this. If you haven't worked with time zones, then you may think that we're going on and on about this subject, but you haven't worked with time zones. And I've only worked on them for four hours. So, right. Exactly. Only four hours for that one project. I still haven't solved it. I'm going to work on it later. Great. So again, I think a lot of this approaching things from the perspective of, you know, this could be more human. This is really the future of software development, most especially the future of open source development, because these types of problems are what we need to solve more and more to create value in the open source world. But you mentioned to me before the show that you actually took a break from open source because you were burnt out on open source. You didn't touch any of your open source projects for a year and a half. So I'd love to talk to you about what that burnout is like and maybe how to avoid that. If for those who are listening, if they're wanting to start an open source project, you know, what to be aware of before they go in, not to scare them off, but hopefully to bring them into the fold here and have them work on open source projects. But also for those who are feeling that burnout, how to maybe get out of it. So we're going to wrap up this first part right here and we will talk more about burnout and bringing people into the fold of open source in the next episode of Developer Tea. Thank you so much for listening to today's episode and thank you to hired for sponsoring Developer Tea today. If you are looking for a job and you are a developer or a designer, go and check out higher.com slash Developer Tea. Of course, that link and every link from this episode will be found in the show notes at spec.fm. If you are enjoying Developer Tea, please consider leaving us a review on iTunes. That is the best way to help other developers find the show. Make sure you subscribe if you don't want to miss out on future episodes of Developer Tea, including the second part of this very interview. You can go and do that in whatever podcasting app you use. And of course, every episode of Developer Teacan always be found at spec.fm. Thanks so much for listening and until next time, enjoy your tea.