#199: Automate all the things with Python at Zapier Transcript

00:00 Michael Kennedy: Do your applications call a lot of APIs? Maybe you have a bunch of microservices driving your app. You probably don't have the crazy, combinatorial explosion that Zapier does for connecting APIs. They have millions of users automating things with thousands of APIs. It's pretty crazy, and they're doing it all with Python. Join me and Bryan Helmig, the CTO and co-founder of Zapier, as we discuss how they pull this off with Python. This is Talk Python To Me, Episode 199, recorded January 21st, 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. This episode is brought to you by Linode and Ting. Check out what they're offering during their segments. It really helps support the show. Bryan, welcome to Talk Python.

01:07 Bryan Helmig: Thank you, thank you. I'm excited to be here.

01:09 Michael Kennedy: I'm excited to have you here. It's so cool to have a look inside a company like Zapier and all the interesting ways you're using Python, and especially, some of the scalability and sort of interoperability stuff you've got going on is next-level stuff you got there.

01:22 Bryan Helmig: Yeah, yeah, it's some really cool stuff. It's really fun.

01:24 Michael Kennedy: Yeah. Awesome. Now, before we get into all that, though, let's start with your story. How'd you get into programming and Python?

01:30 Bryan Helmig: I got into programming mostly, I want to say, early university years, right? So, kind of getting into that, hmm, I want to start some startups. I want to create some businesses online. And I was big into music, so I actually did online guitar lessons for awhile and needed to build a site around that. And it just kind of all expanded from that. But I never trained it, like, formally. I just literally got addicted to doing it, day in and day out. And then all throughout college, that's basically all you could find me doing, was building things and creating all these little side projects and little businesses that didn't really work.

02:04 Michael Kennedy: Where's Bryan? He's in the computer lab, man. He's down there, working on something. That's cool. I really like it. It's like you learned programming because you had these ideas. And you're like, well, programming, it's the hammer I need to build my idea, right? The hammer, the saw, and whatever.

02:18 Bryan Helmig: Yeah, exactly. You learn all the more formal stuff like, after having practical applications for it. And for me, that always just worked better. I mean, the same thing for music. I learned the licks and all the cool things, and then I'd learn the theory of why it works. That was always much more satisfying to me as a person. I found it worked well.

02:38 Michael Kennedy: Oh, that's great. So, did you start out with Python, or did they have you doing C++? Where did you start when you were in college?

02:46 Bryan Helmig: With those sites like the WordPresses, and the Jumlas, and the Drupals, and stuff. It was a little bit of PHP, but once I found Python, and particularly Django, back in the very early days of Django, I was addicted to that. I would say really, Django was the thing that got me into the Python ecosystem, and got me stuck on it. And it's funny, Zapier is built on Django, and I've spent a lot of time in the Django ecosystem since then.

03:10 Michael Kennedy: Yeah, that's really cool. You found it and it's still serving you well. You know, I think that's one of the things that's super interesting about Python, in general. I think of Python as a full-spectrum language, right? There's languages that are really good for getting you started to build something simple, but then they top out before you can go pro with them. And then there's pro languages like Java, .NET, C++ , where it's like, you start there. You start with all the complexity. And Python's one of those few ones that you start easy, but as you need more complexity, you can start to bring in those features of the language, but they're not forced on you from the beginning.

03:47 Bryan Helmig: Right, and the industry support for Python's outrageous. Like a lot of these more niche sort of things, which are kind of fun and cool, or they just don't have as much adoption throughout the industry. When you look at employment opportunities, and ease of starting, and what the ecosystem looks like, community, Python's really hard to beat in both a practical, and I also think it's a really well-designed, nicely done language, as well. It's firing on all cylinders. It's really quite incredible.

04:15 Michael Kennedy: Yeah, absolutely. I totally agree with you. Alight, so, let's talk about, just really quickly, your role day-to-day, just so folks know where you're coming from, right? So, right now you're the CTO of Zapier, right?

04:26 Bryan Helmig: Correct. Yeah, yeah, I'm CTO. I was one of three founders, and we've grown. Man, Zapier's a little over seven years old now. So, we've grown from just us three, Wade, Mike, and myself, to 200 people, so obviously the things I'm doing day-to-day are a lot different than they used to be. Used to be a lot of hacking, and then it quickly turned into a lot of hiring. And that's really been where a lot of my time is spent. Some of the cool things are once you get to certain scales, you can start to really hire amazing, amazing people to take over different slices who are way better than you. And we recently did something similar. We just hired a VP of engineering who I'm hoping will be able to take us to that next level for organizational, and hiring, and all the stuff that's so critically important to building a team. And maybe I can spend a little more time on the code side, and the product, and the architecture side. So, I'm really excited in 2019 to spend a bit more time on that.

05:20 Michael Kennedy: That's awesome. A little bit back to your roots.

05:22 Bryan Helmig: Yeah, yeah, no, it will be really, it's going to be really fun. I'm really excited.

05:25 Michael Kennedy: Yeah, I think in the early days, if it's the three of you starting a company, you all have to do so many things that you just, you are unprepared and unqualified to do, right? You're like, alright, who's going to do accounting and taxes? You're like, wait a minute, nobody knows about this. Who's going to do deployment? Well, we've never deployed. There's just so many things, but now you can find somebody who's, say, super good at DevOps and you don't have to worry about that. That's a big transition, right?

05:52 Bryan Helmig: Yeah, it is, and you kind of, whenever you're just starting out, you can kind of get away with the mess, right? If you mess up a deploy, it's like, well, only 10 people were using your site, so no one noticed. You have little things like that, that really help. You mentioned like accounting, the hiring, and you're not doing so much of it, so if you're not world class at it, you can kind of get away with it. But at the heart of it, you've got to build that product that really connects to people, and if you do that well in the beginning, the rest kind of comes and you can get amazing people who know how to build a great deployment system, know how to run taxes in 50 different states, know how to do all this other stuff. So yeah, it changes.

06:31 Michael Kennedy: Yeah, yeah. I'm sure. Alright, cool. So, we talked a little bit about you working at Zapier and stuff, but you know, I'm sure most folks listening have more or less heard of it, but maybe they don't really know. They're like, oh, I think that's some kind of online startup thing. Tell us what is Zapier.

06:46 Bryan Helmig: Yeah, so you can think of Zapier as sort of the glue between all the different SaaS services out there. So, if you use Gmail, if you use especially, like Google Sheets, if you use things like Dropbox, or Slack, all these different services that people use on a day-to-day basis, they have data in them, and if you want to trigger on that data and do other things in other services, Zapier is that mechanism that does that. Which is very much, I think of it a little bit like, you remember all the, and I guess they still exist, some of those languages like Scratch, who are kind of those visual programming, and they never really caught on, but they kind of were like, oh, we're going to give the power of automation and the power of coding to the masses, right? It was always it's an awesome goal, but it was always really difficult. I think we're kind of doing that and kind of coming in through the back door, so you can do these cool things where when you star a message in Slack, you can add it to your to-do app. And you can choose one of a dozen to-do apps that are supported on Zapier. And then you can think, oh, well if I say super important in that message, I had an extra filter and I send a message to this room in Slack, or that room in Slack, maybe, or I send my colleague a DM. You can start to build these workflows. That's really the power of Zapier, is that you can start to string these actions together and do some really complex stuff that normally you couldn't do, unless you had a fleet of engineers to custom build the spoke software.

08:18 Michael Kennedy: This is interesting. So, you talked about Scratch and some of these other Edu block type of application.

08:23 Bryan Helmig: Right.

08:24 Michael Kennedy: I'm not going to call it application, but programming frameworks that are these visual things, right? And I think the idea, though, is not terrible. I think the problem is that they work at too low of a level, right? They're like, you issue a print statement. You do a for loop. They literally work almost line-by-line as you would with text, whereas what you guys have is like, an email came into Gmail, and that's an integration with an API, and OAuth, and tons of other stuff, and then you've condensed it down to the right size of the draggy droppy thing. You know what I mean? So it's like, there's a few blocks, not 50,000 blocks, which makes no sense.

09:00 Bryan Helmig: Yeah, and you get away from the idea of trying to teach people control structures, right? And how data structures work. All this stuff is really heady stuff. Once you get it, it's fine, and it doesn't bother you, but until you get it, it's another world, right? It's completely foreign. We avoid that and we try to keep it just simple to like, oh, I get a new email and I add a message to Slack. Got it. I can connect those two together. And that's always the beginning point, and then I think the really powerful stuff comes where you have a team in there and they're building zaps together, or they're adding their own little flavors of, oh, I want an extra filter here. Only do it if this matches, or add an extra step to this, and don't just send it to Slack. Send it to my to-do app, or send it to this, send it to my CRM. We have lots of business folks and marketers who are doing all this cool stuff, as well, so this is not only for engineers. We do have some of my favorite stuff to do is you can literally embed Python into these workflows, which of course is very topical for this podcast. I love it. But this is for marketers, as well, so they can build these things. This is for real estate agents who have, form software and they want to trigger off of people submitting that and get e-signatures, and all of this stuff is in this ecosystem. So, it's not just engineers or devs that use this. It's kind of regular folks, right? People who are just trying to get work done.

10:29 Michael Kennedy: It's cool, and you can bring the level down a little bit. You don't have to be, if you're kind of good with computers, but you're not a developer, right? This could be something you could maybe really make what maybe like a developer would, I'm just going to write an app that'll just call this API then this, and write, but there's so many people who even if they could write that, they're not going to say deploy it as some kind of background process on Linux and put it in the Cloud. They're just not going to do that. So yeah, that's great.

10:58 Bryan Helmig: Yeah, yeah, and you think about that's a great example. We often get engineers or devs who are like, I really don't want to build that thing you just asked me to build. I'm just going to use Zapier. Because if you think of like, oh, I got to poll this service, and now I have to come up with this stateful store of which things I've seen and haven't seen. I got to deploy it to, I don't know, maybe we'll put it on a Heroku, maybe we'll ping a DevOps person. It just starts to spider into this whole thing, whereas with Zap, you just create a trigger, create this, and then you can hand it off to the marketer. You can hand it off to your colleague and they can just dig into it, so that's a powerful pattern.

11:32 Michael Kennedy: Exactly. It's also like, I think this is a good idea to build this little integration, but I don't want another puppy that I have to take for a walk and maintain. I don't want a thing to care for. So, if I build it myself, it's my problem. If I build it here and hand it off, that can be your problem. You'll keep it running if the API changes.

11:49 Bryan Helmig: Yeah, we do, and there's a lot of things that change in the API world that we stay on top of. It just takes that whole layer of what's going on away, because we have, and I'm sure we'll get into it, we have tons of tooling that watches this, and it's really cool.

12:04 Michael Kennedy: I definitely want to talk about that, because you have thousands of integrations, and these integrations integrate together, which is even more combinatorially insane. That's going to be fun, and I want to talk about that, but let's just talk briefly about this at a high level why we're talking about Zapier. A lot of folks, they get up and they get in a car, and they drive through angry drivers and traffic for 30 minutes, and they all have to live around their company and they go to work. But as developers, and tech companies, and things like that, right? A lot of times, even if you're sitting next to somebody, you're working in asynchronous modes. You're making a GitHub issue, you're doing a PR, you're throwing a message in Slack. There's no reason you've got to sit next to the person, right? So, that's kind of what you guys decided, as well, with your 200 people. You're, more or less, 100% remote, right?

12:49 Bryan Helmig: That's correct, yeah. 100% remote. We don't have a single office. We're not geographically bound. We have people in, I'm going to say, I think it's like 18 or 19 different countries right now that work for Zapier. And we've been that since the very beginning. So, we started 100% distributed. We've been distributed throughout the entire time. So, every single person, it's funny. Basically, everyone we've hired, we had not met in person , right? There's a few exceptions to that rule, but everyone we've hired has been just a Zoom call, or a Skype call to kind of do the interview, or interacting over email, or interacting over text communications in some way, which really mimics the way that most of us work anyways, right? That's been just kind of a core part of Zapier since day one.

13:35 Michael Kennedy: I think that's really, it's pretty exciting, right? I mean, there's certainly drawbacks to working from home, right? People can get a little bit lonely. You have to be a little more self-directed, I think, because some people see working from home means I have no boss. No boss means I can just do whatever the heck I want. If I want to just watch football for the second half of the day, I'm doing that. Those types of people don't thrive, but I feel like a lot of developers and technical folks are pretty driven anyway, and if they have a proper outlet that's really they feel like they can contribute to, it's pretty easy to work from home, honestly, as a developer.

14:10 Bryan Helmig: Yeah, I think so, too. All the artifacts you're creating in a tech company, you're writing code, you're fixing bugs, you're working on features. The output's all there. You can see it either shows up in the repo or it doesn't. It either lands on the site or it doesn't. It's not that complicated to track the work. I often get folks who tend to be a little bit more, especially in the early days of Zapier, very skeptical about the idea of remote. How do you know people are doing their work? That has not played out to be the biggest problem for us. Many of the problems around, and you mentioned these are trade offs, a lot of the challenges you get into, are just challenges that you hit in a normal company. You just hit them sooner, right? That communication challenge doesn't happen when you're in the hundreds of employees. It happens when you're in the dozens of employees, right? Where everybody's off doing all this cool stuff, and it starts to get hard to coordinate, right? So, we had to invest in coordination and communication a lot earlier in the org, because you couldn't do that implicitly by picking it up around the water cooler, so to say, right? So, that's always been a big focus for us in the early days, was like, what's breaking now that probably wouldn't break until we were double or triple the size in a normal company?

15:29 Michael Kennedy: Exactly. So, what are some of the tools and things you put in place? To me, it feels like distributed teams 2018 is 10 times easier than a distributed teams 2006, 2008. But still, there's a lot of tools to pick from. What's an important part of that whole structure there?

15:46 Bryan Helmig: I mean, they're the same tools I think a lot of companies are using. I mean, they're the GitHubs, right? They're the Slacks. We use Zoom for calls. We do so many video calls. Constantly hopping on calls to chat over stuff. We've even built a couple internal tools that are custom to us. So, we've built an internal tool called Async, modeled around the idea of asynchronous communication, right? Where you look at something like Slack, it's very synchronous, right? You drop information in, it scrolls away, and it's gone. It's not gone, but it's basically gone. It feels ephemeral, right?

16:19 Michael Kennedy: It does definitely feel ephemeral, right? It's hard to keep permanent actions that you need to do somewhere in your Slack history.

16:25 Bryan Helmig: Yeah, that's important. You want to push that out, so what we've done is created this tool called Async and you can kind of think of it like WordPress, meets Reddit, meets Twitter kind of a thing. So, it's basically a blog mechanism that has some structure. Ways to describe it, for example, we require each post have a TLDR, right? Where you can in under 100 words or less, give or take, kind of summarize what your decision is that's enclosed in that Async post.

16:56 Michael Kennedy: Man, I love it. That's such a good idea because then you can tell how much attention you need to pay to it. Just in email, that would be a great inter-office communication way, because I personally get so much email that I'll periodically have to take eight-hour days and just answer email, just so it doesn't get too bad. And it's like, those were those little short bits, that would help sometimes. That's awesome. I like it.

17:19 Bryan Helmig: Yeah, it really would. And we've also added things like, depending on how many people view it, or comment, or like it, or interact with it, it gets hotter. It's a very Reddit style or Hacker News style thing, which helps surface just important information. So, earlier this year, Wade posted a whole bunch of essays on what we're trying to do in 2019, and everybody was interacting, and diving in, and chatting about them, and they popped right to the top. So, you don't even have to really work super hard to get that information. You just hit the homepage of Async and you get a flavor of what's going on in the company. You can read those TLDRs and you get a good idea. You can click in, you could go deeper, if you want. You can interact. So, this is an example of something we built internally for this, but it's not crazy software, right? It's not super complicated. This is something that, in conjunction with other tools like the classic, like we use lots of Google apps, and then the GitHubs, and the Atlassians and the Jiras and all that stuff, so we do, do some custom stuff.

18:17 Michael Kennedy: Yeah, that sounds really awesome, and I think it's great. I've worked for 10 years for a company that was remote, and we had people all over the world. There are definitely trade offs, but I really felt like the people I was working with were some of the very best people because they were chosen from the population of the world, not from the population of the town I happened to be in, which maybe was a small town or whatever, right? How's that either been a positive or a negative for you? I've seen a lot tension between some companies are like, oh, we have to have somebody local because it's super important we have this sort of control or view over them, and interaction with them, but I don't know that that's always the best.

18:56 Bryan Helmig: No, I don't think so. We've seen it in reality. We believe that talent is evenly distributed throughout the world, but opportunity isn't, right? So, in a large way, we see this as an incredible opportunity. Even just talk about America, a small town in America, right? And you have an amazing engineer that lives there. They live there because they have family and it's a great cost of life and they love where they're at. The opportunities as an engineer are likely pretty slim. It's one of those opportunities where those amazing folks, those really talented folks can actually contribute at the level that they can contribute at, that's pretty special. That's really, really hard to do when everybody's geographically located and you require someone sit there in an office. That just really wouldn't really scale out. So, for us, we think of it as it's something that is good for business, but also just really good for people, as well. It's just a better way to work. It's a better way to live. You can live where you want. Just look at the cost of living for your family, for everything. It's just so much better in every way. You just have to work through the little challenges that pop up in a remote environment, and it really helps to be 100% distributed. I think when you get that mix thing, yeah, it gets a little trickier.

20:12 Michael Kennedy: It makes it tricky 'cause you've got the insiders who are at the office, and they don't necessarily fully trust the remote workers, but maybe the remote worker's really talented, so they have to work with them. There's always these little undercurrents of weirdness. I've been in those situations, as well. This portion of Talk Python to Me is brought to you by Linode. Are you looking for hosting that's fast, simple and incredibly affordable? Well, look past that bookstore and check out Linode at talkpython.fm/linode. That's L-I-N-O-D-E. Plans start at just $5 a month for a dedicated server with a gig of RAM. They have 10 data centers across the globe, so no matter where you are or where your users are, there's a data center for you. Whether you want to run a Python web app, host a private git server, or just a file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24/7 friendly support, even on holidays, and a seven-day money-back guarantee. Need a little help with your infrastructure? They even offer professional services to help you with architecture, migrations, and more. Do you want a dedicated server for free for the next four months? Just visit talkpython.fm/linode. You were just talking about having a company retreat in New Orleans, and the company I worked for before when I was working remotely before I started my own certainly we had the same challenges of how do you connect? And so, having some kind of yearly or bi-yearly get together physically, and also you talked about Zoom, the video aspect of Zoom and Skype actually makes a big difference, I think.

21:42 Bryan Helmig: It really does. Internet connections are getting so good now that video connection can feel very real. You can interact, you can see someone's body language. So, you do get that.

21:52 Michael Kennedy: Yeah, you and I are talking, and it's almost as if we're sitting across the table from each other. It's basically as good.

21:57 Bryan Helmig: Yeah, it works really well. So, we've found it to be exceptionally good.

22:02 Michael Kennedy: Yes, I do think having the visual interaction is important like video calls, but then periodically these actual get togethers, right?

22:10 Bryan Helmig: Yes, the retreats.

22:11 Michael Kennedy: Yeah, like these retreats, I always looked forward to them 'cause it was like these people I really liked, and I would have more of a work, like you wouldn't hang out on Skype. You wouldn't like, hey, what are you up to? Man, let's hang out on Zoom. That's kind of weird, but you would have these meetings. So, this is your chance to be more friendly with your coworkers, right? I think it's a good combo. I think it works really well.

22:30 Bryan Helmig: Yeah, I do, too. When it comes to the retreats, we've done those since the early days. I remember our first retreat was seven people, and it's grown up to 185 or 190 people I think were at the last retreat. Which brings about a whole set of unique logistics challenge, but we found them to be really, really useful to kind of help set the stage for the stuff we want to talk about. One of the cool things, at least for me is when you're in an office, you kind of are pretty much like flat-line energy level. Like it's just kind of day in, day out. It's what you do every day. When you meet the team, you get them together, for us it's like twice a year, that energy level's through the roof. Everyone's really excited to see each other. You're diving into things, you're hacking on stuff. There's some really cool stuff that comes out as a result, so you get a little bit of the best of both worlds where you get to go back, you get to be in your space, you get to zone in, you get to have your flow state, but you also get to have that really high energy, connecting with people, spending time with them, which works really well. We try to emulate some of that serendipity things. We've used, there's this product called Donut for Slack, and it will pair you up with folks. So, we have these two-by-two people pairings that happen every week, three-people pairings that happen every week, and they just let you get together and just chat about whatever. And you get matched up with random folks in the team, so you get a little bit of that, as well.

23:55 Michael Kennedy: Oh, nice, and throw in little jokes, or just stuff just for more personal things?

23:59 Bryan Helmig: Yeah, yeah, you definitely do. And you get to hear a little bit about what people are up to, and hear about their family, and hear about this, or hear about that. It's those sorts of unstructured conversations that kind of bring out that humanness, which you do lose a little bit of when you're remote. So, we often have advice for folks to try to plan one day of your week where you go to a coffee shop or you go somewhere just to get out and move around. Some people don't need that, some people need more of that. Just be aware of that for yourself, because you're not often going to get that directly from working on Slack or something like that all day.

24:32 Michael Kennedy: I think that's great advice. People can go kind of stir crazy. I work 100% from my home office or somewhere else, right? Everyone I work with is some kind of contractor, or author, or something who's also not in any form of office with me. I know all the coffee shops around, especially in the summer, you know? Sometimes hit the libraries. But just getting out, that makes a big difference. So, I guess one more question that people out there listening might find interesting. Maybe they will more so after what we talk about in just a moment, but it seems like it fits better here. They're out there listening and they're like, I have this Java thing I'm doing and I'm not really super happy. I'd love a Python job. You guys are pretty much doing tons of Python, and they could work from where they are. Are you hiring?

25:15 Bryan Helmig: Yeah, we're doing a lot of hiring in 2019. We've been really fortunate that, you know, we've talked about this publicly. Zapier's been profitable for years and years, and we've been growing at a really respectable pace, and we have a lot of ambitions for 2019. A lot of cool stuff we've got to build. So yeah, we're 100% hiring. We're looking for folks who have Python background, have a JavaScript background. We're going to be hiring slightly different, on the manager track, we're going to be hiring folks on that side, as well, which we kind of think of as a different skillset. We're also hiring security folks. We're hiring test automation, you name it, we're hiring all the things in 2019.

25:50 Michael Kennedy: Super.

25:51 Bryan Helmig: Lots of cool stuff.

25:52 Michael Kennedy: Alright, awesome. I'm sure there's a career page at zapier.com, right?

25:55 Bryan Helmig: Yeah, /jobs. Zapier.com/jobs, and we've got them all on there.

25:58 Michael Kennedy: Alright, awesome. Nice, alright, so let's dig into some of the technology, because I think there's two sides of things that are super interesting, here. One, you've got your infrastructure and just the amount of people running jobs in triggered actions on your site is really interesting. There's so much happening there. And then also, you're calling thousands of APIs. And these APIs are not totally stable and all sorts of stuff. So, let's dig into that a little bit. Maybe just tell us real quick what kind of tech is involved and things along that line.

26:29 Bryan Helmig: We've tried to keep it pretty simple because we have plenty of complexity when it comes out on the other side with talking to APIs, and some of the interesting combinations users make. For us, we're Python. I mentioned earlier we're Django based, so we're still using a lot of the ORM, a lot of the standard tooling that comes with Django, a lot of the caching bits, a lot of the session bits. All that stuff we still use really, really heavily.

26:51 Michael Kennedy: What kind of database backing are you guys talking to with that ORM?

26:54 Bryan Helmig: Yeah, yeah, we're talking to MySQL right now. We're starting to kind of shard off. Not sharding in the sense of like, sharding over consistent sharding over IDs or anything like that, but functional sharding where you try to extract this service from the monolith and say okay, well, now this is an opportunity. Maybe we'll use a more specialized database. Maybe we'll stay relational. We'll use Postgres, or upgrade the MySQL to something a little different. Or maybe we'll use some sort of NoSQL or specialized read and write patterns that make that use case even better. So, for that we're looking at mostly vanilla Python on the backend, the workflow engine side, right? You think of that big behemoth as running in the background, doing all this crazy stuff, talking to all these APIs, kind of your little robots running around the internet, and that's all Python. You think of Celery. We use a ton of Celery, right? We use a ton of that. And we use RabbitMQ for a lot of the message passing between that. We're still using Django on the HTTP front, I mentioned. We use a lot of pretty vanilla ingest for web hooks. I know we do a lot of polling, which is a lot of backend stuff, but we also pull in a lot of webhooks. So, this is great when services send us those webhooks and let us know about things changing.

28:10 Michael Kennedy: Right, webhooks have to be basically the best possible outcome, right? Because something like an email or an action happens, and that service tells you, rather than just, you got anything for me? You got anything for me? You got anything for me?

28:22 Bryan Helmig: Yeah, yeah, yeah. It's huge. We did a big analysis, and we actually even shared and tried to get more partners onboard with webhooks and what we call REST hooks, which is just a way to subscribe to webhooks. 'Cause I think for a while, especially in the early days of webhooks, it was like, hey user, please copy this URL into this other service. Whereas now that we have REST APIs, we can just post to a subscription or webhook endpoint. It'll create a webhook and send you those events and then you can tear it down. So, we've done a lot there. We did a bunch of analysis in the early days, and it's something like 66 times more efficient. Because on average, you're asking hundreds of times for new data, and there's nothing there. And then the one time there is, right? Just super, super wasteful. So, we try to push towards webhooks and event-driven sorts of things as much as we can.

29:10 Michael Kennedy: Yeah, so you go to these partners. You're like, we would like to not call you 100,000 times a day.

29:14 Bryan Helmig: Yes.

29:15 Michael Kennedy: Could we make it so we just call you 100, or 50, or 1,000, or whatever the right number is?

29:19 Bryan Helmig: Yup, exactly. Some partners are really into that and they have some services, some endpoints set up to create those webhook subscriptions, and some don't. In those cases, we do fall back, kind of that polling architecture, but yeah, we really like it when partners do add those web hoocks.

29:38 Michael Kennedy: I'm sure. So, I feel like this asynchronous queuing, message passing, message bus type of world must be pretty important for you guys. A new trigger has come in from a new Gmail, but then you want to talk to Dropbox. You don't necessarily want to block that up. You're like, okay, well, kick off a message, you need to take this thing from Gmail and move it over to Dropbox when you have a moment, alright? And just sort of pass it down the flow. You want to talk a little bit about when that happens and how that helps?

30:03 Bryan Helmig: Yeah, I mean, if you go into Zapier and you go in to build a Zap, like a workflow, you'll see multiple steps. Maybe it's a, I'll use starring a message in Slack, and then you add it to, let's say, Todoist, right? Those are two distinct steps that we've broken apart on the back end. On the back end they're stored in kind of a self-relational sort of a tree. You can kind of think of it as a tree. There's no real ways to do cyclical sorts of things, because you get into, now you're into control flow stuff, and that's a little bit crazy for most users.

30:35 Michael Kennedy: Recursion with drag and drop. Probably not.

30:37 Bryan Helmig: Yeah, yeah. It gets tricky, so we avoid that. You can kind of think of this as that's a two-step Zap. Slack, Todoist, and we just pull that data out of Slack, we pass it on to the next one, and we have a whole templating system that passes in that data into the inputs of the next step in a particular way, and users can define that however they want, which is kind of this cool customizability. So, you can think of that task would say the message, and maybe the time, and who actually made that message in Slack, and you put that all in the description field for Todoist action, which would be maybe create a task, or something, or a to-do item. That would trigger on and push down to a totally separate step that's going through RabbitMQ in that case. Then once that, you call into Todoist and you're complete with that. You get a 200, everything's hunky-dory. You look for any other children you have, and in that case, you have nothing, and you insert no child task, and you're done. The Zap is finished running. That's pretty much the workflow, and you can see how that would expand, and you could have dozens of steps and it walks down through a dozen steps until it gets to the last one. Nothing to do, so it's finished.

31:45 Michael Kennedy: Yeah, yeah. How do you deal with the poison message equivalent, right? The third step is I want to call the Todoist API, and I'm a big fan of Todoist, by the way. But maybe that day the Todoist API is down for like, two hours, and you're like, well, do you throw it back in the queue? Do you put it in some other place? Like we're going to get to this, maybe when things are better. 'Cause I'm sure you're like, there's probably an API permanently at any moment in the day, there's one of your APIs that is not behaving that great, right? That you've got to interact with. There's so many.

32:16 Bryan Helmig: Yeah, definitely. And there's a couple ways that we handle that. Since we do so many requests, and we log all these requests, and we track all these requests just for understanding the health of APIs, when we see one starting to fail, we see if it's failing for a lot of users or if it's just one user. If it's just one user, that's an error. Maybe something about the to-do item they were adding is actually invalid, right?

32:40 Michael Kennedy: Right, they deleted the project they're trying to add it to, or whatever, right?

32:43 Bryan Helmig: Yeah, exactly. It could be anything like that, and that's a user-specific thing. So, that would pop us as an error, we'd email them, hey, head's up, something funny's going on with your Zap. Click here to learn more. But if it's something that's happening across a high cardinality of users, a bunch of different users are hitting this, now we know, okay, something looks a little fishy here. And at that point, we'll start to hold things back and periodically let them through to see do we have things going from maybe a 403? We're getting non-stop 403s, someone shipped a bug, and da-da-da, it's a mess. And we'll retry those until we start to see 200s, and then we'll let the rest of them go. We'll try to trickle them out until we see them clear up. And that's a really common pattern for us. We've invested a lot in just trying to understand when APIs go down, because I joke that we're like, an edge case catching machine for the internet. Anything that will go wrong, we will find out about it in some way, so we have to have all this really intelligent monitoring to stop that from happening. Really keep it from impacting users, or at lest give them the awareness that, hey, heads up, there's some internet stuff going on. Maybe AWS is having some sort of an outage and look at all these services that are 503ing, and we can kind of tie that together.

33:56 Michael Kennedy: Yeah, cross your fingers and hope that us-east-1a doesn't go down.

34:01 Bryan Helmig: Right, yeah.

34:02 Michael Kennedy: How much stuff runs on the Virginia data center of AWS over there?

34:05 Bryan Helmig: So much. Yeah, a lot of ours does, and we can often tell, if we see any funniness with AWS, we can always just go look at our Partner status health dashboard, and see if anyone else is having issues. And if it's just us, it's like, oh, okay, so we must be doing something funny. But if everybody's having issues, we're like, okay, so Amazon is having an issue and they haven't quite updated their status page yet, right?

34:28 Michael Kennedy: Exactly. You're like, a little bit of a canary on that.

34:31 Bryan Helmig: Yeah, definitely.

34:32 Michael Kennedy: Interesting. This portion of Talk Python to Me is brought to you by Ting. Let me tell you about Ting, a new mobile service available in the US. This targeted developers and other technically savvy folks. First of all, their average customer only pays $23 dollars a month, but they're no discount provider. Their service runs over T-Mobile's and Sprint's fast nation-wide network. If you don't use that much data because you're usually on WiFi, like many of you are, then Ting'll save you a ton of cash. But don't worry, you can still use as much data as you like for just $10 per gig. One mobile feature I use all the time is tethering. With Ting, you get unlimited tethering at the same data rate with your account. $6 a month for a phone line, $10 a gig, $3 a month for text if you usually chat over iMessage or WhatsApp. Think about it. No contracts and super clear and fair billing. Visit python.ting.com. That's python.T-I-N-G.com, and check out their savings calculator. Enter your usage and see exactly what you'd pay. Use that link and you'll get a $25 credit to try them, as well. That's python.ting.com, or just click the link in the show notes. I guess, it sounds like you host a lot of your stuff at AWS, and you probably don't have a big in-house data center. That would make more sense if you have a big office and part of it could be the data center, but if you have no office, who's going to offer up their bedroom to get fiber and cooling? That just doesn't make sense. Are you running AWS? Where's your services hosted?

35:59 Bryan Helmig: We're predominantly AWS. We have a lot us-east, of course, but we also have a couple things that fail over to multiple different regions. So yeah, we've jut leaned into AWS since I think, I think maybe we did Linode or Linode back in the early days for a hot minute, and then that went over to AWS since then. We try to use some of the manage services where we can, so you're looking at the RDSs, and the ElastiCaches, and of course the ELBs and ALBs that exist out there. Tons of S3. So, we try to lean on some of the managed services where we can to just knock down the amount of deep, intricate knowledge we have to have about Postgres, or MySQL, or whatever, right?

36:37 Michael Kennedy: Yeah, let them do the operational bits of that. Interesting. To me, it feels like the Cloud, especially AWS, and Azure, and Google, those three clouds feel like that's the new lock in, right? And I don't necessarily mean that in a bad way, right? When you take full advantage of a platform, you get all of the features of it, right? You could treat AWS as a fancy Linux hosting environment, or you could use all the databases and all the files, all of the APIs, and really get a lot more out of it, but then you're kind of permanently stuck to it. How did you guys think about lock-in and Cloud and all that?

37:14 Bryan Helmig: We kind of tread the line a little bit in between. So, all of our workloads that you think of, or a large majority of our workloads that you think of, just running tasks and performing these actions for users, they're running pretty bare bones, like EC2 instances. We found that, that generally has the best performance characteristics. We have the most control over it. So, in that case, it's not really locked in a whole lot. We're starting to lean into things that are like open source orchestration frameworks. The classic Kubernetes transition that I think a lot of companies are trying to do now. Again, we're talking about pretty open source, standard sort of a thing, which we really like. But we're also not afraid that on an occasion, using some of these specialized services, if it makes our lives a lot better, we'll use it. RDS is a great example of them splitting the middle. It's standard MySQL, so in the future, if you decide you want to swap out, it's not the end of the world, but you don't have to worry about it in the meantime, right? You get all the goodies kind of, a little bit, certainly not for free, but with less work on your side, and now you can focus on the product. So, we definitely leaned into that a lot. We haven't done a whole lot of hyper-specialized stuff. Maybe the only thing, I think, that we do a lot of is use a ton of AWS Lambda. In fact, back in the early days, we built our own version of AWS Lambda. I forget what we called it, but where we could more securely run a bunch of partner-provided scripts and user-provided scripts. That way they could do this kind of Python and Zap thing, or they could stand up their own Partner app, so this allows partners to kind of deploy code to us to talk to APIs and integrate with any of our 1,400 different apps. That was running on our own little flavor, and then as soon as AWS came along, it was like, actually, we got this, and it's way better. We immediately swapped it all over to that as fast as we could. So, we do use things like that, but even that has been commoditized to a large degree. Both Google and Microsoft's Cloud offerings have the serverless sort of vibe going on, too. So, it's kind of interesting. We've tried to balance it, on the whole, to where we can focus more time on the product, but not go too hardcore, use really specialized stuff.

39:33 Michael Kennedy: Right, right. It's that kind of stuff that lets you do what you're doing on a 200 person team instead of a 500 or 1,000 person team, right? There's not like a fleet of database engineers and other infrastructure people, right? There are really big benefits to this, and I kind of do the same thing. There are certain things where you're like, okay, that's really not available elsewhere, or it's so much more work. I'm going to just plug into that API or this API.

39:56 Bryan Helmig: Yeah, definitely. Yeah.

39:58 Michael Kennedy: So, you did talk about calling a few APIs, and if you're doing that with Python, the most common way to do that probably is the requests, the module right? Are you guys using a request for all this, or how does this work?

40:12 Bryan Helmig: Yeah, we use requests, but we use a bunch of our own. I mean the great thing about requests is how extensible it is. You can swap in and out your own HTTP adapters, and then from there you can swap out almost everything, so we have custom DNS resolvers, we have custom request adapter, or HTTP adapters, we have custom response and request types. They all kind of encapsulate some of the behaviors, and the logging, and the monitoring that we want to have. We have different classes.

40:39 Michael Kennedy: Give us some concrete examples. You have a custom DNS thing. Is that so you can do better caching and not make the calls faster? What's the idea there?

40:47 Bryan Helmig: The idea there is if you, for us, we want to be able to have a lot of control over what DNS services we have with which adapter we're using. For example, we use requests for internal communications, which is like a different DNS provider. And then when it comes to user, outbound user stuff, we would want to use either the Google 8.8.8.8, or maybe Open DNS, or even maybe some sort of a custom thing for a user, so in those cases we want to be able to swap that out and that's a fairly low level. I mean, it's kind of automatically done for you a lot of times, but if you want to control that you have to kind of start digging into the HTTP adapters and intercept some of the connections that are opening, and all this other stuff, and you have the opportunity to do that with requests. A really specific example we talked a lot about this monitoring bit, so we have different libraries that you can like, or sorry, different interfaces that you can basically attach and say, hey, this is my Salesforce session, and it'll start to do all the logging for this public API to the proper spots for you so you don't have to worry so much about, oh, am I doing the right logging here? Am I doing? It'll do all the stuff where it kind of cleans up the secrets out of it, and it does the proper truncating so we're not dumping 50 megs logging service. It does all this stuff...

42:08 Michael Kennedy: The logs are full again.

42:09 Bryan Helmig: Yeah, that you kind of forget that, oh yeah, yeah, yeah, you got to remember to do that through a very familiar interface that you can just pop onto pythonrequest.readthedocs.org, and read all about exactly what it's doing. It's so much easier to onboard new employees, new engineers on, and you can kind of extend and give the best of the community, the best of tools that exist out there. So, that's kind of the way we've approached using things like requests. I mean, it's been really quite useful for us, and very successful.

42:41 Michael Kennedy: It's a great library. I'm wondering if there's some of these integrations that are they basically have really nice, pre-built Python packages, and some of are just like, here's an HTTP endpoint. Knock yourself out with whatever tech, right? For example, GitHub. There's GitHub packages that you could use in Python. Do you ever use those, or you're like, it's better for us to just stay separate at HTTP access level?

43:08 Bryan Helmig: Yeah, we've gone the HTTP level. Those libraries are awesome. Especially if you want to just spin something up quick, but we've gotten so good at talking, like we talk to REST APIs. We're good at that. We've done it a lot, right? It's kind of our bread and butter, so we want to talk to that and have the control over that. So, we used to do a little bit of that in the early days, and then we got to the point where observability became tricky. Some of them used things like requests behind the scenes. Some of them used httplib2, some of them just used like the built-in. Everyone was doing different stuff, and then you had to rewrite how your observability and your monitoring worked. So for us, it just became hard to do, so if you're talking to lots and lots of APIs like this, it really does help to standardize your interface on that.

43:53 Michael Kennedy: Yeah, it seems like it must have been almost a dependency hill, of a sort. If you're like, we're going to have 500 different packages, and those packages might go out of favor, and then they're not quite up-to-date, or there's a breaking, there's just so many layers, right? You're just like, let's just do the same for everything, yeah?

44:10 Bryan Helmig: That's really where we kind of landed. That was through some learning. Especially in the early days we did do a couple of those libraries that you could just pip install mailchimp, right?

44:20 Michael Kennedy: Yeah, exactly. We're good. We're good.

44:22 Bryan Helmig: Yeah, they did help, and a lot of them are also, funny enough, they're built on little, odd behaviors, that seem fine in isolation, but when you're running something like what we do, it doesn't really fit. For example, some of these libraries you'll just import mailchimp, and then on the global object, do mailchimp.apikey, and just set your API key there, which you never know which user's API key you're going to use. When you're us, you look at that and you're like, oh, that doesn't really work. I want to create a mailchimp session object, you know what I mean?

44:57 Michael Kennedy: Yeah, any time you're doing multi-tenancy, those little gotchas are super scary. You're like, why did I just expose all of this other customer's data, or something, right?

45:05 Bryan Helmig: Yup, exactly. So, that's why having control over that layer and being really particular about when you're opening and creating new sessions, or you're reusing them or not, you want that control, so that's where we've kind of landed for that, and it works pretty well. When I was talking about the AWS Lambda side, a lot of that's on the JavaScript side, so we do provide maybe not the perfect equivalent to Python requests on the platform, but we call our platform CLI and SDK. That has a similarly inspired sort of a thing. In our case, it's like the Z object that has a request method on it. If you use that, then you get all the magical logging, and you get all the magical introspection on the calls that you're doing, so it supports that. And if you break out of that, maybe you have your own JavaScript SDK for talking to your own service you'll lose a little bit of that. And in that case, it'll be harder for us to debug your services or help users out. So, we do try to encourage folks to use that kind of standard thing both inside Zapier obviously, but also outside of Zapier. So, when partners are interacting and working with us we also provide some.

46:11 Michael Kennedy: Yeah, interesting. You talked earlier about this asynchronous message passing, and queues, and whatnot, and Celery, and that's really important for scalability. But another huge, huge scalability booster is some sort of asynchronous web handling, right? Like Gevent, or async and await, Asyncio, all those kind of things. Does that show up anywhere?

46:32 Bryan Helmig: We have experimented a bit with it. This is one of those classic like, you try it out and then you run the numbers and see how much does it save you? How much headache does it add?

46:43 Michael Kennedy: How much more complex is it, right?

46:45 Bryan Helmig: Yeah, exactly, and we tried this maybe, I want to say, two years ago with Gevent. It was right on the line, but probably at that time, it just wasn't a good enough move for us to like, transition over to it. So, we actually abandoned using Gevent, and we're still using pretty straightforward, synchronous Python, which is right now, we're still transitioning to Python 3 at the moment. Making good headway on it, but a lot of the Asyncio you mentioned, a lot of that adds tons of complexity to your code. Gevent does the same thing. There's all these little extra things you got to remember, and Python, I think, hands you a gun that's very loaded when it comes to Async stuff, so it is a little bit tricky, and that's not to say there's, I mean, there are other languages that do a really nice job with Async. But even something like JavaScript, I think still you get a loaded gun, right? It just adds this layer of complexity that I don't think was worth it for us at the time. I think there's some cool things we can probably do in 2019 to get back to that, and that's through moving more services behind an IO boundary. Just a regular HTTP boundary. So, less things happening in the process itself, and it's sitting across a very easily Async boundary where you're talking over a socket, or something. I think if we start to move more workloads over there, and we have kind of this clean interface, the Gevent equation will quickly tip in the other direction. So, I'm excited to maybe look at that again in 2019. But yeah, we gave it the old college try, and it was a bit of a bear, and it was about awash. Maybe it would have saved us 10 or 15% on our infrastructure cost because you still had tons of locking and database connection stuff that you had to deal with that would still put some limits on what you could do, but I'm excited to play with it in 2019 because I think we could probably drive our cost down, if we do it really well, by 30 or 40%.

48:39 Michael Kennedy: Uh-huh.

48:40 Bryan Helmig: And now that's starting to be appreciable amounts of money. Before, that was not that much, so now I think it would probably be getting closer to worth it.

48:48 Michael Kennedy: It's that complexity trade off, and at some point when it's $50,000 a month, you're like, you know what? We're going to just bite the bullet and solve this complexity problem and give everyone a raise, or whatever, right?

48:59 Bryan Helmig: Yeah, in those cases, yeah. Yeah, yeah. You mentioned that. We also do profit sharing, so there's a lot of incentive to do some of these cool cost saving things, but when you're measuring, this is getting away from maybe the Python side, but you're getting into the business side of, well, we could trade a dollar of cost savings for $2 of revenue? Ah, you know? Do you go for the revenue because it opens up more opportunities later on, serving more customers?

49:28 Michael Kennedy: I go for the revenue.

49:29 Bryan Helmig: Yeah, we're...

49:30 Michael Kennedy: I'd go for the revenue, yeah.

49:31 Bryan Helmig: Yeah, we're the same way. We've been really fortunate that the product itself really connects with all these users, so for us, expanding that's really, really interesting.

49:40 Michael Kennedy: Right, well that's actually basically, has analogies to like why do you even choose Python at all, right? You could right this in C++ mostly with wrapping it in Java, or something. And you could save money on infrastructure, right? But the rate at which you generate features and you make users delighted would be slower.

49:59 Bryan Helmig: Right.

50:00 Michael Kennedy: It's like people say Python is slow and you guys are doing incredible stuff. I don't actually think that's true. I think it's like it's complicated is more of the right answer, but at the same time, that does not talk about, well, Python is fast for features, right? Which is pretty awesome.

50:18 Bryan Helmig: Yeah, it is pretty awesome, and you're looking at companies that are generally selling a digital good. The margins are really good, so you have that headroom. You're not getting squeezed down to some super tight thing where you're like, oh, we have to rewrite this and see. We have to go really super low level and eek that performance out.

50:37 Michael Kennedy: Right, you're not General Motors at 6% margin, right? You got more room to play with, right?

50:43 Bryan Helmig: That equation may change. Let's say you're the, I'm going to say some of these security cam software that exists out there, right? Maybe you do like this cool, little hardware. We sell the hardware. We give away the free tier, and you have a more complex business model, and now you may care a lot about those margins and Python may not work for you. In that case, yeah, it's too slow, right?

51:05 Michael Kennedy: Right, right, right.

51:05 Bryan Helmig: It's very context-specific. For us, it's not too slow because the value we can create with it is orders of magnitude higher than the effort that goes into it. That changes depending on the business, and the margins, and the context, but for us it's been awesome and it's been really, really fun. But that's not to say that there's maybe not cool opportunities to use. Maybe for us might be more like GoLang stuff, in the future is to rewrite some kind of like, core tier zero services in that to eek out a bit more performance, but still use Python for a lot of the product-facing, and things that you're going to be touching on a day-to-day basis and integrating for users. It's not a one and done kind of a thing either these days.

51:46 Michael Kennedy: Yeah, yeah. Well, one of the things that seems like there's probably a place somewhere for this to fit, but it might cross the complexity threshold on the other direction and make it not worthwhile, but with Cython, you could take the little bits that are slow, write that in Cython, and then use the nogil block in Cython and achieve a ton of concurrency and CPU speed with changing 20 lines of code, potentially. Have you explored any of that?

52:15 Bryan Helmig: We have done a little bit of that, especially in some of our ancillary services. A good example is we have a email parser, which kind of lets you tag emails, and then will try to extract pieces of that, and we've done quite a bit of stuff where we've tried to optimize that engine, but it's just pure Python. It's just doing a bunch of string slicing, and comparison stuff, and you can wrap that up in Cython. Cython was a thing that we actually use. We ended up rewriting a little bit of it, like some of the core pieces in C++ to speed it up, but again, a very kind of niche, very specific use case, which is really how you should be thinking about performance, is you should make it work, and then if you need to, right? Make it fast, and use the tools at your disposal, and Cython was one of those. We had pretty good success with it, so I do think it's a realistic option.

53:03 Michael Kennedy: Yeah, I've seen some really good outcomes from that, as well, and I think it's pretty interesting, right? It's like when you look at a huge code base, there's usually a couple of spots that if you could unlock the performance on just those little bits, actually, that's where most of the problem is, right? That's where most of the latency is.

53:19 Bryan Helmig: Yup. 100%. And there's some really cool posts out there. I think Instagram engineering did some where they would use the C profile module, and then measure CPU ticks for all the different stuff that they did. So, they could really get, instead of wall clock time, which can be like, oh, we blocked on this, we waited on this, and you get a different look at the code. You can do some really cool stuff with Python that I don't know if a lot of folks are aware of just the level that you can go just straight Python and get really, really high performance stuff. There's a lot of cool tricks and headroom in the language itself. So, I think we got a lot of headroom when it comes to Python and Zapier. We're definitely doubling down on using Python in 2019, and beyond.

54:02 Michael Kennedy: And the conversion from legacy Python to modern Python, it's underway?

54:06 Bryan Helmig: Yeah, it's underway, yeah. We're running all of our test run in both Python 2 and Python 3, and have been for a little while. So really, what we got to figure out now is just make that transition in production, and make sure that we don't break any caches, or behaviors, or things like that. So, figure out a good way to try doing some canaries, and all this stuff. That's kind of the next step for us. We're right there.

54:30 Michael Kennedy: That's exciting. You're on the cusp of it, yeah.

54:32 Bryan Helmig: Yup, I suspect in the next couple months we'll probably be running Python 3 in production, so pretty exciting.

54:38 Michael Kennedy: Sweet. Yeah, the one place I've heard really scary stuff in is around caching and pickles, right? Pickle take objects, and they just pickle them up and cache them rather than doing a JSON to/from sort of intermediate thing, and then boom, a different CPython grabs it. It looks different.

54:54 Bryan Helmig: Yup, that can cause a lot of trouble.

54:56 Michael Kennedy: All sorts of madness breaks out.

54:57 Bryan Helmig: We try to avoid pickle as much as we can, but for some stuff like the convenience is just so nice. Just...

55:03 Michael Kennedy: I know.

55:04 Bryan Helmig: Right? So, we try to avoid it and we try to do JSON serialization as much as possible, but yeah, that is a tricky thing around deploying between 2 and 3 and testing them. It just makes it really operationally complex, so that's something that I think is sometimes overlooked whenever people think about transitioning their code base to Python.

55:24 Michael Kennedy: Right, right. You got to be careful there. Oh, that's cool. Alright, well, this has been such a super interesting look inside Zapier and what you guys are doing, and a really neat use case. There's a couple other questions I'm going to ask you before I let you go, though.

55:37 Bryan Helmig: Sure.

55:38 Michael Kennedy: Even though we're running a little low on time. First of all, what's it like being the CTO of a big tech company like this? There must be a lot of plates spinning, a lot of things you do, but I bet it's fun.

55:47 Bryan Helmig: Yeah, it's really fun. And the role has kind of changed, and I feel like one thing, the journey that I went on from early CTO all the way to now, which was wearing a lot of the hats, is probably a really common one, but it's different for a lot of folks. I talked to a lot of CTOs. Try to figure out what is a CTO in a tech company? I've talked to maybe a dozen different people and I got a dozen different answers, so it's really a very personal journey, and what does a company need sort of a thing. So, for me it's been definitely a part of discovery, as well, but also for me, it always comes to back to what does a product do? The product resonates with me as an engineer, like giving people the power of engineers to do all this stuff even though they don't know they're kind of like building automations in the same things that we would do. You're still giving them that power and that's really exciting to me. So, I'm excited to spend a lot more time in that, and then diving into the architecture and the scaling issues that a service like Zapier has is really, really exciting for me.

56:45 Michael Kennedy: Yeah, that's a fun part of software to think about, right?

56:47 Bryan Helmig: Yeah. So, being a CTO at a company like this is really exciting. I'm also just really excited to be hiring engineers that are better than me when it comes to all this deep, interesting stuff. We have some core Django contributors, and they're amazing to dive into and learn about some of this stuff that we use every day, and that's always really exciting, so it's really humbling at the same time. So, it's just a really fun, I mean, it's super fun. It's super fulfilling, but we have a lot that we want to do, so I feel like I got to get back to work, too.

57:20 Michael Kennedy: I'm sure. Alright, another one is just a couple real quick. What are your favorite automations?

57:25 Bryan Helmig: Some of my favorite ones, they have a little Python sprinkled into 'em. So, those are some of my favorites, especially whenever I want to do something that's kind of a little bit funky and weird, and I don't want to deploy any extra code. I'll often write a Python step. A really specific one that I've done because I've been running a lot of engineering, like the meetings, the all hand kinds of things, and we try to prep, and have notes, and have a lot of the stuff ready, is I have a schedule set up, and I have a Zap that triggers off of that event, which is kind of a recurring event. And it goes out and it grabs a template from Google Docs. It copies a bunch of stuff into a new Google Doc. It includes a bunch of charts and a bunch of little things that we should be talking about, and then goes into the Slack room and posts it and reminds people, and I have it set up with a delay so it even reminds people periodically. Like hey, two days to go. Make sure you add your notes to this, and like, meeting is coming up in an hour. So, it's really, really helpful because a lot of times, I mean, people are crazy busy, obviously, so I found myself going around reminding folks to get that stuff ready, and this kind of just automates that away, and it does a lot of really cool stuff there. I have so many Zaps running. We have so many bots running around in Zapier, too. Sometimes they'll bump into each other and do crazy things. It's really quite fun. It's pretty exciting.

58:43 Michael Kennedy: That's super awesome. And it has this nice aspect where the thing doing the reminding is not a person, so that person doesn't get a little bit like, oh, that person's a nagger, right? You don't have that aspect. It's like, well, the bot did it. It does it every Thursday before our Friday meeting, or whatever, right?

58:58 Bryan Helmig: Yeah, and it's super handy, and you can go in and you can adjust it. So, if someone's like, oh, that's the way this is phrased, or you didn't include this link, or it'd be great if you added this data to it, like it's in a team account. Anyone can hop in, and play with it, and change it, and swap it out, and tweak it, and we always include the link to edit the Zap in the messages that we send around. So, anyone can go in and make it even better and add functionality to it, which is a really collaborative way to build some of these workflows, and augment these bots that are doing stuff. 'Cause like, you'll see it, and you'll be like, oh, it'd be great if it actually included this link and it said this thing. You just hop in and change it. It's really, really fulfilling to be able to just see something, change something, and then the next time it goes, there's no deployment going on. It's just doing it. It's really cool.

59:43 Michael Kennedy: Yeah, that's super. How cool. The singularity is near. Okay, so the last two questions that are standard, not focused just on you is, if you're going to write some Python code, what editor do you use?

59:53 Bryan Helmig: I use Visual Studio Code, the new one. I think that Microsoft's new code editor, some of their philosophies around focusing on developers has been really great. You get some awesome tools, so I use that, and I quite like it.

01:00:05 Michael Kennedy: That's cool. Yeah, it's definitely got a lot of momentum, and I think they're doing nice stuff there. And then, you definitely work with a ton of PyPI packages. Maybe one that's notable, not necessarily the most popular, but people, you're like, oh, you should know about this. Have you heard of...

01:00:19 Bryan Helmig: Yeah, I would probably say, and maybe everyone knows about this, but it was kind of new for us a couple months ago. The Python formatter, Black.

01:00:27 Michael Kennedy: Yes.

01:00:28 Bryan Helmig: Really, really love that. So, we've completely Blackified our entire code base, and it's so nice to just not think about that. 'Cause we would always be like, oh, do we want to do commas here? Do we want to split these lines? It was just a thing we worried about, and we cared about, and we want our code to look great and be easy to read, and Black does an amazing job at that. So we do that, and we really, really like it. So, if folks out there aren't using Black, you should check it out. It's really cool. Super useful. So, that would be mine.

01:00:57 Michael Kennedy: That's great. Do you set it up as a pre-commit hook?

01:00:59 Bryan Helmig: Yeah, we have it as a pre-commit hook. We have all of our CI stuff running that checks it all. Yeah, it's a big part of our workflow now.

01:01:06 Michael Kennedy: Yeah, solid. That's cool. Alright, well, final question. People are excited about this distributed work, Zapier, all the tech we talked about. What do you got for 'em?

01:01:15 Bryan Helmig: Check us out if you're interested in building any of these workflows, or you have colleagues that could benefit from any sort of little workflows like this. Let 'em know. I mean, we can kind of do a little bit of anything. If you use any SaaS apps, we've probably got something useful for you. Then also, if you're looking for a new gig, and you're interested in remote work, check us out. Not only do we have a ton of information on how we work, like we just shared it and open sourced a lot of our processes, but we'd love to maybe work with you so we have lots of jobs coming up in 2019. Lots of roles, so definitely keep your eyes out there. And you can even set up a Zap that will alert you of new jobs that pop up on the site, and then they will send you an email, or maybe a Slack message, or something like that. So, check that out.

01:01:57 Michael Kennedy: That's pretty meta, and awesome. Awesome. Alright, let me ask I guess, one more follow up. So, we talked about if people want to set up these automations, that makes a lot of sense. What if these folks listening are developers at a company and they're like, why doesn't Zapier integrate with my company and my APIs? What do they do then?

01:02:13 Bryan Helmig: Yeah, so we do have an open platform, so anyone can kind of hop on. I mean, we actually have a lot more private APIs that people have added for their own companies. It's really, really straightforward. We have lots of examples. You can either build them in the browser and just kind of post your REST URLs, and things like that, then we'll do all the magic there. Or you can write a JavaScript Node.js package, which fits just kind of a light spec that we have. We have tons of examples, and you can expose different endpoints and write little custom functionality. So, you can say, here's this JSON list that shows all the most recent leads for our company. That can turn into a trigger, and here's a POST endpoint to create a lead, then you can define what fields go into that, and then away you go. And it works with 1,400 different apps out of the box, which is really powerful.

01:03:01 Michael Kennedy: That's pretty cool. Alright, well, it's been a lot of fun to talk to you about all these ideas. So much cool stuff you're all doing. Thanks for being on the show.

01:03:07 Bryan Helmig: Of course. Thanks, Michael. See ya.

01:03:09 Michael Kennedy: Yeah. Bye. This has been another episode of Talk Python to Me. Our guest on this episode was Bryan Helmig, and it's been brought to you by Linode and Ting. Linode is your go-to hosting for whatever you're building with Python. Get four months free at talkpython.fm/linode. That's L-I-N-O-D-E. Ting is the fast mobile network custom-built for technical folks. Use their savings calculator to see exactly what you'd pay. Visit python.ting.com to get a $25 credit and get started without a contract. Want to level up your Python? If you're just getting started, try my Python Jumpstart by Building 10 Apps course, of if you're looking for something more advanced, check out our new Async course that digs into all the different types of Async programming you can do in Python. And of course, if you're interested in more than one of these, be sure to check out our everything bundle. It's like a subscription that never expires. Be sure to subscribe to the show. Open your favorite podcatcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now, get out there and write some Python code.