Observy McObservface Episode 13: Donkeys and Coffee Cats–Driving Community and Open Source with Kat Cosgrove

In this episode, Kat Cosgrove, developer advocate at JFrog, talks about working on firmware updates for self-driving cars called Donkey Cars, the importance of on-point documentation, and getting the community, especially newbies, involved in open-source projects, programming, and speaking. There are no stupid questions, and stop calling your things “easy”!

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @ObservyMcObserv.

Jonan Scheffler: Hello and welcome back to Observy McObservface, the observability podcast we let the internet name and got exactly what we deserve. My name is Jonan. I’m on the developer relations team here at New Relic, and I will be back every week with a new guest and the latest in observability news and trends. If you have an idea for a topic you’d like to hear me cover on this show, or perhaps a guest you would like to hear from, maybe you would like to appear as a guest yourself, please reach out. My email address is (jonan@newrelic.com). You can also find me on Twitter as the Jonan show. We are here to give the people what they want. This is the people’s observability podcast. Thank you so much for joining us. Enjoy the show.

I am joined today by my guest, Kat Cosgrove. How are you today, Kat?

Kat Cosgrove: Excellent. How are you?

Jonan: I'm hanging in there. I think that this week I've been feeling a little bit better, a little bit, maybe by the smallest of degrees about the state of the world. So yeah, I'm having a good week. I'm hanging in there.

Kat: Yeah, it's getting a little bit less hectic.

Jonan: It is. It is. Just generally, life is getting less hectic. I think people are wrapping up a lot of things for the end of the year, heading into the holidays. It'll be an interesting holiday given the pandemic and everything, but I'm ready to watch that day tick up. I'm ready to see a 2021 and just hopefully see some changes.

Kat: Or at least feel like there's a change even if it doesn't actually change anything. Good Lord, dude.

Jonan: Yeah. It has been a beating. So, my listeners, who maybe are unfamiliar with you and your work would, I'm sure, love to hear some background. Tell us about yourself.

Kat: Sure. So I am a developer advocate at JFrog. You've probably seen me on Twitter, where recently I have actually mostly been screaming about politics instead of tech, so I apologize for that. And if you've stuck with me through the screaming about politics, thanks for that. I live in Seattle. I have a munchkin cat sitting in my lap right now. She's very sweet.

Jonan: What is the cat's name?

Kat: Her name is Espresso. She's 16, and her legs are only about two inches long. She's very whiny and very needy, so she shows up in my talks a lot when I speak virtually now since I'm not going to real conferences. So it's not unusual when I'm speaking to hear her crying in the background or to see her climbing up onto my chest while I'm trying to talk. She really wants attention.

Jonan: And she's always willing to step in and contribute. And I appreciate that in a cat: helping out with the presentation.

Kat: Yeah. She's actually the one writing most of my tweets. That's not actually me. She's my ghostwriter.

Jonan: [Laughs]

Kat: She's much funnier than I am. So we've got a good symbiotic relationship going on, me and the cat. But before I was a developer advocate, I worked on the IoT team at JFrog as an engineer. And I was part of the team that built a proof of concept taking software updates on cars from something that requires physical access to the computer and takes 8 hours or so to something that happens over the air and takes anywhere between 35 seconds and 5 minutes, depending on whether it's an application update or a firmware update and can happen while the car is actively being driven.

Jonan: This sounds totally safe. Do you know what I wish my car company would do? Update my firmware while I'm driving down the freeway.

Kat: [Chuckles]

Jonan: That's not terrifying at all.

Kat: I know it sounds really scary. The application updates are pretty harmless. We never had a single instance of that causing a problem, or wrecking the car causing it to crash, or start driving weird or anything. The firmware updates are not as scary as they sound, though, because the heavy lifting of the update happens while the car is being driven. So it's relying on a tool called Mender that has an A/B update strategy. The car is driving, running the firmware in partition A, and when it updates while driving, the update is streaming to partition B, which isn't in use. So while the heavy lifting of the update happens while the car is driving, it doesn't actually start using the new firmware until the next time you turn the car off and on again because the bootloader is aware of which partition should be current. So if you update B while you're driving to the grocery store or whatever, when you come back out of the store and turn your car back on, the bootloader will flip you into partition B instead of A.

Jonan: I see. So there's no risk of any of the software that is actively running while I'm driving, with the exception of an app like, if I'm using a Pandora application in my -- This is all part of the same system, right? It's all integrated.

Kat: Yeah.

Jonan: So then I update my Pandora over the wire while I'm driving. Will I actually get a new Pandora? Will it restart the app and then give me the new code?

Kat: Yeah.

Jonan: This is interesting, but this sounds much safer. I could see a world where I still feel safe knowing that this code is running. So you had a car that you built, a specialized vehicle?

Kat: Yeah. So JFrog wouldn't let us have a real, whole car, obviously, because they're not going to gamble on three, kind of, cowboy-ish engineers potentially breaking a $30,000 actual vehicle. So instead, we built our own kind of miniature vehicle. It starts its life as a thing called a Donkey Car. Donkey Cars are these little DIY kits; you build a little self-driving car. They're pretty neat. They are a very popular hobbyist thing. People build them and then beef them up. But the standard one only has one camera on it, but some people will put two for better depth perception or a LiDAR camera instead of just normal visual light, bigger batteries, different wheels, and they race them. You teach it to drive itself, and it goes.

So our started life is one of those, but instead of running just Raspbian on the Raspberry Pi 3 they come with by default, we ended up with a Raspberry Pi 3 B+ in a compute module running Automotive Grade Linux, which is exactly what some car manufacturers do actually use for their infotainment systems and whatnot. So we got pretty close to a very simplistic approximation of a real car. And the bonus was that it was something people could actually drive at a conference. We brought it to JFrog's annual user conference and built a huge track in the middle of the convention center. And we were letting actual random people off of the conference center floor either drive the car around the track or push updates to it while somebody else was driving. And we never had a failure.

Jonan: That's amazing. These cars they're called Donkey Cars. I'm definitely going to buy several of these immediately. And a Donkey Car is a kit that I can build myself. Detail for me very briefly how I teach it to drive itself. What is that step?

Kat: It wants to be driven with an app on your phone like a little web app that's being broadcast by the Raspberry Pi on the car. You can do it with a PlayStation controller or something like that, but it requires a lot of extra work, not worth it. So you boot the thing up, load up the controller app on your phone, and hit record, and start driving it around a track. It's not very smart. And the camera it uses is a standard Raspberry Pi cam, which is not very high resolution. So you need a very high contrast track. If you have a darkish floor, like, printer paper on the floor will do it. We also had no problems just using colored masking tape. You start recording, drive 10 or 15 laps around the course as closely as you can, making sure that whatever your track is is in view of the camera, then you have to stop the car, and then move the data from the car back to a computer. It's going to have a big folder of images and then steering and throttle information like telemetry from the car. You dump that back to your computer where you have the Donkey CLI installed and train a model there on your laptop and move the model back to the car. Then the next time you boot it up, you can just click the go try to drive yourself button, put it back on the track, and it'll try to follow the track. If it doesn't follow it very well, and it probably won't at first, you can record more laps and retrain the model over, and over, and over again.

It is a manual and kind of tedious process and training; that model on a MacBook Pro can be pretty slow. So for the actual live demo, we made some modifications to that and built a little crappy Python script running that wrote a tub file for us and chucked it up to GCP to train the model there. There's a TensorFlow on GCP tutorial that works pretty well. So we were able to automate some of the training that way. But you don't have to go through that at home. These kits cost, I don't know, $200, $250, all told, and you can build it in a few hours.

Jonan: I want to make sure I'm understanding, because I'm not actually super familiar with the machine learning stuff. But when you're talking about training a model, we're going over a data set that exists. We're taking these pictures from the car as it travels around, and it's following the blue masking tape on the track. I get a bunch of photos of the masking tape, and then I'm putting these images into a neural network of some variety. And on the other end, it tells me if you see a blue line or you don't see a blue line. So a simplistic representation of this mentally would be you put the picture in the box, and the light turns green or red. Do you see a blue line, or do you not see a blue line? It's training it to follow these lines, right?

Kat: Yeah. It's training it to follow the line because each image you have of the car's point of view with a blue line in it has steering and throttle data associated with it. So you're teaching it what to do when it sees something that looks like this. And over time, it learns, first of all, I need to follow the blue line, and second of all, these are the things I need to do in order to follow the blue line. It learns that over time. There are different types of machine learning, and the type of machine learning that Donkey Car uses is not very sophisticated, but it does work. And it's a really, really good way to teach people who aren't super comfortable with hardware, or don't know anything about hardware, or don't know anything about machine learning to kind of dip their toes into it a little bit because the project is so incredibly well-documented and so incredibly well-supported. It's not insurmountable for anybody with a vague understanding of programming concepts to get into. It's a really good project for kids too. I used it for a hackathon at a local boot camp here in Seattle. I taught a bunch of boot camp students how to race Donkey Cars and build them.

Jonan: That's awesome.

Kat: Yeah, it was really cool.

Jonan: The depth of the technology here can be really intimidating, right? I mean, you've got this understanding of Linux. You've got the machine learning aspects on top of all of the hardware pieces. I'm trying to picture a ten-year-old child assembling this thing. And without very explicit documentation, there are a lot of ways you can go wrong just assembling a thing with a Raspberry Pi in any variety. There are a lot of moving parts. This documentation that exists out there, do you think that my teenager could navigate their way through this on their own outside of the context of a boot camp?

Kat: Yeah, totally. A teenager, yeah, for sure. The documentation has pictures, and in some places, it even has video walkthroughs. It's not as complicated as it sounds because you start with an RC car. And the most complicated part of it, I think, is you have to move the little wires that tell the motor and wheels what to do from the radio controller that is on an RC car, like, to start with, and plug it into a little hat, an extra chip that is connected to the Raspberry Pi. But the documentation is really explicit with photos, like, it says, "This wire goes here."

Jonan: So that's where you're transitioning from the radio controller. And then I just light up the pin on my Raspberry Pi, send voltage to this GPI put in that means turn left, and this means turn right. So that's how it's actually doing the driving.

Kat: Yeah. There's a little application on the Raspberry Pi running called Donkey that is handling that for you. It's interpreting controls from the web app running on your phone or if you've switched out for a controller from your PS3 controller. We were doing it with a Logitech G28 driving force, which is an actual race wheel. We did have to write our own plugin for that because Donkey doesn't support that explicitly or it didn't at the time. So we had to write our own new, extra bit of code for the race wheel. But if somebody listening wants to build one of these and swap out for a race wheel, you can get a hold of me, and I'll be happy to give you the code for that because it is more fun to drive when you can just sit there controlling it from a race wheel.

Jonan: Where would someone find you if they wanted to get a hold of you, by the way? I don't think we mentioned that early on. Where can we find you on the internet?

Kat: You can find me on Twitter @Dixie3Flatline. And also, if you know what that username is a reference to, DM me, and I will send you a JFrog. T-shirt because nobody ever gets it. And I think it was more of a nerd deep cut than I anticipated. So now I'm starting to get a little bit self-conscious about it.

Jonan: I originally had my Twitter handle as leetbot because I thought I was being funny but spelled out in numbers. It was 1337807.

Kat: Oh, you used leetspeak?

Jonan: Yeah. And I go to these conferences and speak to people, and they're like, "Wait, your handle is just a string of numbers, and you want me to remember it?" And I'm like, "No, but it's obviously..." No, it's not obvious.

[Laughter]

Kat: It's obvious for like a certain type of nerd.

Jonan: There's a subset.

Kat: Yeah.

Jonan: This is actually an interesting point because I was thinking about this documentation thing. And I would like to think that everyone wants tech to be more accessible. I think there is certainly a very vocal subset of tech who work really hard to make tech more accessible for people. And projects like Donkey Car go a long way, just having a thing that is well-documented.

Kat: They do.

Jonan: You probably have experience with other similar projects or maybe advice for people on how to make sure that their docs are on point.

Kat: Yeah. It's hard to write good documentation. And I think it's because if we're building something, we're the experts in it. And it's really easy to forget what it's like to not know how to do something. So we don't tend to write documentation from the perspective of somebody who really has no context and doesn't know what they're doing. We write documentation for ourselves or for people like us. And that's not actually helpful because the people who are using your documentation are using your documentation because they know nothing about your thing.

So my number one piece of advice in writing docs is to try to avoid using any kind of jargon or shorthand for things. And if you have to, because sometimes you really do - DevOps is full of jargon, so is cloud-native tech overall, but DevOps and cloud-native are particularly bad about it. If you have to use jargon or an abbreviation or something, explain it the first time, define it. Because somebody who already knows what that thing is is not going to be irritated that they need to skim ahead two sentences to get through the definition, but somebody who doesn't know what that thing is, is going to appreciate having the definition there. Without it, they have to open up a new tab and Google this thing, and then maybe nobody actually explains that very well.

In tech, you see a lot of jargon existing in the definitions of our jargon. And it turns into, kind of, like a rabbit hole thing, and it's super unapproachable and really alienating, especially when doc authors repeatedly call their tool easy. This is a huge pet peeve of mine.

Jonan: Me too.

Kat: Stop calling your thing easy. It's not easy. It's easy for you because you built it because you're the expert, but it's not easy for somebody who has never been exposed to it before. And at best, it's frustrating to not be able to do something when the author is repeatedly calling it easy, and at worst, it's discouraging. And they bounce and go use a different tool that's more well-documented than yours. So write better documentation, or you're shooting yourself in the foot. You're pushing people away for no reason why.

Jonan: If you're out there working on an open-source project and pouring your heart into this thing, your goal is to get people to use it. And you want to be addressing as broad an audience as possible. And you and the people that you think you are serving with this project may understand an acronym that exists. But do any of those people just rage quit a project because you explained it? If I'm going through docs and someone is explaining an abbreviation or some bit of jargon that they're using, I'm not going to throw up my hands and give up on the project because they didn't explain it. But that's the reality for a lot of people who are on the other side.

Kat: It's really frustrating to see over, and over, and over again. And there's almost this mentality of, well, these concepts were difficult for me to learn, so that must be normal - it's just hard to learn that. Why does that have to be true? Kubernetes is hard, right?

Jonan: Yeah.

Kat: Everybody says Kubernetes is hard. Why does Kubernetes have to be so hard to learn?

Jonan: Well, we just don't know enough about how to educate people - we do know that actually, we do know that. And we know how to design a curriculum, and we know how to put in the work and make it happen. And we don't.

Kat: We don't do it.

Jonan: Maybe because we're busy, and I can buy that argument.

Kat: Sure.

Jonan: But also consider that when you're talking about software, the manual is most of the work, right?

Kat: Yeah, you're not done if people can't actually use your thing. And being able to teach somebody how to use your thing that's what makes it usable. It doesn't matter how cool your project is. If nobody can use it, what was the point?

Jonan: If you translate it into the physical world, you have a whole world out there who doesn't know how to drive cars, and you expect to sell them cars without teaching them how to drive or to use inside jokes during the process for drivers. You want to develop your documentation for an audience of race car drivers to sell your cars, that's fine, but you are not selling to the rest of the world who can't drive.

Kat: It's ridiculous. I'm really not sure why this is so pervasive and why it's been a problem for so long. I thought I was just imagining it for me personally. Maybe it was just imposter syndrome. But when I started writing 101 level content like really explaining even the things that people with more experience consider simple, and it got way more engagement and way more attention than any of my technical deep dives, that's an indication that there is a serious lack of this kind of content, just not enough of it. And I can't write all of this on my own. So I need maintainers to please write better docs. Hand your docs over to students at a local coding boot camp or from a CS program. And if they don't understand it, you're not done writing it.

Jonan: I think it is a good opportunity to get the community involved too for a lot of open-source projects. Just outline even on your projects how you want people to contribute, and what process you would like to use, and be kind to people when they try. I get that it's frustrating that you're out there with some project, you get a lot of pull requests on, and it takes a lot of your time to manage that input. But most of the time, people are acting in a way that is designed to benefit your project. And it's ultimately in your long-term best interest to enable that level of help. The resources that are out there for people early on in their careers right now are getting better. We're making a lot of progress, I guess. But at some point, they fall away.

When I was learning to code about a decade ago, I remember coming into this place where I felt like I was in this intermediate wasteland where I'm off trying to learn new, more interesting things than to-do lists and tic-tac-toe, and there's just not enough content out there. And if you find yourself in that position now and you're struggling, go and try and find something like this car. Try and find some project, find a Donkey Car, something that you think is difficult and will be difficult for you to achieve, and just push towards that project by degrees. But if you're out there and you're already on the other side of that bridge, I'd encourage you to go back and fill in some of the gaps. These are fun projects to play with. Donkey Car sounds really well-documented right now. But there are plenty of similar projects out there that could use some attention. If you're using a thing and you're reading through the docs, and it's going well for you, you're the person who we need to stop for a moment and help those who maybe would struggle with those paragraphs.

Kat: Yeah, definitely. And Donkey Car is really well-documented, but that doesn't mean it can't improve, still. There's a bunch of code in the Donkey library that's just unfinished but isn't all that complicated. You could make a small change to it. And that's still helping out this really cool project that teaches anywhere from newbies to intermediate programmers a whole bunch of stuff. Most people don't touch machine learning, and hardware, and embedded Linux. And we got MQTT involved and Kubernetes and all kinds of stuff in one project. That's not all that common. So it's a really cool thing to dive into, and you can make all kinds of crazy modifications to it. And it's a fun project.

Jonan: It's a fun project. I like these kinds of house of cards-style projects. I end up building. Ultimately what it is, is that I enjoy over-engineering things. I enjoy making my waffle maker use Kafka in order to accomplish its job.

Kat: Why not?

Jonan: I think that's fun. It's an interesting opportunity to teach, and I think it's a really good way to learn. You set out with a simple objective, and you make progress towards that. And along the way, leave a trail. I think that the work that you're doing out there in the world and the stuff that I find up on your GitHub is very often designed to bring people along with you, and I really appreciate you doing the work. I think that it's easy when you're learning to find those frustrating parts and then get over them, and you get the endorphin rush that got us all hooked on this stuff in the beginning where you're like, "I will never solve this bug." And then you solve it, and you immediately are high till you find the next bug. It's up and down. It's easy to just move past the frustrating thing. But when you're in that moment of pain, it's a really good time. Learners are some of the best teachers.

Kat: Oh, they are, for sure. Like the DevOps 101 workshop I teach that took me, I don't know, two months to write the content for that workshop is the way it is because I borrowed a bunch of students from the coding boot camp that I went to and just ran them through it several times finding problems. Where did I not explain this well enough? Why does this not make sense? How granular do I actually need to get with explaining to you what the prerequisites are for doing this? Should I actually be specifying that you need a GitHub account to do that? It turns out, yes. That's not something I would've considered because it seems just default to me to have one.

Jonan: It seems like table stakes. And then you realize that in the assumption that they have a GitHub account, you're also assuming they know how to use Git at all and on and on.

Kat: Yeah. It's really important to talk to the people who don't know anything because they will find problems that you can't see. The more expert we get, the more we forget ourselves and what it was like to not understand how any of this stuff actually works. And it's normal. It's human nature. It doesn't make you a bad person. We just forget the pain.

Jonan: Yeah. And it's just a thing that we focus on and overcome that thing. Like anything in your life, in an area you want to grow, just focus on the thing and grow. And it's a thing that people overcome. There were obviously people very late in their careers who are fantastic teachers because they've taken the time to sit down and document for themselves those individual pain points that they found along the way and, where necessary, gone back to the learners themselves to ask. So I'm curious what advice you might have for learners out there now, people who are just coming in. Obviously, they go through DevOps one-on-one, this course that you designed. But what else? What should they be doing with their time?

Kat: If you already know a programming language, my favorite thing to do to try to get the basics of another one -- because I'm not extremely good at any one programming language other than maybe Python. I'm mediocre in four or five languages. But I build a CRUD app the same, like, Create, Read, Update, Delete, crappy web app with some database interaction over and over, and over again in different languages. And that's a really good way to kind of dip your toes into a new language and decide if you like it enough to go further without really committing hard because it's a lot of basic things that you need to know how to do in virtually any language.

But more importantly than practical hands-on advice is, I know that everybody hears this a lot, but there really aren't any stupid questions. If somebody makes you feel like a question is stupid that you've asked, the problem is with them, not with you. It's mean, I think, to make people feel like they're stupid for not knowing something because nobody is born knowing how to do this. We had to ask these questions, too, at some point. So ask the question. It's not stupid. Come ask me. I don't care. I might not know the answer, but I will try to answer it for you or send you to somebody who can answer it. Don't be afraid to ask people questions. And if you can, find somebody who's willing to function as a mentor because it's super-valuable to have somebody that you can kind of get a rapport going with and have that person be responsible for answering questions that maybe you're a little bit embarrassed to ask because somebody was a jerk once and told you that a question was stupid.

Jonan: Yeah, those are the people you walk away from. You don't want to be around them in this industry period. There are people who do this, not realizing that they're doing it. And maybe you'll be the kind one who takes the effort to try and educate them on how crappy that feels to be told. And you don't even necessarily need to find someone who is going to be able to mentor you full-time. This is a big ask to go to someone and be like, "Hey, I need a mentor." Just make them mentor you. Find someone that you have DMed on Twitter who approximately knows the thing and put them in your rotation of 10 people to DM when you have a problem. Build a Voltron mentor out of component parts of people you know in your community.

Kat: That is what Twitter is for. I definitely have just a circle of people that I go to for help. And that's just; this is my laundry list of folks that exist to help me when I can't find the answer to something. And that's called having friends, by the way.

Jonan: Yeah. That's another way we could describe that.

Kat: Yeah. That's what your friends are for, actually. And if somebody does make you feel bad for asking a question that they think is stupid, go crying to somebody more experienced about that because one of us will shut it down. I'm not afraid to shut that down publicly if I see it happen publicly on Twitter or in person.

Jonan: Yeah. It's so damaging. You are very likely immediately pushing someone out of tech. That person may not become a member of our communities because you wanted to sound smart in their replies.

Kat: Yeah. It's exhausting. And it's usually these people that consider themselves 10x engineers, which is just something -- Like, nobody likes working with people. So another piece of advice to newbies - do not idolize those people. Nobody wants to work with them.

Jonan: The 10x engineer is a myth. It's a lie. It's a lie straight up. The 10x engineers that I've worked with left mountains of technical debt behind them. They merged 6,000 lines PRs without a single test against the objections of their team. They look good sometimes from far enough away. When you are someone just entering the industry, or you're observing even from a management level, unfortunately, sometimes these people look productive. They're toxic, and they are dangerous to the industry.

Kat: It's horrible. Maybe this comes from them being useful in super scrappy, very early-stage start-ups, where there are two engineers anyway, and everybody has got six different job titles. Maybe they're useful there. But it's still a trade-off because if your start-up takes off and you hire 12 more engineers, that guy is going to be an absolute nightmare. And his code is probably an unmaintainable monstrosity that nobody else can read. So just do not try to be one of those people. It doesn't make you look smart. It doesn't make you look more reliable. It isn't more marketable. It makes you look like a jerk, and it's just exhausting to deal with. And there are so many of them.

Jonan: It's exhausting in the industry, and it's not like you're fooling anyone, ultimately. The people who have found their way to experienced positions within this industry see you, and they see you faking it. Just stop it. But people who find themselves in those positions, I don't necessarily assume that they act with malice. I think they act out of ignorance often and out of a desire to succeed. And what you're going to learn over the next ten years of your career is that your success is going to come from the people around you and the way you interact with them. This is about humans. Software is made for humans, by humans, but not of humans. If you're grinding up people along the way, you're doing it wrong.

Kat: Oh yeah, yeah. Code's not made of people. It's made by people for people. It's a computer that's executing it, but it's not made of people. So let's avoid the cannibalism, if you will.

Jonan: [Laughs]

Kat: I don't see a slot for a human in my computer. I don't see a slot for it.

Jonan: There's nowhere to get them in there. It's common for people like that to burnout, though.

Kat: It is.

Jonan: And it's even more for the people aspiring to be them. You may not have a very long career here if you're chasing that 10x developer myth up the mountain.

Kat: Yeah. It's not good for anybody. Those people are awful to work with, but they're not happy themselves usually. If your literal, whole life is eat, sleep, code, repeat, that is not sustainable. It's really not. If you're not a hypersocial person with a large friend group or whatever, and in non-corona times, you still don't enjoy going out to the bar with friends, that's fine. I'm not crazy social when I'm at home either. But everybody does need to do something other than work. And this idea that in order to be a good coder, coding has to also be your passion, and you have to do it in your spare time; that’s ridiculous. That is absurd. It is totally acceptable to want to code for the money because the money will be good.

Jonan: It is.

Kat: You can just want to code because it's good money.

Jonan: One of my primary motivations for having a job, period, is money.

Kat: It's money, yeah. If I didn't need to work to pay my bills to live, then I would probably just lay at home reading, and eating snacks, and playing video games all day, but I have bills.

Jonan: So you have a job, and it happens to be a job that you deeply enjoy, but it doesn't mean that you spend your whole life doing it. And that's an important step. I do want to acknowledge that early on in your career, there are sacrifices that need to be made. You're going to have to be dedicated, but you can still be dedicated during your work hours, right?

Kat: Yeah.

Jonan: You could set boundaries for yourself. Don't dive face-first into code all day, every day. You're either going to burn out, or you're going to lead an empty life. Best case scenario, you get to the end of this single lap that you get, and you look back and realize you really haven't gone outside much.

Kat: Yeah. And I did burn out earlier this year because the quarantine has most people in dev roles working much harder than we are used to. Typically, I would give two; maybe three conference talks a month when I was allowed to go places because I had to fly. I had to fly there, and sometimes I had to fly to the other side of the planet. So maybe two conference talks a month, and that's it. And the rest of the time was writing blog articles, or refining conference talks, or writing a new one or whatever. But because everything is virtual now, there have been months where I gave eight or nine talks.

Jonan: Yeah. It's intense.

Kat: It's really, really exhausting. And I burned out, and I burned out pretty hard. It sneaks up on you, the burnout.

Jonan: Yeah, it does.

Kat: It really does. It comes out of nowhere where you're stressed out, but you think you're fine. And then the next day, you're flipping out on your boss, and you're literally incapable of functioning.

Jonan: You just shut down. You stare at the empty Keynote deck for hours or wherever you're making your slides, and you just can't do the work.

Kat: Yeah, you cannot do it. Don't let that happen to yourself. Don't try to chase the 10x dream. The 10x dream is a lie.

Jonan: It is a lie. I think the dev role people get, ideally over time; they build up callouses around burnout protections. I can see it coming sometimes now; I can sometimes be "Okay." Because the nature of our work is such that, yes, sprinting is necessary. If I'm going into a conference and my talk is going to need to be developed, and I'm going to write a lot of code, and I go heads down, and I fly out there, and it's done, that's a sprint. But then I'm down for a few days. And if I don't ever get that down, which is very common right now in the pandemic where we have an infinite opportunity to be available for our peers for all of those - here's a quick check of some copy; here's a project we're working on; can you help out with this code? It's a rough time right now for everyone. Give yourself some space to relax.

Kat: We have to be on all the time. People in dev roles are not allowed to have a bad day where people can see it, and everybody can see our jobs. So it's a little bit exhausting. And it was not as hard when I could fly because yeah, every time I went to a conference in Bangkok or Brussels or whatever, I'd get there a day or two in advance to accommodate for the opportunity of the chance that a flight might get canceled, to get over the jetlag a little. And then I take my weekend two days after the conference, and it's like getting a free European vacation for two days. That does a lot to prevent burnout, but we don't have that right now. [Chuckles]

Jonan: We don't have any of it. Flying on a plane was some of my favorite times when I was on the road because no one could get ahold of me. [Chuckles] They didn't have any choice. I only had books to read. I loved it.

Kat: Yeah. It's fantastic. I hated being on planes before I was in a dev role, and now I love it. It's my favorite part of going somewhere. I actively look forward to being on a plane now just because of the fact that I can just focus on chilling out or finishing my slide deck, or whatever without having to deal with notifications from Slack, and Twitter, and my email.

Jonan: I miss it so much. It's making me sad.

Kat: I'm sorry.

Jonan: That's okay. Soon, soon. I'm told that as soon as two years from now we'll have conferences again.

Kat: Oh, God.

Jonan: If you're listening, event managers, online events are not a replacement, not even close. Please bring back real conferences. Thank you so much, Kat, for coming on the show. You're a joy to interview with. I really have had a good time. And the Donkey Car project is fascinating to me. I'm probably going to be spending a significant portion of my next several paychecks buying Donkey Cars. I want a fleet of these things so I can run a whole cluster. I could run Kubernetes cluster on wheels and drive it down the freeway. I love it so much.

Do you have any last tips for people who aspire to be in your position? So specifically dev role, what if someone's out there in the industry and they're starting to acquire a little experience. I feel like we've given them some good hints so far. But what if someone wants to transition into a dev role? Any tips?

Kat: Just talk. You don't have to be an expert in something to submit a conference CFP. Intro level content is still really, really useful and still really valuable, and it still gets accepted. Write that. You are a beginner, so your specific experience is relevant. It is valuable information that people want to hear about. And people like hearing an individual's perspective. Your personal story is what makes that content compelling. I talk about myself a lot on stage, and people like that because the personal touch is what makes it feel more real. It makes it feel more real than just cold technical documentation. So just submit a CFP. Submit to it, and don't feel bad if it doesn't get accepted. It doesn't mean your abstract was bad. It doesn't mean your topic is bad. It means that it wasn't the right fit for this particular conference or somebody else is presenting the same thing or something similar, and either it was blind in their abstracts, I don't know, or it was a little bit more well-crafted, or they were choosing to balance diversity and inclusion, and you didn't make the cut because of that, any number of reasons. But it does not mean that you're not qualified to talk about it. It doesn't mean that your topic sucks. And if you are having trouble grafting a CFP and you find that it's not getting accepted anywhere, feel free to DM me the abstract, and I will look at it for you and see if we can help make it better because I would like more speakers on the circuit, more new speakers. And you don't have to be an expert. You do not have to have a fancy title. You don't even have to have a job, especially right now.

Jonan: Especially right now. And speakers, when they are just starting out, I remember this paralyzing fear that I wasn't going to choose something technical enough or interesting enough. But you're exactly right that I'm there for the voice. I'm there to watch you be on stage. And I want to hear your take on the thing. Honestly, I could watch the same content from different speakers just one after another. I would find that even more interesting, maybe to hear different takes on it all. So again, thank you so much for joining us. If you want to find Kat online, you can find Kat as Dixie3Flatline on Twitter. Any other links you want to send people?

Kat: Not really, unless you want to try to email me, I guess. My work email address is katc@jfrog.com. But that's just in case if you don't use Twitter, you can email me. But I really I'm not the greatest at checking my email because nobody actually is.

Jonan: Yeah, because it's the digital equivalent of snail mail. So if you appreciate bi-weekly asynchronous communication, use the email. Alternatively, DMs are better.

Kat: Yeah. Correct. [Laughs] Just DM me.

Jonan: Excellent. Absolutely a pleasure, Kat. Thank you for coming on. I will see you on our next episode, I hope. We'll have a reunion episode a year from now. We can come back and talk about my Donkey Car ventures.

Kat: Oh, dope. Yeah, I would love to. Thank you for having me.

Jonan: Thank you so much for joining us for another episode of Observy McObservface. This podcast is available on Spotify and iTunes, and wherever fine podcasts are sold. Please remember to subscribe, so you don’t miss an episode. If you have an idea for a topic or a guest you would like to hear on the show, please reach out to me. My email address is jonan@newrelic.com. You can also find me on Twitter as the Jonan show. The show notes for today’s episode, along with many other lovely nerdy things, are available on developer.newrelic.com. Stop by and check it out. Thank you so much. Have a great day.