How to become a rockstar in software: the Kelsey Hightower way

Marc (00:04): Welcome to DevOps Sauna Season 3. 

Kelsey (00:10) The trick is: you have to be patient, you have to willing to go deep and high, and you have to able willing to do that over time in a consistent manner.. 

Marc (00:23): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:27): I've been to depths that remain classified and Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom.

Marc (00:37): In DevOps Sauna Season 3, we'll explore platform engineering, and the people and cultures that make it happen.

Andy (00:43): Enjoy your time in the DevOps Sauna.

Marc (00:48): All right, here on the podcast this week, we have a recently distinguished individual. I'm so happy to have Kelsey Hightower on the podcast today.

Kelsey (01:02): Happy to be here.

Marc (01:03): Kelsey, I met you at The DEVOPS Conference - Copenhagen, which was just a couple of weeks ago. I hadn't really followed you too much before, I guess I saw you in our DEVOPS Conference earlier this year. But I remember: everybody was really excited and Andy was really excited and when I heard your name, it's like the kind of the name of a rockstar already, it's like your presence kind of comes. Have you become famous?

Kelsey (01:31): It depends. It's all about maybe the circles in which I move. The only time I ever felt famous, like, look, when I go to a tech conference, you know, I get the thing that I appreciate when people come up and say, hey, I would like a picture or hey, could you sign my book. And that's to be expected. In the tech community, we tend to show a lot of gratitude towards people who help us on our tech journeys. And I do it myself, if I see someone, maybe I learned something from them. And it's common for me to go up and say, "Hey, I really appreciate that blog post that you wrote, it helped me understand a particular thing." But the one time I really felt famous out of like 10 years of those type of encounters. We were in Las Vegas. I took my wife, her first time in Vegas, a couple of years ago. And we were just going up and down to Las Vegas Strip, seeing all the hotels, all the attractions, and I'm sitting there trying to take a selfie with me and my wife behind one of the famous buildings in Las Vegas, and I'm struggling, I don't take selfies all the time. Someone got off on one of the trains that you know, get you up and down the strip. And he saw us struggling. And he had an AWS t-shirt on. But he was like, "Hey, can I take a picture of you all? Do you need help?" And I was like, "Oh, for sure." And so I give him the phone and he takes pictures of us. He's doing a really good job, multiple angles. And he has the camera back. And I'm ready to just move on from there, thank you. And he's like, "Hey, mate," he's from Australia. And he said, "Hey, can I just get a photo with you? I love the work that you do. Everyone in Australia is a big fan." Even my team mates at AWS. And he poses with me and he takes this picture. He's smiling ear to ear. And I glance over at my wife like, "See babe, I told you, I'm famous."

Marc (03:21): It's really interesting that when I was talking about that you were going to be at The DEVOPS Conference - Copenhagen. And a lot of people they got really, really excited. And a handful of people had seen your work, and we're familiar with technically what you're doing. And then I remember one person, they were saying, "Oh, yeah, well, I saw an interview with Kelsey. And he seems to be kind of like a one trick guy. Like, he kept kind of steering the conversation back to what is current, his current pitches." And then when we got to The DEVOPS Conference - Copenhagen, I noticed that everybody that came up to you, you directed your energy at them so sincerely, it was like they were the only person in the room. And they would ask you a question, and you would give them everything that you knew, the context, the things that have changed, the history, maybe you had spoken about in a previous talk or something. And then I kind of realized, not only the sincerity, but how many people's lives you can affect.

Kelsey (04:26): Yeah, when people say one trick, if it was 2007, my one trick would have been my work on Python and distutils. I used to commit access directly to distutils and virtualenv. These are the tools you use when you're building your Python code. And I was all about that. I was dialed in. I was on the mailing list. We were going back and forth with the code. I was at PyCon. I was at the after events contributing. If you would have said Kelsey in 2011, it would have been all about Puppet and config management, or my contributions there in the DevOps movement. And that was the first time I started speaking at conferences. So if you saw me speak at a local meet-up, in Atlanta, Georgia, I was probably talking about Puppet and learning Ruby coming from a Python world. And eventually, I would go on to work at Puppet Labs, and lead some of the engineering efforts there. So for that three to four year span, that was my one trick. But during that time, I was also learning about networking. I was part of a team that put Puppet agent on networking equipment, so that you can actually manage Puppet agents on networking. And during that time, I also taught myself the Go programming language. And in that transition, if you saw me at GopherCon, the very first one, there was an impromptu moment when I jumped on stage and said, "Hey, can I try emceeing the conference? I want to bring the energy levels up." And no one knew who I was in the Go community. And I was like, "Hey, I'm just a system administrator doing Go stuff. And I would love to be your moderator for the rest of the day." And I would go on to take on a big role in that Go community bringing new people on board. I also gave a keynote at that conference, and also came up with this open-source project called confd. That was written in Go, it's more of a lightweight configuration management tool. And that became the foundation for console template from the HashiCorp team. If you remember me from the HashiCorp era, you saw me speaking at every HashiCorp, North America, and the ones in Europe. And it was all about Vault, Nomad, all their tools nice to contribute to terraform. And so I think when people look at my career, yes, I am hyper focused on going super deep in anything that I'm working on, from code to docs, to talks to everything in between. And so I think when people think about this current era, the current chapter of the Kelsey book, you see a lot of Kubernetes, you see a lot of container stuff. But the truth is, I've been working on serveress for the last four years. And a lot of the serverless stuff is taking things that I've learned. And so when I think when people say Kelsey keeps steering things back, the truth is, I'm taking fundamentals from the past, the things that work really well, and making sure that they find their place in the future by enhancing some of the new things that come out. And so I'm a fundamentalist, I'm a pragmatic person. But I'm also a person. I have a lane that I swim in, and so I give people depth. So when you ask me a question, I try to give you the book ends. And so some things will sound familiar. But you got to pay attention to the thing in the middle, you got to read the book all the way to the end, to get the full story. And you might miss that plot twist.

Marc (07:32): I've never known anybody like you, but I've known some people that are really good at focus. If you look at every genius that's ever been, everybody from Tesla and Newton, they were all really hyper-focused on the thing that's in front of them. Are there any keys to doing that? I know it's a part of you, I can see it, I can feel it as part of your energy. But how can the rest of us learn from your ability to focus on something so much that wherever you go, you either get to the top of things, or you get everybody involved in it or you raise the energy level? How do you do that man?

Kelsey (08:31): I think there's a binding thing that helps you. You need a core, a foundation to stand on in which to explore. If you don't have a foundation, then you're just wobbling all over the place. So to get to a steady platform allows you then to observe everything in any direction while you're on that platform. And so for me throughout my career, I've chosen to find a steady ground in which to explore. You can pick almost any programming language, and then that can become your foundation. So whether it's Python, or NodeJs, or Golang. Once you pick your platform, then you start to understand I'm going to study compilers, I'm going to think about the code that they generate, I'm going to think about performance, I'm going to think about memory management. And so for me, I pick that platform, and then I go into an adjacent area. So for example, these days, I'm learning a lot more about secure software supply chains. But guess what, I can explore that new territory from the foundation of Golang. I can talk about Golang module system, I can talk about Golang's dependency management, and how vulnerability scans work in a language that doesn't have a traditional package manager, and everyone's pulling code from GitHub. And then I can expand on that and that what gives me perspective. So while I can go to a security conference, and I don't need to pretend to be a security expert, but I can be someone who writes Go code that puts a security lens on top. And so that allows me to expand in these new areas and just branch out and so that's where that comes down to. And you always ask people, it's almost impossible, it can take a lifetime to really become a master in any one of these disciplines. And so if you move around too much, you never get that opportunity to click one or two levels deep. So whatever you're doing right now, you should look about going two levels above the stack. And if you do that often enough, you're going to more than likely hit the human-layer of whatever you're working on. There's a point when you go so high up the stack, you get into the philosophy, you get into how humans use the thing. And then you also need to go two levels below the current thing that you're working on. So if you're working on web servers, eventually you're going to find yourself below then to the HTTP specification below, then to TCP IP, if you want to keep going lower, you'll go into operating systems, then you get into hardware and hardware accelerators. And if you go up the stack, you'll get into the people who actually write code, and manage the equipment that does all those things. And so I think the trick is, you have to be patient, you have to be willing to go deep and high. And you have to be able to do that over time in a consistent manner.

Andy (10:044): So you kind of follow the 'improv' rule of always saying "yes and": you take what you understand, take what you're good at, take what you're focusing on, and apply it to a little bit new. And that way, expanded over time and gradually, always grow it out more and more and more.

Kelsey (11:00): 100%! When I used to play sports, you don't forget everything you learned last year, you play the game, and then you tweak and you improve, and you build upon. That's why they call it muscle memory. As you work out, your muscles are starting to adapt to the type of exercises you do. If you want to get stronger in a new area, then you may have to change the exercise, but the old muscles don't tend to go away. 

Andy (11:20): Well, that might be how you play sports, but I'm on a slightly different level.

Kelsey (11:26): Well, I'm 41 years old now. So we're probably not doing it to the same degree, but in my earlier years, that's the way it works. And I think it's so unfortunate that people come into tech for the first time, and they only look forward. And they try to reverse-engineer everything that's presented to them in the present. Without understanding that a lot of these things we have in tech today, the things that actually work, tend to be compatible with the current world and the world that came before it. And so there's a lot of value in going back and reading those old mailing lists, understand the fundamentals. And then when you take a look at the new thing, you're like, "Oh, this is 85% like the thing that came before and here's the 15% that's different."

Andy (12:07): Marc and I have many times gone to a consulting gig, talk with a new customer, and they're like, "Oh, there's this whole new thing, this whole new idea, whole new framework, whatever." We've both been around for a while. And we look at it and say, well, it's basically this with a little bit different polish, and he changed that term over there. I see what you got, okay, we can work with this. Knowing the past makes the techniques of present so much easier to understand and you can start to predict the future.

Kelsey (12:32): And that my friends, we call experience.

Marc (12:34): There's an interesting connection. I don't know if you've heard of gear acquisition syndrome. But photographers want more cameras and more lenses. I'm a guitarist, to it's more guitars and pedals and amplifiers. And if you're a sports person, there might be other things. And one day, there was some clickbait recently, and they said the cause of gear acquisition syndrome is revealed. And then I scroll and I go and I wait in the ads, and I scroll and I wait. And then here it is the cause of gear acquisition syndrome: lack of skill. So if you don't deeply focus on the thing in front of you, then you're just going to be changing all the time. And you just kind of gave some new vectors on this in the tech world that I hadn't really thought about before. So people want to learn everything and they end up not doing... you can take an adjacent thing and it ends up being a rathole. And they could get lost in 'red pill mode' and every adjacency. But having this core technology every one of those.

Kelsey (13:36): when I think about that, there are some people who can only afford one guitar. That's it. That's all they're getting. And they learn how to repair that guitar. They learn how to make it do things that I didn't know you could do that with the acoustic guitar. It's like, well, it's the only one I got. So I have to learn how to play different things. And if you hold it this way, I know that's not how you're supposed to hold it. Or if you just dump some stuff inside of the guitar, it's going to make a different sound. And that's the way I got it to do things It wasn't designed to do." And I do think having that constraint can be a forcing function to acquire new skills that were not required before.

Marc (14:14): In the art world, the constraints make the art.

Andy (14:17): I was going to say, constraints sometimes feel like limitations and restraints. But if you look at it, from the perspective of: it gives you something to focus on. It can be very liberating to have the constraint of do something with this.

Kelsey (14:32): Did I mention I was a minimalist? I've adopted that philosophy for almost every aspect of my life of just this extreme level of focus and finding comfort in that, if I will just focus on this one thing, I don't need to learn everything. If I can just focus on this one thing...and look I can ask questions of others who have chosen to take an extreme focus in their area and borrow those ideas when required. But I think it's why I do find my career so refreshing is because I can wake up in the morning and say, "It's okay, I can just focus on this one thing." And of course, there's a time to change your focus. And I'll do that when the time comes, but I won't sit around distracted figuring out what to do, instead of doing something.

Andy (15:15): And you're talking a lot about focus, and you said, and taking it up to the human level. And when we met in Copenhagen, and after your keynote, we went to the room next door, and we sat there for about 30 minutes or something and one on one with Kelsey and we were talking, it was really cool. And it's just 100% focus, you closed your laptop, and I felt so amazing. And then we went out and you started walking the floor. And I noticed you're giving exactly the same focus to every single person who you met. And it was just incredible. And thinking about it makes me exhausted. So where can you find the energy to do that.

Kelsey (15:53): When you go to a conference, even if you're the keynote speaker, I know what I'm signing up for. It's not just to give the keynote and then go home, that that is not really what you're doing. People come to a conference for a reason. Think about it, someone decided to take time off work, or time away from their family, they pay their money for a ticket, and they're coming with this agenda in hand. And look, if you're in a fortunate situation where people come to see you specifically. Wow. And so if someone has gone through all of that, the minimum I could do is give them my time in that moment in that situation, to return the favor. Also, when I just think about myself, I've learned that it's really important to appreciate who you are. Appreciate this opportunity that you have every day. When you wake up, it's an opportunity to be better than the day before, you have an opportunity to be helpful to others, whether that's just your core family unit, or your colleagues at work, or just anyone else in society. That's an opportunity that a lot of people don't have. And so out of that respect for myself, out of my respect for the opportunity, when you see another human being-and remember, I'm the type of person who believes all humans are somewhat of an extension of the same core. Period. Whether we share enough DNA, whatever your beliefs are. But humans have so much more in common than the differences we fight over. And so when I see another human being I'm looking to me and an extension of self, how would you treat yourself? And honestly, I've learned how to treat myself well in terms of respecting all aspects of being a human being. So when a human shows up, yeah, you're right, I'm closing that laptop. I'm looking at them and listening very intently to what they're saying, "Hey, I'm a new person. I'm just starting out my career." And I know the best thing I can do with that person is motivate the hell out of them. You are in a fortunate situation that you get to bring all of this energy, I'm going to tell you do not let anyone extinguish this flame in which you hold right now. And so what I want to tell you, I'm going to tell you all about the good parts. Now look, there's some bad parts, but the good parts, they're more of those. And here's how you manipulate the good parts. Here's what they look like. Here's what happens if you twist them in this direction. Here's what happens if you twist them in that direction. And I'm going to be honest with you, I haven't twisted all the parts in every possible direction. And then that's where you come in. You don't have to be a copy of me. You just need to be yourself and let the whole world see it. And then next time, I'll be in the audience. And I'll be watching you give the keynote.

Marc (18:23): Wow. I'm not sure that anybody's left us speechless before, but it was. I'll ask him a different kind of thing. Having been to the places that you've been at, I mean, technical capabilities and communities and bringing things to kind of a new level. Do people ever feel they have to take a 'virtual swing' at you or try to prove something like when you're in these conferences and communities?

Kelsey (18:52): Yeah, depending on what my title is, in a given year. if I'm in dev rel, this person is just copying and pasting someone else's code. Oh, he's saying the things that Google told him to say. I don't even think he knows how this stuff works. And I remember being at a conference right around the time Kubernetes came out. And at that time, I'm contributing to the core of Kubernetes at the source code level. I was one of the few people that didn't work at Google or Red Hat, that had commit access. I earned that commit access through keystrokes. Also at the time, I'm working at CoreOS, the very company, who created things like etcd, based on the Raft white paper, and I used to sit side by side with my colleagues, troubleshooting, how Raft was implemented. I’ve seen things that are never described in the white paper, but only in reality. And we also built things together like CNI, the container networking interface, those original designs, me and another person working it out side by side, in a small office in San Francisco. And then we would go talk about it at meetups on Friday. But at the conference, they only saw Kelsey the dev-rel person, there is no way he knows how any of this stuff works. And at the end of a presentation, you welcome people to ask questions. And some people use that time to make a statement. And also statements are welcome. And the statement just walked on the lines of that's not how that works, it worked this way instead. And as mad as I wanted it to be, I understood how much power I actually had. This person is confused. I actually know the answer. And to the benefit of the rest of the audience and seeing this person, as an extension of myself, I do have this thing in the background that says, "Do you really know what you're talking about? Then prove it." I do that to myself. And so I wasn't surprised that another person would do the same thing because I already put myself through that challenge. So I can be prepared. You're not going to catch me off guard. And look, there are times when I just don't know. And I will just say that, but not this time. I knew exactly what was going on. And so what I decided to do was pick a part of the comment in a way that everyone else could benefit to and say, "Hey, you believe that in terms of CAP theorem that this system was designed as a I don't know, CP system versus an AP system, meaning what would happen if there was a network partition in a Kubernetes cluster?" And I was like, "Well, I can tell you from experience that if there's any problems, the whole system will stop. It's going to favor availability in order to preserve consistency. This is not like MongoDB, or maybe some other 'eventually consistent system', we have very strict consistency. And I'm going to show you. So let's boot up at etcd, I'm going to go back to my laptop. This is the first node, this is the second node. And this is the third node, we now have quorum. Now according to CAP theorm, then, everything should be fine, we have no problems. And consistency is a tradeoff. Now I'm going to bring down one of the nodes. We have a network partition. But we have quorum, so everything still works. Now, let's remove the third node. Now we only have one, we can't be consistent. And guess what's going to happen. As I run this command attempting to put new information into this SCD database, it doesn't work. We've now lost availability to preserve consistency. This is your answer. This is how it works. And this is how you go from theory to reality." And you can see the person walks slowly back to their seat. And they probably ask themselves, "Why the hell did I make that statement? Well, I could easily ask him to show me after the talk."

Marc (22:27): Or ask it in a way that preserve their face, I guess.

Kelsey (22:31): And sometimes, and I practice a lot on social media, I give people a lot of leeway to say listen, "I hear your pain." I can read your frustration from the words you chose to respond with. But my guess is you don't want to behave this way. Not by default, this knee jerk reaction is coming from the wrong place. And you'll see me sometimes on social media just take a step back and say, "Hey, why do we want to talk to each other this way? Really, by default, we have so many ways of engaging with each other, that this one is the most toxic and unhelpful." And a lot of times we will resolve things that are DM and either a I would highlight "Hey, I'm really glad we were able to work this out." And there's no reason to really do this. I can just ignore the comment and just keep moving. But I do think it's important to see good examples in the real world of a disagreement and a resolution. That just makes sense as a blueprint for others to follow.

Marc (22:31): Hi, it's Marc again. We recently hosted Kelsey at The DEVOPS Conference - Copenhagen. If you would like to hear his fantastic keynote about supply chain security, I'll leave a link in the show notes. Now back to the show.

Marc (23:50): Is there anything that you do to tune this all out? Or how do you baseline after giving all this energy and having all this intensity, do you do something to turn it off or to tune it out. 

Kelsey (24:02): Sleep, go to sleep on time. There's something about going to sleep with a clear conscience, actually. We get this moment every day. And if you felt like you've done all the right things during the day, during the week, during the month, during the year, then you get to sleep. And then when you wake up, you don't feel burden for the things you may have not completed before. And so I try to take the sleep part seriously, I've earned my rest. So you give all this inch energy. Be present. So when you're in front of people, you got to go all out! But I know, they're going to go get the sleep. And that's when I was just like to just crash and go into a deep sleep and feeling like I've earned my rest and so I take it. The other thing is, again, it just goes back to this opportunity. Like I am so, so fortunate to be in a position where people care what I think. To be in a position where people elect to follow me whether that's on Twitter, or maybe the thoughts that I'm experimenting with in public. That's just such a fortunate place to be in. Why wouldn't I like try to seize that opportunity. So that's my baseline. My baseline's just very simple, human centric way of working. And that's it. And I rinse and repeat, and practice it every day.

Andy (25:22): I usually look forward to going to sleep just because I'm so exhausted that I have to sleep. But looking at it as a reward, that's an interesting angle. Maybe I'll try it. Maybe I have to try that.

Marc (25:36): Andy and I were recently talking about routines, and you mentioned routine. And I was at Andy's looking over his shoulder at his glorious workstation. And I saw something about the AndyOS. And I'm like, tell me about the AndyOS, Andy.

Andy (25:56): So I got this idea. I don't remember exactly where I would give credit if I could, but I heard it from somebody probably on a podcast or somewhere a long time ago, where I came up with this AndyOS. And what I do is I describe in a git repository, just a readme file, it could be any text file. This is the way I work. 

Marc (26:19): As one does. 

Andy (26:21): Obviously, in a git repository. So I described that when I have obligations coming in, I put them in this system as my task management system. This is how I prioritize my tasks. This is how I decide what I'm going to put off, how I organize my projects, this is how I'm going to manage my projects. And it changes from time to time, sometimes a bit too often because I like shiny new tools and toys and whatever. And I don't always follow it, but it gives me a North Star. So then I just call that my AndyOS. And then it's basically a description of the routines I try and I aspire to follow. And by reviewing that every once in a while, I realized that well, this one I would no longer do, but I really wish I would. And that one I don't do. And I'm glad I don't, let's change that. But just the idea of you have an operating system, Andy, tell me about that was a interesting discussion with Marc.

Marc (27:26): So let's try it again. If you had to describe your operating system, Kelsey, how would you describe it? How do you go about your day?

Kelsey (27:37): Yeah, I do think about task management. So I try to limit those. I'm one of those people where it has to line perfectly. I don't like gaps, like you got a meeting that ends at 11:35. Who are these people? That start meetings five minutes after and then like, you know <laughs> So then I have to try to put in these gaps and I do things like put lunch on my calendar. So I try to reserve space to make sure that I'm learning or taking breaks or eating food. And so I like to kind of see, so I can kind of commit to memory so I like to pre-allocate things, if you will. So I look at my calendar says all right, I'm going to pre-allocate my mental energy. I know where it's going to go and I know how at a pace myself just to make sure I can finish strong. And so the calendar becomes like the core of that. And then I keep things like spreadsheets for like, "Hey, upcoming speaking engagements, what themes will I be covering?" And I tend to think about though there are big narratives that I'm trying to move. And so all of these tasks, I'm trying to make sure I understand what the big program is to. And the big program that the big binary that's running, what is it trying to complete? What's the request, what's the response. And so that's the time where I really step back and say, "Why am I running this program at all? Do these tasks make any sense? Or do they not contribute to the whole?" And if I were to think about my operating system, I'm really trying to make sure that the big tasks have the big thing that I'm trying to solve. All the tasks that are related to that, those are the ones I'm working on. If I don't need the other ones, then you got to remove the calendar entry.

Marc (29:12): Which goes right back to your focus if it's not contributing to the big thing.

Kelsey (29:17): Just having a big thing feels so good because when you do make mistakes, when I'm trying to learn something new, and it just doesn't click, I can always go back to how much progress I've made on the big picture. And then I can find comfort in this, like, "Hey, this is just one task and the whole, it'll be fine. We can just restart the process, right?" If fails, I look at the error logs, try to figure out what happened. And then you just restart the process. And then you keep going from there.

Marc (29:43): Awesome. Couple more things. I don't know if you're a 'trendy' kind of guy, but are there any kind of up-and-coming things or any kind of trendy things that you're interested in at the moment, or that you see or predict?

Kelsey (29:58): Well, I try to pay attention. And there's a lot going on in the Wasm space. And it's very interesting. So this thing that starts off in a web browser, we have all these tabs open in our web browser. In order to make those things safe, we need to have a really great sandboxing technology. It would be a terrible thing if JavaScript running in one browser tab was able to do something to another web page in a different tab, like drain your bank balance. And so we need some really strong sandboxing technology to pull this off. And it needs to be fast. And it needs to be lightweight. And it turns out, you don't need to implement a whole virtual machine like a Linux kernel to make this work, just enough to run network functions or things you would do on a typical web page. And so from that big sandbox, I think Wasm is born this idea can we take this show on the road, if we were to take the sandbox out of the browser, and we were to put it into a CDN, a content distribution network, a place where people stored images. Maybe you have a company like CloudFlare, that can also do things like terminate your DNS, your SSL certificates. But then there's more stuff you want to do at the edge, just like in a browser. if you think about it, the browser's the ultimate edge, it runs right there on the user's device. Stepping back from that, that's when you get into Cloudflare and CDNs. But shouldn't you be able to run logic there too like authenticate a user, personalize a webpage from previous settings that you saw before? We don't need to go all the way to a back-end server to do that. So what sandboxing technology could we use to run a very simple limited set of functionality that's safe, so you bring in Wasm. And it becomes the ultimate plug-in architecture. So instead of Lua, or creating your own plug-in system, we can just bring in this runtime that lets you write not only in JavaScript, but C++, Rust, Golang, anything that can target this Wasm compiler. So now I'm sitting back and says, "Wow, look at all the people talking about Wasm..." I understand some of the use cases. It could be a better platform for things like store procedures and a database. So we don't have the write store procedures in these custom dialects. It can be really useful in the serverless world, where all you want to do is just process some data coming from an event. Okay, that makes sense to me. But then there's a few startups that are having ambitions bigger than that. One day in the future, they predict that you might write more full-fledged applications. So for someone like me, I'm like, "Huh, what would it take to do that?" Now remember, I like to act as a historian from time to time, where have we seen this before? Write once, run anywhere? Java! Sun Microsystems! And so you go back to your Java days, and I used to write Java back in the day. And you realize that the JVM had the same ambitions. You can write things that run on the JVM and Scala, there's Jython for people that like the Python dialect that can run Java bytecode. And the JVM kept getting bigger and bigger and bigger. And now we have specialized versions of the JVM to shrink it back down to be purpose built for things like cell phones or other platforms. And so now that I've seen this before, I asked is the Wasm team wanting to reinvent all of what the JVM does? Where do they stop? And so then you start playing with theories, maybe they can stop at a very small subset because they don't need to support things from 20 years ago, they can kind of stick to like HTTP based services, and network connections to things like databases, and then that's it. And so maybe, just maybe Wasm might be the thing that fulfils that right once run anywhere promise that Java made so long ago.

Marc (33:51): Awesome! So hey, two last questions. This is something we've been asking all of our guests. And I'd like you to think back to when you were young: what was the first thing you can remember that you wanted to be when you grow up?

Kelsey (34:04): Well, I would definitely say it had probably something to do with sports. When I was younger, I grew up in Long Beach, California. And that's a sports city: from high school to living in California, many sports teams, the Lakers, Los Angeles Raiders, it's a big sports town. And so as growing up, I think we used to play outside, eight hours a day. In the summer, as soon as I can go outside, I'm gone. And we go to the local elementary, and we play basketball all day, take breaks, walk around, and then come back and do it again. And so at that time, it was the best north star because you can go home, and you can see excellence on TV. And you can wake up in the morning and try to imitate what you saw on TV. And it was like the first connection of seeing growth and improvement as a young person, like, "Hey, I saw that move, I'm going to go practice it. And so when I get on the court, I'm going to test it out. And then, of course, I would play in like various leagues, I would play in school. And you can see this growth. Sometimes you win the award, sometimes you lose the game. I learned how to lose, I learned how to win. And I learned how to measure my success and get better over time. And so, of course, I picked various athletes. One athlete that I really admire was an NFL player called Deion Sanders. And Deion played two sports. He played pro football. And eventually he would play defense and offense. And then...there's one story where he, like real thing, he played a game and then took a helicopter to play a baseball game. All on the same day. And he had this in a week, they used to call him 'primetime'. And so he talked a big game, maybe he was very boastful, but he backed it up. Ooh did he back it up! And so I looked at that, not that I wanted to be a boastful person. Not that I want to mimic that. But the level of excellence that he expired to; I knew that was going to be the framework that I wanted to adopt. So even though I don't play sports, I take that same mentality of what does it mean to get incrementally better and then be able to back it up?

Marc (36:12): Really cool. Okay, I have one more. Was there a point in your path that you realized that you were on the right path? Or was there a point where you looked at a crossroads and realize that you needed to change the direction that you were headed?

Kelsey (38:44): Yeah, I was really happy when I was writing a bunch of code. I got into the Python community, I was working in the financial institution, I had just learned COBOL. So I can actually rewrite a lot of that stuff from mainframe world into this new world we were aiming towards, and a lot of it was being done in Python. So I'm learning how to write pack decimal libraries, parse older files. I'm really getting deep into this Python stuff. I'm even getting to the point where I'm having to use scientific libraries for performance reasons. And so I remember going to my very first meet-up and watching others speak. And I was like, I can do that. And so I went up there, and I gave a talk about Python. Now before, I'm just coding, coding, coding, coding. And then one day I decided to speak. And I started to talk about my philosophy of how I was learning the things I was working on. And I realized something: I was no longer limited to the team I was working on, the company I was working at. I was now being able to impact people that I have never met before. I was like, "This is freaking amazing." And I wasn't sure if I was good at it yet. It's a local meetup. They let everyone speak at the local meetup. Why not? But I remember that first time I took the stage at my first major conference was, the very first one, I think it was like PuppetConf 2012. And I go on stage, and I'm just trying to be myself. And I remember I'd let a few jokes into the presentation, even though I've never really seen most people even attempt something like that because it's a very risky thing to do. And the response I got back; it was this genuine response from the audience that we see you. And I was like, "Wow, I'm going to add this component to my tool belt. And I won't just be an engineer anymore. I'll be a whole person that happens to be in engineering."

Marc (38:17): And I have to say wholeheartedly, Kelsey, the world is so glad that you made that move. I think that you're one of the greatest people. And you make the world better just by being yourself. And it's been a real pleasure and an honor to have you on the podcast. And I think whatever positive reputation is out there, you absolutely deserve. So thank you so much. This has been absolutely amazing to have you here.

Kelsey (38:43): Thanks for having me.

Andy (38:45): And it's been an honor. Thanks so much.

Marc (38:51): Before we go, let's give our guests and opportunity to introduce themselves and tell you a little about us.

Kelsey (38:59): Hey, I'm Kelsey Hightower. I'm a distinguished gentleman working at Google Cloud.

Marc (39:02): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (39:08): My name is Andy Allred, and I'm doing platform engineering at Eficode.

Marc (39:12): Thank you for listening. If you enjoyed what you heard, please like and subscribe-it means the world to us. Also, check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.