On this show, you know we talk about psychology quite a bit and today we sat down with Jon Yobonski to talk about Laws of UX.com and other practical phycological principles. In the first part of this two-part interview with Jon, we talk about LawsofUX.com and how Jon goes from development to design using these principles.
On this show, you know we talk about psychology quite a bit and today we sat down with Jon Yobonski to talk about Laws of UX.com and other practical phycological principles.
In the first part of this two-part interview with Jon, we talk about LawsofUX.com and how Jon goes from development to design using these principles.
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.
####Get in touch
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
On this show, you know we talk about psychology quite a bit and in today's episode, we're going to do a bit more of a deep dive with a guest. This is actually one of the first times we've talked almost purely about psychology on a show with a guest. Today's guest is Jon Yablonski. I'm very excited to talk to him. He created lawsofux.com and before that, the web field manual. I'm really excited because Jon seems to have a practical understanding of quite a few of these psychological principles and I'm really very interested in this stuff and I hope you are too. Now before we get into the interview, I encourage you to take just five seconds, subscribe and whatever pie-cassing app you use, so that you don't miss out on the second part of the interview. Developer Teaepisodes are typically cut in half when we do episodes with guests. And this episode is not an exception to that rule, so I encourage you to subscribe if you don't want to miss out on the second part of this interview with Jon Yablonski. Now let's jump straight into the interview. Jon welcome to the show. Thanks for having me. Alright, so let's clarify this before we get into the show, how do you say your last name? Yablonski. Yablonski, alright, excellent last name. I'm really excited to talk to you Jon because you've created something that I feel like first of all, it's beautiful. And that's kind of a rarity for something to stand out enough that it kind of gains its all merit just based off of that. But beyond that, I've created something that's really, I think, important for the digital creative world, for developers, designers, product owners, all those roles, regardless of what you call it, whoever's making stuff for people and really for all knowledge professions to understand some of these principles. And I'd love to talk to you about at lawsofux.com for anybody who wants to browse that while we're discussing this stuff today. I encourage you to go and check it out because we're going to kind of use it as a template for some of our discussion. But Jon, first I want you to tell people what you're passionate about, what you feel like your purpose is, and what you do. So yeah, I'm a front end web developer and designer interaction design lead here at VectorForm and Detroit. And you know, really where I live is that space between development and design. And that's really the space that I'm incredibly comfortable being in. And you know, I think that, you know, I really, I've been doing this kind of work for quite a while and that kind of you get to a point, I believe, in your career where you start to kind of look at other industries, other disciplines, if you will, and really start to kind of get influenced by things that are happening outside of, you know, your community. And I think that, you know, a lot of what I was doing with lawsofux came from some of the, you know, things I was reading and understanding about cognitive psychology, specifically. Oh, that's so good. You've said a lot already right there. First of all, this idea of getting influence or inspiration outside of your normal sphere of kind of an echo chamber, right? Did you feel like you were falling into kind of an echo chamber? You know, I think it, yeah, absolutely. I think you can really, you know, you can get lost in your day to day shuffle and, you know, the blogs and, you know, the people that you're following and listening to on Twitter and these things can, yeah, definitely become somewhere of the echo chamber and we're kind of recirculating the same ideas over and over. Yeah, I totally agree with that. I think having a variety of inputs really, I've started recently, as recently as this past week actually, I started calling this raw material, which I know is not necessarily a unique concept, but the raw material for new ideas to form. If you don't have enough raw material, then a lot of your ideas are going to kind of look like the same thing. Absolutely. So cognitive, cognitive science, you said, right? Yeah. Or cognitive psychology, you said. Yep. So tell us a little bit about that. What made you get interested in that? Well, I was, you know, well, there's two things really. The first is that I was working on an automotive-related client being in Detroit naturally. And of course, part of that meant working very closely with their HMI team, which are, you know, very traditional kind of UXers that are specific to the automotive space. And you know, a lot of the interaction that I had with them was, you know, it was pretty intense. We do a lot of research and really justify design decisions that were being made because there was a lot of stake, you know, that they were going to, these things could eventually make their way into vehicles and, you know, could, you know, really affect people's lives, their lives and their safety in the vehicle. So there was a lot of research that needed to go into everything. And we didn't always have a lot of the user data that I was looking for. And in the process, kind of, I, you know, would do a lot of research and come across these cognitive principles, which, you know, a lot of designers, I think, are somewhat familiar with at some point in their career. They'll hear the really common ones like Hicks Law or Fits Law, for example. But I found myself really diving deep into this field and really wanting to learn more and more. And I think the, you know, the deeper I dug, the more I kind of learned enough that I could justify design decisions effectively. And I saw it being like a very effective approach to, you know, really just transcending that, that intuitive gut instinct that a lot of us designers have and really validating that with these cognitive principles that really help to, you know, justify design decisions. Yeah, that's really good. So for those who are not familiar with Hicks Law and Fits Law, let's do a quick dive into what those are, Hicks Law. I'm reading it on lawsofux.com, by the way. So if you didn't go to lawsofux.com now is probably a good time to do that. But the time it takes to make a decision increases with the number and the complexity of choices. That's Hicks Law. So how does that play out? Well, I mean, I think that really, this comes naturally to designers, but you know, it boils down to something really simple. You know, too many choices, cluttered interfaces, for example, really make the decision making process for users more complicated and it takes longer. And you know, you see this in a lot of places. We're all familiar with the apps or the websites that just have way too much going on compared to the simpler interfaces that just feel like a breath of fresh air. And that's really what Hicks Law is doing. It's simplifying the choices and really kind of decreasing the cognitive load on users so that they don't have to consider too many options at once and become overwhelmed. Yeah, this is really good. So some of the ways that Hicks Law plays out, I've read a little bit on the subject of cognitive psychology as well. And this is one of my favorites, actually. I have a little kind of a special place in my heart for Hicks Law. And here's why. If you go to the grocery store and you try to pick out, let's say, a type of serial, very often the way that you pick out serial because there's so many options, right? There's so many different options as serial. You're going to find one or two features rather than evaluating all of the relevant ones. So let's say, for example, that you're watching calories or something like that, right? That's going to be the one feature that you kind of slice all of your options with. And so instead of actually evaluating thoroughly all of your options, you're going to pick a few specific features. Now, the interesting thing about Hicks Law and this cognitive overwhelm is that very often, you don't expect it to be that hard, right? So you start looking at the serial and you think, oh, yeah, I'm going to come out with the best possible option because I'm a superhuman. And the reality is that a lot of the time, even though calories would be a pretty good feature to use to determine what serial you're going to buy, a lot of the time you don't use something so rational as calories. Instead, you're going to use something like, for example, the packaging, you like the packaging. And it has nothing to do necessarily with the experience of eating the serial, but unfortunately, your brain doesn't really care about that, right? So you make a decision that's easy rather than one that's good. Yeah. That's pretty common. It really boils down to decision fatigue. Yeah. And the overwhelm is such an interesting part of that. Okay. So we've covered Hicks Law, perhaps more in detail. So let's move on to Fitz Law. What is Fitz Law? So Fitz Law dictates that essentially the time to acquire a target is a function of the distance to the size of the target. If just the boil that down a bit simpler and apply it directly to what we do as designers and developers, the bigger the button, the easier it is to press the button. It's just quite frankly. And that really kind of comes down to anything, you know, any interface element, really text links or anything that the user needs to engage with. The size that it is and how close it is to the user is going to dictate how easy it is to interact with it. Yeah, this is also another really interesting one, even for developers. So I'll give you an idea for developers who are writing code. This is actually on the other side of the product, the code itself. If you want to make your code more navigable, use more white space. What does this do? Oh, for example, let's say you put a couple of extra line breaks in between your methods. Now the target is effectively larger because you've what you've essentially done is you've added padding on the outside of those methods. It's kind of a weird and not really intuitive thing, but as you're navigating code, you'll find that code with more white space is typically a little bit easier to navigate. I like that. Actually I do that quite often. It's really helpful. Of course, this is going to apply certainly in product design and as you're developing products. So these are more intuitive boss. These are the ones that anybody who's listening to this who's been developing products, design products for very long at all. Hopefully, you kind of think, oh, yeah, so there's a name for that. I kind of already knew that through discovering it by watching users or by using products myself, I kind of already knew that three choices is better than 30 and that the bigger the button, the easier to press it. But there's some not really intuitive ones as well. There's some laws, especially in your list here, kind of cognitive psychology principles, I guess you could call them, that are not really as intuitive. What are some of the less intuitive principles? I think one of my favorites is Tesla's law, which really dictates that every application has an inherent amount of irreducible complexity. And really, the question is whether or not who has to deal with that complexity. So to directly apply that to what we do as designers, quite often, we're taught to simplify the experience to improve the experience for the user. And that's a process of reduction, reduction, reduction, and really questioning the purpose of every element, whether it's a button or paragraph, a copy, or an image that might not really be supporting the end goal. But there is a point when you can simplify to the point of abstraction. And at that point, you're passing complexity from you, the designer, to the user. Interesting. So abstraction, in what way is that passing it to the user? What do they now have to do that they didn't have to do before? Well, a great example of this. I like to use is your classic TV remote, which if you're familiar, like the universal remote, they have a lot of buttons. And this kind of harkens back a little bit to what we are discussing on Hicks law and cognitive overload. But really, the abstraction is really taken away because all your buttons are there at one time. This is like an Apple TV, which is so simple that a lot of that abstraction is now passed on to the user and to find a lot of the functions that they would have on the surface right away with their universal remote. They have to dig through menus via the Apple TV remote and find settings and things like that. So it's a, I don't think anyone would argue a vastly superior design, the Apple TV remote, that is. But at some point, a little bit of the, a little bit of the complexity is passed over to the user because then they have to, you know, explore a little bit. There's a discovery process in learning what that remote is capable of. Yeah, that's so, that is a very interesting, I've noticed this because I bought a TV, I don't know, back in 2009 or something like that. And then more recently, I bought another TV. And the more recent TV has a remote that has kind of like a pseudo touchscreen kind of thing. But it, but all of that complexity has moved out of the remote and it's moved into the TV. So it's all the same stuff just in a different location. And I think, you know, obviously the, the benefit of that is that the remote becomes flexible to update that the TV may have, like some software updates since it's just, you know, it's a connected TV. And so maybe there's some new menu options and, you know, whatever rendering algorithms that they want to send down the pipe over the internet, eventually in the future. And the remote doesn't necessarily have to change because it's kind of like a way-finding device more than it is a list of options. But I noticed this in a lot of, especially Apple's products. If you go through your iPhone, for example, they have these kind of buckets of complexity. One of those would be your settings, right? So if you go to the Apple settings menu, man, that's just a lot of complex, there's so many options, so many that they make it searchable, right? So you have this complexity there. You have the complexity in your, the kind of the widgets and what is the pull-up screen called? I can't even remember the name of the screen now, but the one that has the brightness and, you know, you can configure all these little, they're not widgets, but they're, you know, that, what do they call it? I'm drawing a blank, a drawing a blank, yeah. In any case, it's this relatively flat kind of looking thing and there's all these various utility functions, you know, you can turn your flashlight on or start a video recording on your phone. All this stuff has been kind of thrown into this bucket of complexity. Yeah. You know, it seems like you mentioned, you mentioned flat too. I think that another way to interpret Tesla's law is that, you know, a lot of the flat UI that is, you know, become pretty common these days in applications and whether it's on the web or mobile. I think there is a drawback to that, obviously, and that sometimes that complexity, the visual complexity that is, has been removed, but it's been passed on to the user because sometimes the flatter UI is harder to interpret as, you know, what it's intended to be, for example, a flat button versus text that's got a border on it, you know. And that's a great example of complexity being passed to the user and them having to really kind of discover what items do sometimes. And it's not necessarily because the designer needs to, like, it's difficult, right? It's not that difficult. It's not much more difficult to create something that isn't, and I'll take it one step further on the flat portion, that flattening out your option. So a single dimension for those options, rather than nesting those options inside of something, having them all in a single, kind of, viewable source, is another type of flat that kind of reduces complexity because now you don't have to think about nesting or, you know, the context where that particular thing shows up. And that's what I get on that particular menu, that slide up menu on the iPhone. And it feels like it's a bunch of relatively unrelated things, frankly, that are put in one place. And it's a single dimension. It's very strange in some ways. Yeah, I totally agree. Today's episode is sponsored by none other than Linode. It's no secret that Linode has been a sponsor of Developer Tea for quite a long time now. And here's the reality. Linode cares about developers. And the reason for that is because Linode, oh, it's made up of developers. It's a bunch of people like you and like me. And the benefit of this is that you have a lot of these services that Linode provides that are burst out of the experiences of a developer. So for example, you know, if you weren't a developer, you may not know how frustrating it can be to accidentally lock yourself out of a server because you accidentally edited a config file which took down your SSH access, right? We've all been there to some degree, somehow, somewhere. You had to totally spin up a new server because of some stupid error. This happens to the best of us and Linode knows this. So instead of you know, punishing you for your accidents, Linode provides tools to help you recover from them. Other examples of this, if you are a developer that doesn't necessarily mean that you aren't expert in DevOps and it may be really expensive for your company to hire a DevOps engineer. Linode provides DevOps services, professional development operations services. I encourage you to go and check out what Linode has to offer. Not only are all of these incredible services available, but everything is billed on an hourly basis and you can get started for only $5 a month. And Linode is going to give you $20 just for being a Developer Tea listener. You can use that $20 on any of their plans and services. Go and check it out, spec.fm slash Linode to get started today. Thank you again, Linode, for sponsoring today's episode of Developer Tea. Okay, so that's Tesla's law. Really an interesting one. I think there's a lot of other things, kind of laws of conservation that go beyond this complexity that are worthwhile to discuss in psychology and in design. Maybe we'll get to some of that. Let's talk about another one that is not so intuitive. One that might surprise someone. What's another good one? You know, I think my next favorite one that's somewhat uncommon is the Zegarnic effect, which really predicts that people remember uncompleted or interrupted tasks better than the completed ones. So a great example of this is, when you sign up for Dropbox, for example, and there's the set up checklist that you have to go through in order to achieve your additional 250 megabytes of storage space. What that checklist is essentially doing is burning itself in your memory because they know, you know, unless you get through all those steps in a single session, it's going to stay on your mind that you haven't completed it yet. And I think that that's a great example of that, probably the best that I could give. But really, it boils down to steps and progress bars in general seem to have this psychological effect on users. Yeah, of not having completed. We actually did a show. It's funny that you bring that one up. I did a show on this effect because it's so interesting to me. And you can definitely use this to your advantage as well, even in just your own kind of productivity schemes, whatever it is that you go through to try to stay productive. One of the things that you can do is, you know, leave something undone and you're more likely to remember that than if you leave it having been completed, right? Absolutely. This is one of the reasons, by the way, that inbox zero might actually be important for some people. And there are people, and this is, so here's an interesting kind of side effect of this. There is a level of incomplete that people tune out. So for example, I know I have personal relationships with people and often I feel pain for them, but they have over 30,000 unread emails in their inbox. And I can't imagine. So the interesting part of that is, you know, that obviously is not having the same psychological toll as my five or 10 emails that are unread because they would be completely debilitated until they clean that up, right? So there seems to be, from my anecdotal perspective, at least, at some point, there seems to be the kind of a threshold where people no longer pay attention to that incompleteness. Yeah, you know, I don't have quite that many, but I have quite a few emails that, you know, I haven't deleted from my inbox. You know, I think at a certain point, you do kind of start to drown it out just like you would the home of a refrigerator or, you know, maybe other house appliance. Like there's a frequency level, whether I guess it's sound or if it's even data that you just start to kind of drown out. Yeah, I like to think of it as, you know, if it's a hill and you're kind of climbing up over the top of the hill and you're already on the other side of the hill and you're rolling down it and for whatever reason you stopped at the last 10%. Well, in that case, you're going to feel that pull of gravity towards the bottom of the hill. But if you're at the other side of the hill and you haven't even started climbing it yet, then you're going to feel less of that pull of gravity. Again, that's completely anecdotal. I have no evidence to back that up other than my own experiences. But it seems like those tasks that are most of the way complete rather than just incomplete. Yeah. They have a strong effect. Okay. So that's a really interesting one and one that we've, you know, I'm fined of here on the show as well. What would you say is another really impactful one or one that you have that you've experienced in a project before? Hmm. Well, let's see. I think one that came to my attention recently and maybe this is because I'm a halting catch fire fan is the dodery threshold, which really has a lot of, has a lot of similarities to how we talk about performance these days in the front end, web development community. And really what this predicts and it goes all the way back to, you know, the 80s at IBM. But productivity sores when a computer and its users interacted a pace, which they discovered was less than 400 milliseconds that ensures that neither the user or the computer has to wait for the other. Hmm. Interesting. So by productivity soaring, what did they use in that scenario to kind of measure that, you know? Well, they were really, they were looking at users and because of the computing power and or how slow it was in the 80s personal computers, they sometimes took up a full two seconds to run the next task or give feedback to the user. And I think that, you know, they were, they were really examining that and determining that they thought that was okay because it would take around two seconds for the user to figure out what it is that they wanted to do next. Yeah. But what Walter Dodery actually realized was that the shorter amount of time that feedback was relayed to the user, the quicker they were responding with the next task or whatever it is that they were, you know, set out to do. So it really became a correlation with speed and productivity that I think even influences us now. Yeah. I love the way that this is worded. The idea that a computer and its users interact. I think that's so important. That's an important part of this because it kind of has this sense that, you know, as you're working with your computer, that if the computer is sufficiently slow, then you come, you kind of become out of sync with it, right? That it's somehow, you know, previously, if it's below that 400 millisecond threshold and I would say now we may even be expecting more from our computers than even that. But if it's below that, whatever that threshold is, that you can get into a flow state, right? And that's a really important thing to understand, you know, what, how do you get to that, to that degree? I recently took a fitness test and if you've never done one, I highly recommend it. I'm sure you what the limits of your physical capabilities are. But it was a, you know, a basic physical fitness test. And one of the things that they have you do, or at least for mine, they have me walk at a four and a half mile an hour pace. Now, I don't know if you've ever walked at a four and a half mile an hour pace, but it is neither slow nor fast. It is right there in that extremely uncomfortable middle place, right? Where you're not really walking, you're not really jogging, you're walking very fast, and that's very uncomfortable. And so I was actually relieved when they upped that pace a little bit. And now all the power walkers are probably laughing on me on the show, but in any case, there's this weird sense that, you know, I almost would rather it have been longer than two seconds, right, so that I can actually maybe do something other than wait on the computer. Because it's just short enough that I can wait on the feedback. And it's just long enough that it's really throwing me out of that flow state. My mind is working faster than the computer at that two second level. I love it. Awesome. All right. So we've covered the dough and the threshold. We covered the zegar and zegarnic effect, the Tesla's law, and of course, the fits and hicks. Are there any other interesting laws that you feel like, again, are, you know, especially for developers, may not necessarily be as intuitive as some of the others. Well, I think that, you know, I definitely won that I come across and use in my day to day work all the time, but I find people don't necessarily know as intuitively as they seem to do a lot of these other psychological principles is one called the serial position effect, which really predicts that users have a propensity to best remember the first and last items in a series. And kind of when you think about it, it ties in with a lot of other psychological principles. You know, a great example of this is that if you were to make a grocery list and you have those first items in the list and the last items in the list and then a bunch in the middle, you have a tendency to just kind of remember the ones at the beginning and the end. And there's a lot of reasons for this. It comes down to, you know, items entering into your more long, you know, short term memory and then the last items being in your working memory, which is really interesting because it has correlations with computing. For example, you know, your temporary storage memory, right? And the brain works in a similar way. So it's interesting to kind of see the correlation between psychology and computing in that regard because sometimes you can think of the computer or the brain as, you know, a very powerful computer. But you know, back to serial position effect, I think that we have a tendency to remember the relevant information we need right away. And sometimes that really is determined determines where it is or how we, what in what order do we experience that? I think, you know, the serial position effect, you see a lot in design through something like landing pages, for example. So, you know, an example I love to use is the Apple's landing pages for each one of its products. One, I'm looking at now is the iPhone 8 landing page. And they really sell the device up front. They, you know, they say it's a beautiful mind and they go into a description of all the features and then they end that paragraph with a link out to the keynote and, you know, TV ads. In the middle of that landing page, you're going to see a lot of information regarding, you know, various things like how, you know, is charging capabilities and, you know, really information that's less relevant to sell the selling proposition to users. But then they end it strong, they end it with call to actions to, you know, iPhone upgrade, upgrade program and, you know, how to get money toward your new iPhone and they're really just kind of, you know, ending strong with these call to actions that really compel the user to take action. So that, you know, that's a great example of the serial position effect. Another simple, a simpler one that we're all familiar with is, you know, mobile apps where, you know, I'm thinking of LinkedIn right now where home and jobs anchor either side of the navigation. And that tends to kind of be seared in our memories because when we look at that and we see these items positioned at the beginning and end, arguably some of the most important features of LinkedIn. You know, seeing your network, their updates in a feed format and then jobs, which is, you know, obviously critical to what LinkedIn does, those are the two items that anchor that entire navigation. And we have a tendency to remember the position of those items by heart. Yeah, I think this is such an interesting effect as well because I think it's rooted in some further psychological research that has kind of echoes of similar things. So for example, the anchoring effect, right? This is something that that Coniman studied, Coniman and Tversky. And they essentially say that, you know, the first number that you see or the first piece of information you have is how you set the tone, how you judge the rest of the information. And so for that reason, this has implications into the ordering of everything, right? It's not just about memorability, although that is specifically what we're discussing in this particular law. But it also is about, you know, how do you set that bar? How do you set up the user for the remainder of the information that you're getting ready to give them? It's also why or perhaps it's why it's so easy to have your day kind of ruined by the person who cuts you off on traffic in the morning, right? Because you've created this tone and then, you know, every moment after that is kind of viewed through the lens of the moments before. And so at the end of it's why the beginning of your day. And by the way, these are not bad things necessarily that humans do. This is really important. These are not necessarily weaknesses. There are things that we have developed over years and years and years as our brains, I say years and years, I mean, thousands and perhaps hundreds of thousands of years, our brains have developed to and adapted to situations such that we need these things, right? Probably less in modern day, but certainly they were a part of survival. So for example, remembering the last thing, there's something that humans needed that ability for, right? There's something that caused that to be important. Perhaps there were a lot of errors, maybe even fatal errors that would happen at the beginning of a process and at the end of a process. And so we increased our ability to pay attention to those particular phases of any given thing. So there's a lot of things that we can really point to in that realm, but remembering that, you know, for a given user, the last thing that they're going to see is what's going to stick in their mind, but this also has implications into things like interviews. So if you rush out of an interview, this is like a cardinal sin, right? If you are leaving an interview in a hurry because you're trying to make it to, I don't know, something like a doctor's appointment, then you're very likely to leave a negative impression on the people who just interviewed you, unless those people are particularly aware of this particular law, right? Unless they understand that they need to have processes that smooth out that kind of focus on the beginning and the last. But it's also where we get this concept of first impressions, right? There's so many things that we can uncover in our human experience. The first act of a play and the finale of a play, these are things that are really important and perhaps more important than the second act, right? So there's so many things that we, again, that we can uncover unearth in human nature that point back to this simple reality. Yeah, do you agree with that? Do you think they're connected? I absolutely do. I'm really glad you bring that up because to your point, a lot of these, what can be seen is somewhat psychological limitations and boundaries that we have are evolutionary features of being humans that have served us very well for a very long time. And now that they really, I think, define how we both interpret data and define a lot of how we see the world and even make relationships with other humans. And to your point, the example you give is a great example of that. I think all of these things can be extrapolated and seen in so many different areas. And they really are sources for behavioral guidelines, not just for when you're creating product, but for yourself. It's not just your users that have the, this isn't the laws of UX for people that don't know about them. It's the laws of UX for everyone, including yourself. Exactly. You can shape your tools around these. You can shape your habits with reference to these. You can start to see, you know, once you've kind of been bitten by this cognitive psychology bug, like I believe Jon has been, and I definitely have been, you start seeing this stuff kind of surface in all kinds of ways. And you start making better connections and understanding your own tendencies, and perhaps the tendencies of the people that you work with, and the people that you make things for, just a little bit better. That you absolutely. Thanks so much for listening to today's episode of Developer Tea. My interview with Jon Yabonsky, don't forget this interview is two parts. So if you haven't yet subscribed and you don't want to miss that second part, probably the best way to do that is to go ahead and subscribe. You're going to get a notification or whatever, depending on what app you use. And that'll be the easiest way for you to get reminded. The second part of this interview will come out on Wednesday, so make sure you tune in or download or however you get your podcast. Thank you so much for listening to today's episode. Thank you again to Lynneau for sponsoring today's episode. If you have an idea for an app or a microservice or anything else that can run on Linux, encourage you to check out Lynneau. Have a respect.fm slash Lynneau to get started and get that $20 worth of free credit for being a Developer Tea listener today. Thank you so much for listening. Until next time, enjoy your tea.