Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell 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 in whatever podcasting app you use. Today's episode is sponsored by Hired.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, Hired may be the perfect place for you to start. We'll talk more about that. We'll talk 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? Hmm. Well, I got into programming. I was always fascinated with computers as a kid. One of my favorite toys as a child was playing with paint on the Windows 3.1 machine my dad had. Sure. Yeah. And so, you know, 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... I was really old. It 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. It came with DOS 3 and it had a 20 meg hard drive. I learned BASIC. I had like a kid's BASIC book that I had got a hold of. And I taught myself BASIC. And... How old were you? So it's like fourth grade. So probably nine or ten. And, you know, then over the years, I always had this antiquated hardware. So I was always learning really old technology. But I learned C, really basic C, you know, 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 are, you know, every ISP used to give people like a little slot to put a website. I got a little site up on back in the day. And for some reason that account still it's still online. So I found that recently. Wow. And just last night I went and I got the EXEs that I had generated from my like first software package for my friends. 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 read it. 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 the archive team, they do incredible work. Yeah, it's pretty cool. So Splashware. Yeah. So that was like C, you know, and that was like middle school type stuff. And, you know, HTML. I always got books in the library. Yeah. Yeah. Yeah. They would have those CDs in the back. That's where I'd 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 on that path or I could like be a photographer or I could do this, 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. Luckily. What school is this? George Mason University. Okay. Yeah, CS 112 was a Python course. They 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 I was getting ready to say that. Typically these courses, especially the early CS courses, are Java. Yeah. They typically are. There's a trend in universities 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 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 and preferably. One way to do it. Yeah, yeah, exactly. 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 learning how to manage servers with all the Linux knowledge I had. And I did 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. I was going to say somebody showed you Flask or something. Well, it didn't exist at the time. But it was great. There's being able to like I went from a job where my first tech job was doing like PHP. And 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 Heroku? No, I was working at NetApp 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 it relates to Python, I'm responsible for. So there's when you push up a Python application, all the code that gets executed to. To run your app. I manage all that, all the documentation, all the customer experience stuff. Support tickets, making sure that we have great presence in the community. And that the community's 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 PyCon every year is my favorite. Conference. That's my. I like to highlight every like, you know, how 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 PyCon is. That's when you make your resolutions for the year. Yeah. Because it's you get to 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, or what 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? Hmm. 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 it's 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. Probably gained a lot of popularity as a result of that. Yeah. And now with all the web technologies 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 resurgence 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. 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, you know, it's very similar in terms of the utility of the language. The one thing that I think, you know, across the board Python kind of wins is the portability. Python can be deployed on like many more machines. For example, than Ruby can in large. Would you agree with that? I think so. I mean, it's it's. 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 CERN for the big Hadron Collider, you know, satellite stuff. Like it's it's it's used for all kinds of things. And. You know, Ruby is technically capable of those things, but it's just not a good fit for a lot of those things as 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 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. Yeah. So. You know, I've been working on a lot of these projects. 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. And but still kind of assert that 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, well, 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 in Python, if you try to use the standard tools that are available, it is like the worst experience you could possibly have. And especially if you want to do simple things like deal with cookies, set headers, have authentication, follow redirects. All these things can be done. But it is like it's not a good experience by any means. It's like you're going to spend hours on this. And you're you. 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 HiRub. HiRub. On HiRub, software engineers and designers can get five or more interview requests in a given week. Each of these offers has salary and equity up 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. HiRub works with over 3000 companies from startups to large public companies. And they have employers from 13 major tech hubs in North America. And they have a lot of great people. And they have a lot of great people. And they have a lot of great people. 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 HiRub, they typically give you a $1,000 thank you bonus. But if you use the 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 HiRub.com slash developer T. Of course, that link will be in the show notes at spec.fm. Thanks again to HiRub for sponsoring. Developer T. 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. Right? Same thing with post requests. Right? Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. I want to do, right? Yes. 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, it's 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 here's 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, 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 Unicode representation. Now servers sometimes report, the encoding in their headers when they're responding. They sometimes don't. And sometimes when they do, they're lying. Very often when they do, they're lying. 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 C, 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 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 Overflow 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, and I, I typically do this with Ruby. And we have the net HTTP library, which 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 it is very different. And even that still has its quirks, right? Because HTTP is not a super approachable thing, because we don't think about all of these terms, now. Naturally, right? With with an HTML document, we 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, I have to read something to be able to understand what that is, because there's, there's not like a mental model that they're mapping that onto. It's all fundamentally new. Interesting. Well, you should try 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. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. At. 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, Kenneth, that focuses on the human side, which is I see a thing and I have to, you know, 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, they 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 you 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. Sure. And so in order to use it 95%, you have to do 20 things. And so 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? So in the Python world, for me, the big one right now is Datetimes. I was going to mention this. You tweeted about this as well today. I've talked about Datetimes 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. But I'm just trying 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. Now, I could have done it manually by just changing a string around, but I'm trying to use the API properly to do this, right? And it's crazy. Yeah, yeah. Yeah, I think this is a ubiquitous problem. I would say, you know, 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, in every case. The issue so often is, you know, the server's time is slightly different, and then you have daylight savings time. And then what happens if the... Person is visiting, you know, in a community where they actually are right on the line, right? Where they actually go back and forth between different date times, or between different time zones, rather. And then, you know, I actually 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 used Moment for any... Or have you written much datetime-oriented JavaScript? I haven't written much JavaScript in a while, but I've definitely heard of Moment.js. Yeah, it's kind of the go-to at this point. I think Ruby really handles datetimes decently well in the date class. The datetime part's 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'm parsing from a string just a simple date, right? You get a datetime object back. And I want to specify that it is a US Eastern time zone. And US Eastern's fine, because that means it'll change automatically between daylight savings times. And then I would like to render that string out as ISO. It seems easy, doesn't it? Well, it is easy. Until you want the code to work anywhere. And then I just can't get it to work. When there's a different locale on a different machine, it has different behavior. And I can't figure out the proper way to do it. And it's probably naivety. I've never used these modules before. But 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. But there is a limit to how much time is really actually worth it to try to solve this kind of 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 datetime thing, if I was to try to solve the problem for myself, I think the amount of time... 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. I'll be that 100% use case. And so I can try to apply a 95% use case API around it. But I'm still going to need to consider... Because I have a very narrow view of how... I'd ever use these libraries. And I need to find out how everyone else does. HTTP is much simpler. I know how everyone's going to use the library. Right. Yeah. Because 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. Oh, cool. And it's updating live because it's JavaScript. Oh, 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 epochs? 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... 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. But 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, there should... They don't need any time zone information. You just... This is the time. It's a 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 to export to a given time. That's kind of the concept that I have in my head. But I really have to sit down and, like, 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 at literally exactly the same time, they could be totally different objects entirely. And they should be the same, but they aren't. And 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 a need that creation end 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... That information in a different way than instantiating an object. So that you have to pass in whatever that time is. And 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. And 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... 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. Right. Only four hours for that one project. I still haven't solved it. I'm going to work on it. I'll talk to you later. Oh, great. So, again, I think a lot of this approaching things from the perspective of, you know, this could be more human is really the future of software development. Most especially the future of open source development because, you know, 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. Yeah. 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. 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, if they're 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 hired.com slash developer tea. Of course, that link and every, 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 Tea can always be found at spec.fm. Thanks so much for listening. And until next time, enjoy your tea.