Have you ever wondered what a developer advocate, sometimes called a developer evangelist, does?
You know the folks. They're often seen at conferences, working at some high-end tech
company's booth, or traveling from conference to conference speaking on their specialty.
Who are these folks? How did they get this job, and what is it really like to do it from day to
day? Join me, along with Cecil Phillip from Microsoft, Matt McKay from Twilio, and Paul
Everett from JetBrains to dig into what it means to be a developer advocate and how they each became
one for such cool tech companies. This is Talk Python to Me, episode 189, recorded November 28th, 2018.
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 at,
mkennedy. Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on
Twitter via at Talk Python. Cecil, Paul, Matt, welcome to Talk Python.
Thanks for having us.
Yeah, it's great to have you all here. I'm super excited about this, I'm not even sure what we're
calling it, developer advocate, developer evangelist, developer relations conversation, because I feel
like this role is a little bit mysterious to many folks in the software engineering field.
But at the same time, it looks really fun. And I think a lot of folks interact with all of you,
and it's going to be really fun to just dig into what you do and how you got there.
So I guess the first place to start will be, where do you work for who you are? A little more background,
who you are, where you work, and what you do there in terms of this advocacy role.
Cecil, let's start with you.
Sure, no problem. So my name is Cecil Fulop. Right now, I'm a developer advocate at Microsoft.
Primarily, my team focuses a lot on just making sure developers have a really good experience moving their
applications into the cloud. So as you can imagine, we work a lot with the folks on the Azure side of things,
but then also, too, we spend a lot of time in the community kind of just going around to various events and doing
workshops and different things like that.
All right, excellent. Paul, I'm a developer advocate, using the word advocate.
We'll get back to that later. JetBrains, primarily for PyCharm, and I'm based out of the U.S.
I get to tell people I work for a check company founded by Russians out of my basement in Virginia for the Boston office.
And many of them are in Germany. So yeah, it's quite the international space. And in terms of developer focus, that's basically all you guys do, which is pretty awesome. So you'll have a lot of tools to talk about there. Matt, how about yourself?
Yeah, so I work in developer relations for Twilio. And I actually been with Twilio for about five years, used to be just an evangelist. Then I was helping to basically serving the evangelism team, leading the evangelism team. And now I run a peer team of the evangelism team, which focuses on helping developers get their code and their stories published on Twilio.com.
So does that make you like a meta evangelist?
Well, I still do. I still do a lot of evangelism, but it's more focused on the online activities of getting developers to basically promoting developers who built really cool things with Twilio.
Yeah. And I guess it's also worth throwing out that other folks may also know some of you from your online stuff. Like Matt, you do full stack Python, which is super popular and well known. That's awesome.
Thanks.
Yeah. And Cecil, you're away from the keyboard podcast is excellent as well. People might know you from there.
Sure. Thank you.
Yeah, sure. So I guess the first thing is, you know, when you go to college or where you teach yourself programming, there's a big gap between I can now write a program and I'm now representing Azure, JetBrains, Twilio in sort of a public speaking semi marketing thing.
But you still, you know, I know all three of your programming work and you're all excellent programmers. So there's this deep technical side, but there's also this capability that many people in the software field don't embrace too much like the public speaking and marketing side.
So the story of how you got there, I think it's really interesting. Maybe we'll go in reverse. Matt, how did you go along that path?
Yeah. So I I've been programming since I was a kid and then I became full time programmer. I became a tech lead. So I was doing really heads down coding for about eight years. And then I wanted to get out of my own bubble. I live in Washington, D.C. and get out of the tech scene here and kind of explore elsewhere.
So I did a road trip around the country for five months to 30 different cities and just like send emails to developers and was like, hey, like, what's it like being a software developer in Memphis? Like, what's it like being a software developer? Obviously, San Francisco, Chicago, all places around the country. And then I met a bunch of folks from Twilio. And after I was done with my project, my road trip, they asked me if I was willing to join the company.
So for me, it was a little bit of getting out of my comfort zone. I still code every single day, but it was sort of stepping out outside of my typical boundaries and then expanding my skill set beyond just programming.
Man, that sounds like such a cool trip.
Yeah, you can actually see the pictures. It's codingacrossamerica.com. I still have the website up.
Really?
I haven't updated it. Yeah, codingacrossamerica.com.
Oh, right on. That's awesome. Paul, how about you? Did you do like a world tour or how do you do it?
No, I sat in my basement.
But the internet, the traffic, the commute to the basement is way, way nicer. That's for sure.
Yeah, so tell us about it.
Sure. I like to joke at Python conferences. I'm not the oldest person you know, but the company that was a Python startup, I was in the Navy in 1994.
And I wanted a boss. I wanted to be on a team. I wanted to work for something I believe.
And then I got really lucky to get a job offer from JetBrains.
And to come back to your lead-in point about what's being asked for, when I was offered the job, my boss, Hadi Hariri, you know really well, Mike.
Yeah, I've known Hadi for a long time. He's a great guy.
Fantastic guy.
Yeah.
He said something, and I wonder if Cecil and Matt had the same experience, but he said, it's important for you to be part of the community and be perceived as part of the community.
And when you do things, you need to do it as you, not us.
And I thought at the time, that's just BS that you say, but you don't actually believe.
But I joined the company, and that's actually the way the job works.
You're expected to be respected as a community person first.
I think that's a great point, and I think it's really interesting that there is this little bit of cult of personality aspect to this job role.
Like many of the folks that I know in this field, they're semi-well-known, if not really well-known, on their own.
And I think the companies see that as an advantage.
Like, we're going to have this person who is really well-known or respected in the community, and their halo will shine off on our company a little bit.
Indeed, and that's kind of a dark side to that because it implies that we as the company don't have enough reputation.
We've got to ride the coattails of this person who will then become a mouthpiece for our message.
And that is thinking backwards along several axes.
Yeah, sure.
Cecil, how did you get to where you are?
You work for a company about 2,500 miles away from where you live, so it's not just down the street either, which I think is a pretty common trait of this role, right?
Yeah, definitely.
Most of my teammates, probably not all of them, or everybody's all remote, right?
So everybody's at some different part of the world, which, as you can imagine, makes meetings a little bit challenging sometimes.
You get really good with figuring out time zones, right?
Yeah, exercising, scheduling, calendars for time zones is an exercise in itself.
That definitely takes a lot of time.
But for me, I want to say, you know, so I've been in the South Florida community probably ever since I left college.
And at some point, I decided that, you know, I kind of wanted to reach out a little bit more and get a little bit more than what I was getting inside of the office.
So, you know, I started to go to user group meetings, and I started to go to these CodeCamp things.
You know, CodeCamps are like these free technology, kind of like conferences, but not really, like smaller conferences.
And, you know, I started to go to these things because, you know, I kind of wanted to just be around the community and learn a little bit more than what I was getting.
And at some point, some person decided, hey, you know, you've got some interesting stuff to talk about.
Why don't you come up and give a presentation?
I was like, nah, nobody wants to hear what I have to talk about.
Like, why in the world would I ever want to do that?
So after some continuous poking, like eventually I, you know, I accepted it.
I started speaking.
And, you know, I just, I got a little bit addicted to it.
Like, I kept doing it more, and I went to more conferences and whatnot.
And, you know, that led to a lot of interesting opportunities.
You know, I became a teacher at Miami Dade College for a little bit.
I talked there for about three years.
But, you know, I've always had that, you know, wanting to go out and, you know, talk to people and kind of listen to their problems
and really just understand what they've been doing.
And honestly, randomly, one day I saw a message on Twitter and it said, hey, we're building this really cool team at Microsoft.
And I was like, eh, whatever.
I'm not doing anything.
I'll just reply to this tweet, right?
Because, of course, people get tired like that all the time.
And I got a reply back in a couple interviews later and some formal conversations later.
Yeah.
That's awesome.
You know, that really mirrors my path.
I mean, I didn't go down the dev relations side of things, but I sort of wanted to branch out from where I was.
I felt like there wasn't enough growth in what I was doing.
You know, I felt like, oh, I kind of know at least as much as everyone in the field and the company that I'm working at.
And how do I how do I get better?
Right.
So I started going to user groups and doing speaking.
And a developmenter actually came to me and said, hey, if you're going to do this for free, we'll pay you to do this if this is the thing you want to do.
So I said, actually, that's a pretty cool idea.
I'll do that.
So, yeah, I think I think it's really interesting how these little steps lead down these paths that you don't necessarily expect.
And it also sounds to me like all three of you sort of had that feeling of I'd like to kind of branch out from from where I am for something bigger.
Right.
And it kind of led those little steps down that path led to these roles.
Right.
Yeah.
You know, when I spoke to my first manager, he always said, you know, I actually asked him, what do I need to do to prepare for this job?
And he looked at me and he's like, you've been preparing for this job like all your career.
Right.
Which is kind of interesting when you think about it.
Right.
Because as a as somebody that's coming out and just starting into the workforce, you never think, oh, OK, this is what I want to do.
It's not like your typical career path, I guess, like if you do computer science or if you decide you want to pick up and learn a programming language or web pages or something.
But so I think it's something that's very like just a part of who you are as a person.
Right.
Like, do you like talking to people?
Do you like, you know, engaging with folks?
Do you like helping people learn and succeed?
Right.
And again, if it's something that you want to do, again, it's just kind of a part of your your DNA as a person.
Right.
Like, it's kind of hard to teach those types of things.
Yes.
It's funny to me because the side that a lot of people see of evangelists or advocates is speaking on stage or reading a blog post.
But what it really comes down to for me and what I feel like the best evangelists do, they really just want to help other people, help other developers.
They retain that sense of curiosity and learning like any programmer, any great programmer.
But they really want to help other programmers become better.
And to me, that's like the crux of the job is just like, hey, how do I help other developers at scale?
That's that's what I get really excited about.
Yeah, I'll add to both of what I think Matt and Cecil got really to the heart of it, that, yeah, you see the rock star thing.
But the prime directive is the human side and the deep empathy for people and the desire to measure your success by making other people better.
That book, Badass, Making Users Awesome, really gets to that point.
And if you're not wired that way as a human being, then you're not going to be good in this role.
Would you say that if you're the type of person who really gets a lot of satisfaction of sitting down next to, say, a junior teammate or somebody and like showing them how to start working with an ORM or do something that they haven't done before?
Does that kind of experience and desire sort of map well to this like more professional version?
Yeah, definitely.
And you have to have the humility to say this person I'm sitting next to or this person I'm having a conversation with via email.
Like they may not know as much in this area.
And, you know, I'm just going to help them work through the problem as best as possible.
And just having the humility to – because we've all been – we've all worked with developers who kind of dismiss your questions.
You can't do that.
You really have to have empathy for other people and have humility for what your own skills and other people's skills are.
Yeah, you've got to still feel the pain of learning it, you know, five or ten years ago yourself or maybe not so long ago.
So I guess one of the things that would be interesting would be sort of talking about what is – what does your job actually look like?
I mean you have to stay on top of all these technologies, you know, especially you, Cecil.
Like I feel like Azure has got like a whole new thing every day or something.
And you're just like, wait, what is this?
The old thing is new or the new thing is now old.
This new new thing is the thing.
So how much of this is like studying, learning, personal research?
How much is travel?
How much is public speaking?
And what else is there to it?
I want to say in our particular organization, it really depends, right?
I like to tell people it's kind of like a choose-your-own-adventure type role, at least the way that we kind of approach it.
So a big part of what we do is, you know, we spend a lot of time with the engineering teams.
You know, when updates are happening, when new products are coming out, when, you know, tutorials and documentation and like when things are being created, right?
So we can tell the good story.
And so a lot of the times, you know, we've been – you'll probably be working with some of these tools or these SDKs before some folks have seen them.
You know, because, you know, part of the role is, again, it's not just traveling or, you know, being on videos and stuff like that.
But, you know, we have to provide constructive feedback.
You know, do people like these things that we're building for you?
And, you know, is this useful?
Are we recovering your use cases?
You know what I mean?
Like, is this a thing that's going to make it easier for you to build, you know, applications and solutions on top of the platform that we're trying to provide for you?
And so, you know, what you find is a lot of our teammates, you know, again, other than just, sure, the traveling and all that other stuff, but we try and align ourselves with products that we just generally care about.
So, you know, like, I spend a lot of time with the Azure Functions team because, you know, I'm really interested in learning about serverless.
Or, you know, the Service Plus team because, you know, I want to learn about messaging and A or QP, right?
Because, again, Azure in itself has like 100 and change products, right?
Maybe even 200 products, right?
And, you know, each one of them has their own sets of buttons to press and knobs to turn and all that stuff.
And no one person is going to know all of it or even half of them.
But, again, like, if you generally care and are passionate about something and you want to see this product succeed or, you know, you want to really understand how this stuff works because your audience that you're focusing on cares about these things, then, you know, you can make the time to sit down and focus on it, read the documentation, create samples about it so you can have like a genuine understanding of, well, this is kind of how this stuff works.
And here are the pain points are.
And here's how we can make this better for our communities.
That's really interesting.
So it sounds to me like almost you're the first user or consumer of the thing the engineering team is creating in some sense because you're trying to learn it as they're creating it and you're giving them feedback like, whoa, guys, this API is wonky.
People aren't going to love it.
Is that accurate?
Yeah, that happens in most cases, right?
Most cases, you know, we get to play around with things or see some feedback or slide decks or whatever the case is.
So we can then, again, make some, you know, make some recommendations or, you know, do some reviews on things.
Because, again, like, you know, we know our community better than everybody else does, right?
Because we're out in the field and we're talking to them and we're interacting with them.
Again, most advocates come from a community, right?
Like that's, you know, that's kind of how it is.
And so, you know, with that context, we can look at these products objectively and say, well, you know, I really don't think .NET developers are going to like this thing.
I really don't think JavaScript folks are going to like that thing.
Because you know how they work.
You know what the tool sets are.
You know, you know, how I like my environment set up.
And so based on that, you can give some useful feedback to the product team so that, you know, they can focus on building and solving the right problems.
Yeah, that makes a lot of sense.
And, of course, there's going to the conferences and sort of organizing that stuff as well, right?
Being at the booth maybe?
Yeah, booth is interesting.
You know, we got a lot of good questions when you're at the booth, right?
Because, you know, a lot of the times when you're after you've given a talk and after you've done a workshop or whatever the case is, you know, not everybody is as, you know, not everybody's going to come up and talk to you, right?
Like they probably do have questions and they do have things that they want to ask.
And so, you know, sometimes it's kind of good to just kind of hang around and linger a little bit.
So whether that's at the booth or sometimes just even on the hallway, right?
Like it's the same kind of thing a little bit.
Just try to make yourself accessible to these people so that they can know, hey, well, you know, he's not so busy now.
Like maybe I could go and talk to him and ask him a question because, you know, you might not always be like available to do that.
Yeah, sure.
Paul, what's it look like from the JetBrains side in terms of the stuff that you do?
What's your balance there?
Cecil said so many good things.
I'll kind of zero in on the last part about the booth.
And traditionally, back when I was a kid with Moses and all those people at the booth, it would be salespeople or engineers.
Neither of which are the ideal target for someone in the community to come up and engage with.
Yeah.
So you need a hybrid.
And I think that's us.
And the word developer advocate, the phrase developer advocate is the advocate for the developers.
And that's another part that Cecil said that I thought was pretty good, which was the choose your own adventure.
And the things that he feels passionate about and the serverless and the function stuff.
When he digs in on it and he has the developer experience, he can be the missing chair at the table internally as the voice of the community, as the consumer of this stuff.
And instead of being a case where the company just transmits a message to the recipients, the developer advocate is a way for the recipients to transmit a message back to the company.
I see.
So you're like a web socket.
Yeah.
In fact, I think that's a really important role.
What I was actually thinking was more like an elected representative, right?
Like you're sort of almost.
Or an ombud for the newspaper.
Yes.
Yeah.
Sort of.
You're almost a representative for the community back to the company as much as you are for the company to the people.
Indeed.
Yeah.
And so in order to be a trusted outlet for the community, you got to be in the community.
Yeah.
And like Cecil said, you got to be seen as participating and having the mojo on the thing that you're speaking for.
Yeah.
The developer community is pretty good at finding out people who are clearly imposters.
And I'm not talking imposter syndrome.
I don't feel like I'm good enough to do that.
I mean, people who are like actually not skilled or not interested, right?
That comes out pretty quick.
Yeah.
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.
So in terms of speaking, working with engineering teams, travel, conferences, all that, what's your breakdown look like?
One-third serving the product team, one-third conferences, one-third advocate.
Right on.
And then the advocate is...
Sorry, go ahead.
I spent a lot of time maintaining the Twitter and Facebook for PyCharm.
And that's an interesting point, kind of getting back to what we were talking about, Matt was also talking about earlier, about the motivators.
That is quite a spotlight.
The Twitter account for PyCharm.
Yeah.
And if somebody does something cool out there, and boy, Michael, you are great at this.
Thank you.
At giving love to other people.
And showing respect to them.
And then you probably have them on cloud nine for the whole week.
Wow.
Talk Python noticed me.
It's an important part.
There's people doing amazing stuff.
And if you notice it and you respect it, that creates a real bond.
And sure, from a Machiavellian perspective, the company is giving them love so that they become an advocate for the product, blah, blah, blah.
But just from a human perspective, it feels a lot better to show respect to people.
Yeah, absolutely.
Matt, what's your world look like?
Yeah, so I think there's two large areas that seem very nebulous to developers when we talk about developer relations.
The first is kind of the tactical day in and day out.
How much do you travel?
How much time do you have for coding?
I actually have a landing page.
It's at devangel.io.
And that is a roll-up of different blog posts that developer evangelists, developer advocates have written about.
Like, here's what my day looks like.
Here's what my responsibilities look like.
So I have a whole...
That is awesome.
Yeah, there's a bunch of posts that are out there.
So you can get kind of a wide range of like here.
And I even have some of my own posts.
Like, here's how I spend my day as a developer evangelist.
So that's kind of like one sort of nebulous reason, nebulous area.
It's like, what tactically does the role look like?
And then there's the second area, which is like, what's the difference between a developer evangelist, developer advocate, developer relations?
There's all these titles floating around.
And to be fair, part of it is actually confusion.
In a lot of cases, the titles aren't necessarily put out there with a lot of thought behind them by some companies.
But the way that we view it at Twilio is developer evangelists are called evangelists because they go to where developers are.
So, for example, like we go to PyCon, the PyCons around the world, because that's where Python developers are.
And we are showing them how to build Twilio, helping them use Twilio.
A developer advocate sort of has a different function, which I think the other guys have talked about, which is they're bringing feedback into the company.
So the evangelists are bringing some feedback in, but I would say it's like 10 to 20 percent of their job.
Whereas when you're a developer advocate, it's like actually tends to be like 50 percent or more.
You're bringing feedback in from developers in the community and saying to the product teams like, hey, I think we actually need to change like, you know, the way that this API is structured or something like that.
And so I think those are kind of like the two large areas that people often have questions.
And so at least at Twilio, when I joined five years ago, we only had developer evangelists.
And then from there, we branched out into a developer education team, which works on the docs and what's called Twilio Quest, our training platform, 8-bit adventure training platform.
We have a developer community team, which sets up events just for Twilio developers.
And then a team called Developer Voices, which helps to shine the spotlight, as you were just talking about, the big power of shining the spotlight on developers who built something really cool.
Because so many developers were coming to us and saying, I built this awesome thing with Twilio.
Like, how do I show it to more people?
And we're like, actually, maybe this is something that we should do more often.
That's a really great distinction.
I hadn't really thought about the different titles, but you really explained it well.
So I guess one of the things that people who maybe are considering a role like this, because it sounds more fun than closing Jare tickets in a cube farm, for example, we can talk about some of the drawbacks as well, but is maybe how much travel is involved.
So just I go around really quick.
Like, if on any given month, how many days of a month would you say you're gone, Cecil?
On a busy month, I'd probably say eight days.
So eight days being like, I'd probably travel two, I'll do like two trips for that month.
Yeah, that's not too bad.
Paul?
I'd say the average on our team matches what Cecil said.
I have a different situation with an elderly father who lives with us, and so I'm not going to be traveling as much as other people do.
But I'd say that if you're going beyond eight, you're on your way to burnout, and you're also not serving the longer term goal.
Right.
I think it's also there's a difference between eight one-day trips and two or one four eight-day trips, right?
Like, the airtime and the being in the travel action versus being in a different location are also – there's more wear and tear on the eight one-day trips.
Matt?
So in my current role on my team, I run a remote team.
We generally only travel roughly once a month for internal meetings.
But as the evangelist team does travel significantly, but it's all seasonal.
I mean, you know, when there's a lot of conferences going on, that's when you tend to be on the road a lot.
And then, you know, holidays during the summer, people tend to be able to hang out and write some code and not get on an airplane.
So it really, I think, depends on your ecosystem, which programming language you're working in, and kind of what your yearly schedule looks like.
You really are at the mercy, to some extent, of the community as opposed to always setting your own schedule ahead of time.
Yeah, like for Cecil, it would be really hard for you to say, I'm going to skip build this year.
Yeah, I definitely couldn't do that.
So I'd say any of the first-party events, like we generally have like a strong force of people there.
But then, you know, anything that's third-party, that is kind of up in the air, right?
Like, is this an important conference to go to?
And when I say important, it's, should we have a good presence there?
Like, you know, are we going to go and, you know, do we have good big announcements to make?
Or, you know, is there a community there that we're not really serving that we should really pay attention to?
You know, like some of those types of things we look at and, you know, we determine, hey, well, we really need to send some manpower here.
Or, you know, hey, well, you know, these folks have a lot of .NET developers ready.
Maybe we don't need to, like, do that as much, right?
Like, maybe we should spend that time looking at more underrepresented communities and underrepresented focus areas, you know?
Yeah, absolutely.
That makes a lot of sense.
I guess one thing that would be interesting to consider is which companies are out there that are doing a good job now.
Like, what companies would you hold up as being, doing this advocacy or evangelist role well?
I mean, I certainly think Microsoft, JetBrains, and Twilio are all in these categories with each of the three of you.
But what else?
Seems like Google's doing pretty well.
Seems like there's a lot of folks there.
Google does do really well.
And actually, Hugh, I was on their YouTube channel just yesterday, actually.
You know, if they can't look at their YouTube channel, they have a lot of interesting shows that a lot of their evangelists do.
And just talking about product updates and what's coming out.
And Flutter is a big thing.
They've been talking about that.
Google App Engine, things like that.
So I definitely pay attention to what they're doing there in that space.
Yeah, they have kind of a cool interview video channel.
It's almost like a TV channel that you can stream or is also on YouTube.
Like, I saw Kelsey Hightower interviewed there, and he did a great job.
You know, that made me realize, Cecil, that I totally overlooked all of your Channel 9 work.
And Channel 9 is actually one of these interesting creations that came out of the whole dev evangelist advocate side of things.
You maybe want to just talk a little bit about that and maybe what you're up to there?
Sure, I can talk about that for a little bit.
So Channel 9, and that's channel9.msdn.com, is Microsoft's developer portal for video content.
So, you know, it dates back, I don't know, maybe at least 10, 15 years.
I don't know.
Like, it's way longer than I've been at the company.
But essentially what we have is a collection of, you know, curated shows around, like, various different topics.
We have stuff, again, that's on .NET, stuff that's on Azure.
You know, we have an open source show that's really popular now.
So we talk a lot about, you know, things like Kubernetes and Kafka and, you know, some of those types of technology.
It's almost like CNN for developers, right?
You've got sort of those panels and you're talking, there's a screen.
It's pretty produced, pretty well produced.
It's pretty well produced.
And, you know, one of the things that we used to do a lot that I think we're going to try and get back into is doing some more of that, like, personal touch videos.
We used to do a lot of videos where we actually just walked into people's offices or we'd walk the hallways of the company and just pop in and be like, hey, what are you doing, right?
And then it ends up into, like, a whiteboard discussion.
Obviously, we'll tell you that we're coming, right?
But, you know, it ends up into a whiteboard discussion of, hey, well, this is the beta of this or the alpha of that or here's some of the things that we're thinking about.
So we don't do that as much as we used to.
And I think that would be a good element to add back into the list of shows that we have today.
Because people like to see that stuff, right?
Like, people want to see, like, the human side of what's actually happening, right?
Like, let's walk into the team room and let's, you know, let's do the whiteboarding session and let's just kind of talk to the people that actually build a product versus the dude that's on stage or the person that's, you know, at the booth.
Right.
Peel back the marketing veneer and just talk straight to the people building it.
Right.
Exactly.
Paul, Matt, what are you guys doing around that kind of stuff?
Like, are you doing video stuff or things on YouTube or any of those areas?
Yeah.
So Twilio does have a YouTube channel.
My colleague Brent Schooley is doing some great work there.
He's also, he's been live streaming on Twitch, some live coding, things like that.
And the main thing that we do is the team that I run, which is Developer Voices, which is if a developer says to me, hey, like, I built this awesome thing with Twilio.
So one of my favorite examples is, like, someone was tweeting about, they took one of the little Amazon buttons, the Amazon dash buttons.
The dash, yeah.
Yeah, they built a poop button with it because they're, the developer's two sons slept in the same room and he was potty training one of them.
And he said to his son, like, hey, if you have to use the bathroom in the middle of the night, like, just push this button.
And it sent him a text message so that he would know, like, okay, let's not wake up the other kid.
Let's go use the bathroom.
And so he was, like, tweeting about this thing.
And we had him not only show, like, not only show, like, here's what it is, but actually teach other developers how to build that.
Like, that's actually the most exciting thing to me is, like, yes, there's the human element, but it's also, like, how do we show developers how to build what you built?
Like, recreate this awesome thing that you built.
And so that's, like, the main way that we kind of highlight what developers are doing with Twilio.
That's, man, that could be its own show.
That's pretty awesome.
Paul?
Video channel?
Certainly.
Certainly there should be a patent pending on that idea.
It's going to be on Shark Tank any day now, man.
Check your email.
A lot of good ideas that make me feel guilty about things I should be doing listening to Cecil and Matt.
When are you going to take your little camera and just, like, walk into Hadi's office or Dimitri's office and just go tell us about this, man?
What are you doing?
What are you building?
No kidding.
Actually, I will use you, Michael, as an exemplar.
We historically had done webinars, you know, what's new?
And blah, blah, blah.
And it was the advocate doing the webinar.
And I decided it would be better to get outsiders to come in and do the webinars and talk to them.
And the webinar with you prompted a change in the way we were thinking about doing webinars.
Oh, wow.
Yeah, we made it more conversational, split it into segments, took questions at the end of each segment.
I had you and I rehearse some banter beforehand to make it sound well-produced.
And the numbers went up.
The survey numbers went up afterwards.
I needed to take that lesson and the lessons from Matt and Cecil and do more of those kinds of outward-focused things in 2019.
It's a little bit of that important versus urgent stuff, right?
Like, I don't know about how you all feel, but I'm just like, feel beaten down every day by like little things that are not that important, but they kind of got to get dealt with.
And all these great ideas, it's like, you know, maybe one of them will come to reality, right?
It's crazy.
That's just life though.
What are you going to do?
So I guess if folks out there are listening and they're like, man, this sounds really fun.
I would love to do this.
Be on the cutting edge.
A lot of this technology, work with engineering teams, go to the conferences.
What couple of steps do you think someone could take or skills that they need to have so they could go acquire them that would get them on this path?
Cecil?
So like we were talking about earlier, I think in general, first you just have to care, right?
Like, what are the things that you care about?
What are the things that you want to work on?
You know, it's the same thing I tell my students or anybody I mentor.
Like, you just generally just have to care first.
And then, you know, once you get on the path, just reach out to your local user groups and, you know, see what's happening.
See what's happening there.
You know, reach out to schools, high schools, middle schools.
You know, maybe you can do like an hour of code thing, right?
Like, just kind of get used to getting out and speaking with people and helping people.
You know, I'm really just trying to understand, like, well, what's your experience like?
And what are the things that you're having problems with?
And how we can or how, you know, you as a person can help them be better and, you know, achieve their goals?
Because, again, like you just get into the habit of doing that, right?
And, you know, once you hit those checkboxes, then you're well on your way to, you know, being able to, you know, approach something like an evangelist or advocacy position.
I think the getting out there and doing some form of public speaking or teaching or training, like those sorts of things that you're touching on are just so super important.
I honestly think if people were to come and ask me, you know, what is one thing that I could learn this month or this year or whatever that I don't already know necessarily I'm not good at or even maybe I'm scared of that would change my career or really improve it?
I would say public speaking if I'm speaking to developers, right?
Like this ability to get out there and present either in a training context or a conference context or however else.
So few people work on that so that if you can do it, I think it would really put you above a lot of folks or at least in a way.
You know, it's funny.
We were talking about that the other day.
And so today my team has like a fair amount of folks like geolocated.
And one of the things that we kind of speak about is, you know, like your mileage may vary, right?
Like some folks are better speakers than others and some are better teachers than others.
And, you know, some are better on camera and some are better doing podcasts, right?
Or maybe some people are really good at making really compelling demos and they work really great with the engineering team that they create lots of great samples.
Right. Or blog posts writing or something.
Or blog posts or maybe publish on your own blog or maybe you publish on some other publication online.
But the thing is, like, you got to kind of figure out, like, what's going to be your way to contribute, right?
Like, and focus on that.
And I'm just saying that because, like, if you don't feel like you're comfortable public speaking, it's not to say that you, if I'm not a good public speaker, I can't be an advocate and I can't help people.
You still can.
And it's helpful if you can do some public speaking, right?
But if not, then there's tons of other ways that you can contribute to the community and help people succeed.
Yeah, for sure.
Paul, what do you think?
A couple of things people could learn to go this direction.
To follow up with the last thing that Cecil said, if you think that becoming an advocate evangelist, DevRel, is rock star public speaking, you're in the wrong line of work.
It is the wrong motivation.
I'll come back to, I live south of D.C., so Matt can attest to this.
I believe it's recently the worst commute traffic in the country, past L.A.
Yay for us.
Almost number one.
You guys just work a little harder.
You'll get there.
And so I've got a lot of friends that get in the grind and drive and drive.
And, you know, you're not getting paid extra for that hour and a half each way.
And they see my life like, oh, my God, I could work from home.
And then I kind of mentally play this scenario in my head.
OK, so you live the high life.
You quit your job.
You work for yourself.
And the first month you're sitting in your pajamas staring at the wall, which is not a pretty picture.
Because you're not a self-directed person.
And I came to this from being an independent consultant.
So it's a decade basically managing myself.
That's a hard bit to flip, especially if you're like on Cecil's team and it's geographically dispersed.
Maybe we'll talk later about there are no good metrics for DevRel.
It's any claims that you can measure success and justify budget are propositional at best.
And therefore, how do you know if you're getting your job done?
Well, you got to be a self-directed person who doesn't wait for things to come to you.
You go to them.
Yeah, you have to be pretty independent in this job, don't you?
I do think working from home is pretty amazing and not having a commute.
I mean, I do have to cross a little sidewalk, but the traffic's not bad.
Sometimes a squirrel is there.
Sometimes, but it runs away.
So that's pretty beautiful.
But there is a lot of self-directed aspect where some days I'm up at six in the morning and I'm working and there's no boss.
There's nobody that said, Michael, you got to be at work at six today.
You got the things just like, you know, I'm just I'm falling behind on stuff.
So I'm up at six this week.
That's just the way it's going to be.
Right.
And I think that works really well for people who can leverage it like you because you can take that hour of commute that you would have had and put that into something productive or a hobby where you're more refreshed, whatever.
But if you don't, it can be tough.
And I remember when I first started working from home, I had stuff to figure out to make that work.
Right.
So my wife would be like, hey, you're home.
Can you take care of this?
Like, we need to do the laundry.
We got to vacuum this floor.
And she works, too.
Right.
To be clear.
But she's like, could you also just vacuum this?
I'm like, I'm at work, actually.
I know I'm not gone, but I have got to be working.
It's just really hard to have that separation in time without space.
Right.
So I don't know, I guess maybe I could come back to what you all do to work well from home.
But Matt, I want to let you weigh in on the two ideas or two points.
Yeah, for sure.
Well, the very first step, if someone wants to be a developer and developer relations, is to be really deep in your tech stack.
I sometimes field questions from folks and they say, hey, I've been programming for a while.
I want to get out of programming.
Can I go into evangelism?
And I say, actually, that's the opposite thing you want to do.
Because when you're a heads down developer like I was for a long time, you have time to focus on really hard problems.
And when you're an evangelist or an advocate, typically you have a lot more demands on your time that cause you to kind of have two hours here, maybe three hours there.
Or you're in an airport trying to debug some code.
So you really have to be deep in your tech stack and just love coding because there's so many other distractions that are there for you when you're traveling or you're writing blog posts, things like that.
I think that Cecil is spot on in that people have different strengths and you should play to your strengths.
So if you're really deep in your tech stack and you really love writing, just do that and focus on that and become a better writer every day.
If you like the public speaking side, that's awesome.
I mean, that tends to be the most visible because when people go to conferences, they're like, oh, this person is a really great public speaker.
Not everyone has to fall into that boat.
But I just think that, you know, you kind of have to figure out, like, what am I really good at?
You dabble in a bunch of things and say, what are my strengths?
And then it's the combination of being deep in your tech stack and with something else that helps other developers learn, which is really where the power comes in.
And I actually completely disagree with Paul.
I think there actually are significant metrics for measuring ROI to companies.
And you can tie your own performance to those metrics and be confident that the work that you are doing, regardless of whether it's public speaking or blogging or open source work, is actually really, really valuable to your company.
Nice.
We're coming back to that then.
So one thing I do want to throw out there, though, one of the shifts that I had when I switched into from being a regular developer to doing training, and I think would be quite similar to developer evangelist, is when you're a regular developer, if you find one way to solve a problem,
you're good.
You solve your problem.
You check in the code.
You go on to the next thing.
But if you are representing a tech stack or a product or you're teaching somebody about one of those, like in the course of training, you need to know, oh, there's actually four ways to do this.
These are the tradeoffs between them.
This is the situation when you use this one versus that one.
And that's just like a different level of digging into learning a technology and a curiosity about it.
It's not enough to, like, make it work one way.
You have to understand sort of the tradeoffs in a little bit deeper.
What do you guys think?
Well, I do think you have to be comfortable with explaining something to other developers.
And that's actually where the big leap was for me.
It's exactly what you're talking about.
I can get something to work and then no one asks any further questions.
It kind of passes code review.
Okay, it works.
There's a unit test for it.
Yeah.
Let's move on.
User can log in.
We're good.
Let's roll.
But I mean, it's a little bit scary to me when I write a blog post on how to create SSH keys on Ubuntu.
And I don't have a flag that needs to be on there for certain versions of Ubuntu, which causes a security vulnerability.
And then, you know, my post is popping up and a lot of people basically have security vulnerabilities in their SSH keys because it's something that I wrote.
Like Matt told me to do it this way.
Well, Matt was wrong this time.
Yeah, no, it was wrong.
And I went back and I fixed it.
But I mean, it was out there for a long time.
So I think that's kind of the leap.
You have to ask yourself, like, do I feel comfortable with what I'm putting out here?
Because, you know, there's a lot more people who are reading that.
They're following that.
And just like we copy and paste off Stack Overflow, you don't, as a developer, you're just trying to get something done.
You don't always do the work yourself.
You just say, okay, this is a solution to a problem.
I put this in regardless of whether there's an issue with it or not.
So I think that's a big leap when you're in one of these roles.
Yeah, kind of like what Matt was saying.
Like, you have to know where the bodies are buried, right?
Like, you got to know the things that work and the things that don't work, right?
Because sometimes it's not just about talking about the happy path, right?
You got to talk about, you know, what are the right scenarios for whatever it is that you're talking about?
You know what I mean?
Being able to give people accurate, useful, practical advice on that, right?
I think that's when, you know, you see the differences between, and I'm not throwing shade at marketing people, but like that's where you see the differences
between somebody that's kind of going through a script and somebody that's like, you know, I understand this product that I'm talking to you about it.
Yeah.
Right.
So like, you know, if you're presenting a particular position, you got to be able to defend that position, right?
Like, kind of like what you're saying, like, hey, if I'm telling you this is how I create SSH keys, like he has to defend that position, right?
And this is why I do it this particular way or whatever the case is.
Or if you say this is how you should use this function and here's why you pass this parameter.
Someone says, well, I'm not really sure.
I think it should be this way.
It's like, well, let's just disassemble it or pull up the source code and let's look and I'll show you the line where the thing is that, you know, doing this matters, right?
Things like that.
This portion of Talk Python to Me is brought to you by Rollbar.
Got a question for you.
Have you been outsourcing your bug discovery to your users?
Have you been making them send you bug reports?
You know, there's two problems with that.
You can't discover all the bugs this way.
And some users don't bother reporting bugs at all.
They just leave, sometimes forever.
The best software teams practice proactive error monitoring.
They detect all the errors in their production apps and services in real time and debug important errors in minutes or hours, sometimes before users even notice.
Teams from companies like Twilio, Instacart, and CircleCI use Rollbar to do this.
With Rollbar, you get a real-time feed of all the errors so you know exactly what's broken in production.
And Rollbar automatically collects all the relevant data and metadata you need to debug the errors so you don't have to sift through logs.
If you aren't using Rollbar yet, they have a special offer for you, and it's really awesome.
Sign up and install Rollbar at talkpython.fm/Rollbar, and Rollbar will send you a $100 gift card to use at the Open Collective,
where you can donate to any of the 900-plus projects listed under the Open Source Collective or to the Women Who Code organization.
Get notified of errors in real time and make a difference in Open Source.
Visit talkpython.fm/Rollbar today.
Let's go back to this idea of metrics and what defines success.
Matt, I think you're in a really good position because you work with other evangelists and almost in an overseen somewhat angle, so maybe you want to kick it off.
Yeah, so Twilio...
What are the metrics?
Yeah, like how do you measure this?
Like what looks like success for Twilio, and how do you know if you're doing it?
Yeah, so it's very important to tie the developer relations program to the company strategy and the overall metrics that a business has.
And so Twilio's mission is to help developers build the future of communications.
And we want every developer in the world to have Twilio in their tool belt so that if they need to add two-factor authentication to an application,
or they want to build a custom call center for their company, that they say, oh, I can do that with Twilio.
And so for us, like a lot of the ROI calculated, return on investment calculations are around how many developers are actually using Twilio.
Like we have usage metrics, and we can very clearly tie like which blog posts are actually driving the most usage of various products.
You know, I think that's an interesting point because you, in particular with Full Stack Python, are really good at looking at analytics and sort of fine-tuning the web pages and the web stories to really resonate best,
and then even changing them a little bit.
So it can be done, right?
It absolutely can be done.
And, you know, I said I kind of disagree with Paul.
I also want to agree with him in a way that you have to do what's best for developers.
If you let the metrics drive you completely, you're going to do it wrong.
Like you have to be a developer.
You have to be a part of your community and know what's right and what's wrong.
And then you kind of have like these internal metrics that show that what you're doing is valuable.
So there's almost a little bit of two sides to it.
You have I'm a developer.
I know what's right for my community, and you really want that to happen.
That's your ideal.
That's what you drive towards.
But then you also have the metrics that allow you to justify the expansion of the continued existence and the expansion of a developer relations program.
So you can continue to help more and more developers over time.
Yeah.
Paul?
Yeah, I'll jump in on that.
That sounds great.
I can promise you I'll be following up with you about that.
In particular, on the macro side, the team as a whole's impact on the company.
I was talking more in the context of a fairly self-directed job activity.
Should I do this or that task?
And it's pretty hard to get the granularity at the micro level versus the macro level of this blog post led to that impact.
And maybe your context allows you to because of both ends of the equation on that.
Or even giving a conference talk.
We debate this endlessly about how to concoct measurements, how many people show up, what were the follow-ups afterwards.
So certain activities, if metrics are introduced, create perverse incentives that poison the mission of developer relations.
That's the worry that I have.
Yeah.
I think a lot, too, comes down to the company's strategy and business model.
I actually would never be a developer evangelist or work in developer relations for a company that has a free API.
Because if it's not worth paying for, then it could immediately be disbanded.
Like Netflix had an API.
Gone.
So to me, to be able to tie the company making money off of an API so that it continues to justify investment is actually what drives a successful relations program.
Now, it's harder to do that when you're talking about a subscription model or a one-time purchase model.
So I think a lot comes down to the company's strategy and business model.
Dude, make a PyCon talk this year on this topic.
I'm sure a lot of companies would be interested.
Cecil, how do you guys measure success?
How do you know if you're doing better?
So this is a problem that we've had that we're continuously trying to iterate over and figure out.
So just for context, my team is maybe about a year and a half old.
We started, I want to say, April or so, 2017.
So one of the things that we do is, so we have like this internal dashboard.
But essentially, all we're really doing is just tracking to see, like we're doing click tracking for the most part.
And that's one of the strategies that we use.
Because it's kind of hard to say, hey, if I went to this conference and I gave this talk or you watched my video.
You know, there's a person that watched the video, going to come and download Visual Studio, and you're going to sign up for an Azure account or whatever the case is.
Right.
So we do a little bit of click tracking to kind of flow people around and kind of follow them.
But even with that, too, like those, that method is a little subjective, I suppose.
Like how accurate is that exactly at the end of the day?
And like, you know, like who's to say, you know, hey, this person didn't just like pass this thing around throughout all of this company and like take out my tracking link.
Right.
So like maybe there's more people that are coming in and they're just not clicking my link.
But maybe I gave it to like you and you shared it around your company.
Like I can't really track those people.
And so I kind of look at it as a way to judge like relative change.
I think that's a good way for us to look at those things versus like absolute numbers.
Because if you look at it relatively, then you could say, OK, well, you know, maybe the strategy that we're taking is a good idea or a bad idea.
Or, you know, maybe I don't know, like we change the background of the video.
Like people don't really like to like we should change the background because our viewers just dropped off or something like that.
But yeah, again, for us, it's just something that we're constantly trying to tweak and iterate over and just, you know, try different strategies to see what happens.
Yeah.
I think one thing that's important is that, you know, kind of like what Matt was alluding to a little bit, like we don't like our jobs aren't tight.
And to metrics.
So it's not like there's no competition here, right?
There's no competition.
There's no like, you know, in team fighting.
Oh, I got to get more views than you do.
You know, because again, like when you do that, like now your focus is different, right?
Like you're looking at the wrong thing versus, you know, hey, I'm trying to be at the top of the leaderboard versus I just want to put out good content that people care about.
Yeah, that makes a lot of sense.
And you have so many different areas to measure like channel nine versus conferences versus other social.
There's it's hard to know the relative value.
I'm sure.
Yeah.
All right.
Well, I think we're getting a little short on time.
So I want to close this whole conversation out with I know you all go to a lot of conferences.
You do a lot of presentations.
You do a lot of travel.
Maybe you all could just tell like one story of either like a conference that went conference presentation or a travel experience that went crazy or something like that.
Like I'll give you the really, really short version for me to give you an example.
Like I was traveling to do some training in Salt Lake City and I decided I got there a little early, decided to go skiing, went up on a Sunday morning, put a snowbird.
There was an avalanche to close the road and I could almost not get back down from the thing for my event on Monday morning.
It was like narrowly escaped.
It was crazy.
So maybe if you have any funny or weird stuff like that, I know, Cecil, you have a way to get stuck on airplanes.
Yeah, I have some interesting stories on airplanes.
I think one story I want to tell because I think it has an interesting kind of follow up to it.
So I went to a conference recently and I'm all ready to go, signed up, CFP, submitted and accepted or whatever the case is.
And then maybe two days before I'm supposed to speak, like the conference organizer sent out this email and they're like, well, there's not going to be any Wi-Fi and you can't use your own machine and like can't do this, can't do this, can't do this.
I'm like, you're telling me this like two days before I'm supposed to go speak to these people.
Like what exactly are you expecting me to do, right?
So again, like for somebody that's trying to show a demo of, I don't know, let's say I'm trying to show a demo of Azure or whatever it is if there's no connectivity.
It makes a demo a little bit hard to do.
It looks a little bit challenging.
So I guess I walked into the room and I was like, hey, well, usually I would have been showing you a demo, but let's just pretend like I ended up telling like a lot of stories, which is interesting.
So like now my talk that was supposed to be like 40 minutes with demo turned into, it turned into a lot of interesting conversation with the audience, which I think worked out pretty well.
So instead of me talking actually, like I was talking with you, we're sharing stories back and forth.
So, you know, I think the folks that were in the room still got some value out of it because now they, you know, they got to share their experiences and whatnot, which I think is really cool.
But again, for me, like if anybody that's listening is a conference organizer, please tell your speakers accurate information early and not two days before.
That's crazy.
It's really cool that it turned out all right, though.
That's great.
How about the other guys?
I think the funny thing about the horror stories is after you've been doing this for a while, they kind of fade into the background.
And what kind of stays with you are the times when you meet a developer, like at PyCon this year, I met developer Sam who I'd been working with.
He'd been making a bunch of pull requests on full stack Python.
And then he wrote a blog post for Twilio.
And so just to be able to work with them online, you get to meet somebody in person and just kind of swap some stories and then work on them with some other work with that person on some other things.
That's just kind of the highlight to me is just the connections that you make that transcend the online part and then you meet offline and stuff like that.
That's probably the best thing for me.
Yeah, that's cool.
Paul?
I'd say this one's definitely in my wheelhouse because the only value I have to the Python community is funny stories.
So like 2000-ish, back in the days of Zope, I was at a free software conference, the big free software conference in Brazil.
And I went over somewhere else to do a sprint one day and we got a phone call.
Paul, get back here.
The governor of whatever state in Brazil.
The governor wants a demo.
No, with a film crew in the press and he wants to sign a proclamation.
Oh my gosh.
And you need to come and on behalf of open source, do a meet and greet and sign the proclamation.
Did you sign it?
That's the funny part.
Or funny.
So I'm rushing back over there with my dear friend, Python hero, Luciano Romala.
And we're talking the whole way.
And I'm like, Luciano, we've got an issue.
I don't speak Portuguese.
And I'm going to walk up and right into this situation with no prep.
And so we worked it out where I would go over and stand beside the governor and do kind of the handshake and all that kind of stuff.
And he would go over and read the damn thing and kind of give me a thumbs up if it was safe to sign.
So we go do it.
And he does all of his BS.
And I do my BS.
And we turn around to go sign it.
I can't find him anywhere.
And I'm staring.
It's a one page thing.
I'm like, what do I do?
So I signed my business partner's name on it.
Oh, there you go.
It's like you could sign your dog's name or something.
Yes.
Your pet's name.
On behalf of open source, Rob Page.
That's right.
Fido or green.
But if there is.
None of my stories ever have any value.
But if there is a value in this job, you'll be put into situations that you have to extract yourself.
Absolutely.
That's awesome.
Yeah.
This reminds me of a book called Confessions of a Public Speaker, which is really hilarious.
I don't know if you've read it, but it's got a lot of great stories like this.
All right, guys.
We're about out of time.
So I guess we'll wrap it up.
Normally I ask two questions at the end of every one.
I'll just do one this time since there's three of you.
What editor do you use to write some Python or whatever other code?
Matt, it could go any way for you.
I'm pretty sure I could guess what the other guys are going to say giving their affiliation.
But I'll let them speak for themselves.
Oh, it's the same.
Vim and Tmux.
Right on.
Paul?
I was doing PyCharm before I was PyCharm.
Right on.
Sezzle?
Honestly, I've spent a lot of time inside of Visual Studio Code lately.
I would say those two are definitely the big up-and-comers, PyCharm and Visual Studio Code.
So pretty cool.
All right, guys.
It's been so much fun to talk about all this and all the stories.
And I really think this is a rewarding career path for a lot of folks if they're looking for
a change.
Also really valuable for companies that maybe they should consider reaching out to folks like
you, making positions like that.
So thanks for coming on and sharing everything.
Thanks, Michael.
Sure.
It's been a pleasure.
Now, I've already said goodbye to the guests, and it was so great to have them on the show.
But after we stopped recording, we had a quick conversation about PyCon and hanging out at
booths and stuff.
And what we decided is, if at all possible, the three or four of us are going to put on an
open space at this year's PyCon in Cleveland.
If you really got into this topic and you'd like to meet the guys, talk more about it,
that kind of stuff, be on the lookout for an announcement around the open space for the
developer evangelists at PyCon.
You are going to PyCon, right?
You must go to PyCon.
Definitely get your ticket.
There's still some available at the time of this release.
Hope to see you there.
And I hope to see you at this open space as well.
Thanks for listening.
This has been another episode of Talk Python to Me.
Our guests in this episode were Cecil Phillip, Matt McKay, and Paul Everett.
And it's been brought to you by Linode and Rollbar.
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.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have
gone unnoticed until users complain, of course.
Track a ridiculous number of errors for free as Talk Python to Me listeners at talkpython.fm
slash rollbar.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into
all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Take care.