In today's episode, I talk with Chris Shinkle, Director of Innovation at SEP. I believe today's episode is one of the most important interviews I've done to date, and I hope you enjoy it as much as I did! Today's episode is sponsored by Linode. In 2018, Linode is joining forces with Developer Tea listeners by offering you $20 of credit - that's 4 months of FREE service on the 1GB tier - for free! Use the code DEVELOPERTEA2018 at checkout.
In today's episode, I talk with Chris Shinkle, Director of Innovation at SEP. I believe today's episode is one of the most important interviews I've done to date, and I hope you enjoy it as much as I did!
Today's episode is sponsored by Linode.
In 2018, Linode is joining forces with Developer Tea listeners by offering you $20 of credit - that's 4 months of FREE service on the 1GB tier - for free! Head over to https://spec.fm/linode and use the code DEVELOPERTEA2018 at checkout.
Another huge announcement - Developer Tea is officially available on Spotify!
How often do you need to change code that you wrote before? Hopefully the answer is every day. None of us are writing code that stays in the same state that it was in when we wrote it indefinitely. I would imagine that all of us are writing code that we're changing pretty consistently, some more than others, but certainly all of us have had that experience. We're talking about that change management process and many other exciting topics with today's guest, Chris Schinkel. Chris is the Director of Innovation at SEP. This is one of those interviews that I think a lot of you, and certainly I, am going to come back to many, many times because there's so much great information packed into this interview. Chris is such a well-seasoned developer, but he has a lot of experience in the field of code. He has a lot of great experience to share with us, and I'm just really excited to get started. So I'm going to get out of the way. Again, you're listening to Developer Team. My name is Jonathan Cottrell. The goal of this show, by the way, is to help driven developers connect to their career purpose. And we already laid out kind of the plan for the year to focus on these three pillars, the purpose, the practice, and the principles. And in today's episode, most of what we're talking about is in that principles area. So hopefully that is apparent. This is a two-part interview. The interview at the second part got cut a little bit short because my wife and I, we thought we were going to go and have our son that day, that night. And actually, while I was interviewing Chris, she texted me and said, we need to go to the hospital. And you'll hear that part actually at the end of the second part of this interview. Let's go ahead and get into the interview with Chris Schenkel. Chris, welcome to Developer Team. Thanks for having me. I'm looking forward to it. At the end of this discussion, you have been giving a talk recently that I think is right in line with some of the things that we've been discussing on Developer Tea. And we'll get into that in just a moment. But first, I want to ask you, you know, about your origin story, I guess you could call it. What were some of the experiences or the initial moments that got you interested in software development? Sure. So I was born, I'm old, I was born in 1971. But really, in really, the first kind of cohort of, I'll say, the serious gamers. I grew up in that world where the world of video games and the Apple IIe and even the Atari and programming at home kind of originated. And so I had an early interest in computers and engineering as a kid, went to Purdue University and studied computer electrical engineering. And after that, I got out and sort of found a job that really allowed me to kind of apply some of those skills. But really, I love just the never-ending landscape of learning and solving problems and challenges and puzzles. And so that really fueled me to get into software development. That's so interesting. Can you kind of reminisce? Can you tell us a little bit about your early days and your awareness on some of those early projects? What were some of the technologies that you were actually using in those early days? Sure. So the first, I'll say, professional project I was on was an engine monitoring system for a military aircraft. And it was written in Pascal. Oh, wow. It wasn't even a Windows GUI. It was all DOS-based GUI system. Wow. So... So you're writing this Pascal code. And I assume, since it's military and it's something that's so important as flight engineering instruments, that you had to have some level of pretty rigorous testing and validation and that kind of stuff. We did. So Agile really wasn't around, or those concepts, at least for us, weren't really familiar. And so the concept of pair programming, or even though we didn't call it that, we worked together as pairs. But what we often did is worked closely with our customer representatives. So this particular fellow, his nickname was Willie, and he was at some naval bases and worked with a lot of the young guys working on planes and seeing stuff and would capture all these flights and flight data. And every so often, he'd come to SEP and sit down with us. And we'd look at like an actual flight. He'd say, here's what happened. And this is what the system reported and said happened. And that's not right. And so we would sit and work really closely together to sort of figure out what went wrong or what diagnostic wasn't getting triggered or what was maybe getting falsely triggered. And so there was just, there was a lot. It wasn't the rigorous testing in terms of a big, huge automated test suite or these really in-depth test scripts. As much as it was working with customers. Yeah. With actual flight data. Yeah. And using that in the system to sort of validate all of these diagnostics and faults and stuff that we would detect. And over the years, we would build up this pretty exhaustive case, this library of all these flight data. And when we would run the system or do a new release, we would run through and execute all the flights and they would generate flight summary reports. And we would look at those then and confirm that we were getting all the data. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And that's really what we expected to get. And so in a lot of ways, we were doing what developers do today. It just wasn't so much with a lot of automated systems and PFC build scripts and build servers and whatnot. But it really involved a lot. You know, it involved a lot. And I think it's funny. We did a lot of using actual live data to validate the system. Yeah. And, you know, sometimes today I see people get away from that. They end up using, you know, manufactured data or test scripts or test data or somebody inside the organization builds the data and it's just never quite as robust. It just never has all the nuances or all the craziness in it that the actual data does. And so, yeah, we might have been a little ahead of our time, I guess. Yeah, that's such an interesting thing because, you know, basically what you did was sort of like test driven development in a way in that you set up your expected case and then you ran your code against it. But it just so happens that your expected case wasn't just a written out file. It was, well, I'm actually going to go and record the data or create an expected flight rather than an expected, you know, CSV or something like that. Right. Very interesting. Very interesting reality there. But it outlines and underscores this concept of, you know, just because your tests are green or just because things seem like they should be working, that may not necessarily be the case. Right. You still need to validate that in the real environment, still need to look at, you know, with your own two eyes is the way I like to put it. You need to, as a person, validate that the software is doing what you're expecting it to do. And that takes time. That takes time. So, yeah, I think a lot of people are shipping software today, you know, whenever all their tests pass and they expect that to cover them. And a lot of times they don't put their own two eyes on the software. Whatever the outcome is, they don't validate, you know, even in very simple cases, a lot of times that software doesn't get validated properly. And that ends up, you know, being very costly. Very interesting use case. Yeah. So I'd love to talk to you, you know, about that progression. And, you know, about 10 years later or so, I guess, is when Agile, you introduced Agile to SEP. Can you kind of discuss, first of all, you know, the scale of SEP, what you do with SEP, but also, you know, how you came on this concept of Agile? And then we're going to go into discussing how behavioral science actually can apply to Agile. But first, tell us a little bit about SEP. Sure. SEP is a product design development company in Carmel. Indiana, which is just outside of Indianapolis. And we work with mostly Fortune 100, Fortune 500 clients, big companies, although we do some, a fair amount with some smaller organizations in aerospace, healthcare, medical devices, consumer electronics, agriculture, finance. So a really diverse, you know, set of industries and help our clients create products and get products to market. So we have about... About 120 so developers, total people in the company, somewhere between 130, 140 individuals, but mostly development, design, test, right? But the majority of the work is makers or the majority of the people there are makers that work in the code. SEP has been around for 29 years. So we've gone through and seen a lot of stuff. And it's interesting how the industry has changed over that. That time period. When I started working and introducing Agile to SEP was 2004. And at that point in time, it was really sort of had the purest kind of form where I guess the Agile really originated from, which was just looking for better ways to build and deliver software. So I just had worked with a lot of customers and you just, you've kind of gone through and seen some of the same stuff over and over again. And you just kind of felt like, you know, there's gotta be a better way to do this. There's gotta be a better way to build. Software than this traditional big design upfront, write all these requirements, build these documents and, and let that drive development and ultimately, you know, verification or testing at the end to try to. Can you actually share some of those signs that some of those things that you saw over and over that, that felt wrong? It felt like, you know, there must be a better way. Can you share some of those signs with us? Sure. So, I mean, Some of it was, so a lot of our clients are these large companies. And in fact, some of them have been around more than a hundred years. And so they, they have got the lion's share of their, their organization, their culture, their management structure, their philosophy for building and delivering products. It comes from, you know, an era where, where most of what they built and delivered were all sort of manufactured products and goods. And in that world, it was essential to get things figured out upfront. It was essential to get things right up front because once I built the software, so I'll go back to the example I was using earlier in the engine monitoring, we delivered that software on CD ROMs. So once I burn the CD ROMs and give them to the Navy and they put them in, in, um, Siemens hands on boats or aircraft carriers that are around the world. It's pretty difficult to go to tell the. Captain of the boat, Hey, you need to do an update on your software and somehow deliver a CD ROM to them. Now we don't have wifi out there is the point, right? They do. But like what we were always told is the ship's captain is God. And when he says there's no communication on or off the boat, then, then that's what happens. Right. And so in those early days, those early days, there was just this huge emphasis on, we had to get it. We have to get everything right up front because it's too costly. Later on, it's too expensive to. Iteration. Is expensive back then, right? To do that. So the transaction costs and coordination costs associated with that are just way too high. And so we need to get things figured out. Well, well, well, that philosophy sort of, um, or that, that, that, um, that, that fact sort of permeated all levels of the organization. So when he funded projects on an annual basis and their governance structure and the way they went through and had to secure funding and get approval and all of that stuff, you know, evolved around. The. So.! of staged gate philosophy and lots of checks and balances up front before they'd made substantial investments and what. But what they were checking wasn't working tested software like we would today. What they were looking at a lot was documents and papers and stuff. And they saw those documents as an asset as opposed to a sort of a liability. And so those things, that philosophy, that kind of experience or idea of I've got to get things figured out up front, when you started to apply those to software, where it was easier to change software. Now, even though we were delivering stuff on CD-ROMs, it was harder to change, but that was still easier to change than, say, a physical e-primer or chip that you're burning and actually manufacturing. I mean, that's literally the difference between hardware and software. Software is supposed to be this thing that was soft and easy to change that you could make it work. And that's what they were looking at. And so they were looking at software as a way to make adjustments to. But these companies, these large organizations that have been successful for so many years, had all of their experience in systems and culture and organizational structure or whatever, all coming from this other area that made it very difficult to adopt those. And so they were taking the same philosophies to software. And so oftentimes it was about, the philosophy was, well, if we get the platform, we're going to be able to do it. And so they were taking the same philosophies to software. And so they were taking the same philosophies to software. And so they were taking right up front, we just have to execute the plan and that equals success. Or if we define all the requirements up front, then that's going to equal success. Or if we get the design perfect up front, that's going to equal success. And it just never did. It just never did. It didn't matter how hard you tried or what new idea came about for getting the requirements right. And it sort of led to this like, you know, like it kind of took you in the right direction. And so it was a little bit of a wrong direction in the sense that the more you tried to get them right up front and you feel as you were wrong, then the more time you tried to spend up front and that just means you were more wrong by the time you got to actually building software and wrong again. So I need, I need to spend more time up front. Right. And it just kind of was moving further and further away from short iterative cycles, building small increments, testing and validating those, you know, early and often. And, and so just, we just saw that, over and over again, organizations struggle, um, recognizing that there, there, there was a, a better way. There was a different way to approach it. It sort of fundamentally started with the notion that we don't have to get everything figured out, right. Because it is easier to change now, um, than what it was. And, um, it's software. And so there's not a huge cost, right. With, uh, right, right. You're not remanufacturing. You're not, you're not out material. Right. Right. Yeah. Today's episode is sponsored by Linode. It's a new year, but Linode is still providing the same excellent service that they've always provided. And they've come back in 2018 with another four month credit, a $20 credit for their Linux in the cloud service. You can instantly deploy and manage an SSD server in the Linode cloud, and you can get a server running in just a few seconds with your choice of Linux distribution resources and node location. So if you're interested in running a server in just a few seconds with your choice of Linux distribution resources and node location. This is very simple and it hasn't changed very much because these same building blocks are kind of fundamental if you're a developer. Linode is providing you with the Linux operating system in the cloud and that's really kind of a fundamental building block for pretty much every app or web service that you can imagine building. Now of course Linode is continuing to innovate within their company and in their service offerings. For example, they do have 24-7 friendly support. They have phone support. You can call somebody in the middle of the night and you're going to get a human on the phone and you're going to talk to them and they're going to help you with your problem. This is a unique experience to have if you're a developer that you're working on an app at 2 a.m. on a Saturday. Hopefully you're not doing that but maybe you are and you need support. Well Linode has your back there. They have VMs for full control. You can run Docker and containers and cryptography. You can run Linux. You can do anything you can imagine doing on Linux. You can do on Linode except it's in the cloud. So they also have a new beta manager and this is one of the cool kinds of things that Linode does. They've open sourced this. It's a React app. It's a single page app. They built it with React and it's available on their GitHub page. So Linode is basically a company of developers and they're going to give you resources too. This is such a cool thing. Linode is basically a company of developers and they're going to give you resources. They're building a knowledge base and they'll send you resources. For example, after you have called them on a support line, they'll send you a resource that's relevant to your problem so you can learn more. Not just solve the problem, move on, but solve the problem and then gain some better insight. So Linode is providing you with that four free months for using the code. This is a new code. DeveloperT 2018. DeveloperT 2018 at checkout. Head over to spec.fm. slash Linode now to get started. Thank you so much to Linode for continuing to sponsor DeveloperT. You know, it's something I talk about on the show a lot is doing small things, right? And this is kind of at the heart of Agile. This small iteration, the very smallest thing that you can do is what you should do next, right? And moving the value forward as much as possible. And the reason or some of the reasons that I've been doing this is because I've been doing this for a long time. And I think that's one of the reasons for this, maybe not the only one, but some of the reasons for this is that smaller things are more manageable in your own mind, right? Basically what we're doing when we create software is we're engaging, we're bringing an idea into our brains and then we're doing some sort of operation with that idea in our minds to translate it to a machine and to other humans simultaneously and fit it into these previous ideas that we have already translated. And that sounds like an ethereal, but if you think about the process of writing code, that's exactly what it is. You're taking some idea and you're translating it into code, right? Instructions for a machine that another human can read. And so this is important because the larger the idea, the more difficult the translation process is going to be, the less likely you are to be able to hold it all in your mind and the more error prone you're going to be when trying to translate. So very simple process of, you know, you're going to be able to do that. And so that's the basic concept. The only notion I would challenge there is just that it's not small for the sake of being small. So, you know, it's about delivering an increment of value. Now that value could become in terms of the product itself is valuable or the feature is valuable. It could come in the form of value and some form of learning, right? And this is really kind of starts to adopt lean and lean startup philosophy of small experiments. And what the throughput is, is actually learning. I'm executing small steps and that learning and the recognition that learning or knowledge is the greatest constraint to throughput, right? I'll ask people all the time, think about the last product, software product you worked on. If you were to do that, build that same thing today, knowing everything you know, you're going to be able to do that. And so that's the basic concept. So that's the basic concept. And so that's the basic concept. And so that's the basic concept. So today and everything still happened, how much less time would it take you? And, and, and, um, it's usually a little more than if I sort of take a pull a poll, it's, it's, you know, oftentimes between 50 and 60% less time, right? So knowledge is one of the greatest constraints of throughput. And so I see some people when they adopt agile, they just break things down in small chunks and they break things down in small chunks in terms of what's convenient for the developer or what's easy to do for the developer. Or maybe it's even what you're doing for the developer. Or maybe it's even what you're doing for the developer. Or maybe it's even what you're doing for the developer. Or they may find it hard toension, they may find it hard toension, they may find it hard toension, they may find it hard toension, they may find it hard toension, they may find it hard toension, they may find it hard toension, they may find it hard toension, they may find it hard toension, side of we're trying to deliver a small increment of value or we're trying to expedite the learning process and so sometimes maybe what we're working on isn't the smallest thing we could work on but it's the smallest unit that's going to maximize our understanding or learning of the problem we're trying to solve and in doing so we're going to increase throughput and reduce cycle time and and so on and so forth and so um you know lean to help teaches us that a you know from a system a a local optimization and optimizing a small individual piece oftentimes results in a suboptimal whole and so um i don't want to just build these small things and optimize my entire system around building these just small individual increments you know in such that doing so would reduce my ability to do that and so i'm going to be working on that and i'm going to be working on or make the entire system less optimal in terms of my ability ultimately to deliver a product or deliver you know could be the test or inside an organization or whatever the whoever you're delivering or wherever you're delivering to um i think it's i think it's tricky right there's a balance um but but you need to understand why you're breaking something down and you what you said is is true it is easier to understand it's easier to manage um you know in our minds and what we're working on and and for somebody to review and provide feedback all of that is true um but i think you have to sort of frame that with the context such that we're delivering value or that we're optimizing learning or that we're reducing risk um those are the things that end up being the greatest constraints and that's how that's one of the ways that a client will ultimately end up buying into the idea in the first place right um if you can if you can recognize okay the best way to deliver value earliest in this is to create a system that's going to be able to deliver value to the client and then to create the smallest version of value uh the right highest return over time uh there there is a really interesting thing you said in there that i'd like you to kind of expound on if you don't mind sure um and and i'm just going to take all the knowledge that you can possibly give us uh in all the years that you have in the experience that you have at scp but uh the discussion of uh hyper optimization or or local optimization creating a a less than optimal outcome for the whole can you kind of discuss a you know why that is and how that actually plays out sure so it's a concept that really originated from lean manufacturing and so if you think about um if you think about a series of machines on a manufacturing line that's producing a physical product and i have all the all the all these let's just say yeah we have five different machines there each one performing a job and then passing the results on to the next one and so on and so forth um optimizing each of those individual machines working to to optimize that each one of them is the most efficient and the fastest as possible doesn't often result in the the greatest throughput through the system meaning one of those machines is slower than the rest and um if if that one ever is starved for work it's going to slow the whole system down and um and so i i need to understand that and i'm going to understand and this is kind of comes from again sort of lean manufacturing but was originally from sort of this theory of constraints and that a system has a single constraint and if i don't work to manage that constraint the whole system is going is going to suffer as a as a whole and so in software development um i'll oftentimes see um i'll give you a real example we were working on a product for a customer that was a lock would um would be installed in small office buildings and the lock was a wireless system and so there was firmware in the actual lock there was um communication protocols all the locks would talk to each other there was a sort of central router um and admin interface that to the system and so if it was in a school or a building you could lock down all the doors at once or you could set different schedules on different doors and so you basically could control this you know you get access control to this this physical location and so you could lock all the doors at once and so you basically could control this you know you get access control to this this physical location and so you could lock all the doors at once and so you could lock all the doors at Well, we were building essentially all three of those pieces of the parts. We had sort of three individual teams working on the firmware. We'll just call it the router software, the high-level sort of admin piece, and all the communication protocol in between. And when it came to doing – we were working in an agile way. And when it came to doing sprint planning and sort of laying it out, each team was picking the pieces that was easiest and made the most sense for them to do. So the firmware team was selecting user stories or tasks that made the most sense for them. They're in this file. Hey, it makes the most sense to do A and B with C because we're all in the same location. So I'm going to focus on that. And every team was doing this. So every team was optimizing and looking at the entire process, pile of work that they had to get done. And they were planning and developing and building it in a way that made the absolute most sense for them. Okay? Now, all that's going through development, and things are getting into test. And we use Kanban boards and visual task boards. And so all of a sudden, you started to see tickets start to pile up in test. And you're thinking, okay. Yeah. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay.! and test and validate this, you know, or work with real users to make sure it's working. And nothing was getting through the system. We were getting lots of stuff done. I mean, we were flying all three of those teams individually optimizing, but all of those pieces didn't work together to form a bigger whole unit that we could then test. So features were in the firmware, but maybe the communication protocol wasn't ready to support them because it hadn't made sense for that team to build those features. And maybe some of the communication protocol was there and it was in the firmware, but you couldn't actually do anything with it because the interface to the router and stuff wasn't built yet. Or maybe there was features in the router, but it wasn't in the firmware. And so you had all these pieces. And so you had this thing piling up and test. And so nothing was getting through and things were piling up and delayed work creates additional work. And the more things sit there, the more likely defects are going to, you know, delays also increase, reduce quality and increased number of defects. And so you start having quality issues and the whole system started, right. You can sort of see sort of slow down. And so what we did is we backed off of that and said, look, we need to get something through test, ultimately into the customer's hands to look at, to test and make sure all these pieces are working. And so from there, we started working backwards. Well, in order to do that, what do I need to test here? Well, I need to test this. Okay. If that's the unit I'm testing, that's the smallest piece of value I can deliver to the customer. What does that mean for each of the teams? What does that mean for the customer? What does that mean for the team? What does that mean for the team? What does that mean for the team? What needs to be there for each of those teams? Well, initially the developers resisted that notion, right? Like, well, you know, test is usually the guy at the end that kind of is the, the afterthought and just, you know, it just gets whatever's handed to them and says, go test. But it was actually starting to drive and influence development. And, and then in some cases it, you know, going back to say a team that was implementing features A, B, and C, and it made sense to do all three of them at the same time, because they were, they were all in the same file or the same part of the code base. But doing B and C was going to take three days and just doing A was going to take a day. And so now I'm delaying testing in this release by several days or several weeks and so on and so forth. And so it started to feel very, developers didn't like the notion because it started to feel very suboptimal to them. They, they didn't feel like they were, they were working in a very efficient way, which is something that's very, very important. And so, you know, I think that's something you'll hear if, if, in a system, if you're, if you're not the constraint, right, if you're not the system, it feels like what you're doing is maybe not real efficient. But what happened was, is we, we were able to double our throughput and reduce our cycle time by half by sort of reorienting. So we were basically getting twice as much done twice as fast as we were before. And, and the reason that happened was, is we started looking at the entire system, the entire value stream from, you know, this feature inception all the way through to delivery and what pieces needed to be done. And we were only working on those pieces. And again, it felt inefficient to some of the developers or some of the development teams, but in the end, what, what it, what it produced was a much better overall system. Yeah. Yeah. That's absolutely. I see that a lot, right? A developer wants to do what makes the most sense for them. And they, and it happens, and this is why we use visual task boards on Kanban because developers make decisions and it's not always clear, clear the impact of those decisions. So I'm going to go and do this. It's not going to take me that much longer to do this other thing. Maybe it's just a couple of days, big deal. So when your project, what's a couple of days, right? Oh, but those couple of days means this gets delayed by a week and oh, well, that's delayed a week. Then this gets delayed by a month. And all of a sudden all of those things start to pile up. And when they don't have visibility and understanding of what those individual decisions do it's hard to make good decisions. Yeah. Yeah. Absolutely. Sorry. That was a very long answer to that. Not at all. No, I think that's a very excellent answer to to what ultimately may not feel like an intuitive problem to people because that, that the first version of that discussion where you're talking about, you know, having systems that are, that are really on their own working quite well, it's well-oiled machines. And we see this a lot in web development when we have a siloed, guilds of people, right? So you have people who are really good at front end web development and they're in one kind of silo. And then you have people who are really good designers and they're one silo and things come in and you know, that silo is a really well-oiled machine. They, they crank through exactly what they're given and they pass it along. They throw it over the wall. And the problem is, you know, very seldomly, you know, and this isn't, this is, I'm not saying specifically at the company I work at, but, uh, you know, there's a lot of people who are really good at front end web development and they're in one kind of silo. And then you have people who are really good at front end web development and they're in one kind of silo. And then you have people who are as a general rule in web development, the problems end up arising when, uh, you know, the, the design doesn't quite translate very well to web, right. Or, or when the, uh, the, the front end developer didn't quite exactly get, uh, you know, something from design correct in, in the interface. And so there's, there's a lot of that, that, uh, really we need to learn from this, this multi, uh, discipline team, the, the idea that, Hey, you know, if you're a designer, you're going to have to I'm going to be able to learn from you better. And you're going to be able to learn from me better. And really, and I say this all the time, we're building one thing together. It feels like in a silo, you're building multiple things, but when you actually integrate your teams, you, you realize it's like an epiphany that you'll have. You're really building one thing together. And that's such an important, uh, distinction to make as you work. And I have found that, that, um, we use a lot of visual controls and visualization in our work to help us see those things, right? Cause a knowledge work, it's very difficult to see inventory piling up. If we were working in a manufacturing floor, um, you could see inventory piling up and you could see, you know, this siloed group of people over here, the UX team producing lots of assets that, um, that, that are piling up, right. But in a, in a virtual world, digital world, you don't see that you don't see code, um, and artifacts piling up. It's not evident. We're walking through an office building. And so we want to make that, that hidden work, that inventory, that virtual digital inventory, we want to make that, um, apparent and easy to see. And so we'll do a, we do an awful lot of stuff to create, you know, visualizations and, and, um, uh, visual representations of that work so that we can make better, but ultimately make better decisions. It's been a jam packed episode of Developer Tea. Thank you again to Chris for joining me, uh, for today. Today's episode, make sure you subscribe if you don't want to miss out on the second part of this interview. And more importantly, beyond the second part of this interview, we're going to continue releasing three episodes a week. Uh, this show is going to continue moving on and we have tons of, uh, uh, incredible content planned for this year. I'm more excited about this year. I've already said it many times already, but more excited about this year of Developer Tea than I have been any other year previous. So please, if you find yourself in that group, motivated developers, driven developers, and you want to level up your career, of course, level up your career. But beyond that, kind of start with yourself. Start with the person rather than just focusing on your career as if it's an object external to you, right? Philosophically speaking here, imagine that your career is a part of you and you're bettering a part of yourself by leveling up in your career. That's what we want to do with this show. So if you are ready to accept the challenges and the difficulties of taking on that huge responsibility of crafting your career and finding your purpose and developing your principles and practices, this show is for you. Please subscribe so that you can join us for more episodes. Thanks again to Linode for sponsoring today's episode of Developer Tea. If you want to learn more about how to develop a career, please subscribe to our YouTube channel. Essentially a free $20 bill. It's four months worth of Linode service. The plans start at $5 a month and you get a gigabyte of RAM on that plan. If you want a full four months of free service on Linode, head over to spec.fm slash Linode. Use the code developer tea 2018 at checkout. Thanks again. And until next time, enjoy your tea. See you next week.