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 Jon. I think 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 in 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 at BuildKite. I actually did a little bit of digging and I found that you worked once upon a time at it in Votto. That's right. Yeah, that's actually kind of where BuildKite started at Invader. Oh, really? I did not know that. Yeah, maybe this is a good segue into telling the story of BuildKite. Yeah, please. It's great that I can do it. So I was at Invader and I was working on a tool there at the time called MicroLancer. It's now known as Invader Studio, I think. And it was a small tool within the company and we were using a hosted CI tool called Traverse CI. I'm a big fan of Traverse. I love Traverse. 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 Invader 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 fill in that spreadsheet, we had to answer no to that question. We didn't know where our code was at all times because we kind of get, we had a really good idea of where it was with GitHub, but we didn't know where it was with Traverse. And so we were told, you know, the other teams in the company use hosted CI providers. We really want you to leave Traverse and use a hosted CI provider. And I was really bummed by this because Traverse was part of this new wave of next-gen developer experience type CI products. I was used to tools like Haroku and GitHub, you know, the tools that had really modern developer user experience, but a lot of the hosted CI CD tools like you Jenkins, your team sitting in 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 in my head, I hosted 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, 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 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 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. If you were to evaluate the landscape and let's say, let's say, Bill Kite didn't exist today. And you were to look at the available tooling out there and maybe find that, you know, 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 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 the time, I probably wouldn't have built it. I just felt compelled for this thing to exist because 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 in 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 what you wanted to do. You saw the other 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 none of them did everything that you needed them to do. And it wasn't necessarily, I'm going to put words in your mouth. It wasn't necessarily because it was a novel idea. It was because it was a mix of multiple ideas that had already been executed on just not together. Is that true? Yeah, that's right. I took the best of both worlds. So for listeners that may not know much about CICD, there are two different sort of flavors of CICD. The first flavor is the self-hosted option. And that's where you run the tests yourself on servers that you control. And then you run the orchestration plane yourself as well. And that's got a big con. And if you have 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 CICD 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 a 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 the 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 Bill Coy was born. And 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, I have this idea and it doesn't exist, but people can do it themselves if they go and 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 taking one thing, the best of both worlds, like you said, the new product is multiplicative and value rather than additive. In other words, somebody could probably go and run two different things to get the same values. But when you put them together, it changes the landscape. It's not the same thing. It's just running those two things back to back. It's changing kind of the fundamental shape of that product. 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 the 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, who tells, but they've taken it, mash it up and made something new. CI City, I didn't invent CI City, 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. I just improvements of existing ideas. I think that, I don't think Facebook would be around forever. There will be a better Facebook at some point. There will be a better Spotify at some point. There will be a better Apple at some point. 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 and build it because even if no one uses it, I think the building of something in and of itself is a journey and a lesson. Bill Cuyte wasn't my first CI City platform. I have built a CI City 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. 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. I don't think Bill Cuyte would have been as successful as it was if I hadn't already built a version of it long before that that failed measurably. It's great to hear that because I can relate in kind of a very small way. Before I ever started this podcast, I actually was considering starting a different one. This was very, very early in my career and it was when podcasts were still quite young and my idea was to talk. I was mostly a front end developer at the time. I was going to talk with a back end developer and we would chat back and forth and essentially and I didn't even know who this person would be. I was just kind of assuming that I would find somebody who would be willing to be a co-host and we would talk about the differences or the negotiation points between the front end and the back end. This would have eventually and probably pretty quickly gotten old, right? Now, fast forward a couple of years after that and I decided to start Developer Tea. It's interesting to see how these ideas that keep recurring or keep resurfacing tend to be the ones that at least that 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. They're going to continue investing in that idea because it's something that has resurfaced multiple times. Yeah, totally. One bit of advice that I have to people when I talk about this sort of stuff is if you have an idea and you want to focus on the idea, focus on building the idea, I love video games. I play a lot of video games and I've always wanted to make a video game. Whenever I've started to make a video game, I've always got stuck on the engine and the building of a tool and I would get stuck up on the idea of trying to build this amazing engine for this game. It's funny how when you look at CI-CD and build the tool itself, it's the engine for a video game really where the tests are the game and the platform is itself the tool. One thing that I think that made BookCard successful is that I use the tools that I knew when I built BookCard. A lot of the people that I know who set out to build something often tie that in with learning and do language or new framework at the same time. I feel like they end up getting stuck on learning at the same time as building a thing. If you want to learn a language and build the thing at the same time, that's totally cool but if you want the tool or the idea to succeed, I think the best bet. The best way you can make it succeed is by using the tools that you knew and I probably categorize myself as a Ruby on Rails developer and I use Ruby on Rails to build BookCard. I think that if I was to have looked at BookCard'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 enjoy the idea unless around the technical implementation. No matter what you are building, you can build it on top of Linode. Today's episode is sponsored by Linode. 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 your personal project or managing larger workloads, you deserve simple, affordable and accessible cloud computing solutions. By the way, you can launch BuildKite on Linode because anything that works on Linode, it runs on Linode. You can get started with $100 in free credit for listeners of Developer Tea. You 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 customers. You also receive the full top tier support. The reason for that is because there are no tiers or handoffs regardless of your plan size. You can get the same support level as you scale from the bottom up. You can choose shared and dedicated compute instances or you can use your $100 in credit on S3 compatible object storage, managed Kubernetes and more. Head over to linode.com slash Developer Tea and click on the Create Free Account button to 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. Whatever your most common thinking language is, is very likely going to be the one that you're most productive in. With that said, there's also plenty of soft value in other languages, 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 flex the learning muscles through the product you're building. 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. You can focus on 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 going to 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 gyms and you're trying to decide which one do I want to use for authentication. I don't know. Then you go and do a bunch of research on authentication gyms rather than building the form that you need to authenticate with. Yeah, totally. I think that a great example of learning at the same time is the build-cut agent. Build-cut is a hybrid CICD, 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. The other part of it is the agent. The build-cut agent you install on servers that you control and build-cut orchestrates work and being run on those agents. When I first started writing build-cut, the agent was written in Ruby because Ruby is what I know. If you were to write down a list of requirements for what the agent is, this self, this extremely strong process that runs on machines that never breaks, that has 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. After about a year, that didn't work anymore. Ruby was not the right choice for that particular problem. Ruby had a lot of memory-ish 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. I needed to choose a different language to solve this particular problem. I didn't know Girling before that. I set out to rebuild the agent in Girling. That was a successful learning experience because I had a very strong problem I was trying to solve. It was a very, the scope was small. Rewrite the agent in Girling. That was, I could learn Girl at the same time and had a real concrete idea of what I was trying to build and I didn't lose my way in the idea because the idea was already very, very clear. I was really successful in learning Girl when I did that particular job. It's interesting. I actually really like this way, this method of learning a new thing. Having a fairly sophisticated product or fairly sophisticated idea that you've already built, that you can see the technical implementation of in another language. I've been choosing to, for more or less, translate. You're trying to say, okay, I've got this idea over here in Ruby and I want to translate this functionality, this functional idea into something and go. 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? 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? You start to learn about Go's structure. It's underlying structure by comparing it or contrasting it with an existing Ruby project. You have a built-in test. Have I learned it? Did the thing work? It gives you some true validation and in a way, it's almost like refactoring. You're just refactoring to a completely different language rather than... Yeah, totally. That's how I learn Go. I would look at the code of 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. 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. I would mutate the Ruby into Go bit by bit by just sort of solving one small bit at a time and learning as I went through that process. That worked out really well for me. 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. I don't feel like I am particularly smart. I don't feel like I am this whizbang engineer. I dropped out of high school to pursue a career in programming. I would love to tell you that the reason I dropped out of high school was for some Bill Gates related reason where I was really smart. That was just, I had a really bad breakup with a girl. I dropped out of high school and started programming full time. I don't see myself as, and I have not been traditionally trained. I don't have a university degree. I don't consider myself all that smart, but what I do consider myself is just being excited by ideas. I wish people would ask me about how to build something or how to be excited by an idea more. That's what I wish people would ask me more about. It's interesting that you are focused on this kind of fuel, the motivation rather than a specific skill set or all the way on the other end of that scale, I guess, would be tricks. What is the secret to a successful business? 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. 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 the most important thing for a successful venture like this? Absolutely, I would. It's easy to get caught up in everything but the idea. I tend to have these hobbies and I tend to go deep into these hobbies and 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 really wanted to paint them all. 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 on one day. I'm going to just going to learn everything I need to learn and then I'll go paint too many. I think I've painted too many 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 what I should have done is just started painting. I'll start painting a mini and then I will learn and then I could hone my craft from there. 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. I wish that they would just do the idea. Just go build it. Just what you know, go build something because often I feel like 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, when I was starting out build kite, I would tell people the idea. It's the ICT 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 another thing. I don't understand why you exactly what you said before. Can you just add these two things together and get the same outcome? Absolutely you can. But it wasn't until they could have got their hands on something, something tangible that they could say, oh, I get it now. I understand what you're trying to achieve. And I know that it's easy to have people get you down when you do things like customer research and 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 build it. And it doesn't matter if no one buys it, it doesn't matter for themselves 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 kind of gold in a lot of ways, this advice that focusing on the idea. 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 kind of stock up on all the things that I might need. For example, if you're painting miniatures, you may be also interested in 3D printing. That's actually something I've been interested in recently. I went into my found, I did all the research, I'm one of the best filaments and I went and I got those filaments and I went overboard in kind of trying to learn rather than getting in and just kind of designing things. I really enjoy the functional print style of 3D printing. Finally, I realized the best thing for me to do is to open up my 3D design tool and to start making mistakes, start making prints that I'm going to throw away. This stuff is cheap and I think in the back of my mind, this hoarding of ideas, information, and supplies is maybe an instinct to save something, to not waste something, not waste my time, not waste my energy, not waste the plastic filament. At the end of the day, that instinct to not waste ends up wasting more. It's kind of this weird paradox possibly that I don't want to waste my time. 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 want to hear this all the time. I don't want to go down the path of this other language, this wrong tool and then regret it. We end up spinning in circles, trying to find the right thing and I can't use that one because it's, I don't know, the community might be less than it was last year. There's not as many people using it. I'm going to write that one off and I can't use that one because of another reason. Then we end up doing nothing. We're totally actionless. I'm interested to know if you feel like this is something that you can kind of will yourself through or if it's important to recognize how this could be a part of your personality and to find ways to cope with it or get around it to be more productive or more active on your ideas. Once you've recognized that step one, I think we tend to value, it's kind of funny. We tend to value money cheaper than our time. 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. My time is way more valuable than just buying this $20 paint for this miniature paint that I wanted to paint. We should be buying more of our time. That time that I spent researching and investigating all these things, I should have been painting with what I had and buying more of my own time to do something and investing in that more because knowledge is power but that's definitely the case here. Then you want to learn a tool. I have a ton of knowledge in programming that is completely useless now. I know how to make web pages with tables and layouts with tables and that is the one that I have that it will never be used again. When I was first studying my career, I had two options. I could learn about this new thing called CSS 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. When I learned that, if you were in hindsight, that was the wrong thing to learn. It meant that when I did learn CSS, I was able to appreciate it much more. I understood the other way better so that I could compare and contrast with the new way of doing things. This is so much better than it was before. I know this other thing now and I know not to use that one again. Even if I do learn a tool or some language that ends up being not that useful, I think people underestimate that knowing not to use something is also very useful in and of itself. Yeah. I think knowledge, especially in this career, in this industry, knowledge is much more fluid than we give a credit for. Partially, maybe this is something that we're trained to do. We have these bullet points on our resume and we consider knowledge to be whenever we know enough to feel comfortable to put it on our resume. 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. Does it matter really that you know that language? 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. It's a deeper knowledge than what we give credit to. It's about this kind of orchestration of skills rather than a specific thing. I know how to manage a Kubernetes cluster. Okay, great. What does that mean? How does it fit in with the bigger picture of managing software servers? What do you do with it? Why does it matter? If you just know it, if you just have the certification, then that's just another bullet point on the resume. If you're learning, okay, here's why Kubernetes is, you know, ostensibly better than the thing that I was using before, then you can recognize, for example, when it's overkill. That's a perfect example of this, the advanced DevOps engineer might be able to quickly say, you're doing too much, right? You're buying too much into this as a solution to a problem that you don't even have. That's the kind of learning that I think is a marker of a long and kind of successful career. 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. Everything you do from now on will lead to some other point. I guarantee you, if you don't do the things that you are doing today, that might not lead you to some point in the future. I have learned lots of tools and learned lots of things. I have spent countless hours with CI-CD tools before BuildCade. I had spent hours and hours configuring Jenkins and configuring Travis and other tools. 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. I could use that knowledge when I built BuildCade. That knowledge came out of me and I could use that to inform the things that I was building. Nothing is wasted. You never wasting your time by learning something. For me, I learned by doing, 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. What you're doing in your hobbies and painting ministers, that knowledge in some way that perhaps we can't really access or understand is going to play into the rest of your knowledge. It gives you a broader range of things to pull from, a broader range of models to pull from to understand the world. Just because it's not code, just because whatever you want to say, it's separate, it's out in this other world, doesn't mean that it's not going to make you a more kind of capable person, a more capable engineer. Yeah, Charlie. 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 pretty crappy jobs in my career. I've worked for some people that I wouldn't consider good bosses. 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. If you've got a bad boss now, one day you will use those learnings when you start managing people. You'll remember that time that my boss did that thing. Yeah, I won't do that again. Yeah. I mean, with things like Harvey or with things like a previous job that has nothing to do with this industry, you learn kind of these meta skills. You might, for example, I'm just kind of making this up, but you might learn the importance of patience with painting. Yeah. You know, I screwed this up, but it's resilient. 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 watch things off. Again, I'm kind of extending the metaphor a little bit further than perhaps it has the little 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 Develop a Tea, the first part of my interview with the CTO and co-founder of BuildKite, go and find out more about what BuildKite does and what it can do for your company at BuildKite.com. BuildKite did not sponsor this episode and has not sponsored Developer Tea in the past. Thank you so much for listening to today's episode. Today's episode was sponsored by Linode. At over to Linode.com slash Developer Tea, you can get $100 worth of free credit by using that specific link at linode.com slash Developer Tea. 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 Cutrell. Make sure you subscribe so you don't miss out on the second part of this interview and until next time, enjoy your tea.