Software Misadventures - Learning in public | Kelsey Hightower

Episode Date: April 16, 2024

We’re super excited to have Kelsey back on the show! Our last conversation was around his incredible career journey - from working at McDonald’s after school to starting his own computer store, to hacking on python infrastructure with the core developers, to meeting Satya Nadella for an interview. In part two of this conversation, we dive deep into Kelsey’s experiences learning in public and writing “Kubernetes: Up and Running”: The biggest barrier to getting started with learning in public and a step-by-step guide to overcome it Cautionary tale of the “JavaScript sucks” guy Developing the skill of crafting good analogies The business and economics of writing a book Much more   Segments: [0:01:12] Writing and learning in public. [0:10:58] Writing "Kubernetes: Up and Running." [0:16:05] The business and economics of writing a book. [0:21:27] Why your first book should not exceed 100 pages. [0:23:36] What prevented Kelsey from giving up on the book. [0:26:15] Being intentional about building an audience and the cautionary tale of the "JavaScript sucks" guy. [0:36:44] Authenticity does not guarantee success. [0:39:09] Developing the skill of crafting effective analogies. [0:47:47] Advice for engineers to leverage their technical skills outside of the nine-to-five.   Show Notes: Kelsey on twitter: https://twitter.com/kelseyhightower Our previous conversation with Kelsey about retiring as Distinguished Engineer from Google at 42: https://softwaremisadventures.com/p/kelsey-hightower-on-retiring-as-distinguished-057   Stay in touch: 👋 Make Ronak’s day by leaving us a review and let us know who we should talk to next! [e-mail]

The first month you're like, man, I'm about to write a book. Woo! It's crazy. And month number four, you're like, man, I'm not finished, bro. Why did I do this? I can literally stop because I didn't tell anyone. And then you start to understand the value of a co-author because when you're tired or too busy, your co-author's in there writing, adding chapters, and then you can review.

Welcome to the Software Misadventures podcast. We are your hosts, Ronak and Gwan. As engineers, we are interested in not just the technologies, but the people and the stories behind them. So on this show, we try to scratch our own edge by sitting down with engineers, founders, and investors to chat about their path, lessons they've learned, and of course, the misadventures along the way. Hi everyone, it's Guang here. Last episode, it was all about startup advising. In this part two of the conversation, we get into Kelsey's experiences about the what,

why, and how of learning in public, as well as writing his book, Kubernetes, up and running. Without further ado, let's get into the conversation. You've been learning in public. And I think as learning in public, you've done a few different things like used to be meetups, for example, at some point where you would go and talk about a new thing you learned with, let's say, Puppet, that transformed to Kubernetes, that transformed to, you know, giving keynotes, for example, where it's still at least, and I might be off base here, but it seems like it's still part of just learning in public. It's an extension of that in a way. Many folks think about, well, I want to start blogging, posting on Twitter, or giving conference talks. But they don't exactly know where to start.

Do you have any advice for people who want to do a little more of this, but just don't know where to start? They're like, I don't have anything interesting to talk about. I'm sure others would think differently, but they themselves don't have an idea. You know, I think the biggest barrier to getting started is people keep trying to compare themselves to people who've been doing it for 10, 20 years. Yes. Right?

Some people say, oh, I want to start a podcast, but I got to get Joe Rogan set up first. It's like, what are you doing? And so then it delays you, right? Especially if we're talking about engineers here, they overthink everything. They start thinking about all the branches, you know, how it can end up, just overanalyzing some of these decisions. So if you think about what it means to learn in public, and we're just going to try to be hyper-specific. You have a job, you work on backend engineer, you're using Node.js, expresses your framework of choice,

you build these APIs, it's what you do every day. One day you get an issue from support and it says, hey, we're not returning Unicode. Customer names are coming out of the database and certain Unicode things are being stripped out and missing. So you don't know what's going on. Maybe you're early in your career, you don't have any idea, you're not really thinking about Unicode things are being stripped out and missing. So you don't know what's going on. Maybe you're early in your career. You don't have any idea. You're not really thinking about Unicode versus ASCII. You're not thinking about any of this stuff because stuff was just working before.

And so the ticket gets assigned to you. You go in the database, and after some digging, you see UTF-8. You're like, what's UTF-8? What does that have to do with anything? You look at your client libraries, you look at your JSON serialization tool, you look at Nginx, and you notice that somewhere in the chain, one of them is just doing ASCII by default. So it's getting an array of bytes, and it's interpreting them a different way. And you're like, how is this

possible? So maybe you go to Stack Overflow, you look at something, and then you learn the fundamentals. The fundamentals say, data is just an array of bytes arranged in some way. That's what it is. A string just happens to be an agreed upon set of bytes with some terminator at the end. And the database interprets and stores those string of bytes as UTF-8, your library gets streamed UTF-8, you parse the data as an array of bytes, and your JSON parser treats it as ASCII for some weird reason. And what it generates back out to the client is in a different interpretation of those bytes. So you fix it.

You go to your library, you go to the parser, you say, you know, text format is Unicode, right? And you check in the code, bug fixed, done, right? You learned a lot, that's it. So what is learning in public? Learning in public could be as very simple as, hey, in the commit message, by default, the JSON parser we are using

defaults to ASCII. This change uses UTF-8 by default, which matches all the databases we use in the company. This change changes just that one line and updates other parts of our place because we think that's the right thing to do. And so that's your pull request. Now, the person reviewing the pull request,

which is a small audience, by the way, gets to learn everything you went through because you're not just saying, fix Jira ticket 278, where you look at the diff it's just like you know text format equals UTF-8 that doesn't teach anybody anything someone just said I don't know man if that's what you needed to do to fix it yeah there's a whole lot of that by the way yes yes a lot of that so learning in public is that patience to say hold on stop

it took me two days to learn all of this fundamentals. Let me put it in the issue. And now that it's in the issue, it's in public. The co-reviewer is going to see it. A lot of times when you're a developer, you usually put the Jira ticket number in the commit message so that it can be linked and close the upstream issue. Now, support may be curious, like, how'd you fix it? And so when they click on the issue, it goes and they get to read this phenomenal commit message. And when they have to explain to the customer or explain to other people and support what they're doing, what's happening, they see this nice commit message. So now they learn. And then they say, you know what?

We've had 200 of these type of issues in the last two years. Now that we finally see this commit message, we can finally explain the other 200 issues. Now everybody knows what's going on. Now a lot more people know about bytes on disk and how they're interpreted by these different codes. And then one thing you could do is, and this is where I think a lot of engineers get thrown off. That sounds very simple to people with experience, right? So, oh man, everyone knows that I'm embarrassed that I didn't know it. So I'm not going to tell anybody. Oh, yes. Right? But if you want to be transparent, you go to your local meetup. I didn't say KubeCon.

I didn't say the big national conference. I'm saying the local meetup where the same two people talk every day. It's like, dude, this guy giving a talk again? So if you don't want to see that, that means you have to step up and give a talk. And so you take the situation we just talked about. So you did the commit message. You've educated the jury ticket. And now you go to the meetup and say, hey, look, I'm going to give a very short talk.

And as an engineer that's been doing this for a little while, I never thought about how data is represented in the database, in our apps, and when we return to clients. And so I'm just going to walk through an issue that I had to troubleshoot and what I learned about Unicode versus ASCII and why it's important. So you go give that talk at a local meetup. There's like 13 people there. And those 13 people are like, I knew that, but I never explained it to anyone else before. And I never really thought about why it's still a problem. And it's a nice refresher for them. Then there's going to be a bunch of people that's like, I work in ops and I never thought about any of this stuff. So they're educated.

And so that's just 13 people. So what happens then? Two years from now, one of those 13 people run into the exact same issue. And they say, hey, is it ASCII or Unicode? And they will remember the talk. And I can go on and on about them tweeting about that talk or writing a blog post about that talk. So I think for you is don't skip out on things

because you think it's too simple. Because remember, we're talking to millions and millions of people worldwide. Someone needs this reminder. For someone, this is the first time that someone that they can resonate with is talking to them. so that's how you start very tangible very straightforward very easy you don't have to create a cfp and submit to some

large conference when the time comes from that then you do it at that time i think it's super important like the part you pointed out about being able to set aside your ego right not feeling embarrassed like when you're telling the story i can like sharply imagine like my ex-coworker ben who's like amazing at this and one of the things that really jumped out to me is that right it's not that he's very smart but not just that he's very smart and he communicates super well but he's like very humble and i think that also lends itself right to like empathy of like when i'm watching it right like, like, whatever he's presenting, it also makes me, like, oh, yeah, like, I can totally see being in his shoes, right? Like, he's telling the story in a way that, like, I can really relate to.

And, yeah, there's many times where when he started out, it was, like, very simple, right? I'm like, oh, yeah, I sort of know, like, what's going on. Yeah, I haven't seen this before. But then, you know, halfway through, I'm like, oh, I didn't know i didn't know like right like these are all the nuances that like go into it the stories are right in front of you when you run into these things and you struggle with it you power through and you solve it that is the story don't try to add a car chase don't try to add an explosion and a helicopter like this is not you know everything doesn't have to be a transformers movie right so i think some people like oh man this is not exciting enough right so you hear people say what is the most interesting bug you

worked on they say oh man i found a bug in the intel cpu it's like dude what that's not normal bro that's that's that's something else uh don't tell all the stories yeah uh the other thing which i would just say is that i think the added benefit of actually going that extra mile in the commit message or the meetup talk or even a blog post is it ensures you fully understand the thing and whatever you've thought you understood or whatever you fixed wasn't just, or it just seemed to work, coincidence. But it ensures that while you're explaining it to others, you really deeply understand.

Okay, so going from learning in public to educating others, you have written a few books. I'll say Kubernetes Up and Running is probably the one that at least I have read. And I saw that there were three editions of it. And in other cases, wherever I've heard about people talking about writing books, they just say, well, they wanted to write a book because it seemed cool. But then it was a whole lot of work i remember asking i think one of our friends manu who wrote a book and we asked him what's your advice on other people writing a book and

he's like don't do it it's too much work um but you've written a book as well so we're curious to know your thoughts uh what was that experience like so kubernetes comes out i'm contributing i'm working at core os and i'm a big fan of the O'Reilly book series, because when I was learning new skills, I remember just finding an O'Reilly book and just reading it multiple times until I learned, and I felt like that was one of the best ways of really improving your knowledge, especially if you were already working, just kind of filling the gaps. So I wanted my opportunity to create a book, too.

And so back in that time, I was the only author, right? I went to Wikipedia, I looked up pods and found the killer whale, they travel in pods, blah, blah, blah. And so I didn't know, but you don't normally get to tell O'Reilly or propose what your book cover is. They pick an animal for you. There's a person who draws the animals, and that person may have drawn 20 animals that are waiting to become book covers. In this case, I'm like, hey, I don't know anything about that. I would like this whale to be my cover.

And they're like, fine. So you put together a draft, an outline of the things I wanted to cover. And luckily for me, there are zero Kubernetes books at this time. So this will be the first one. So more than likely, you have a great chance. But when you think about the book business, so there's two things here. There's the, I just want to write a book to put my thoughts on paper, and I don't care if they sell a single copy. Right? So you're just doing it for that reason. And in that case, you know,

the book was very successful in terms of putting these things on paper. I think I got to about 100 and something pages of a 220 page book before I realized I needed some help. So co-authors, Brendan Burns, Joe Beda, right, two of the multiple founders of Kubernetes, really brought in, so I started the book saying, look, I want to make sure it's very hands-on. I want to start with Docker fundamentals, a bit of storytelling. I want people to really learn and actually type through this thing and really learn and how to do these things. Brendan brings in like the why. Why did we have pods? Why did we do this? Why did we do that? Why do we make all these decisions? And Joe brought up that analytical stuff well, especially his experience working on

things like Borg. So all three of us then put this combination together, and then you get Kubernetes up and running. So a lot of people saw all three of those styles blended together, right? Because we didn't write individual chapters. It was more like, all right, Kelsey has the frame. Most of it's here. Brendan may go in and redo some things. Joe may go in and redo things, maybe make the examples a little clearer. And then you get the editors come in and they clean it up, make sure all the formatting matches the style of O'Reilly. And then the book goes. Now, before that process, the business side, given that Kubernetes was so hot, the only thing in town, I remember, I won't mention the dollar amount, but, you know, it was some people's medium income probably

just for the first chapters being marketed through some download. You know, you see these things like, hey, download the rough cut. Yeah. And a company will pay for exclusive access just so they can host that book. It's a bit of co-marketing. And so that's really good business when you can start to get basically sponsors to, you know, put this thing out, drive demand for the book, a couple of sample chapters, and then you just get early revenue from that. The book has been translated into Chinese, German, lots of dialects and languages. So, you know, every time they do that, usually they have to seek your permission.

Like, hey, we're going to let you all know. We're going to translate this work into a different language. And at that moment, you're no longer the author of that new language, but it's a derived work from your previous work. And so I'm done. Volume one, I am done with this thing. It does take a while. It took me like six to nine months to just get to the hundred pages to realize that I need help to finish this thing. Maybe it takes another three to six months to really get this thing wrapped up. And so there's a lot of work that goes into it. Number one, mainly because we're not professional writers. Now, what I've learned is that trying to write perfect chapters out of the gate, that's not how you do it. You don't write code that way.

Right? You do the first pass, then you clean it up. And for some reason, when it comes to writing, we all forget that there will be multiple phases to get to where you want to be. So volume one is out. Now, luckily for me, since I do speak at conferences and have this other kind of revenue stream, book signings. I've definitely made more money on book signings than book royalties. Because there's something about people wanting you to stand somewhere for two hours that you could sell 5 000 books and wouldn't make as much as i would make on a book signing so that in-person thing is it's like a artist like a concert you may make more money on the concert than actually selling albums to

all the people who showed up at the concert how does that work yeah i'll give you an example different people have different prices but i usually charge like keynote prices my keynotes are 20 to 30 000 plus travel book signings are roughly the same for me so if you put out a number like that they order the books so you'll get some revenue from the book sales but remember you got three co-authors two co-authors the publishers taking their cut like you know now look i think my average check size even to this day might be six or seven hundred dollars it was much bigger six years ago seven years ago when the original edition published so i am not complaining to continually getting royalties from this you know work that i did a long time ago. But a book signing, there's something about

being in person. And so people come, they get to shake your hand. It's almost like a keynote. So you stand there, you may give a little talk to kick things off. And now there's a book signing. So that's 20,000, no shipping, no printing. You're just there signing books. Now, different authors may not necessarily get to charge those same prices. I'm not going to say it's the same for everyone, but there's a lot in an appearance fee. So some of the more popular artists may have an appearance fee where they show up at these book signings and it just drives people to the establishment. Maybe people pay to get in. So a lot of these conferences, people pay to get into these things. Sponsors pay a lot of money for those booths,

and why not drive traffic to a booth via a book signing? So that's just kind of how that works. But again, now as an author, you have to also be a business person. You see this in music as well. A lot of artists are not business people. They just make great music, and then someone else deals with all the business.

So they're like, oh, you don't make money doing music. I'm like, there's money in the music business, but it includes merchandise, concerts, appearance fees, those kind of things. So when I thought about like, hey, when you write a book, you have to think about the whole package in terms of like that book is a product. But you probably have to do the other things it if you really want to maximize it. The thing about a book though, when you sign with a publisher, it is not your book. It's their book and there's a royalty split.

So when they decide that they want to do a volume two, then it gets a little tricky because volume two may not be guaranteed to be written by you. Now your name stays on it because you know most of the content was probably written by you and the other co-authors so maybe one co-author wants to go off and do you know a second edition they have the bandwidth to update the chapters i think brandon burns kind of led the charge on volume two hey let's update this thing there's new data types in kubernetes we have services

ingress right when i started writing the first book there was no ingress so he came and added all these things and most of the time you just kind of keep the splits roughly the same you know brendan is not hurting for money just wanted to see the second edition out I may do some reviews, but he largely leased the charge. Volume three, we added a new co-author, Latchin from Microsoft, right? He worked at Deus for a while, worked on things like Helm, and he wanted to do lots of updates. So we added a co-author there. And, you know, again, you have to negotiate your splits, right? And so I didn't have to do pretty much anything, but I still got my splits. But this is the book business, right? So it's not yours.

Now, out of all of my experiences, all the book signings, all the value that that book has brought to the community, to me financially, and all the co-authors, I think it was definitely something I'm glad I did. It's a good experience. But now that I understand the book business, my advice to anyone would be just write a 100-page book. Stop. You don't need 200 pages. Maybe a book publisher needs 12 chapters or something like that. You probably need only 100 pages. If you think about the technical concepts we're trying to convey,

Kubernetes was so big that I can't believe I even tried to cover all the concepts you would find in something like Kubernetes. But if I were thinking about writing a book today, let's say I wanted to write a book today, I might say how to write a modular monolith using Go. Right? Very straightforward. Right?

You can write microservices, but here's my opinion why you shouldn't. Here's what that looks like. Here's how i would approach it with a go code base and 100 pages if that's not enough you're talking too much get closer to what you're trying to say 100 pages because you will finish 100 pages you're not going to have enough space to say all the things you want you're going to cut it down if you think about it there's a famous book the uh knr uh who is it um kearney and ritchie dennis ritchie you know the inventors of c they wrote the c book if you've never seen it's like a white book but a blue c on the top that thing is a hundred pages and for a long time that was they call it the c book it is the book about c hey here, here is C. It's a high-level programming language.

I remember them describing it this way. And they show you how to write, like, temperature apps, temperature conversions, you know, how to do all this stuff, how to compile, all these things, an appendix in the back. Like, it had a whole appendix about what these words mean. But the book is very concise. And so I think if you're going to do this as an engineer, do not torment yourself. Get very clear on the idea you want. And look, if you want to add more later, do a volume two. Do a volume three. These books have life cycles and they don't last as long

as you think, but think about the whole business. If you write a book today that's any value, think about the talks you'll give about the book think about um the things that you didn't get a chance to write about that you can then do an author series or a video about but it's a business but you were when you were writing um did you think about giving up at any point maybe after like the first hundred pages you're like you know what this is uh too much yeah in the beginning because once you start talking about all the formatting, like when you write for O'Reilly, they have a really good publishing system. So it was Git-based, largely like just kind of ASCII doc,

kind of markdown blend type of thing. And so you didn't have to worry too deeply about the formatting, but you did have to kind of line things up. But I had a lot of code snippets in the book. And so then you've got to like like where am i hosting the code you can never take it down because it's in the book the links so we try to print as many code blocks but there are some parts where you have to go download something from a url and bring it in so you're kind of stressed out about these things um and then like i said you know the first're like, man, I'm about to write a book.

Woo! I'm crazy. And month number four, you're like, man, I'm not finished, bro. Why did I do this? I can literally stop because I didn't tell anyone. And then you start to understand the value of a co-author because when you're tired or too busy, your co-author's in there writing, adding chapters, and then you can review. So I think for the first time, having a co-author isn't terrible.

A lot of people have shadow authors anyway, right? There's ghost writers that are doing a lot of these biographies where you see someone's name on it. Oh, yeah. And they're not really writing the whole thing. So it is a lot of work. But, yeah, I do think you start to think about giving up. But luckily, again, having Joe Bader, Brendan Burns, and the support of like O'Reilly, that is the value I think having a publisher.

Publishers do all these things. Like, I mean, they're so fast at writing. When they do their pass, they're correcting for tone. They're asking you really good questions. And they make sure you actually ship something of quality. So I would say if you go to book publisher route, that is why Manning Press, all of these people are really good to work with because they fill in the gaps and they'll tell you, do not try to get this thing

perfect, just write and then use the whole iteration step to do it. And as long as I had that, I kind of felt confident later on that it was going to get finished because there was finally a team behind it. In this case, when you propose the idea, do you have to kind of send a chapter or a draft? Well, I had some trust, right? Because at that time, I was the chair of OSCON, which was the big O'Reilly open source conference. My name was kind of out there publicly, you know, talks, you know, I kind of had a brand next to me. And it's kind of had a brand next to me. So, and it's kind of like anything, if someone that is like a known quantity, respect of the community, high profile,

there's nothing better for a book publisher to have someone with a name, a brand, an audience, and an area of expertise that's unique in the marketplace. And I was proposing a book where there was none that existed anywhere, you're going to get a lot of support from that. But let's say you don't really have some of these attributes, right? You don't have a good public profile. You haven't built that audience. You're kind of an unknown entity. Remember, the book publisher has to put a lot into this as well. They got to pay people to edit book covers, printing press, the whole nine. So they have to be calculated about some of the risks that they're taking here. The other part of it, book covers, printing press, the whole nine. So they have to be calculated about some of the risks that they're taking here. The other part of it, I think, is what are you writing about?

Some people are like, I want to write the 7,000th book about Kafka. It's like, bro, listen, it's too saturated for someone to really kind of organize around it because just the potential for it succeeding is a little more challenging so you got to be real careful about uh about how you approach that so talking about building an audience for you like as you were giving these talks that some of this became a little more organic where organically people were interested in what you were saying they started following you and now you have a really big audience. Do you think engineers should think about being intentional about this?

Like today, they are amazing at what they do, but this is not something that, like they don't put themselves out there for a lot of reasons. As we discussed earlier, I don't have anything interesting to say as one of them. But is this something that they should be intentional about? I don't know if I read it somewhere or heard it somewhere.

It was, I used to care what people thought now i care even more right because the lie we tell ourselves is i don't care what people think about me so you're lying don't lie you care because i think now so there's two things here i don't care if you think I'm successful or not, because I can't, that's subjective. Right? And then I'll stress myself out way too much trying to hit your definition of what success is. So I'm not in that game. But I do want to be a kind person. So if I get feedback from a person that I am not that, then I'm willing to make adjustments to be the person I want to be. So

I do account for that feedback loop. I'm not good at the intentionality around growing my audience. There are some people, they got spreadsheets, they know the number of followers they're getting, who's dropping off. I'm like, I don't, you know, I don't, I don't want to do that because I think once you start talking for the audience, this is where I think things can go wrong. I've seen people get on social media and you might do something like JavaScript sucks, right? Maybe you're just frustrated that day. You know, you, you miss types because you're coming from a programming language that has

types that will help you. You know, you ship this thing, then JavaScript doing some undefined behavior. It's like, how does anyone use damn JavaScript? And you go on Twitter and you say, JavaScript sucks. And it blows up. I'm talking about, you get 10,000 likes, 2 million retweets, reads, you know, it's crazy.

And then you watch the news, you know, CNN, and this week on tech, JavaScript sucks. And people are texting you, it's like hey, man, your tweet is blowing up. And you're like, yo, I've never been this famous before in my life. You know what I'm tweeting tomorrow? Why it sucks. And so now you become the JavaScript sucks person. And people will keep cheering and cheering.

And then one day you're going to wake up happy as hell. You're happy. But you got to be mad today for Twitter. Because people want more of that negative energy. Because if you say, hey, guys, I'm happy today. I finally found why JavaScript is so flexible. I was trying to do something really hard I take back what I said nah no no no

no man you posted beyond team I hate JavaScript forever you're a traitor I am unfollowing you I used to think that you were authentic but now you said this nah I don't follow this guy anymore so now you're like oh okay

I need to fix this right I need to fix this. Right? I need to fix this. So you delete the other tweet and you say, I was just joking. JavaScript. What are we doing? You don't want that because then you become a slave to the audience. What I've been trying to do is I don't even tweet as often as people think.

There are days, multiple days, I don't say anything because I don't have anything to say. I'm too busy experiencing life. There's a musician named Maxwell. He had a phenomenal album. He has songs like This Woman's Work. There's so many albums. He had this amazing album, and it took years between that album, I think he won some awards, and the next album, people are like, what took so long? He said, because I had to live. You have to live and love if you're going to write love songs. You can't just be writing back-to-back albums because some albums require lived experience in order to tell these new stories. And so for me, typically when I tweet is because I'm talking to someone and I say something in the moment that I think is worthy of sharing with other people. Or maybe it's something I learned or I'm going to go kick the tires on a new thing and now let me go and rephrase it, that whole learning in public thing.

So I think when it comes to intentionality is you should be intentional about who you are online. If you want to be pretending, then you need to be intentional about who you're pretending to be. Because a lot of people online are pretending that they have everything figured out. So they only try to tweet smart stuff the whole time. So, OK, now you got to pretend to be the smartest person all the time. It's not sustainable. I try to be just as authentic as possible and appreciate that there's a part of this community that says Kelsey gets to be authentic and uses a normal voice. He doesn't have to pretend with us. So some days I care about inflation getting out of

control. Some days I care about rust versus go and I'm going to try it and put my notes out there for people to judge and tell me I don't know anything. And so you just need to be very careful about what it means to put yourself out there like that. I don't post my family if people have a note. I don't, my private life, I try to keep roughly to myself because that's not what I'm trying to put out there and portray. But I do think your voice is important. So let's get to the other side of this equation. When I got my first Twitter, it was probably like 2012. I just became a full-time engineer at Puppet Labs after working in the enterprise using Puppet in production. And I'm sitting at this desk and then we're starting to do these little puppet conferences. And people's like, hey man, you should probably get a Twitter

to tell people where you're going to be or what issues you're working on. And I was like, oh no, man, people who use social media, they're just showing what shoes they're buying. I don't want to be any of those things, man. I'm not. I'm okay. And I was like, all right, let me create one. And so I created a Twitter account. And I'm just kind of posting some of the stuff we're working on engineering.

Like, hey, did you know Puppet can do this? Or, man, I ran into this issue with the Inet system. And I started just posting things. And then you get your first 10 followers. You're like, man, it's over, man. I might quit and just go full time. You think you want to go full time on Twitter? And I was like, nah, let me just keep using it to broadcast to the world

what I'm working on, what I'm facing challenges of. But then your audience does start to grow. And you have to pay attention to who's in the audience. Because then you'll get someone like, wow, this person follows me. Hmm, why? You know, what do they care about? But the thing that I've noticed is that your perception of who you are outweighs your resume. Full stop. The last 10 years, maybe the last 15 years of my career, no resume required. No fill out this job application.

Tell us about what you, no, people are like, no. I had an interview with Microsoft and an executive recruiter reached out to me. It's a different process. They're not saying fill out this job. The executive recruiter says, hey, listen, we've been thinking about bringing on talent. All these things is very flattering

because they know what they're doing. This is a very strategic hiring process. And I'm like, okay, do I have to give a resume? Because I don't have a resume. I didn't even have LinkedIn. I just created a LinkedIn again the other day because someone wanted me to review some founders for due diligence. And I'm like, man, I got to create a LinkedIn account. So now I have one.

There's nothing there. So don't ask me to imitate to be connected. Oh, man. Sorry, sorry. But when they reached out, they're like, no, we know who you are. And when I heard that, I'm sitting there like, wow. I've seen that from other tech companies. They kind of see me in the community, especially when I went to go work at Puppet.

I was already contributing to the open source. So it's like you're already working with those people. So that whole work in public, learning it creates this reputation especially when you start to get into things like solving hard problems or you're on a podcast and people get to hear you and one thing i learned about when you operate in public you're always interviewing there's someone that's going to listen to one of your podcasts and be like you know there's some people like man i don't think kelsey really knows this stuff he just looks like a tech influencer that just knows how to copy paste say the right things but then when you hear the stories and you hear the nuance he's like nah you're not talking about unicode and

byte arrays unless you know yeah and then that becomes the new perception like yeah i don't think kelsey tech influencer i think he might know what he's talking about because now there's evidence, right? Can Kelsey write code? Like, just go to GitHub. What are you talking about? The code is on the GitHub. And so I think when you start to build up this personal persona, that is your resume. So back to your original question, should software engineers be intentional? Like 100%. You are, you're intentional about your code base, and you yourself have a public resume that should rival the paper resume. The biggest takeaway from the last conversation was when you were like, oh yeah, you know, I got a bunch of things lined up,

thought about rescheduling the podcast, but I was like, you know, just do it. And now every time, I kid you not, like, well, I'm like, ah, you know, it's on my calendar, but I said it you know just do it and now every time I kid you not like well I'm like ah you know it's on my calendar but like I said it like two weeks ago I don't really want to do it now I just have your voice just like playing in my head being just like just do it um and this time I think because you know in the background like we've been trying to grow this podcast as well and one thing that I think we're like kind of struggling with is trying to kind of you know we want to tailor it towards like to the audience right but at the same time we also want to kind of keep true to like what we actually care about like you know who we want to talk to what we want

to talk about and i think finding that balance is kind of tricky at times like if you look at the data sometimes right it's too few data points right so it's hard but i think authenticity uh like you said i think it's a huge takeaway of exactly like if we're like trying to pretend in order to cater to sort of what we think the audience cares about without actually caring about it then we have to carry that on and yeah that's bad news bears i mean the truth is authenticity does not guarantee success and and that's everyone should be okay with that, right? I mean, if you can financially afford it, and I think that's the biggest challenge. Because when you see someone that you know is being inauthentic having success,

like it could be a coworker that's tweeting, and you know their code is terrible. You know they're on a performance review plan you know they're not a good engineer you are on the review panel you can't believe they hired this person and while you over here working solving issues they're on twitter talking about the day in the life of a software engineer and you're reading their tweets like this guy is about to get fired why are people liking any of this stuff like what the hell is this how is this working so you go on there and you say some actual authentic thing and people like boo unfollow this guy's talking about facts and you're sitting here like i don't understand

the social media game so authenticity isn't a guarantee of success but boy when you hit being authentic it's sustainable because you don't have to pretend out right and I think that's the thing so look you know you're right there is an audience some audience draw their attention to certain things but if you can give them something that you all actually believe in then then the work becomes very easy to do right you're not like hey who is the most controversial guest we can bring on to try to get more views? Like, you don't want to get into that game.

I think that has been one of the filters we've had on the podcast is we'll talk to people we are interested in talking to. We'll ask the questions we are curious about. And some of the friends have asked at times, like, well, why don't you bring on so and so and it would be great to talk to that person like well we just don't know what to ask and i don't have any questions for that person anymore so i completely agree with you in terms of keeping it sustainable and part of being authentic and it may broaden out you know i think at some point

there is value in a person that i've heard interviews from thousands of times, but it's a different interview when they get interviewed by you. Oh, yeah. Right. You may have a different set of questions they've never been asked before. So but that just that will come naturally. Yeah. OK, coming back to what you have the Postgres driver, it's a really well said thing. Like if you say this to someone, it clicks. It clicks in terms of what you're trying to describe. I recently saw a tweet from you, I think sometime in the last couple of weeks. Oh, yeah, it was about perplexity and Google search, for example. Like when Google search is like the index on a book versus perplexity is like the cliff notes.

But you got to trust cliff. When I read that, I chuckled. I was like, well, that's really well said. So when you put out these tweets, is this like an initial thought that you had? Or is there more that goes into putting out a tweet like that? Or is it an instinct that you've just developed over time? My confidence level to say that I understand something, I don't believe it unless I can explain it in simple terms.

You know, because a lot of the stuff we work on is like, how does a for loop work? I know I can write it, but what's happening? What is the instruction set? What is the compiler doing? Why does it break sometimes? There's so many things that

just work that you don't understand. And so when we try to explain things we don't understand, for example, someone wins the lottery for $500 million. And then they go around giving financial advice. Hard to lose at all. You should just buy this stock. It's like, wow, man, how much are you worth?

$500 million. Actually, when you ask them at that time, they say, how much are you worth? I'm worth $400 million. It's like, what happened to the other $100 million? Oh, okay. I lost a lot of money in the stock market. It's like, why didn't you tell us you won the lottery and you don't know anything?

And I think this is what happens when you don't actually understand what's happening. So for me, when I think about perplexity, I'm asking like, why would I use this over just Google search? I'm like, what is the difference between these two things? And then you say, well, what does Google do? They index the internet and they try their best to just say, this thing is over here. This thing is over here.

You click on it and then you go there to get the rest of the context, like a book index would. So if it's like a book index, then what would perplexity be in that analogy? And these analogies help you really frame it. And also the thing that you do with these analogies is, given my audience, when you put this out, the people that work at perplexity will say, you don't know what the hell you're talking about. That analogy doesn't work at all. And so I'm risking a lot when I throw that out there because I'm saying, I'm trying to take something so complex and simplify it to a sentence or two. And then I remember the people from Perplexity was like, yeah, that's a good way to sum it up.

One dude, he chimed in on a comment. He said his grandfather was Cliff, the actual Cliff. And he talked about his grandfather wasn't the only writer of all the Cliff Notes. He would go get college professors and other domain experts that would summarize these books and content and produce the Cliff Notes, and then he would allow them to bear his name. And if you think about what Perplexity is doing, they are doing the same, right? They're summarizing things. Hopefully their models have enough domain expertise. And then we have to trust Perplexity's name that they're going to summarize this stuff correctly,

because if Cliff and I start being too far off, then we can't trust the whole brand. And so being able to do that kind of knowledge compression, because I have people that work at the school district that follow me on Twitter. I have people that are seasoned engineers or just starting out. And so when I think about my audience and also the way I think, when I get an analogy that works and I can test that analogy and then the feedback is like, okay, that is a good way to summarize it. Especially when I get feedback from the people who work at Perplexity AI. They say, yo, this is a good analogy. It really makes me feel like, okay, I think I'm starting to understand where we're going

with this. In this case, you're willing to risk that too, of being wrong in this case. You have an analogy. In this case, Perplexity folks are agreeing with it which is great there could be the alternative where they come back and say well kelsey this is not really how this product works but it's something that you're open to and i think for but then it starts a conversation right which then you get to learn more which yeah i don't have any fear anymore i mean i've been doing this so long that my mind now tries to simplify anything. When you're doing advisory work, it's an hour call. We don't have all day to try to come up

with a way to give very succinct advice, right? So they got issues, they got input, there's an agenda. And when you can come back with a really succinct path forward, the light bulb just goes off for people. And one thing I'll do, and you probably see in some of my live events, I'll say a thing one way, and people look like, and then I hit them with the analogy, and they're like, oh my God, I get it now. And since I'm reading the room, and a lot of these analogies come on the fly, then the light bulb goes off.

And I was like, you know what, I like this skill. And I used to joke with some of the distinguished engineers at Google, they would write these 20 page white papers like Brian Grant. He would write these and they're beautiful too. Like if you really want to have a thorough investigation of a topic, some people are really good at writing the 20 pages. So I'll read or skim it. I'll talk to Brian and I'll just do a tweet. And I remember there was one tweet because he wrote this really nice piece about config management and orchestration and how they differ and why they're so challenging. And a lot of it came down to the imperative nature of infrastructure as code. And I was like, the difference between, and I was like, Kubernetes

isn't infrastructure as code, it's infrastructure as data. And when you have infrastructure as data, that means you can build pipelines. I can take the semantics of a pod, give it to Helm. Helm can manipulate that data structure, give it to an emission controller. That can manipulate that data structure and land in Kubernetes. And then the entire ecosystem of controllers and operators can operate on the exact same data model. And you now have coordination. And you're always left with a common API. Infrastructure as code and config management is totally different.

You have to write something like maybe an HCL or Puppet or Ruby if you're using Chef. And you have to know the entire syntax before you can manipulate anything. And you're manipulating the wrong layer. In the world of Kubernetes, you're implementing essentially the bytecode, the thing that the thing will be executed no matter what. But in the other tools,

you have to manipulate a thing that you don't have an idea how it's going to come out. If you change an if statement in your puppet code, you have no idea what that's going to compile down to what result you're going to get. And so none of the tools are interchangeable. You can't pipe puppet to chef. It doesn't work. They're independent islands.

But in the case of Qube, and you start to say infrastructure as data, you reframe the whole problem and you think about chaining together tools very differently than the automation world infrastructure as code. So Brian Grant looks at this like two sentences and he's like, yeah, that's what I'm trying to convey in the 20 pages, right? Now, look, you still need the 20 pages. I don't want anyone thinking that, hey, you can need the 20 pages i don't want anyone thinking that hey you can excuse the 20 pages but for a lot of people it's the spark that makes people want to go and

investigate deeper and then they can substitute or augment their knowledge with the 20 pages but i found that you can inspire people really quickly if you can kind of get to the point and just give them the tools they need to go investigate further. That is definitely a skill. It reminds me of the Transformers paper. I haven't read it fully. I started reading it. It's like, attention is all you need, for example. My wife introduced me to that, and I was like, that's pretty interesting.

When you put it like that, it makes me want to go and actually read it instead of if there was another technical title that said, here is a 15-page paper, go read that. 100%. Okay, so Kelsey, we are coming towards the end of the conversation, and you've been very kind with your time and all your experiences as always. We really appreciate that. Before we wrap this up, a couple last questions.

So we talked about technical advising we talked about writing technical books and in both of these cases one thing that kind of stood out is having a business mindset of sorts as an engineer where even if you're technical advising for example you need to do that too you need to think about the business to give advice to the company you're working with. True for jobs as well, like if you're working at the current company. In case of book writing, it's again thinking about that business aspect. In your opinion, what are the things that engineers could do or think about to use their technical skills outside of the nine to five to actually

grow in any dimension? Could be technical, could be financially, could be starting a business, doing something on the side. A large part of society, unfortunately, has no time, will, ability to strategically think about what happens next. And it affects more people than you can imagine. Imagine someone that, and you've seen people like this. What are you doing? I'm going to work. And 100% of their cycles is about what train to catch. You got to be safe on the train.

Got to get there on time or you're going to get fired. If I get a 15 cent raise, does it mean anything? Because it may not do anything. What more can I afford with 15 cents an hour? It doesn't even change the trajectory. And so you're just, I got to get there on time. And I hate this job so much that I can't imagine making it better. So I just tune out. And so they only think of five minutes ahead. That's it, five minutes ahead. So what happens when you think this way? If someone bumps into you on the train,

and you're only thinking five minutes ahead, you may push them back and say, hey, why are you bumping to me? Because you're still thinking in five-minute increments. Now they hit you back, and all of a sudden you're in a fight and you get arrested and you're late for work and you get fired for being late for the second time. Now you have no money, you're evicted,

you can't afford a lawyer. All of these things spiral from just the fact that someone bumped to you on the train because you didn't have this analytical branching. So when we think about being an engineer, even though people aren't really paying attention, luckily you have this analytical mindset. And even then it's underutilized because at work you're just like, I got this bug and no one's going to be satisfied until it's fixed. And we have a time boundary. So luckily you have math and science and you have these pragmatic tools like the ability to write software. And so you're constantly solving puzzles every day, all day. That is the expectation of you. Problem, solve the problem. So in essence, a software developer, typically just a person solving problems. Luckily for us, we have much more well-designed problems

to solve, almost like a jigsaw puzzle. This puzzle has 1,000 pieces. These are the corner pieces. Look, we'll even give you a photo of what it looks like if you do it correctly. And software engineering is a lot like that. We're typically given a vision of what the end state looks like. And so we just do these jigsaw puzzles, putting together the right tools and pieces until they fit, and we ship it. And if you think about outside of your job, if you're actually paying attention, because I think the thing that software developers do is they tune out the real world. They don't look at the people on the train. Some people have never caught the train because they never had to deal with public transit in their life.

And so for them, they don't understand what the problem is. Why are people complaining about public transit? Just buy a car. Because they're too far from the problem. They don't see the picture on the box. So a lot of times you got software developers with these amazing analytical skills, these abilities to solve some of the world's most complex problems. And then they take that and they just bottle it up and then that's it. So in the real world, since they're not paying attention,

maybe because they don't expose to enough of the problems. And so they don't even apply themselves. So what we see more of isn't, you know, how to apply these skills. Like you're not even paying attention to the problem. It's like, you know, sometimes you're, you know, you get it, you're busy. You got too many tickets. You're like, look, man, if they, if they really want this thing to be blue, I don't care. Like, I'm just going to do it, right?

The ticket says you want it blue. I change it to blue. I shift it. What's the problem? And you haven't thought through the big, big picture. So I think when it comes to a software engineer, you have this amazing set of abilities to do this. Then you start to pay attention. Don't drive your car and try to catch the bus to your job. And you'd be like,

it's not possible. Why? There are no bus stops. I have to walk two miles first. That's a problem. Maybe your neighbor really does need a bus. And you notice that your neighbor's paying $30 to get to work at a job that only pays $50,000 a year, that's $60 a day back and forth. A large percentage of their income is just going to getting to work and back again. And so that person, how would you solve that problem if you paid attention to this scenario?

You would say, hmm, where could we put a bus stop? So you use your analytical mind and you look at the map, the drive map and say, hmm, if I were to solve this problem, where would I put bus stops in a way that's going to be safe for the, oh, I know that there's no sidewalks outside of our subdivision. So putting a bus stop here with no sidewalks doesn't make any sense. That's dangerous. The person's going to get hit. So now you're an engineer. You got to solve the problem now, right? Because typically we can't run away from the Jira ticket. Once that Jira ticket gets assigned to you, you need to solve

that problem. But you don't have to solve the problem by yourself. You can get help. The QA team, the product manager, the support team. Society is the same way. You have city council, you have engineers. and a lot of times if you go to the city council meeting, if you go to the places where they're planning these things, because a lot of that stuff is public information, you can say, hey, our area has grown by a population of 3,000. On average, 1% to 2%, 5%, 10% of these people would prefer public transit. We've asked them. And I've looked at the current bus routes, and I've looked at the most optimal path.

If we just had a bus stop here, here, and here, then people in my community can actually take the bus to work. And now that you've presented this design doc, then it becomes an implementation detail about when and where and how to prioritize. You can do this for any other aspect of your life, your health, a nonprofit, a family member that doesn't understand. You know, they're broke all the time. It's always asking you for $20. It's like I can totally give you $20. But maybe if we just made a budget so I can see where your money's going, you won't need the $20. And so as a software engineer, this is how I kind of think about the world.

I was so appreciative of learning these analytical abilities because when I used to work in fast food, it was more of like thinking linearly about things. I get paid on Friday. I will pay my bill. Don't get fired. Then I can continue to do this until I'm 65. But when you start to think about like branches, if this, then that, and you start thinking about optimizing and then there will be bugs and there's something you can learn from this feedback loop and you start applying it to your real world, people notice you just think differently. So when someone bumps into me in the train,

Kelsey, you have too much money to be fighting. If I fight somebody, win or lose, I am going to court and they're going to take my money away from me for some assault charge. That's what happened. I'm going through that whole branch prediction when someone bumps to me on the train. I'm going through that whole branch prediction when someone

bumps to me on the train because I'm thinking through this. So that's just kind of my advice for anyone that's an engineer of how you can leverage this. The takeaway here is you got to pay attention to the real world. And based on our salaries, we are shielded from so much of reality that we don't necessarily point our skill set at the actual problems in society, especially the ones that live outside of a computer screen. For sure, for sure. That's very well said. I think that's a great place to bring this part to an end.

Kelsey, as always, thank you so much for joining and sharing everything you did today. It's always a pleasure to talk to you. And we do hope that we can continue these conversations in the future, too. Thank you so much for your time. Awesome. Thanks for having me. Thank you, Kelsey.

Hey, thank you so much for listening to the show. You can subscribe wherever you get your podcasts and learn more about us at software misadventures.com. You can also write to us at hello at software misadventures.com. We would love to hear from you. Until next time, take care.