The first month you like, man, I'm about to write a book. Woo! I'm crazy. I'm not number four, you like, man, I'm not finished, bro. Wow, 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-authors in there writing, adding chapters, and then you can review. Welcome to the Software Misadventures podcast. We are your hosts, Ronak and Guang.
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. As of so, it was all about startup eviting.
In this part to you of the conversation, we get into Kelsey's experiences about 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.
Transform to Kubernetes, that transform 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 off this, but just don't know where to start?
They're like, I don't have anything interesting to talk about. But when you, 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? I've got that. And so it then delays you, right?
Especially if we're talking about engineers, 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.js, expresses your framework of choice, you build these APIs, which 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 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 on the database, and after some digging, you see UTF-8.
You're like, what's UTF-8? What does that have to do with any... You look at your client libraries, you look at your JSON serialization tool, you look at Ingenx, 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.
So 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 terminated 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 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. And you check in the code bug fixed. Done. You learned a lot. That's it. So what is learning in public? Learning in public could be as 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 poor request. Now the person reviewing the poor 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 is just like, you know, text format equals UTF. Hey, that doesn't teach anybody anything. Someone just said, I don't know, man.
That's what you needed to do to fix it. There's a whole lot of that, by the way. Yes. So learning in public is that patience to say, hold on, stop. It took me two days to learn all of these fundamentals. Let me put it in the issue. And now that it's in the issue, it's in public. The code 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 do 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 had to explain to the customer or explain to other people in 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 this 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? Slah 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 coup con. I didn't say the big national conference. I'm saying the local meetup, whether same two people talk every day, right? 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 this situation we just talked about. So you did the commit message. You've educated the Jared 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 we'll return to clients. So I'm just going to walk through an issue that I had to troubleshoot. And what I learned about unit code versus ASCII and why it's important. So you go give that talk at a local meetup. This 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. And 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 then 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 CIP and submit to some large conference. When the time comes from that, then you do it at the 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. And when you're telling the story, I can like sharply imagine like my ex co-worker Ben who was 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, like whatever he's presenting, he 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'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. What's the stories are right in front of you? And 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. Like, dude, what? That's not normal, bro. That's something else. Don't tell all the stories.
The other thing that I would just say is that I think the added benefit of actually going that extra mile in the commit message or the meat talk or even a block 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, nobody didn't ensure 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 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. But you've written a book as well. So we're curious to know your thoughts. What does that experience like?
So Kubernetes comes out, I'm contributing, I'm working at Corolless 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, you know, 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 lived at Pods and found the killer well, 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 covers. They pick an animal for you. 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 well to be my cover and they're like fine. So you put together a draft, an outline. Other things I wanted to cover. 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 cup. Right?
So I'm 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 something pages of a 220 page book before I realized I needed some help. So cool authors, Brendan Burns, Joe Beta, 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 out that analytical stuff. Well, especially his experience working on things like Bork. 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 clear. And then you get the editors come in and they clean it up, make sure all the formatting matches the style of a Riley 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. And a company will pay for exclusive access just so they can host that book as 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, they'll usually they have to seek your permission like, hey, we want to let you all know we're going to translate this work into a different language. You know, 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. 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 rollities. Right? Because there's something about people wanting you to stand somewhere for two hours. That you can sell 5,000 books and wouldn't make as much as I would make on a book signing.
So that in person thing is like an 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? I'll give you an example, different people have different prices, but I usually charge like keynote prices. My keynote is 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 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 in 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 of an in and under 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 boobyah, a book signing. So that's just kind of how that worked. 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. 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 of terms of like that book is a product, but you probably have to do the other things around 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 co-authors. So maybe one co-out there wants to go off and do, you know, a 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 and Kubernetes. We have services, ingress, right?
When I started writing the first book, there was no ingress. So he came and added all of these things. And most of the times, 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 leads to charge. Volume three, we added a new co-author, a latch in from Microsoft, right? He worked that day as 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 hundred-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. 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. Like, you can write microservices, but here's my ping-y. You shouldn't. Here's what that looks like. Here's how I would approach it with a Go code base. 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 see all the things you want. You're going to cut it down. If you think about it, there's a famous book, the K&R, who is it's a, Kerney and Richie, Dennis Richie, the vendors of C. They wrote the C book. You've never seen it like a white book, but a blue C on the top. That thing is 100 pages. For a long time, they call it the C book. It is the book about C. Here's C. It's a high level programming language. They were describing it this way.
They show you how to write. Temperature apps, temperature conversions, how to do all this stuff, how to compile all these things and appendix in the back. It had a whole appendix about what these words mean. But the book is very concise. I think if you're going to do this as an engineer, do not torment yourself. Get very clear on the idea you want. If you want to add more later, do a volume two. Do a volume three. These books have life cycles.
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 the things that you didn't get a chance to write about that you can then do an author series or video about, but it's a business. When you were writing, did you think about giving up at any point, maybe after the first hundred pages, you were like, you know what, this is too much.
Yeah, in the beginning, because once you start talking about all the formatting, when you write for a Riley, they have a really good publishing system. It was get based, largely like just kind of asky doc, kind of mark down blend type of thing. 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. So then you got to 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 kind of stressed out about these things. And then like I said, you know, the first month, you're like, man, I'm about to write a book. I'm not finished, bro. Wow, 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. So I think for the first time, having a co-author isn't terrible. A lot of people have shadow authors anyway, right? Those ghost writers that are doing a lot of these biographies where you see someone's name on it. And they're not really writing the whole thing. So it is just a lot of work.
But yeah, I do think you start to think about giving it up. But look, again, having Joe Biden and Brendan Burns and the support of like Arali, 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 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'll tell you, do not try to get this thing perfect, just right, 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 chapter or draft? Well I had some trust, right? Because at that time, I was the Chair of Oskon, which was the big Arali 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. 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 author, 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 I think is, what are you writing about?
Some people are like, I'm going to write the 7,000th book about Kafka's like, bro, listen, it's too sad for someone to really kind of organize around it because just the potential for a succeeding is a little more challenging. So you got to be real careful about how you approach that. Talking about building an audience for you, like as you were giving these talks, some of this became other people more organic. Where organically people were interested in what you were saying.
They said, following you and now you have a really big audience. Do you think engineers should think about being intentional about this? Well, like today they are amazing at what they do, but this is not something that 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. Is this something that they should be intentional about? I don't know if I've read it somewhere or heard it somewhere.
I used to care with people thought, now I care even more. Because the lie we tell ourselves is, I don't care what people think about me. 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. Then I'll stress myself out way too much, trying to hit your definition of what's successful. I'm not in that game. I do want to be a kind person.
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. 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, dropping off. I'm like, 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. Maybe you're just frustrated that day. You miss types because you're coming from a programming language that has types that will help you. You ship this thing, then JavaScript doing some undefined behavior. You're just like, how does anyone use damn JavaScript? You go on 20th to JavaScript sucks and it blows up. I'm talking about you get 10,000 likes, two million retweets, it's crazy.
Then you watch the news and I'll see you in this week on Tech, JavaScript sucks. People are texting you. Your tweet is blowing up and you're like, yo, I've never been this famous before in my life. Know what I'm tweeting tomorrow? Why is that? 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 here 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. No, no, no, no, man. You pause to be on a team. I hate JavaScript forever. Your trader. I am unfollowing you. I used to think that you were authenticated but now you said this. No, 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. And you say, I was just joking, JavaScript sucks. What are you doing? You don't want that because then 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, anything in the same, too busy experiencing life. There's a musician named Maxwell. He had a phenomenal album.
He has songs like this one in work. There's so many out. It's 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. 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 and 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 okay, now you've 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 her normal voice.
It 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. My private life I try to keep roughly to myself because that's not what I'm trying to put out there for trade.
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 was 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.
That's 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. I'm not, I'm okay. And that was like, all right, let me create one. And so I created a Twitter account and I'm just kind of posting some of this stuff we're working on an engineer and you're like, hey, you know, did you know Puppet can do this or man, I ran into this issue with the init 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, let me just keep using to broadcast to the world what I'm working on when I'm facing challenges of. But then your audience does start to grow. 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 fail out this job application. Tell us about what you, no, people like now. I had a, I had an interview with Microsoft and an executive recruiter reached out to me, right? It's a different process. They're not saying, fill out this job.
The executive recruiter says, hey, listen, you know, we've been thinking about bringing it 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 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.
So now I have one. There's nothing there. So don't ask me to imitate, to be connected. Oh, man. Sorry. Sorry. Sorry. 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 see you 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'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's like, man, I don't think Kelsey really knows this stuff. He just looks like a tech influencer that just knows how to copy, pay, 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 and byter rays unless you know. And then that becomes the new process. 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, you 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 your 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 them under things lined up, thought of rescudeling 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 like I said it like two weeks ago, I don't really want to do it. No, I just have your voice just I point in my head and just I just do it.
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, will 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, too few data points, right? So it's hard. But I think authenticity, 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 that new spares. I mean, the truth is authenticity does not guarantee success. And that's everyone should be okay with that, right?
But 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 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. 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 and 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? Like what the hell is this? How is this working? So you go on there and you say some actual authentic thing and people are like, boo, unfollow. This guy is 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. That boy when you hit being authentic, it's sustainable because you don't have to pretend. 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 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. Oh, I think that has been one of the filters we've heard 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 of us at times, like, well, why don't you bring on so and so. And it would be great to talk to that person. 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. 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. Okay, coming back to what you said, makes a little sense.
Now in terms of tweeting, for example, or even conference talks, I've seen you have an incredible skill to very succinctly describe things. And I'll take an example from this conversation itself. You mentioned something about span of being the Gmail of databases, for example, if you have the Postgres driver, it's 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 perfect for flexibility and Google search, for example. Like when Google searches like the index on a book versus for flexities like the Clifnodes, but you got a trust cliff, when I read that, I chuckered and 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 do you act?
Is there more that goes into putting out a tweet like that? Or is it an instinct that you've just delivered over time? That 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's 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 sometime?
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. And then they go around giving financial advice. How to lose it all? You should just buy this stock. It's like, wow, man, how much are you worth? $500 million. Actually, when you asked him at that time, they say, how much you were, and we're $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 just 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, 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. But if it's like a book index, then what would 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 comma. He said, his grandfather was Cliff. The actual Cliff. Wow. And he talked about his grandfather wasn't the only writer involved, the Cliff note.
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 notes 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 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.
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 this product works, but it's something that you're open to. And I think for them. But they start the 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 sick sync device, right? So they got issues, they got input. There's an agenda and when you can come back with a really succinct path forward, 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 will look like, and then I hit in 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, he wrote 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 those 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, I was like, Kubernetes isn't infrastructure as code is 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 is 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 byte code. 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. Or either independent islands. But in the case of Q and you start to say infrastructure as data, you reframe the whole problem and you think about chain together tools very differently than the automation world infrastructure 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. 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. 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.
It's a reading. 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 of itself. 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.
Or before we wrap this up, a couple of 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 a technical advising, for example, you need to do that too. You need to think about the business to give advice to the company 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 9 to 5 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 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, you got to get there on time, you're going to 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 have for 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 under utilized because at work you're just like, I got this bug and almost going to be satisfied until it's fixed 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. Some 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 1000 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 in-state looks like.
And so we just do these jigsaw puzzles, putting together the right tools and pieces into the 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 have 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, if 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 how to apply these skills. You're not even paying attention to the problem. It's like sometimes you get it, you're busy, you got too many tickets. You're like, look, man, 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 shit the 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 buy, 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 is 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 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 then you 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 pit, oh, I know that there's no sidewalks outside of our subdivision.
So put in a bus stop here where 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 Jiro ticket. Once that Jiro 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. One 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 route. 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 because of 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, their broke all the time, was always asking you for $20. It's like, I can totally give you $20.
And maybe if we just made a budget so I can see where your money is 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 to plan it to your real world. And people will 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, when are 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 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 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 softwaremissadventures.com. You can also write to us at hello at softwaremissadventures.com. We would love to hear from you. Till next time, take care.