Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I have the pleasure of continuing my interview with Russ Taylor. Russ works on the continuous integration team at Etsy so he's working on a very big product and that was what made it so interesting to talk to Russ. He's working with a team of quite a few developers and he is talking about how to make things easy, how to lower the bar of entry to allow everyone to start testing. We talk about the importance of testing as well and in this episode we also talk about how to stay productive. I hope you enjoy this episode of Developer Tea with Russ Taylor. Russ welcome back for part two of our interview. I'd love to jump in and start the interview or start the second part but I want to do a quick recap of what we talked about on the first part of the interview. We talked about continuous integration and doing programmatic testing and how every business is different, how testing looks different for every business. What else did we talk about on that last last part? Just kind of making testing easy, making sure that you kind of have a level of confidence in your tests. Definitely. So speaking of making testing easy as someone who is primarily involved with the testing culture, we're going to talk a little bit now about how to encourage Developer To continue testing because it really comes down to being disciplined and doing those tests, actually writing the tests because it's not always easy to continue forcing yourself to write tests especially when you know exactly how to solve a problem with code already, writing a test for something that you already know is going to work, sometimes it seems like overkill. So how especially as a senior developer that is trying to mentor junior developers and make sure that the quality of our code is continuing to be high quality code, how can I encourage those younger developers especially to continue writing tests and even when it doesn't feel like they need to? I'd say one of the biggest things is especially when it especially applies in a larger organization, but I'd say even just if it's just you on a project, it's still important because you want to make sure that things don't break in the future. So even if you know exactly how to solve a problem and it's going to be really straightforward and you just want to get the resolution to this issue or build out this feature really quick, testing allows you to know that in the future if someone makes a change or if you make a change that breaks that feature or breaks that method you wrote, whatever it may be, you know that the test is going to catch it and that the test is going to let you know, hey, there's a problem here. That's one of the biggest things is causing those regressions, those bugs that in a feature that was perfect beforehand, but something changed maybe in something that it depended on. Let's say you have kind of a layer of abstraction to deal with the database. If you're changing something there and all of the rest of your code is depending on it, you want to know if you break something in the rest of your code and if you don't have tests in place, chances are you're not going to notice it and that's the problem is that a lot of bugs can be so subtle. And if you don't have good testing in place, you'll just never notice that it's a problem. So like for example, I know especially when you're dealing with payments and things, just little things can make a big difference. I think just a few weeks ago, there was an issue on Etsy site where we were actually overpaying some sellers and we were underpaying other sellers. So it could have been as simple as a rounding error. But when you're dealing most terms, it makes a big difference. Sure. Especially when those numbers start getting multiplied, right? Because you see 50 rounding errors. Well, that's no longer a rounding error. Exactly. And even technically speaking, 10, that is no longer a rounding error. That's actually a true error. It's beyond that decimal point. Right? And that's a hard, sometimes that's the hardest type of thing to test because you may not even see the reality of testing is there's never a way to cover every possible scenario in the world. Right? No, definitely not. You need to cover the most important cases. And I think another big aspect of testing is making sure that you have a good infrastructure in place for testing. You need to be running the tests often. One thing that we do at C, I know it wouldn't necessarily work everywhere, especially if, say, you're just doing freelance work. But we actually have in the IRC bot that we talked about in the last episode, that IRC bot before it actually pushes code will tell you if someone is in the push queue who didn't actually run test locally beforehand. We kind of keep track of who's actually run the test that we already have on their new code. And if you haven't run those tests, it'll say, hey, someone so didn't run these tests. I just want you all to know. So there's like a social aspect to that sort of. Exactly. It's kind of a little bit of public shaming. Yeah. On tests. And so that's one other aspect. So you want to run your tests often and you want to make it super easy to write tests. If it's hard to write tests, it reduces the number of Developer That will actually write tests exponentially. Yeah. Well, and it already is hard to write tests. Exactly. Writing tests is a difficult thing to do. Don't let anybody tell you otherwise that it's a beginner's level thing. Tests are not easy. And the reason they aren't easy is because knowing what to test is the hard part. Writing code after a test, that's relatively more. I would say that writing test is harder than writing the features that support those tests typically. That's not always true. Typically, that is the case. Now, if you're working with like a difficult algorithm and you know what the outcome is supposed to be, and then you have to write the code to make that outcome true, that's a different story. But typically speaking, there's a lot of creative thinking and a lot of problem solving that happens when you are architecting your different test cases. Because you have to think about all these different problems that might happen. They haven't happened yet. You aren't fixing something. You are predicting a future thing that you would have to fix. A scenario that causes an error. And you want to make sure that it doesn't cause that error. Exactly. I'd say thinking about writing the tests is one of the best ways to actually write bulletproof software. It really helps developing the software itself. When you're writing a feature, if you're thinking of all of those test cases and thinking, oh, what happens if say, you know, I pass in a negative number here, even if you never expect a negative number, those are the types of things that really help you write more bulletproof software. I don't say just bulletproof because no software is ever bulletproof. Yeah, it's more like a bulletproof vest. Exactly. Exactly. It helps. It really helps. If you didn't catch the joke there, bulletproof vest don't always work. But they increase your chances of surviving if you were to get shot. Anyway, the idea here is to, and have you heard this concept of, I'm sure you have the happy path? I actually haven't. Oh, okay. Well, then I'm glad I get to introduce this to you. The happy path, and I'm not going to mess this up. I'm going to look it up to make sure that I'm not going to get this wrong. Hang on. Okay. Happy path, according to Wikipedia, it says in the context of software or software or information modeling, a happy path is a default scenario featuring no exceptional or error conditions and comprises the sequence of activities executed if everything goes as expected. For example, the happy path for function validating credit card numbers would be where none of the validation rules raise an error, thus letting execution continue successfully to the end generating a positive response. So this concept is to write tests for the things that are supposed to happen that are not exceptional cases that are what the user intended to do, they actually succeeded in doing. And that's a different way of thinking about testing than just avoiding errors, because the most common case is that people are going to get it right. People know how to enter their email and password, typically speaking. It is that 5% that spend, we spend a lot of time developing for, but if we don't have our happy paths properly in place, well then what's the point, right? We have to make sure that the software works in the right case as much as we have to make sure it works in the wrong case. Exactly. And that is a useful concept, I think, when writing tests to consider that first and then the diverging paths you consider kind of afterwards and make sure you handle those properly to get people back on the happy path. Exactly. That's exactly what what error handling is for is to help your users get back onto the right path. It's not just to inform them, but to guide them. Exactly. Exactly. And that's one thing if users can break your software, they will. Even if it's just in that 5%, and it's important to be able to help them gracefully back to that path. Sure. Yeah. But you have to have that path in place to help them back to. And that's kind of the idea of that happy of those testing. And that brings up another concept and I guess a question for you. What things do you guys not test? Like what do you say? Okay, that's, you know, you don't need to test that necessarily. For example, we don't test visual stuff. We don't we don't test our our CSS. And I've seen a few articles that have been coming out that talk about, you know, how to test CSS and how to raise, you know, how to identify when you're using hacky or improper CSS. How do you guys handle that? I would say for the most part, we we don't handle that. I think number one, that's one of the most difficult things to test is the visual aspects. Number two, those are the things that either won't affect users as much as say overcharging their credit card. Yeah. Yeah. But also there are things that are much more noticeable. Sure. And so they're not necessarily as important to test. And so the fact that they're so much more difficult to test and they're not necessarily as important to test means that, you know, they're not necessarily worth spending a huge amount of time on. Right. Yeah. Because it takes a lot to try to test that stuff. It does. It does. In in my last last position at my last company, I was writing automated tests that were actually going through the user interface. And it it was so difficult to get the tests stable enough that we could actually be confident in their results. Yeah. They were they were failing for, you know, random little things that the the test suite out ran the JavaScript on the page. Yeah. And trying to click on an element that wasn't there. And the the test failed. Yeah. When that's not something that a user would ever experience. I've never seen a user click around the page in milliseconds. Right. So just the added difficulty doesn't necessarily warrant spending a lot of time there. Sure. And you run into some of those things with with integration tests. Just just a quick overview of what that is. Basically, an integration test is at least my understanding of an integration test. Everybody has their own definitions of these things. But my understanding is that it brings together everything and actually acts as the user to to walk through each of these processes. And that's kind of what you're alluding to there is, you know, it opens up a browser. It actually runs JavaScript stuff. Right. And so you're going to run into some of these difficulties with with integration tests or or things that that try to model a user's behavior. But in reality, it's very hard to model a human. And so so there's some intuition that has to be used and and just be smart. Right. I know that sounds really dismissive. But but be smart about what you're doing. If your tests are failing and they shouldn't be and you can go into your browser and prove that it's that it's working, well, there's probably something wrong with the test suite somewhere. Right. And it warrants looking into, you know, how do you fix the test itself. And that's not to say that you shouldn't be testing, but but that tests are not always perfect, right? They aren't always going to work. Test can have bugs just like code can have bugs because it is in fact code. Exactly. And that's why it's the hardest thing to write. You can't write tests for your tests. It's it's you can't write tests for your tests. You are the tests for your tests. How many times can we say tests on this? A lot more. Exactly. That's the spirit, right? More tests more tests. Oh, yeah. So the moral of the story listeners is to cover your code with tests, especially tests that are for the most critical parts of your application. Really obvious examples of this are, you know, user privacy and interaction with other users core functionality that, you know, is a part of your business model. Anything dealing with payments, anything dealing with passwords and hashing, anything dealing with security, all of those things are the things that you want to test. Not so important to to show everything or to cover absolutely everything in your tests. But the more coverage the better is kind of the moral of the story, right? Exactly. If you have to choose, though, the first 20% that you should be covering should be the most important 20%. Yes. And that goes without saying, I suppose, but I'm going to say it anyway. Cover the most important things, right? Yeah. Most definitely. And coverage, by the way, I meant to say this on the last on the last part one of the interview, but coverage is not just a percentage. And some people show their test coverage. They they tell a particular percentage, you know, whether it's 100% or whatever. Some people have over 100% in code coverage, which I don't understand how that's even put. I guess it's lines of code. Is it a ratio? I don't know how it calculates these things. Yeah, I don't know how it's possible to be over 100% either, but it seems kind of silly. But the reality is test coverage is is an ethereal concept that you can't really nail down to a number. It's a good guess, right? So if you have a lot of lines of code of tests, then hopefully if you're doing the testing correctly, that's a good sign, right? But it's but it's not it's not absolutely, you know, fail proof or it's not absolutely bullet proof or fail safe. Exactly. It's it's something like you said, covering the most important cases is what's going to be the most important. It's kind of repeating important. But it's you know, if you're covering that kind of the critical actions that users are taking most of the time, you know, you don't necessarily need to test everything. You don't need to test that, you know, maybe someone can say, view your about page perfectly. You know, it's it's definitely there are some more important things in that that it takes prioritization and saying, okay, what are the most important actions that users are taking, you know, with this feature or just in the site as a whole and how much do we want to test that? You want to cover every possible test case that we can think of or only the most common right or somewhere in between right exactly only the most common and then maybe some of the least common but not all of them or yeah. Yeah. Yeah. Examples of things that I probably wouldn't cover would be like FAQ pages, right? That that's probably just a visual thing. You can go and test and if an FAQ if a question is missing, you'll probably find out, right? Because somebody's going to ask that question anyway. And you could test it and it would be easy to test, but could you spend your time writing another test for a more important feature? Probably. Yeah. Probably better spent time writing tests or you know, if you are trying to decide between writing a test for your FAQ page or lowering the the barrier to entry for testing for your junior developers at your company, lower the barrier to entry. I'm going to go ahead and make that decision for you right now. Absolutely. Awesome. Well, this is this has been enlightening and I hope that listeners understand that we aren't just you know, obviously we aren't selling a product here. We aren't selling Etsy. We're selling the idea that that writing tests is is a good practice because it protects you from getting into scenarios where people experience your bugs, right? The hope is to avoid future issues by spending the time that you would fix them in the future anyway, right? So it typically is a wash in terms of time. You're going to spend time in the future fixing bugs or you can spend a little more time on the front end writing tests to catch those bugs before you know, the user experiences them. Which one is better? Well, in the latter case, you have to put more investment, right? There's like a 20% investment cost to writing tests up front or something like that. I don't know exactly what that number is, but there is it takes longer to write tests than to just write the feature. However, it may not in the long term be more of an investment than the total amount of time and losses that you would experience if you didn't write tests. Definitely. Definitely. I mean, the goal of tests is really just if you're running your tests, you want to be pretty sure that those tests would catch any catastrophic failures. You want to be reasonably confident that your tests cover the majority of cases that users will see. If you're deploying some code and your test pass, you can be pretty sure that most users will not see any difference. Even if there are some bugs that make it through, which inevitably there are, you just want that kind of reasonable assurance that your tests would catch big bugs. That's great information. I want to take a quick sponsor break and then we're going to come back and talk about just a few more questions that I have for you before we wrap up the interview. Thanks so much to this week's sponsor, Imagix. Imagix is real-time image resizing as a service. It's backed by a CDN with global presence so response times for images average 70 milliseconds. With Imagix, you can manipulate images by simply changing their URLs. Imagix doesn't just crop images. You can manipulate things like brightness, blend modes, and watermarks all by changing the URL of the image. You can even choose from over 10 formats and adjust the image quality all on the fly. There are libraries for Ruby, Python, PHP, Go, Objective-C, Swift, JavaScript, and more. So integration with your existing projects and new projects is very simple. Stop maintaining your Frankenstein image magic setup and let Imagix handle it. It's free to get started. So just head over to Imagix.com. That's imgix.com. Of course, there will be a link in the show notes. Thanks again to Imagix. So Russ, I don't think anybody is going to walk away from this podcast with any question about how we feel about testing. I hope that you guys understand once again that this isn't preaching for the sake of preaching. This is proven. There's tons of use cases where tests have covered me specifically and Russ, but tons of other people. So I would recommend that at least you try it out on a project or two projects just to see how it changes your workflow and how it protects you from bugs in the future. So Russ, I have a few questions that I like to ask my guests and I like to ask them all this because I think it's really important that we all learn from other developers in the community and that's exactly why I actually do these interviews on Developer Tea. So the first question that I like to ask is if there was one thing that you wish more people would ask you whether that's developers or non-developers, what would that question be? I had, if there was one question that I would like more people to ask me. Yeah, so the reason I came up with this question because I come to interviews and I have all this long list of questions that I'm interested in asking people and the reality is, I come to an interview knowing what I would like to be asked, like knowing what I can hit a home run on. And not just hit a home run on, but things that I'm interested in talking about that I wish other people would be interested enough in that thing to ask me about it. And that's kind of the spirit of that question. Right, okay, that makes perfect sense. I like the thought process behind this. I would say one thing that I think developers could almost always pick up on, not even just developers, people in general could always pick up on from other people is kind of how to stay organized and stay productive about things. Like in just your day to day work, how do you stay productive? I think that's something number one that I like to ask other people. And the other thing is it's kind of something that I like being asked as well because it's a way for me to kind of reflect on the way that I handle things. And on how I'm doing in, let's say I've got this process set up for my to-do list. It's one way for me to reflect on how well I'm actually doing at keeping my to-do list or maintaining it or actually using it or whether or not I'm planning out things as well as I could be. And it's something where I feel like we can all learn from each other. Even if someone's process is completely different than yours. Oh yeah, yeah. There are things you can learn. And I like to ask you that question. What would be something that you would recommend? Just maybe something that you're currently experiencing that you feel like is helping you stay productive on a day to day basis, especially. And perhaps there's something specifically for remote workers that you could offer, but anything at all really that you want to share on that subject because I think that's such an important subject for us to learn about. Yeah, I would say one of the biggest things that's made a huge impact for me is just writing down what I need to do. I mean, this applies across the board. Oftentimes, say my wife will approach me and say, hey, could you do this? If it's something that I can't do right then and I don't write it down, then more often than not, I'm going to forget about it. Especially if it's something Monday and like, hey, we're out shopping or something. She said, oh, hey, I really appreciate it if you take the trash out when we get home. If I forget to do that, it's going to hurt her. Sure. And her being. And it's simple. It's very simple to do it, but it's not simple to remember it. Exactly. And so I feel like one of the most important things is having a system where you can write down all the things you need to do. And even as small as they might be, writing down the things you need to do and kind of the process you're going to take. And not even the big things, the little things because our minds are really bad at keeping information and remembering everything. And I think now technology is so good at helping us with that. If you put an appointment in your calendar, say in Google Calendar, it's not going to forget to remind you 10 minutes before or whatever. But if you forget to write it down, it's obviously not going to remind you. The same goes for tasks. If you don't write something down, you can't know that you're going to actually remember it. Right. Yeah. My wife and I actually did this process over the weekend, actually. So it's interesting that you mentioned it. We were talking about all the things that we needed to do. And it felt a little bit overwhelming. And so what we decided to do is write out literally every single thing that we could think of that we wanted to do within the next week or so. Right. And then we gave each thing an effort score. This is the developer inside of me coming out here. We give it like a one to five rating on effort. And we give it a one to five rating on stress. And then we gave it a one to five rating on what I call the must do column, which is basically like, do I really have a choice about this? You know, regardless of how much effort it takes, do I, for example, Developer Teahas a really high must do score? Because that, you know, I'm committed to getting these episodes out. Whereas, you know, I don't know, cutting the grass is slightly lower because I can function with long grass. I might not like it. But I can function with longer grass. Right. And that really was helpful. It helped us kind of visualize. And this is actually a thing. Have you heard of Kanban? I'm assuming you probably have. Kanban. Yes. Yes. So Kanban for anyone who hasn't heard of it is the idea of, you know, limiting your current work and progress. And the very first thing that they tell you to do, I say they, but the very first part of Kanban is to visualize the work. So whether that's writing it down or putting it, you know, put it on postcards on a wall or if you want to do it on your computer, whatever, exactly what Russ is saying is write it down or get it out of you and on to something so that you can kind of see the relationship between the different things that you have to do. The reality is if you go shopping and you have, you know, 30 things to get, try going shopping without a list of those 30 things. And tell me how successful that is. The what will probably happen, what always happens to me when I do that is I go shopping and I get 35 things, right? And about 15 of those things are not even on the list at all. Yes. And so I miss out on the 10 that I was supposed to get and I get more than I intended to get in the first place. You know, it's just it, we're not good at holding that kind of information in our brains. Yeah. It's true. And I mean, there's something to be said, I know it, it sounds like a lot to say, write down everything you need to do. But when you do it, like there's, it's kind of this, this zen that you know, there isn't something that you forget it. Yeah. Yeah. But if you don't so much of the time you'll just spend worrying, did I forget to do something important? And am I missing something? And if if you know that you can trust kind of the system you have in the list that you've written for yourself, it's it's amazing how that changes things. And you don't have to get fancy. Like a lot of people practice GTD and that's fine. You know, the getting things down method. And that is there's a there's a significant portion of this though that is just psychological, right? That you're just trying to hold on to information in your brain. But if you put it out on a list, well, I mean, you don't even have to necessarily keep that list on you. The process of getting it out on paper helps you understand the realities of what those things actually are. Absolutely. And this is totally true for development too. Like if you have if you're working on a project and you need to get, you know, 10 things done this week on that project or whatever, it definitely helps to plan when you're going to do those things. I mean, it's very simple, right? Plan when you would like to do those things and actually write them out, you know, but I like to do this at night for the following day. And some people like that method, some people like to do it first thing in the morning. I like to do it at night and then sleep on it. And then when I wake up in the morning, I don't really have to think about a lot. I just go straight for that list of stuff to do. Yeah. Yeah. You already know where you're going to start and what you need to get done. Now, let me ask you this. When you write out the stuff that you need to get done, do you integrate all of the categories of life? I know some people have like a work to do and then like a personal to do and then, you know, home projects to do and all these different, like, ways of handling. I like to bring everything into a single list so I can say, okay, you know, there's trade-offs in my day, but ultimately, you know, I have the same amount of time in every day, right? Yeah. Yeah. I think that there's a lot of value in having them together because depending on your position and, you know, what you're doing, things aren't always neatly separated in life. And so, you know, if you're out, say you need to ship something for work. If you're right next to say the pharmacy and you need to pick up a prescription, it doesn't make sense to, you know, forget about the pharmacy just because that's a personal thing. Yeah. And just go ship it. I mean, you know, you can integrate things and make it, it's just it's so much smoother. Right. If you can have a good idea of, you know, everything you need to do all in one list or, you know, just in one place. Yeah. Great insight. I think that's a, I think this is something that a lot of people don't, you know, a lot of developers kind of assume that they can just rely on their tools or, you know, I don't know, a list into a podcast that talks about being productive. And then suddenly they are productive. I challenge the people who are listening to this episode to actually try this for a week and see how it changes the way you think. First of all, it's going to be hard because you have to actually change the way you're acting on a daily basis, change the way you're thinking about, you know, the tasks that you have to do. But secondly, I really do think not not one thing works for everyone. But this, this might definitely works for me. It apparently works for Russ. And quite a few people I know this is really effective for them, especially developers I've found. And I think that might have something to do with the way that developers naturally think, you know, in terms of kind of concrete construction and that kind of stuff, try it out and, you know, let me know on Twitter, let Russ know on Twitter that it was helping you or that it was a terrible idea, you know, share with us what you think about this because I think, you know, exactly what Russ was saying, we have to start these kinds of conversations to be able to learn about how to stay productive in such a crazy, busy world. I've talked about this on the podcast so many times about how focus is really hard to achieve, right? It's just notoriously hard, but it's also absolutely necessary. You touched on a really important point and that's that it's going to be different for everyone. And, you know, the important thing is to decide on a process and try it out. And if it works for you, awesome. Chances are it's not going to work 100%. It's not going to be the perfect thing. It's never going to be the perfect thing. So be willing to adapt it as time goes on, just stick to it. And that's the important part. And, I mean, all you can do is look at what has worked for other people and try it. And if it doesn't work for you, that's not because you're doing it wrong, necessarily. You could be implementing exactly the same thing that they implemented and their brain just works differently or maybe they have a different work style. There's so many different variables that go into what we call productivity. We try to, we want to simplify productivity down to this, like, you know, what is the equation for productivity? I don't, and I just don't think that's a reality. I think the reality is more like, well, we're constantly hacking ourselves to try to stay productive. And we, it's mostly about behavior, right? We have to learn what our behaviors are. And we have to continue the good ones and stop the bad ones. It seems simplistic. But, but it's in reality, you know, what is simple, and I said this on actually another episode, what is simple is not always easy, right? So doing the hard thing here is saying, okay, you know, I, I'm not being productive when I don't write my tasks out. And writing your tasks out could be the hardest thing that you do in a given day because it forces you to prioritize things or it forces you to face the facts or whatever. But it could very well be the thing that, you know, really helps you gain focus. Absolutely. Well, that was a great question. I'm glad that you, that you shared that with me so that we can, we could talk about that. That was certainly not planned, but sometimes those are the best kinds of conversations on Developer Tea. The last question that I want to ask you before we close out the interview, if you could spend just a few minutes with a new or with an experienced developer, what advice would you give them? And this can be, you know, somebody who's brand new to the field or even somebody who's been in the field forever, what, what, what kind of advice would you give them? I would say to keep things simple. You know, we've talked a lot about testing and, you know, getting coverage and, you know, continuous deployment and all of those things. If it's overly complex, it's probably not going to work. So one, one thing that I really kind of like at Etsy is that the CTO of Etsy has, has talked about this a lot and it's that Etsy uses boring technology. You know, PHP is not the coolest thing around, you know, I would probably, I personally would much rather be using Ruby. But at the same time, sometimes it's a lot simpler to use PHP. It's ubiquitous. It's everywhere. And it's, it's weaknesses are very well known. Same thing with, with mySQL. It's not the new hotness. It's not, you know, a no-s people data store that, you know, it's not, I don't know, MongoDB. I don't even know. But it's, it's not new. But at the same time, it's well known. We know what the weaknesses are. And trying to simplify things as much as possible, it, it makes a world of difference. So, you know, don't rush out to try the latest tools just because they're new. Sure. Yeah. Sometimes, sometimes there's a lot of value in waiting until those tools are actually proven. And, you know, if it's something that really meets your needs, then yeah, go ahead and give it a try. But, you know, try to keep things simple. Yeah. That's great advice. And, and I think it's great advice quite literally too when, when you're, when you're coding the single responsibility principle. And all of these things that we've heard about so many times, you know, if you want to do the dry principle, that one's kind of controversial amongst object oriented design people. But in any case, keeping things simple, that means that your code will be simple for other people to read, right? And, and the processes that you use, if you have a simple process, well, then when you hire, for example, it's going to be simple for them to come on board. The onboarding process will be much easier for them if you have a simple process. Exactly. Well, that's, that's a great answer. A lot of insight. Russ, you have provided us with just an incredible amount of knowledge and just so many things to think about going forward. And a lot of inspiration. I hope that the listeners have enjoyed this as much as I have. I hope so too. Thank you so much for being on the show, Russ. Thank you. Thanks so much for listening to this episode of Developer Tea. My interview with Rust Taylor. Of course, if you missed the first part, you can find that and the show notes for all of the episodes at DeveloperTea.com. If you have not yet subscribed, you can also do that on any podcasting app that you use. We're on Stitcher and there is an RSS feed available at DeveloperTea.com. Developer Tea is also in the running for this 16th annual net awards. There's just over a week left in voting at the time of the airing of this episode. So make sure you go check that out. The website for the net awards themselves is the net awards dot com. Of course, you can vote directly for Developer Teaby going to bitly. That's b-i-t dot li slash vote T V O T E T E A all over case. That's bitly slash vote T. That link and all the other links from this episode will be in the show notes on DeveloperTea.com. Thank you so much for listening and until next time, enjoy your tea.