Keith Pitt, co-founder and CTO of Buildkite joins the show this week to talk about his journey into building Buildkite.
Have you ever thought about building something because you assumed the product already existed?
In today's episode, we dig into this question with Keith Pitt. Keith is the CTO and co-founder of Buildkite and in this part 1 of our two part interview, we dig into starting Buildkite and Keith's journey in development.
Thank you to long time sponsor and friends of the show Linode for sponsoring today's episode!
Simplify your cloud infrastructure with Linode’s Linux virtual machines and develop, deploy, and scale your modern applications faster and easier.
Listeners of Developer Tea can now enjoy $100 in free credit! You can find all the details at linode.com/developertea.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
Have you ever thought about building something but decided not to because you thought, well, certainly this thing exists? That's the story that you're going to hear from today's guest. Today's guest is Keith Pitt. He is the CTO at Buildkite. My name is Jonathan Cottrell. You're listening to Developer Tea, and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. I'm very excited to talk to Keith in this episode. I hope you will subscribe so you don't miss out on the second part of my interview with Keith. Let's get straight into the interview with Keith Pitt. Keith, welcome to the show. Thank you so much. Thanks for having me on the show. I'm very excited to have you on, and I'm excited to talk about your journey as a founder, as a co-founder, as now a CTO. I'm a CTO at Buildkite. I actually did a little bit of digging, and I found that you worked once upon a time at Envato. Is that true? That's right. Yeah, that's actually kind of where Buildkite started at Envato. Oh, really? I did not know that. Yeah. Maybe this is a good segue into telling the story of Buildkite. Yeah, please. Get straight into it. So I was at Envato, and I was working on a tool there at the time called Microlancer. It's now known as Envato Studio. I think. And it was a small tool within the company, and we were using a hosted CI tool called Travis CI. And Travis, I'm a big fan of Travis. I love Travis. They do amazing things in the open source community. And this was, I think, seven years ago, seven or eight years ago. And this was during a time when the GitHub permission model was very simple. And that permission model was... If you connect one repo to a third party on GitHub, then the third party gets access to every repo on GitHub. And I was only a small team within Envato, and we were working on a small tool. And one day we did this risk assessment sort of workshop. And one of the questions we were asked was, do you know where your code is at all times? And as we filled in that spreadsheet, we had to answer no to that question. We didn't know where our code was at all times because we had a really good idea of where it was with GitHub, but we didn't know where it was with Travis. And so we were told, you know, the other teams in the company use hosted CI providers. We really want you to leave Travis and use a hosted CI provider. And I was really bummed by this because Travis was part of this new wave of next-gen developer experience type CI products. And I was used to tools like Heroku and GitHub, you know, the tools that had really modern developer user experience. But a lot of the hosted CI CD tools, like your Jenkins, your TeamCity, and your Bamboos, didn't have that. A lot of them were built before the iPhone came along. And so none of them really had that developer experience that I was really expecting. And so I went on the hunt. I was like, surely there is a tool. This tool that I envisioned. I had imagined in my head of a self-hosted CI CD tool that had a really modern dev experience. Surely this exists. And I went looking for it. And to my surprise, I couldn't find it. I was thinking, surely I'm Googling this wrong. Surely I'm holding it wrong. I'm holding Google wrong. Surely this thing exists. But it didn't. And so I kind of felt compelled to build it. I was thinking to myself, hmm. Maybe I'll try building something in my spare time. Maybe I'll spend a few weeks building something and see what comes of it. And that was seven years ago, seven or eight years ago. And I'm still building it to this day. But that's kind of how the idea came along. It was just, I had identified a problem in my own career and in my own job. And I set out to solve it myself. And I've always been a fan of building things. I've always enjoyed building things. I wouldn't consider myself an entrepreneur or a business person. But I think if you were to. I would write down the things that I have done in my career that probably are the labels that would be applied to me. But I just don't see myself as that. I see myself as someone who enjoys building technology, building tools and having fun with technology. Hmm. If you were to evaluate the landscape and let's say, let's say BuildKite didn't exist today. And you were to look at the available tooling out there. And maybe you find that there are some other self-hosted kinds of things. And would that have deterred you? You know, kind of trying to rewind back. If you had found something that kind of filled that need for you, would you have, you know, gone and built something yourself? Or was that really the critical kind of crux of the matter that it didn't exist yet and you wanted it to? I think if I had found what I was looking for at the time, I probably wouldn't have built it. I just felt compelled for this thing to exist because my problem, the problem wasn't solved. If someone had solved it already for me, I would have been great. I would have been very, very happy and over the moon. Because I'm way more about the problem being solved than solving the problem myself. Yeah. And so, yeah, I think that if the tool had existed, I probably would have used it already. But it didn't. So I just felt like the need to build it. So that's the story. It was this need that you had. And. You were able to recognize that you were able to see clearly kind of what you wanted to do. You saw the other, you know, competing or not even competing, but kind of the pieces of the puzzle, the different pieces of the puzzle. One did one thing you liked. Another did another thing you liked. But they didn't. You know, none of them did everything that you needed them to do. And it wasn't necessarily. I'm going to put kind of words in your mouth. It wasn't necessarily because it was a novel idea. It was because it was a mix of multiple ideas. At the same time, you were bringing together players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from players from a distributed team where they need to access the tool from home. A lot of these tools aren't really that great of being run on open internet. So a lot of them are sort of kept within VPNs or hidden inside offices. That's the self-hosted option. The other option is the hosted CI CD tools, your circles, your traverses, and those tools, you hand over all of your code to them and they manage the orchestration plane and the running of the tests yourself. The problem with that is twofold, but the hosted options are two major problems. The first problem is you have to hand over all of your deploy keys. If you want to do continuous deployment, which I'm a big fan of, you have to hand over your deploy keys to a third party, which for some organizations is a bit of a no-go. The second problem is that those tools only go so fast. If you go to their pricing page, you'll see this slider that only goes so far to the right. And you can only go so fast without there being a big sign that says, contact us to go faster. And I didn't want any of those. I didn't accept the cons of the hosted option. I didn't want to accept the cons of the self-hosted option. And so I was thinking to myself, surely there is some middle ground. And so I sort of set out to kind of cherry pick the best of both worlds and sort of create a mashup of what I thought would be the perfect tool. And that's how kind of how Billkart was born. And I wanted to zero in. I wanted to zero in. I wanted to zero in. I wanted to zero in on this idea because I think it's important to recognize, especially for engineers who are kind of thinking, oh, you know, I have this idea and it doesn't exist, but people can do it themselves if they go and, you know, mix X and Y, these two existing things out there. A lot of these ideas that tend to be kind of remixes of multiple other ideas together or, you know, taking one thing. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right.. Right. And so it's important to recognize that because most critically, I think a lot of people who are thinking about starting a business or they're thinking, hey, I might do this side thing. I might build a product on the side. I think a lot of them are thinking, oh, I have to come up with a truly new, completely novel idea or else nobody's going to want it. There can't be a shadow of this idea on the market. Otherwise, it's already saturated. Every idea is already taken and I have to come up with something totally new for it to be successful. And it couldn't be further from the truth. Yeah, that's exactly right. There's no such thing as a new idea. I think South Park said it really well. They have this episode called The Simpsons Already Did It. And there's a recurring joke where they have these themes or plots within the episode. But The Simpsons have already done that particular plot. It's the same with products as well. If you look at the big ones, Uber, Uber is taxis. But they sort of took it and did a mashup and made it better. Airbnb, hotels. But they've taken it, mashed it up and made something new. CICD, I didn't invent CICD. I didn't invent it at all. I just took the best of a bunch of really good ideas and put them together to create something new and a new product. And I think that's kind of what a lot of the tools are these days are just improvements of existing ideas. I think that, you know, I don't think Facebook will be around forever. There will be a better Facebook at some point. There will be a better Spotify at some point. There'll be a better Apple at some point. No one holds, you know, no one holds King forever. So I think it's a matter of just sort of leaning into those new ideas. If you think you have an idea of something, I would absolutely go build it. Because. And even if no one uses it, I think the building of something in and of itself is a journey and a lesson. Buildkite wasn't my first CICD platform. I have built a CICD platform before. I built one 12 years ago. It was called Jasper and I never saw the light of day, but we used it at my job. And I learned a ton of lessons around how to build this sort of tool then. And then it sort of went back on the back burner in my mind for four or five years. And then this problem resurfaced in my career. And I thought, well, now is the time to try it. And I don't think book out would have been as successful as it was if I hadn't already built a version of it long before that, that failed miserably. It's great to hear that because I can really relate in kind of a very small way. Before I ever started this podcast, I actually was considering starting a different one. Um, this was very, very early in my career and it was when podcasts were still quite young. And. My idea was. To, uh, to talk, you know, I was, I was mostly a front end developer at the time. I was going to talk with a backend developer and we would chat back and forth and essentially, uh, and I didn't even know who this person would be. I was just kind of, uh, uh, assuming that I would find somebody who would be willing to be a co-host and we would talk about kind of the differences or the negotiation points between the front end and the back end. This would have eventually, uh, and probably pretty quickly gotten old, right? Yeah. But, um, now, you know, fast forward a couple of years after that, and I decided to start developer T and it's interesting to see how these ideas that keep recurring or keep resurfacing, um, tend to be the ones that. Uh, at least that I I've heard from other entrepreneurs or other people who start things like podcasts or whatever, the ones that stick with you tend to be the ones that you're going to stick with. Uh, you're going to continue investing in that idea because it's something that has. At least you may have taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken engine for this game. It's kind of funny how when you look at CI CD and Billkite, the tool itself, it's kind of sort of like the engine for a video game really where the tests are the game and the platform is itself the you know, the tool. But yeah, one thing that I think that made Billkite successful is that I use the tools that I knew when I built Billkite. A lot of the people that I know who set out to build something often sort of tie that in with learning a new language or a new framework at the same time. And I feel like they end up getting stuck on learning at the same time as building a thing. And if you want to learn a language and sort of build a thing at the same time, that's totally cool. But if you want the tool or the idea to succeed, I think the best way you can make it succeed is by using the tools that you knew. And I'm a a I probably categorize myself as a Ruby on Rails developer. And I use Ruby on Rails to build Billkite. I think that if I was to have looked at Billkite's requirements today, Rails may not have been the right choice. But at the time, Rails was the right choice because I knew it. And that meant that I wasn't worrying about the technology. I was worrying about the idea and the implementation of the idea and how customers enjoyed the idea and less around the technical implementation. So I think that's a really good way to build a tool. No matter what you are building, you can build it on top of Linode. Today's episode is sponsored by Linode. And with Linode, you can simplify your infrastructure and cut your cloud bills in half. You can do this with Linode's Linux virtual machines by developing, deploying, and scaling your modern applications faster and easier. Whether you're developing a personal project or managing larger workloads, you deserve simple, affordable, and accessible cloud computing solutions. By the way, you can use the tools you have. You can launch Billkite on Linode because anything that works on Linux, it runs on Linode. You can get started with $100 in free credit for listeners of Developer Tea. You can find all the details at linode.com slash developer tea. Make sure you go and click the create free account button to get started. Linode has data centers around the world with the same simple and consistent pricing regardless of the location that you choose. So choose the data center nearest you or nearest to your computer. So if you're looking for a cloud computing solution, click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click the click button and click get started today. Thanks again to Linode for sponsoring today's episode of Developer Tea. Yeah, it's really interesting. I've come across this discussion multiple times, both on the show and in the real world of how do you pick... This is the never ending argument, especially for people who are in their jobs already. How do you pick a tool? Well, there's a lot to consider with the answer to that question. But very often, the answer is go with what you know. It's a good heuristic at least, because what it ends up providing is something that you're likely fluent in. And so whatever your most common thinking language is, is very likely going to be the one that you're most productive in. And with that said, there's also plenty of soft value in other languages. There's also plenty of soft value in other languages. Just pursuing other languages, as well, I can imagine that if you were to go and learn another language, or another framework, even, within a language that you already know, that you may be able to kind of flex the learning muscles through the product you're building, right? There's some kind of motivation there, but, largely, I agree with you, the idea that you're very likely to be successful with something that you already know, so you can focus on what you're going to need, what you're going to need, what you're going to need, what you're one thing rather than going off on a tangent to learn all about, let's say you're learning Rails. Well, you need to go and learn all about Action Controller. It's been a while since I've worked in Rails, but you're gonna go off on this tangent and it's not really producing any value directly to the thing you were building. Or you could get hung up between two different gems and you're trying to decide, which one do I wanna use for authentication? I don't know. And then you go and do a bunch of research on authentication gems, rather than building the form that you need to authenticate with, right? Yeah, totally. And I think that a great example of learning at the same time is the Buildkite agent. So Buildkite is a hybrid CI CD, which means that the orchestration plane and the platform itself is hosted. We look after that. We take care of all the hard bits with that. And you run, and the other part of it is the agent. And the Buildkite agent is the agent you install on servers that you control. And Buildkite sort of orchestrates work being run on those agents. When I first started writing Buildkite, the agent was written in Ruby, because Ruby is what I know. But if you were to sort of write down a list of requirements for what the agent is, this extremely strong process that runs on machines, that never breaks, that is long lived and can run on different operating systems, Ruby is probably not the best choice for that. But I wrote it in Ruby because that's what I knew. And after about a year, that didn't work anymore. Ruby was not the right choice for that particular problem. Ruby has a lot of memory related issues when it's long lived. And having customers install a very specific version of Ruby on their servers to be able to run this agent was just a bad developer experience. So I needed to choose a different language to solve this particular problem. And I didn't know that Ruby was going to work on servers. So I had to go to GoLang before that. So I set out to rebuild the agent in GoLang. And that was a successful learning experience because I had a very strong problem I was trying to solve. And it was a very sort of, the scope was small. Rewrite the agent in Go. And that meant that I could learn Go at the same time and sort of had a real concrete idea of what I was trying to build. And I didn't sort of lose my way in the idea because the idea was already very, very clear. I was really successful in learning Go. And I was able to do it in a way that was really interesting for when I did that particular job. It's kind of interesting. I actually really like this way, this kind of method of learning a new thing. Having a fairly sophisticated product or fairly sophisticated idea that you've already built, that you can see kind of the technical implementation of in another language. And then choosing to more or less translate, right? You're trying to say, okay, I want to do this idea over here in Ruby. And I want to translate this functionality, this functional idea into something in Go. Now, what it kind of forces you to do is these different steps of kind of metaphor creating, or the translation process is very mechanical. You say, okay, I've got a class in Ruby. What do I do with that in Go, right? It's a very different structure. It has some different concepts. I've got this function in Ruby and it takes multiple types of input. How can I support that in Go? And you start to learn about, you know, Go's structure, its underlying structure by comparing it, or I guess, contrasting it with an existing Ruby project. And you have like a built-in test. Have I learned it? Well, did the thing work? Right? Like, hey, I'm going to do this. And it gives you some true validation. And in a way it's almost like refactoring, right? You're just kind of refactoring to a completely different language rather than, you know. Yeah, totally. And that's how I learned Go. I would look at the code in Ruby and I would say, okay, I need to do a HTTP call. Then I would Google how to do a HTTP call in Go. And then I would stumble across some Stack Overflow post and then sort of go from there. And the next problem, how do I shell out to a process in Go? I would Google that and sort of figure out how to do that. And so I would sort of, I would mutate the Ruby into Go bit by bit by just sort of solving one small bit at a time and sort of learning as I went through that process. And that worked out really, really well for me. Yeah, that's such an interesting process. I'm curious, I kind of want to take a step back and take a look at your career. I want to ask you a question that I tend to ask towards the end of these interviews. What do you wish more people would ask you about? Wow, that's a spicy one. That is a spicy question. What do I wish people would ask me about? I wish people would ask me more about how they can build a product or how they can start a business. Because I don't feel like I'm particularly smart. I don't feel like I am this whiz-bang engineer. I don't, you know, I dropped out of high school. At the age of 22, when I signed up for the university program, I signed up for the university program, and signed up for the university program, and signed up for the university program, and signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, signed up for the university program, do consider myself is sort of just being excited by ideas. And I wish people would ask me about how to build something or how to be excited by an idea more. What can they do to build something? That's what I wish people would ask me more about. It's interesting that you are focused on this this kind of fuel, the motivation, rather than a specific skill set or, you know, all the way on the other end of that scale, I guess, would be tricks, right? What is the secret to a successful business? But it seems that you are kind of on the opposite end. You're not talking about skills or tricks or that one thing that you need to do or that one book you need to read. But instead, it seems that what you care most about is this passion or fuel or focus on the idea. Would you say that that's a secret to a successful business? The most important thing for a successful venture like this? Absolutely, I would. I feel like it's easy to get caught up in everything but the idea. I know that I tend to have these hobbies and I tend to go deep into these hobbies. I never really am successful in a hobby. For example, my most recent hobby is miniature painting. I love board games and I tend to have lots of board games with minis. And I've really wanted to paint a board game. And I've really wanted to paint a board game. And I've really wanted to paint a board game. And I've really wanted to paint a board game. And I've really them all. So I did a lot of research in the paints that I need, the brushes that I'll need. I would watch lots of YouTube videos of techniques. But in all those things that I was doing, the one thing I wasn't doing was painting. I was sort of gearing myself up. I'm like, one day, I'm just going to learn everything I need to learn. And then I'll go paint a mini. I think I've painted two minis. And I have probably 100 paints and 20 different brushes. And I've watched probably 100 hours of YouTube video of people painting. But I've only painted two or three minis. I feel like I'm going to be a successful entrepreneur. I'm going to be a successful What I should have done is just started painting. Just start painting a mini. And then I will learn. And then I could sort of hone my craft from there. And I feel like that's what people sometimes do with ideas for products and businesses. They skirt around the idea. They have to read this book first. They have to read this language first. They have to go to this seminar. They have to join this incubator. They have to do all these things before they can actually do the idea. And I wish that they would just do the idea. Just go build it. Use what you know. Go build something. Because often I feel like, you know, they say a picture is worth a thousand words. I feel like a prototype is worth a thousand words. And it's not until, you know, if I was to, when I was starting out Buildkite, I would tell people the idea. Oh, it's the ICD platform that is hybrid. And people would say to me, oh, I don't get it. Why don't you just use X, Y, Z? Just use this other thing. I don't understand why you, exactly what you said before. Can't you just add this? Two things together and get the same outcome? Absolutely you can. But it wasn't until they sort of got their hands on something, something tangible that they could say, oh, I get it now. I understand what you were trying to achieve. And I know that it's easy to have people get you down when you do things like customer research and sort of like finding, there's a whole bunch of stuff you can do around an idea that is not building the idea. I think that if you truly are passionate about the idea, you should go try. And it doesn't matter if no one buys it. It doesn't matter if it doesn't sell because I bet you that that idea will come back in five years time and that will be a successful idea. So even if the first time, even if your first attempt doesn't go anywhere, that's totally fine because the lessons that you, things that you learn in doing that will pay dividends the next time you build something. Yeah. Yeah. This is, this is kind of gold in a lot of ways. This, this advice, that focusing on the idea, you know, I, I think there are certain personalities perhaps that tend to do what you were saying. It's kind of this information hoarding or over-preparedness. I do this as well. I, I kind of stock up on all the things that I might need. For example, you know, I think if you're painting miniatures you may be also interested in 3d printing. That's actually something I've been interested in recently. So, uh, you know, I, I went and I found, you know, I did all the research on what are the best filaments and I went and I got those filaments and, you know, I, I went overboard in kind of trying to learn rather than getting in and just kind of designing things. Um, you know, I, I really, uh, uh, enjoy the functional prints, that style of, of 3d printing. And finally I realized, you know what, the best thing for me to do is to open up my 3d, you know, uh, design tool and to start making mistakes, start making prints that I'm going to throw away. This stuff is cheap. And, uh, I, I think in the back of my mind, this, this hoarding of, you know, ideas, information, even supplies is maybe an instinct to save something, to not waste something, uh, not waste my time, not waste my energy, not waste the plastic filament. Um, but at the end of the day, that, that instinct to not waste, uh, ends up wasting more. Uh, it's kind of this weird paradox possibly that I don't want to waste my time. You know, a good example of this for an engineer that's starting out is I don't want to waste my time learning the wrong language. I hear this all the time. I don't want to, you know, go down the path of this other language, this wrong tool, and then regret it. And so we end up spinning in circles, trying to find the right thing. And, oh, I, well, I can't use that one. Because it's, I don't know, uh, the, the community might be, uh, uh, less than it was last year. There's not as many people using it. So I'm going to write that one off and I can't use that one because of another reason. And then we end up doing nothing, right? We're totally actionless. And I'm interested to know if, if you feel like this is something that is, um, that you can kind of will yourself through, or if it's important to kind of, recognize how this, this could be a part of your personality and to find ways to kind of cope with it or get around it, uh, to be more productive or more active on your ideas. Once you've recognized it, that's step one. I think, uh, I think we tend to value, it's kind of funny. We tend to value money cheaper than our time. Um, you know, I was able to go buy some paints and some paint brushes for miniature painting. And it felt like, I was making a good investment. You know, uh, my, my time is way more valuable than, than just buying this, this $20 paint for this, this miniature paint that I wanted to paint, but we should be buying more of our time in that time that I spent researching and investigating all these things. I should have been painting with what I had, um, and, and buying more of my own time just to do something and investing in that more because knowledge, like, I mean, they say knowledge is power, but that's definitely the case. You know, when you want to learn a tool I've learned, I have a ton of knowledge in programming that is completely useless now. Um, you know, I know how to make web pages with tables and layouts with tables. And that is knowledge that I have that it will never be used again. Um, and this was when I, when I was first starting my career, I had two options. I could learn about this new thing called CSS, uh, that I didn't really know or understand. Why would I be using a different file? I don't get it. I'm just going to make tables. Uh, and I learned that, but you know, if you would have in hindsight, that was the wrong thing to learn, but it meant that when I did learn CSS, I was able to appreciate it much more. You know, I was, I understood, I understood the other way way better so that I could compare and contrast with the new way of doing things. Oh, you know, this is so much better than it was before. I know this other thing now, and I know not to use that one again. So even if I do learn a tool or some language that ends up being not that useful, I'm going to be able to use that one again. I think people underestimate that knowing not to use something is also very, very useful in and of itself. Yeah. Yeah. It's, you know, it's, I think knowledge, uh, especially in this, uh, in this career, in this industry, knowledge is much more fluid than we give a credit for. Um, partially, and maybe this is something that we're trained to do. We have these bullet points on our resume and we consider knowledge to be a very, very useful thing. And I think that's, I think, whenever we know enough to feel comfortable to put it on our resume, right? Uh, so, so we learn in these categories, we learn a framework, we learn a language, but actually what we're learning is something totally different. We're not just learning a language because you could learn a language and never make anything valuable with it. Right. So does it matter really that you know what you've actually done when you learn something or when you learn not to use something is you've learned more about kind of a landscape than you have about a technology. You're learning comparative analysis between different tools, right? It's, it's a deeper knowledge than what we give credit to. And it's about this kind of orchestration of skills rather than, you know, a specific thing. Right. I know how to manage a Kubernetes cluster. Well, okay, great. What does that mean? How does it fit in with the, with the bigger picture of, uh, of managing software servers, right? What do you do with it? And why does it matter? Right. If you just know it, if you just have the certification, then that's just another bullet point on the resume. But if you're learning, okay, here's why Kubernetes is, you know, ostensibly better, right? Um, then the thing that I was using before, then you can recognize, for example, when it's overkill, right? That's, that's a, that's a perfect example of this. The, the, uh, advanced DevOps engineer might be able to quickly say you're doing too much, right? And you're buying too much into this as, uh, as a, as a solution to a problem that you don't even have. That's the kind of learning that I think is, is, um, a marker of a long and, and kind of successful career. Yeah. And I think that we should just learn to not regret the things that we learn. There's no regrets because everything that you have done in your career thus far has led you to this point. And everything you do from now on will lead to some other point. And I guarantee if you don't do the things that you are doing today, that might not lead you to some point in the future. Um, I, uh, you know, I've learned lots of tools and learn lots of things. I have, I've spent countless hours with CICD tools before Buildkite. You know, I'd spend hours and hours configuring Jenkins and configuring Travis and all these other tools. And all of that time that I spent, even though at the time I didn't know it, all of that time was sort of going, being stored in the back of my brain. And I could use that knowledge when I built Buildkite, you know, that knowledge came out of me and I could use that to inform the things that I was building. And I think that's, I think that's a really, really important thing. And so nothing is wasted. Nothing. You never waste, you're never wasting your time by learning something. I think that, but for me, I learned by doing, um, that's the biggest thing that I know about myself is I learned by doing, I don't really learn by hoarding information like you were talking about before. Yeah. I'll extend that even further and say that your knowledge bank is not just limited to your technology skills, right? What you're doing in your hobbies and painting miniatures, that knowledge is not limited to your technology skills. And so I think that's a really important thing to remember when you're building your platform, bringing your platform together, bringing your platform together, bringing your platform together, bringing your platform together, a more kind of capable person, a more capable engineer. Yeah, totally. And, you know, there are other things in my life that I can look back on that really helped build kind of the business be successful. I've worked in, I've worked in pretty crappy jobs in my career. You know, I've worked for some people that I wouldn't consider good bosses. But all of that time that I spent with them really helped me hone in what not to do when I started a business. When we started hiring people, I learned very, very quickly what I shouldn't be doing based off my experience in the past of having bad bosses. And so if you've got a bad boss now, one day you will lose, you will use those learnings when you start managing people. You'll remember that, oh, I remember that time that my boss did that thing. Yeah, I won't do that again. Yeah, yeah. I mean, with things like a hobby or with things like a previous job that has nothing to do with this industry, you learn kind of these. These meta skills, right? You might, for example, I'm just kind of making this up, but you might learn the importance of patience with painting. Oh, you know, I screwed this up, but it's resilience. You might also learn how resilient the things that you're working with can be, that you can repaint that particular portion or that it's easy to start over, that you can wash things off. Again, I'm kind of extending the metaphor a little bit further than you perhaps said before. It has the legs to go. But this is the kind of thinking, though, that integrated learning experience that we can have, that everything plays into everything else. And I do think that, you know, those small experiences make us a more complete version, a better thinker than we would otherwise be. Thank you so much for listening to today's episode of Developer Tea, the first part of my interview with the CEO. And I'll see you next time. This episode and every other episode of Developer Tea can be found at spec.fm. And this episode was produced by Sarah Jackson. My name is Jonathan Cottrell. Make sure you subscribe so you don't miss out on the second part of this interview. And until next time, enjoy your tea.