Learning in public | Kelsey Hightower
Learning in public | Kelsey Hightower
Kelsey is a former Distinguished Engineer at Google
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! hello@softwaremisadventures.com
Transcript:
**Kelsey:** [00:00:00] the first month you're like, man, I'm about to write a book. It's going to be crazy, Month number four. You like, man, I'm not finished, bro. Why 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 authors in there Writing, adding chapters, and then you can review.
Welcome to the Software Misadventures podcast. We are your hosts, Ronak and Guan. 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 Guan here. Last episode, it was all about startup advising. In this part two of the conversation, we get into Kelsey's [00:01:00] 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.
**Ronak:** 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. Um, 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.
**Ronak:** It's an extension of that in a way. Um, many folks think about, well, I want to start blogging, posting on Twitter or giving conference talks. Um, 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.
**Ronak:** Uh, but when you, [00:02:00] I'm sure others would think differently, but they themselves don't have an idea.
**Kelsey:** 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. 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?
**Kelsey:** 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 back end engineer, you're using Node.
**Kelsey:** js, expresses your framework of choice, you build these APIs, this is what you do every day. One day you get an issue from support. music ends And it says, Hey, um, we're not returning Unicode. Customer names are coming out of the database and certain, [00:03:00] um, Unicode things are being stripped out and missing. So you don't know what's going on.
**Kelsey:** 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?
**Kelsey:** 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.
**Kelsey:** 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 [00:04:00] end.
**Kelsey:** 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.
**Kelsey:** So you fix it. You go to your library, you go to the parser. You say. Um, you know, text format is Unicode, right? And you check in the code, bug fixed, done, right? You've 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. [00:05:00] 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, you know, you look at the diff, it's just like, You know, text format equals UTF 8.
**Kelsey:** 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. Merge.
**Ronak:** There's a whole lot of that, by the way. Yes.
**Kelsey:** Yeah, there's 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.
**Kelsey:** The co reviewer is going to see it. Uh, 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 [00:06:00] 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.
**Kelsey:** And when they have to explain to the customer or explain to other people in support what they're doing, it 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.
**Kelsey:** 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, this is where I think a lot of engineers get thrown off. That sounds very simple to people with experience, right? It's like, oh man, everyone knows that.
**Kelsey:** I'm embarrassed that I didn't know it. So I'm not going to tell anybody,
**Ronak:** Oh, yes.
**Kelsey:** right? But if you want to be transparent, you go to your local meetup. I didn't say KubeCon. [00:07:00] I didn't say the big national conference. I'm saying the local meetup where the same two people talk every day, right? It's like, dude, this guy giving a talk again.
**Kelsey:** 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 JIRA ticket. And now you go to the meetup and say, Hey, look, I'm gonna give a very short talk. And as an engineer, that's been doing this for a little while. 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. It'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 [00:08:00] like, I work in ops and I never thought about any of this stuff. So they're educated.
**Kelsey:** 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 then tweeting about that talk or writing a blog post about that talk. So I think for you is don't 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.
**Kelsey:** Someone needs this reminder for someone. This is the first time that someone that. They can resonate with. It's 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.
**Guang:** Think it's super important, like the part you pointed out about being able to set [00:09:00] aside your ego, right? Not feeling embarrassed that when you're telling the story, I can like sharply imagine like my ex co worker, Ben, who's like amazing at this. One of the things that really jumped out to me is that, right, it's not that he's very smart, not just that he's very smart and he communicates super well, but he's, like, very humble.
**Guang:** And I think that also lends itself, right, to, like, empathy of, like, when I'm watching it, right, like, whatever he's presenting, it also makes me, like, oh, yeah, like, I can totally see Bing 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?
**Guang:** I'm like, oh, yeah, I sort of know like what's going on Yeah, i've seen this before but then, you know halfway through i'm like Oh, I didn't know like right like these are all the nuances that like go into it.
**Kelsey:** 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 [00:10:00] to At 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?
**Kelsey:** So I think some people are 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.
**Ronak:** 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, uh, or, or whatever you fixed wasn't just, or it just seemed to work coincidence.
**Ronak:** Uh, no, 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. [00:11:00] Um, you, you have written a few books. Uh, they'll say Kubernetes up and running is probably the one that at least I have read. Um, and. I saw that there were three editions of it.
**Ronak:** And in other cases, whenever 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.
**Ronak:** Um, But you've written a book as well. So we're curious to know your thoughts. Uh, what was that experience like?
**Kelsey:** So Kubernetes comes out, I'm contributing, I'm working at CoreOS. 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 like one of the best ways of really improving, uh, you know, knowledge, especially if you were [00:12:00] already working, you know, just kind of fill in the gaps.
**Kelsey:** 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.
**Kelsey:** They pick an animal for you, right? 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, I don't know anything about that. I just, I would like this whale to be my cover. And they're like, fine. Um, so you put together a draft, uh, an outline of the things I wanted to cover.
**Kelsey:** 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, 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 [00:13:00] sell a single copy, right?
**Kelsey:** 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 a hundred and something pages of a 220 page book before I realized I needed some help. So co-authors, Brendan Burns, Joe Beta, right? Two of the multiple founders of Kubernetes really brought in.
**Kelsey:** So I started the book saying, look, I wanna make sure it was very hands-on. I wanna 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?
**Kelsey:** Why did we do this? Why did we do that? Why do we make all these decisions? And Joe brought all that, 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 [00:14:00] of those styles blended together, right?
**Kelsey:** Cause we didn't, 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. So, and then you get the editors come in and they clean it up and make sure all the formatting matches the style of O'Reilly and then the book goes.
**Kelsey:** 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
**Ronak:** Yeah.
**Kelsey:** and a company will pay for exclusive access just so they can host that book is a bit of co marketing and so that's really good business when you can start to get.
**Kelsey:** Basically sponsors to, you know, put this thing out, drive demand for the book, a couple of sample chapters, [00:15:00] 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, every time they do that, they'll, usually they have to seek your permission, like, Hey, we're gonna let you all know, we're gonna translate this work.
**Kelsey:** 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 a hundred pages to realize that I need help to finish this thing.
**Kelsey:** 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 either.
**Kelsey:** 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 [00:16:00] 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 how this other kind of revenue stream book signings, I've definitely made more money on book signings than book royalties,
**Ronak:** Hmm,
**Kelsey:** right?
**Kelsey:** 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. So.
**Guang:** that work? Yeah, book
**Kelsey:** I'll give you an example. Different people have different prices, but I usually charge like keynote prices. My keynotes are 20, 000 to 30, 000 plus travel. Book signings are roughly the same for me. So if you put out a number like that, they order [00:17:00] the books, so you'll get some revenue from the book sales.
**Kelsey:** 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 600 or 700. 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.
**Kelsey:** 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. [00:18:00] Uh, maybe people pay to get in. So a lot of these conferences, people pay to get into these things.
**Kelsey:** 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 you, 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.
**Kelsey:** 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, uh, appearance fees, those kinds 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 gonna have to do the other things around if you really want to maximize it.
**Kelsey:** 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 [00:19:00] tricky because volume two may not be guaranteed to be written by you.
**Ronak:** Hmm.
**Kelsey:** Now your name stays on it because you know, most of the content was probably written by you and the other coauthors.
**Kelsey:** So maybe one coauthor wants to go off and do You know, second edition, they have the bandwidth to update the chapters. I think Brendan 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.
**Kelsey:** So he came and added all of these things. And most of the time you just kind of keep the splits roughly the same, you know, brand is not hurting for money. Just want to see the second edition out. I may do some reviews, but he largely leads to charge volume three. Um, we added a new coauthor, uh, uh, latch in for Microsoft, right?
**Kelsey:** He worked at days for a while, worked on things like helm and he wanted to do a lots of updates. So we added. there. [00:20:00] 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.
**Kelsey:** 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 coauthors, 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 hundred page book.
**Kelsey:** Stop. Don't, you don't need 200 pages. Maybe a book publisher needs 12 chapters or something like that. You probably need only a hundred pages. Just, 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.
**Kelsey:** But if I was 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, Very [00:21:00] straightforward. Like, 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 codebase.
**Kelsey:** 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. If you think about it, there's a famous book, the, uh, K& R, uh, who is it? Um, Kearney and Ritchie, Dennis Ritchie, you know, the inventors of C.
**Kelsey:** They wrote the C book. If you've never seen it, it's like a white book with a blue C on the top. That thing is a hundred pages. And for a long time, that was, they called it the C book. It is the book about C. Hey, 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.
**Kelsey:** Like, it had a whole appendix about what these words [00:22:00] mean. Like, that's, 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. Dual Volume 3, these books have life cycles and they don't last as long as you think, but think about the whole business.
**Kelsey:** 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.
**Guang:** 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 were like, you know what, this is, uh,
**Kelsey:** 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 this kind of ASCII doc, kind of markdown blend type of thing. And so, you didn't have to worry too deeply about the [00:23:00] formatting, but you did have to kind of line things up.
**Kelsey:** But I had a lot of code snippets in the book. And so then you gotta 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.
**Kelsey:** Um, and then, like I said, you know, the first month you're like, man, I'm about to write a book. It's going to be crazy, Month number four. You like, man, I'm not finished, bro. Why 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 authors in there Writing, adding chapters, and then you can review.
**Kelsey:** 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
**Ronak:** yeah.
**Kelsey:** And, eh, [00:24:00] 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 Beda, Brendan Burns, and the support of like O'Reilly, that is the value I think having a publisher.
**Kelsey:** Publishers do all these things like, I mean, they're so fast at writing when they do their past, 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 they'll tell you.
**Kelsey:** 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.
**Ronak:** In this case, when you propose the idea, do you have to kind of send a chapter or a draft?
**Kelsey:** 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 [00:25:00] of out there publicly, you know, talks, you know, I 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 the name, a brand, an audience, and an area of expertise that's unique in the marketplace.
**Kelsey:** 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.
**Kelsey:** 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, I think is, um, what are you writing about? Some people like, um, I want to write the 7, 000 book about Kafka. It's like, bro, listen. Is too [00:26:00] saturated for someone to really kind of organize around it because it's just the potential for us succeeding Is a little more challenging. So you got to be real careful about About how you approach that.
**Ronak:** So talking about building an audience for you, like as you were giving these talks, 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?
**Ronak:** Well, 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. Uh, as we discussed earlier, I don't have anything interesting to say as one of them, but is this something that should, they should be intentional about?
**Kelsey:** I don't know if i've read it somewhere or heard it somewhere. It was um, I used to care what people thought Now I care even more All right, because the lie we tell ourselves is I don't care what people think about me. It's like you're lying Don't lie you care [00:27:00] Because I think now, so there's two things here.
**Kelsey:** 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 more, 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.
**Kelsey:** 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 [00:28:00] types that will help you. You know, you ship this thing, then JavaScript doing some undefined behavior.
**Kelsey:** It's like, how does anyone use damn JavaScript? And you go on Twitter and you said, 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 and on CNN and this week on tech, JavaScript sucks. And people are texting you.
**Kelsey:** It's like, Hey man, your tweet is blowing up. And you 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, right?
**Kelsey:** 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 [00:29:00] today. You know, 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. You posted beyond team.
**Kelsey:** 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. So you delete the other tweet and you say, I was just joking.
**Kelsey:** JavaScript sucks. Ha, what are we doing? So 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 cause I don't anything to say. I'm too busy experiencing life.
**Kelsey:** 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 has this amazing album. And it took years between [00:30:00] 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.
**Kelsey:** 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 gonna go kick the tires on a new thing.
**Kelsey:** 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.
**Kelsey:** That they have everything figured out. So they only try to tweet smart stuff the whole time. So, okay, now you got to pretend to be the smartest [00:31:00] 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.
**Kelsey:** 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 gonna 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.
**Kelsey:** 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 Uh, 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 You 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 [00:32:00] people where you're going to be or what issues you're working on That's like, ah, nah, man people who use social media.
**Kelsey:** 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 You know, did you know puppet can do this or?
**Kelsey:** You Man, I ran into this issue with the in it system and you know, I started just posting things and then, you know, 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 when I'm, when 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.
**Kelsey:** Hmm. Why? You know, what did they care about? But the thing that I've noticed is that your perception of who [00:33:00] 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 know, people like now we, I had a, I had an interview with Microsoft and an executive recruiter reached out to me, right?
**Kelsey:** It's a different process. You did not say fill out this job. No, no, no. The executive, um, recruiter says, Hey, listen, um, You know, 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?
**Kelsey:** Cause I don't have a resume. I didn't even have LinkedIn. Like 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. Ha. So now I have one, there's nothing there. So don't ask me to. Invitate to be connected.
**Guang:** Oh man. [00:34:00] Sorry. Sorry.
**Kelsey:** When, when they reached out, they're like, no, we know who you are. And when I, when I heard that I'm sitting there, like, wow, I've seen that from like, you know, other tech companies, you know, they, they kind of seen you in the community, especially when I went to go work at puppet, I was already contributing to the open source.
**Kelsey:** So it's like, you've already working with those people. So that whole work in public learning public, 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 was like, nah, you're not talking about Unicode.
**Kelsey:** And byte arrays, unless you know, and then that becomes the new perception. Like, yeah, I don't [00:35:00] 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 you just go to GitHub. We were talking about the codes on the GitHub. And so I think when you start to build up this personal persona, that is your resume.
**Kelsey:** So back to your original question, should software engineers be intentional, like a hundred percent? You are, you're intentional about your code base. And you yourself have a public resume that should rival the paper resume.
**Guang:** The biggest takeaway from the last conversation was when you were like But 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 like two weeks ago, I don't really want to do it.
**Guang:** Now I just have your voice just like pointing in my head, being just like, just do it. Um, and this time I think, cause you know, in the background, like we've been trying to grow this podcast as [00:36:00] 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?
**Guang:** But at the same time, we also want to kind of keep true to like, will we actually care about like, you know, who we want to talk to? What do 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 You 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.
**Kelsey:** I mean, the truth is authenticity does not guarantee success.
**Guang:** And and that's everyone should be okay with that right like but
**Kelsey:** Yeah. I mean, if you can financially afford it, and I think that's the biggest challenge, because when you see someone that you know, as being in authentic, having success, like it could be a coworker that's [00:37:00] tweeting and you know, the code is terrible. You know, they're on a performance review plan. You know, they're not a good engineer.
**Kelsey:** You were 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 is like, this guy is about to get fired. Why are people liking any of this stuff?
**Kelsey:** Like, what the hell is this? How's this working? So you go on there and you say some actual authentic thing. And people are like, boo. Unfollow. This guy's talking about facts. And you're sitting here like, I don't understand this 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.
**Kelsey:** 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, [00:38:00] then the work becomes very easy to do, right? You're not like, Hey, who is the most, uh, controversial guest we can bring on to try to get more views?
**Kelsey:** Like you don't want to get into that game.
**Ronak:** Oh, no. I think that has been one of the filters we've had on the podcast is, um, We'll talk to people we are interested in talking to. We'll ask the questions we are curious about. Uh, and some of the friends I've asked at times, like, well, why don't you bring on so and so and it would be great to talk to that person.
**Ronak:** And I was 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.
**Kelsey:** And it may broaden out, you know, I think at some point, right. 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, right? You may have a different set of questions they've never been asked before. So, but that just, that will come naturally.
**Ronak:** Yeah. Okay, coming back to what you said, uh, makes a lot of [00:39:00] sense now in terms of tweeting, for example, um, or even conference talks, I've seen.
**Ronak:** You have an incredible skill to very succinctly describe things. And I'll, I'll, I'll take an example from this conversation itself. you mentioned something about Spanner being the Gmail of databases. For example, if you have the Postgres driver, it's a really well set thing.
**Ronak:** Like if you say this to someone, it clicks, it clicks in terms of what you're trying to describe. Um, I, I recently saw a tweet from you, I think sometime in the last couple of weeks. Oh yeah, it was about perplex, perplexity and Google search for examples, like when Google searches, like the index on a book versus perplexities, like the cliff notes.
**Ronak:** Uh, but you got to trust cliff. I, when I read that, I chuckled and I was like, well, that's really well said. So when you put out these tweets, um, is this like an initial thought that you had, or do you, is, is there more that goes into putting out a tweet like that? Or is it an instinct that you've just developed over time?
.
**Kelsey:** My confidence level to say that I understand something, I don't believe it unless I can explain [00:40:00] it in simple terms, you know, because a lot of the stuff we work on is like, how's a four 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 sometime?
**Kelsey:** Like, it's just, there's so many things that just work that you don't understand. And so when we try to explain things we don't, for example, someone wins the lottery for 500 million dollars. And then they go around giving financial advice.
**Ronak:** How to lose it all. Oh,
**Kelsey:** when you ask them at that time, they say, how much 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 you didn't 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 [00:41:00] search? I'm like, what is the difference between these two things? And then you say, well, what does Google do? Right? They index the internet and they try their best to just say, this thing is over here.
**Kelsey:** 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, if it's like a book index, then what would, what would perplexity be in that analogy? And these analogies help you really frame. 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.
**Kelsey:** 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, a good way to sum it up. One dude, he, he chimed in on a comment.
**Kelsey:** He said his [00:42:00] grandfather was Cliff, the, the actual Cliff. And he talked about his grandfather wasn't the only writer of all the Cliff notes. He would go get Um, 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.
**Kelsey:** 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 no 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 now 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 [00:43:00] that analogy.
**Kelsey:** 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.
**Ronak:** In this case, you're willing to risk that too, of being wrong. In this case, like 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, Um, This product works, but it's something that you're open to.
**Ronak:** And I think
**Guang:** But then it starts a conversation, right? Which then you get to learn more, which,
**Kelsey:** 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 you can come back with a really succinct [00:44:00] path forward.
**Kelsey:** It just 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 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?
**Kelsey:** 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. Like he, 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.
**Kelsey:** 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, um, 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.
**Kelsey:** And I was like, the difference [00:45:00] 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, and Give it to Helm, Helm can manipulate that data structure, give it to an admission controller that can manipulate that data structure and land in Kubernetes.
**Kelsey:** 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, uh, infrastructure is code and config management is totally different. You have to write something like maybe an HCL or puppet or Ruby.
**Kelsey:** 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, [00:46:00] you have to manipulate a thing that you don't have an idea how it's going to come out.
**Kelsey:** 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, right? They're independent islands, but in the case of kube and you start to say infrastructure as data, you reframe the whole problem and you think about chaining together tools very differently.
**Kelsey:** Then the automation world infrastructure is 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 excuse the 20 pages, but for a lot of people, it's the spark that makes people want to go and investigate deeper.
**Kelsey:** 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 [00:47:00] point and just give them the tools they need to go investigate further.
**Ronak:** 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. Uh, for example, my wife introduced me to that and I was like, that's pretty interesting. Uh, like when you put it like that, it makes me want to go and actually read it.
**Ronak:** Uh, instead of if there was a, another technical title, it said here is a 15 page paper. Go read that.
**Kelsey:** 100%.
**Ronak:** 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. Um, before, before we wrap this up, a couple last questions.
So we talked about technical advising. We talked about, um, 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, uh, where even if you're technical advising, for example, you need to do that too. You need to [00:48:00] think about the business to give advice to the company you're working with.
**Ronak:** 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? actually grow in any dimension could be technical could be financially could be right starting a business doing something on the side
**Kelsey:** 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 a hundred percent of their cycles Is about what train to catch You got to be safe on the train Got to get there on time.
**Kelsey:** Are you [00:49:00] gonna get fired? If I get a 15 cent raise Does it mean anything? Right because it may not do anything like what more can I afford with 15 cents an hour? It doesn't even change the trajectory and so You're just, I gotta 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 you bumping to me? Cause 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. [00:50:00] 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.
**Kelsey:** And we have a time boundary. So luckily you have math and science and. You know, 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.
**Kelsey:** Luckily for us, we have much more well designed problems to solve, almost like a jigsaw puzzle. This puzzle has 1000 pieces. These are the corner pieces. [00:51:00] 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.
**Kelsey:** 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.
**Kelsey:** 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. Um, and then [00:52:00] 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, they're Maybe because they don't expose to enough of the problems.
**Kelsey:** 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.
**Kelsey:** 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.
**Kelsey:** And you'll 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 [00:53:00] work at a job that only pays 50, 000 a year. That's 60 a day back and forth. A large percentage of the 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 patrol.
**Kelsey:** 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.
**Kelsey:** 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 [00:54:00] 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, cause a lot of that stuff is public information.
**Kelsey:** You can say, Hey, our area has grown by a population of 3000. On average, 1 to 2%, 5%, 10 percent 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, fit. A family member that doesn't understand, you know, they're broke all the time. It was always asking you for 20.
**Kelsey:** It's like, I can totally give you 20, [00:55:00] 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, I was so appreciative of learning these analytical abilities because when I used to work in fast food.
**Kelsey:** 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.
**Kelsey:** It's just, 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 [00:56:00] assault charge. That's what happened. I'm going through that whole branch prediction. When someone bumps into 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 gotta 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 skillset at the actual problems in society, especially the ones that live outside of a computer screen.
**Ronak:** For sure, for sure. That's very well said. I think that's a great place to bring this part to an end. Uh, Kelsey, as always, thank you so much for joining and sharing everything you did today. Uh, it's always a pleasure to talk to you. And we, we do hope that we can continue these conversations in the future too.
**Ronak:** Uh, and thank you so much for your time.
**Kelsey:** Awesome. Thanks for having me.
**Guang:** Thank you Kelsey.
[00:57:00] Hey, thank you so much for listening to the show. You can subscribe wherever you get your podcasts and learn more about us at SoftwareMisadventures. com. You can also write to us at hello at SoftwareMisadventures. com. We would love to hear from you. Until next time, take care.