Today's episode is full of all of the things that you come to expect from Developer Tea. And if you are just now listening for the very first time and you end up enjoying this episode, I encourage you go ahead and subscribe in whatever podcasting app you use because this is a perfect example of the kinds of things that we talk about on Developer Tea. This is the second part of my interview with Andrew Ofstad, the co-founder of Airtable. If you haven't listened to the first part, I encourage you to go ahead and listen to that first. Just in case you end up feeling a little lost in this episode without the context of that first one. Thank you so much for listening. Now let's get into the interview with Andrew Ofstad. So I talked to a guest on the show, his name is Kalid Azad, he created betterxplain.com, which is a site that's essentially dedicated to making math interesting again. That's my version of what Khaled Azad does. And one of the things that he talks about is his method for learning. And I actually want to know a little bit more about your style of learning and how you kind of bring, for example, you mentioned mental models. I assume that's a big deal for you and for people who work at Airtable. But before we get to that, his model is called the adept method for learning. And I don't believe that he created it. I can't remember it. But essentially, you start by creating an analogy. So tell me what it's like. Give me some kind of thing that I can hold on to that I already understand that I can kind of use as a comparison. Yep. And then he says, give me a diagram, help me visualize it. Give me something that shows me kind of a 10,000 foot view. What does this thing look like? Then he talks about an example. Let me experience this. Let me actually see. So, you know, applying this to machine learning, you can say, oh, well, a machine learning is kind of like a prediction machine, right? It creates a prediction. And guess is based on some kind of information that you give it, guess is something on the other side. And then, you know, you could diagram that. You could give an example that helps somebody actually experience what it's like when machine learning is correct, you know? Yeah. And then also what it's like when it's wrong. And then plain English is the next step. So describe it with everyday words, which is going to be very similar to something like an analogy. And then finally, the technical definition is the kind of the most granular piece of the puzzle discussing the formal details. Yeah. This is such a cool, cool way of thinking and learning. I'd love to know in your experience, you know, do you approach learning intentionally, for example? Do you have a regiment that you follow? How do you continuously grow? Do you believe that continuous growth is important? Yeah, that's a great question. I guess I sort of have always been a pretty visual thinker. So I sort of the second part of what you just said really resonates where it's kind of, you know, kind of building that visualization in your head. And I like the idea of trying to experience that as well. So I definitely do do that. And I would say like, you know, a lot of time when I'm doing creative work, a big chunk of that is just sort of like what I think of as kind of booting up and just kind of building that model in my head and sort of like reading all the, you know, you know, from like sort of working on a feature or something in the product is kind of like getting all the data in there and sort of like reading all the feedback from customers or whatever and kind of just like getting setting the context and then kind of like building up that mental model where you can actually kind of see something. And then from there, you can actually kind of run simulations and say like, you know, if I were to come in and do this, like what would happen? And this scenario would happen, that scenario and actually just kind of visualize how things would play out. So I think like, yeah, I think learning for me a lot of times is the process of kind of like booting up and building that mental model and being able to visualize something. I like the idea of trying to kind of, you know, communicate that afterwards. And I think it's in a medical school where there's kind of like this concept of the way you learn something is, first of all, you like read it or study it and then you actually like do it. So, you know, if you're like learning some surgery, first of all just kind of read the book and like, okay, I got that, this is how you do it. And then afterwards you go actually practice it. So, you know, eventually you're kind of like under supervision practicing the surgery and trying it for the first time. And then after that, the way you really learn it is teaching it to somebody else. So if you're like a resident in medical school, you are then required to sort of teach that to the, you know, upcoming med students. That's kind of a process they use. And I think, which makes a lot of sense, like the sort of teaching it is kind of the last component to make sure that you understand it. And it's like another, yeah, I also like this kind of problem solving trick for developers, like the rubber duct buggy, where it's kind of like talking through a problem a lot of times will kind of lead you to the solution and make sure, like, communicating something is one way to make sure that you kind of know all the moving pieces of it. I think like another way that at AirTable, we put a lot of emphasis on is just kind of writing stuff. So, you know, I think Jeff Bezos said, Amazon said this, but like writing is thinking. And you know, I guess famously in Amazon, before you go to a meeting, like you're required to write up a two page memo. And you know, part of that is to save people's time, the meetings so they can read it beforehand. And then discuss the sort of media topics that are in that memo. But I think a big part of it too is basically the process of writing requires you to think about something at a very detailed level. Not only that, but it requires you to communicate it and sort of teach it to somebody else. And as you mentioned, that's sort of like one of the best ways to learn a problem and make sure that you're thinking through it comprehensively. Wow, I love that concept of requiring some level of writing. Even if it's just a five sentence, like a single paragraph, would go a long way. I don't know that I can convince somebody to write a two page memo, but certainly if you're Jeff Bezos, then I assume that people will listen to him. But man, that is a really interesting concept to bring people into that thought process and say, hey, you know what? Let's not start thinking when we walk in the door for the meeting. Let's get a little bit of that loaded into memory before we get in. Yeah, and yeah, it's sort of the, you know, also a reaction to the PowerPoint culture and Edward Tuffty talks about this a lot in one of his books. But basically, you know, a PowerPoint is this very condensed form of information and low density way to communicate. And so like you can sort of get by, create a PowerPoint that doesn't have a lot of depth or thought into it. Whereas if you really write something down, you have to connect all the pieces and really kind of put a much deeper little thought into something than you might if you just had to toss together a PowerPoint with a few ball points, you know. So I think that's one of the other motivations for the kind of written memo thing. Yeah. I have a few questions for you before we, before we round this thing out, I want to make sure I get to get to all of them. I think let's switch gears a little bit to a completely different kind of avenue. I'd love for you to talk about a time, if you can, a time where you feel like you were either aimless or you didn't really know exactly what to do where to go. Maybe you had a significant failure that you're willing to talk about or something like that that really kind of defined for you something important. Maybe you had a breakthrough where you figured out something about yourself or about the work you were doing that was enlightening for you. Can you talk about a low point? Yeah, I guess like going back to college maybe I sort of had this conception that I sort of was into, you know, as I mentioned back in high school, I kind of got into software because of video games. I sort of went into college thinking that I wanted to work on the hardware side of things. I studied electrical engineering and I sort of, you know, I think I looked around at a lot of the things that other people graduating in electrical engineering were doing and it didn't seem to interesting. I think because you sort of kind of worked on a very tiny piece of kind of a larger project and a lot of times kind of companies that really aren't doing much innovative, much in terms of innovation. And so yeah, I think at that point I felt a little bit like, you know, like maybe, yeah, I sort of like always had this sort of idea that I really just kind of wanted to work on something where you're sort of like, you know, actually making more of a direct impact on people's lives through creating something new and doing something very creative. And I sort of thought that, you know, as electrical engineer and, you know, studying economics, like I was kind of starting to look at jobs that just didn't really, you know, kind of feel like they had that creative aspect. So, you know, jobs and like consulting, for example, and sort of like, yeah, just kind of standard electrical engineering jobs like place like Intel and stuff like that. And, you know, I guess I just wasn't too thrilled about that career trajectory and I was sort of like kicking myself for not, you know, studying computer science. But, and this was kind of like getting towards my junior year. And I had friends who were kind of at that point, you know, it was back in 2008. So, not a lot of people were actually, you know, too hot on startups and there wasn't kind of the same cashier on that as there is today. But I had a friend that went to work for Google and, you know, talked about how amazing it was and I was just like, man, that sounds great. Like you work on these small teams, you actually kind of, you know, it's a very, you can actually have a big impact. And as an engineer or a product manager designer at these tech companies, you can sort of, you know, just from nothing create products that just impact, you know, millions of people. And that seemed super appealing to me. But I was sort of not exactly in that path. So, I kind of like shifted gears and got, you know, kind of switched, you know, with my create bill and more over to computer science and really just kind of like started working on side projects and doubling down on that stuff. And yeah, so I think that was sort of a transition. And since then, I've sort of been, you know, kind of on this, this kind of, you know, in the software space and, you know, such a great medium to work in just because without any capital, you can just go create something that impacts a lot of people, as I mentioned, whereas that's not a case in other industries. Now, looking back, I guess there are a lot of cool stuff, you know, companies you could build if you're a electrical engineer and cool projects you could work on. But I guess for a while, like, you know, it's kind of like a bit of a list list that you had mentioned where it's, you know, kind of like, oh, maybe this isn't, I've been studying this for a few years, probably isn't what I want to do. Like, how do I kind of change, tackle it? Right. Yeah. And that can happen with software development, especially because it starts to, you know, it starts to, it kind of can be a self-feeding thing where you get really interested in software development and then you're developing software because you want to develop software. And so a lot of Developer That I know have, you know, they end up working in a job where the development process is really particularly interesting or maybe the tool set is really interesting. But eventually that spark for that particular tool set runs out. And then they're kind of left with whatever the company is doing and that can be really difficult. That can be a really difficult place to end up in because, you know, you ultimately, the only way is to either really love and appreciate what the company is doing or to innovate on the tool set. And so that leads you in kind of a constrained position if you don't love what the company is doing. And if the company is relatively invested in the tool set, then it becomes kind of a difficult spot to be in. But I think that's really important to recognize up front that software development is such a kind of a polymorphic thing, you know, pun intended, but truly polymorphic in the sense that, you know, it really wraps around almost every industry and almost every kind of mission that may be stated. You can go to Mars with software and you can also, you know, manage paychecks with software. So there's a very big gap in between those two things. Yeah, for sure. And, you know, I think the other thing I kind of learned in that process is, you know, I have this feeling in college sometimes where it's like, oh, it's too late. I'm kind of like locked in this trajectory. But I think that anything you do, if you're going to do it well, you have to be at a path of lifelong learning. And so, you know, you can sort of change direction at any point and just take it upon yourself to learn something and sort of go out in your own and basically just be, you know, a voracious consumer of information and build aptitude to something that you would kind of like like to do and that you should be doing to kind of grow in whatever way you like. So I think just sort of like there is some amount of kind of self-actualization, realization of like being able to kind of do that that emerged out of my college experience. I think that was incredibly empowering. Yeah, yeah, that's a great experience to have. There are a lot of people, unfortunately, that come out of college without that experience. So it's really good to hear that you had that experience. You know, I've actually found that a lot of founders specifically studied electrical engineering. I think that's a really interesting kind of probably just a correlation. But maybe there's some kind of cause hidden underneath there. I think, you know, maybe it's that principle's first thinking that you have to do at that level in electrical engineering. I don't know. I think that's kind of interesting though. Yeah, yeah, I'm not sure. I think part of it is, you know, studying anything that is kind of, you know, physics-based. You sort of have to have the skill, like we said earlier, to kind of build that mental model. And you can't do that. Yeah. You're not going to be good at sort of understanding how, I mean, it's not a very, very intuitive thing, right? Like how, you know, circuits work and that type of thing. So you have to be able to kind of build up this mental model. And I think that's a skill that is transferable to pretty much anything you're doing. If you're going to sort of create something or optimize something in the world. And you said you studied economics as well, correct? Yeah, I did. I think initially I sort of did that because I was interested in the business side as well, but I think the thing I learned there is that that's also just like another, you know, most of the class you take, you're just kind of building out these models for the economy. Most of the time those are sort of like, you know, grounded in kind of shaky principles, a lot of times. But you sort of, it's another thing where you're kind of thinking about what's the model for this and what happens if we do that, like what happens if we take that. So I think I sort of enjoyed that process. And it's actually tied pretty closely to some of the kind of problem solving you do on the interior side. Yeah, that's what I was going to ask you about is if you, because I didn't study economics I study it kind of as a pop psychology behavior economics. We talk about that on the show all the time. So I see a lot of correlation. I wanted to know from a formal side, if it felt like a lot of correlation to you as well, just the idea of those various models, economic models, you know, demand curves and all those things, they look a whole lot like some of the stuff that you would see in a computer science class. Yeah, for sure. It's a lot of the same, you know, I mean, it's kind of based on math. But like I said, some of the kind of basic assumptions are sometimes questionable. But sort of, you know, some of the earlier classes too were less quantitative and more qualitative. So, you know, they kind of give you a bunch of rules of thumb and you'd be like, oh, but why is this the case? And tell you the sort of the mathematical principles behind that and tell like the later classes, which was kind of frustrating. But I think some of the best courses are like econometrics, which just, you know, gives you thinking about like modeling based off of data and just like really apply statistics, which is incredibly useful for any discipline. And then like a lot of it's just kind of like, yeah, what's the curve look like? You know, how does this, you know, what if these inputs change like how to things shift and that type of thing, which is sort of, you know, just kind of more modeling? Yeah. How does this respond to a different input? I think that's, you know, that really is a problem solving, exercising in and of itself is, you know, how does this, and you carry that into every part of your career really. How does this change as I change the input? What is the output? What is the effect? That's really a key factor, especially for software development, but in many other fields as well. Yeah, for sure. Today's episode is made possible by Linode. Linode is our sponsor for today. And with Linode, you can get up and running in just a few minutes with your favorite distribution of Linux. Now, what can you do with Linux and the cloud? Well, just about anything you can imagine doing with Linux locally, except now you can actually network it with multiple instances. For example, you can use Linode service called node balancer and spin up the same application on multiple instances of a Linux server. And now you can balance between all of those, depending on the load that your application is taking on. If you want to run your own private internal network or maybe you want your own private get repository, you can make those things happen with Linode. Go and check it out, spec.fm slash Linode, and you can get started for as little as $5 a month. Now, that may sound like it's an entry-level product, but Linode also provides a very high-level services and products as well. High-memory plans, for example, and even DevOps as a service. If you don't want to focus on DevOps and you just want to focus on your application and writing code for the business side of things and making decisions in that sphere, then Linode can take on the DevOps portion for you as a service. Go and check it out, spec.fm slash Linode. You can get $20 worth of credit if you use that special link or if you use the code Developer Tea2018 at checkout. Spec.fm slash Linode. Thank you, Gindel Linode, for sponsoring today's episode of Developer Tea. Okay, Andrew. So I have another question for you. At AirTable, let's say I am a student software developer, software engineer, aspiring, I just got out of school and I'm applying for jobs. What are you looking for from a developer when you're hiring at AirTable? Yeah, so I think, first of all, we look for real passion for creating anything, whether it be software or something else. Obviously, it's important to have projects you've worked on, maybe have a website where you've created a bunch of cool stuff or just any cool projects you've worked on. I think we really love candidates who have a mix of skill sets and are really multifaceted. We have a lot of people like this in the team where you're a front-engineer but also a designer. Our design team, for example, are product designers or actually really good front-engineers so they can actually build out the UI that they design. Likewise, we have engineers in the team who are basically fill their role of product manager and some people are very good at writing and just I think not just being really good on a technical level but having some other skill you can sort of mix in with that I think is a huge plus for us and it's something that we've tended to had a lot of that in our team so far which has been amazing. So that's one thing, definitely if you studied CS or you have some technical background but you're also really into the design side and you have a good portfolio that would be a very appealing thing to us. But generally for small people that seem interesting and have sort of a, yeah, I would say just generally curious and intelligent and we're sort of good at building things. There's the kind of main things we look for. Yeah, I think what you mentioned there is so true for a lot of the future jobs. I think AirTable is going to be one of the companies leading the way on this but a lot of the future jobs that developers, designers, project managers, product managers that those jobs are going to blur the lines further and further especially in the actual production roles that those lines are going to continuously blur further and further and so you'll see I think a lot of the best products will be built by a bunch of people who don't really have perfect titling because it's just not really relevant. Yeah, exactly and I think it helps to mix different disciplines as well because the one example is knowing how to be a designer who can actually do the engineering piece. You sort of, I think like, to take in another stab at this, I guess the best architects are ones that have a very deep understanding of the material and they know that in order to support this building, you have to have concrete that's reinforced in this way or like this would have to be, you know, or instance, you can only kind of solve the problems, the best possible way by sort of understanding the material and I think sort of being able to understand how the software, the engineering side of things when you're designing allows you to kind of make these mental trade-offs between like, yeah, we could do it this way but, you know, yeah, it's like this is a better way to do it and this platform and that type of thing like those are very important even if you're just kind of not actually doing the engineering part mostly designed but yeah, it's good to know the material if you're doing any type of signwork. Yeah, and generally intelligence in the creative sphere, I mean, I think a lot of this is, you know, shifting from one place to another and so you'll just, I think these roles that we've had previously defined, it's strange because you're seeing it go both directions, it used to be a front end developer, now that role is significantly more involved and you can have specialists that are much more deeply involved with a specific slice of the front end, whereas it used to be, you know, you could be a web developer and that was the full job and you were expected to do the full stack and that has changed, right? So you're starting to see much more granular roles, but at the same time, we're also seeing the need for much more informed and multidisciplinary and kind of like, I don't know, it's weird because it's a generalist concept but with a specialist skill, like a skill in a particular direction that needs to be supported by kind of more kind of, like maybe it's contextual awareness, I'm not really sure exactly how to articulate it though. Yep, yeah, and I think like certainly as you progress in your career, you sort of start, you know, kind of connecting different pieces and you're, you know, kind of, you start like, you know, managing teams or that kind of, you know, include a variety of different disciplines and so you sort of have to know all those pieces in order to really kind of compose the best possible combination to those, you know, and so I think like if you want to sort of grow in your career, like you can, you know, it's obviously helpful but be very deeply knowledgeable about a few things but also the more you can sort of pick up other pieces of the puzzle, whether it be, you know, marketing, you know, thinking about a technology company or design or engineering or kind of, you know, dealing with customers, like the more you can kind of master all those pieces, the more potentially you have to kind of move up in the company and kind of handle broader and broader swast and put all those pieces together into the cohesive product, which is kind of not just one, one little bit of that but the whole of all those, those components. Mm-hmm. Yeah, it goes right back to our component discussion, doesn't it? When you can compare multiple skill sets to each other, you actually learn more about each one and it's something that a long while back I did an episode and believe I called it skill stacking but the basic concept is, you know, skill number one is almost certainly going to be more valuable if you add skill number two to it, right? And even more so if that mixture is kind of intentionally curated, for example, you can imagine that, you know, learning HTML and CSS, you're going to become, you know, a much better, much higher value worker if you also learn JavaScript. Yeah. But if you were to learn any one of those on their own, then the value diminishes significantly. Yeah, yeah, that's a good point. Yeah, sort of like having the full, you know, all the pieces individually is not as valuable as them combined into, you know, the actual final product. Yeah, yeah. And I would say that's true for almost all things that anything that you add is going to provide new context for the rest. Yeah, absolutely. Yeah. Well, Andrew, this has been a fantastic discussion. I think I could probably talk to you for another couple of hours about complexity and creating things that are useful for people. Yeah. But I'd love to go ahead and ask you these final two questions that I ask every guest that comes on the show. The first question is, what do you wish more people would ask you about? What topic do you want to talk more about? Let's get question. I think we covered some of the topics, honestly, just sort of, you know, talking about people, yeah, sort of, let me think about this for just a second. I might have to edit. Sure. No problem. No problem. Let's see. Yeah. I think actually one of them is just general, you know, I wish more people would sort of ask what kind of the meta lessons are of how to, you know, sort of grow as a person and grow in your career. And obviously I am still pretty early on this journey. But I guess, you know, one is that I think you, you know, you shouldn't be afraid of kind of stepping into new things and trying out new disciplines. And I think we've touched on this in a number of cases. But yeah, I think like people are oftentimes kind of like label themselves as one type of role or another or being good at one type of thing or the other. And, you know, I've always had the mindset that it's worthwhile to just kind of like dive in and know that you're going to be bad at something when you first start on it. But basically it's worth worthwhile kind of if you want to do something and trying to not be afraid is a huge component to being able to sort of, you know, kind of branch out from and really grow as a person. So I hear a lot of people who are listening to this show right now in my head asking, oh, well, does this apply to stepping out into, you know, a new job or does this apply to, you know, how does this apply practically to me as a developer that feels stuck? Yeah, I think part of it is just if you can get yourself excited about something, whether it be kind of learning design or, you know, just learning, you know, how to serve for something just your random example. Like, I think part of it is just, you know, building, building the excitement and sort of just kind of, you know, wanting to do something enough where you just kind of start doing it on the side and maybe ask your job, that's tough and a lot of scenarios I know. But, you know, or even in the workplace, you can sort of start trying to get involved in kind of reading what people are doing on the marketing side of the company or kind of, you know, just paying more attention to what the designer is doing and kind of trying on your own to sort of do that type of thing and not being like embarrassed about it. I think, you know, that's kind of real ways to just kind of start doubting initially and just kind of make sure that you're excited about something and hopefully that will provide some motivation to just kind of do it and maybe even outside of your, your core responsibilities. I think that's excellent advice and it may have actually covered an ex question, but we'll see. What is 30 seconds of advice that you would give to developers of all backgrounds, all experience levels? Yeah, I guess one thing that I've kind of learned over the years is that I think the best way to basically, you know, build the best things and kind of be the most productive is to kind of, a lot of times drop your ego. And I know that like in, you know, creative industries, a lot of times there's like a lot of, part of authorship and people think that they have this brilliant idea and are sort of oftentimes reluctant to give it up or to kind of listen to other viewpoints. And so I think like just having an open mind and taking feedback and basically not letting your own ideas get in their way of sort of listening and kind of curating all the best ideas from different people in the team. I think like, yeah, if you're going to work in sort of an environment where you're kind of creating something with a bunch of other people, you just have to know how to sort of harness the power of the group as opposed to basically being too tied to your own ideas and that type of thing. So I think, yeah, just generally having an open mind and kind of making sure that you're kind of waiting, curating the best ideas in your own versus trying to kind of push your own agenda is a great way to sort of add the most value to any group of people. So yes, that's definitely one big one. And I think that's also a way for you to grow is to be open minded to new ideas and points of view and perspectives and think about them rationally rather than sort of letting your ego and your desire to sort of like win argument or conversation getting away. And I think that's something that, you know, especially developers who engineers and designers who have very strong opinions, I think sometimes that can sort of, you know, get in the way of them progressing and contributing as much as they potentially could to a team environment. Yeah, you are speaking my language right now. I love this stuff. Excellent advice. I think especially, if you're listening to this podcast right now and you have somehow ended up in a position of leadership, you know, by way of whatever has happened to put you there, I think this is especially important for you because so many times an organization will get kind of limited based on a leader's ego because here's the key. A leader's ego ends up being the most difficult ego to challenge. So like if you're a young developer and you come in with an ego, you're very likely to get kind of squashed like somebody's going to tell you, hey, you know what, what you think doesn't really matter compared to what's true, right? Which is really kind of the, that's actually true. Hopefully you get that lesson. Hopefully somebody, you know, more tactfully. Hopefully somebody says that to you early so that you can say, you know what, you're actually right. And what I think doesn't really have any bearing on reality, you know. But if you're if you are in a position of leadership and you don't have that lesson under your belt, then very often you become kind of your own echo chamber and the people who work with you very often have a harder time questioning that difference, right? Unless you cultivate that kind of that positioning, that culture, that can be a toxic, toxic thing. If you hold onto your ego too strongly, and I really like the other thing that you said, Andrew, the idea that I think people don't even realize how badly they want to win at conversation. Yeah. Yeah. Not in a competitive way necessarily, sometimes just in a protective way. Sometimes I just don't want you to think that I'm dumb, right? And so it is normal. It's normal to want that. Yeah, it's human nature. And I mean, I think part of it too is the way that you're going to, if you're in a leadership position, the way it's going to deliver the best results is by taking the best from your team and pushing that forward. You have to, even though maybe you'd rather, as you mentioned, win the argument, the sort of more, the thing that's going to be better for you is to basically take the best and then make it just based off of that. So yeah, yeah, definitely. Don't get married to your ideas. Yeah. Yeah. Excellent, excellent advice, Andrew. And thank you so much for taking the time to talk to me. And I really appreciate the work that you're doing with AirTable and all of the concepts that you shared on today's show. I think it was extremely valuable. Thank you so much for your time. Yeah, thank you. I really appreciate it and enjoyed the conversation. And yeah, thank you so much. What if people want to follow you? Do you have Twitter or something where they can go and learn a little bit more about you? Yeah, I'm on Twitter. I don't tweet that much. It's a off-stead. You can just follow AirTable. So at AirTable on Twitter, that's kind of most of the stuff I tweet about is what's going on. But the company is a lot of what is going on with me. So I would encourage you to just follow AirTable instead. Perfect. There you go. Well, thank you so much, Andrew. Great. Thanks a lot, Jonathan. Thank you again to Andrew for joining me for the last two episodes of Developer Tea. And for sharing his experiences, his insight, his recommendations, and his advice with all of the awesome people who listen to this show. Thank you so much for listening. If you haven't taken a moment to let us know what you think about Developer Tea, I encourage you to do so. It's the best way to give me feedback and to help other developers just like you find the show. So to do it is either in the Google Play Store or in iTunes. Thank you so much for listening. If you haven't subscribed yet, go ahead and subscribe and whenever podcasting app you use. So you don't miss out on future episodes. And thank you again to Linode for sponsoring today's episode of Developer Tea. You can get $20 worth of credit by heading over to spec.fm slash Linode. Use the code Developer Tea 2018 at checkout. Thank you so much for listening to today's episode. And until next time, enjoy your tea.