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 John Jablonski. I'm very excited to talk to him. He created LawsofUX.com and before that, the Web Field Manual. I'm really excited because John 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 in whatever podcasting app you use so that you don't miss out on the second part of the interview. Developer T episodes 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 John Jablonski. Now, let's jump straight into the interview. John, welcome to the show. Thanks for having me. All right. So let's clarify this before we get into the show. How do you say your last name? Jablonski. Jablonski. All right. Excellent last name. I'm really excited to talk to you, John, because you've created something that I feel like. First of all, it's beautiful. And that's that's kind of a rarity for something to stand out enough that that it kind of gains its own 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. You know, regardless of what you call it, whoever's making stuff for people and really for. All knowledge professions to understand some of these principles. I'd love to talk to you about it. Laws of UX dot 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, John, 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 designer. I'm a design lead here at Vector Forum in Detroit. And, you know, really where I live is that space between development and design. And that's that's really the space that I'm incredibly comfortable being in. And, you know, I think that, you know, I really had 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're a designer, you're a designer. 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 Laws of UX 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 yourself. I think that's a really good point. You're living your normal sphere of kind of an echo chamber, right? Did you feel like you were falling into kind of an echo chamber? your! 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 science, you said, right? Or cognitive psychology, you said. Yep. So tell us a little bit about that. What made you get interested in that? Well, there's two things, really. The first is that I was working on an automotive-related client being in Detroit, naturally. Of course. Part of that meant working very closely with the people that I was working with. Their HMI team, which are very traditional kind of UXers that are specific to the automotive space. And a lot of the interaction that I had with them was pretty intense. I had to do a lot of research and really justify design decisions that were being made because there was a lot at stake. These things could eventually make their way into vehicles and could really affect the way that I was doing my job. 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, I would do a lot of research and come across these cognitive principles, which 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 Fitts 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 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 really just transcending that intuitive gut instinct that a lot of us designers have and really validating that with these cognitive principles that really help to justify design decisions. Yeah, that's really good. So for those who are not familiar with Hicks Law and Fitts 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 it boils down to something really simple. Too many choices, cluttered interfaces, for example, really make the decision-making process for users more complicated. And it takes longer. And 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. Right. Right. 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 cereal, very often the way that you pick out cereal, because there's so many options, right? There's so many different options of cereal. 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 cereal and you think, oh yeah, I'm going to have, 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, you know, even though calories would be a pretty good feature to use to determine what cereal 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. It has nothing to do necessarily with the experience of eating the cereal, 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, and that's pretty common. It really boils down to decision fatigue. Yeah, 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 Fitts Law. What is Fitts Law? So Fitts Law dictates that the, essentially the time to acquire a target is a function of the distance to the size of the target. If, you know, just to 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 just, quite frankly, it's a very simple thing to do. 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 is not the same. It's not the same as the code itself. If you want to make your code more navigable, use more white space. What does this do? Well, for example, let's say you put a couple of extra line breaks in between your methods. Now the target is effectively larger because 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. And so, of course, this is going to apply, certainly in product design and as you're developing products. So these are more intuitive baws, right? These are the ones that, you know, anybody who's listening to this who's been developing products, designing 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 discovery, you know, through discovering it by watching users or by using products myself, I kind of already knew that, you know, 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, you know, 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, you know, directly apply that to what we do as designers, you know, quite often we're taught to simplify the experience to improve the experience for the user. And so I think that's one of the things that we're trying to do. To improve the experience for the user. And, you know, that's a process of reduction, reduction, reduction, and really questioning the purpose of every element, whether it's a button or a paragraph, a copy, or an image that might not really be, you know, 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. Okay, so abstraction. You mean, 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, you know, a great example of this, and I like to use is the, you know, your classic kind of TV remote, which, you know, if you're familiar, has like the universal remote. So they have a lot of buttons. And this kind of harkens back a little bit to what we were discussing on Hicks' Law, but in cognitive overload. But really that the abstraction is really taken away because all your buttons are there at one time. Versus 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 kind of find settings and things like that. So it's a, you know, 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 complexity is passed over to the user because then they have to, you know, explore a little bit. There's a discovery process and learning process and 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 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 benefit of that is that the remote becomes flexible to update that the TV may have, like some software updates since it's a, 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 wayfinding device more than it is a list of options. But I noticed this, you know, 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 complexity. 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 widget. What is the pull-up screen called? I can't even remember the name of the screen. I can't 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, what do they call it? I'm drawing a blank. 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. It seems like. You know, 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, in 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? Yeah. 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 options. 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 is. And that's what I get on that particular menu, that slide up menu on the iPhone. 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, well, 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 birthed 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 locked yourself in a server. You accidentally edited a config file which took down your SSH access. 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 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 are an 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 T listener. You can use that $20 on any of their platforms. You can get started with their plans and services. Go and check it out. spec.fm.com. Thank you again to Linode for sponsoring today's episode of Developer T. Okay, so that's Tesla's Law. Really an interesting one. And I think it actually, there's a lot of other things, kind of laws of conservation that go beyond just complexity that are worthwhile to discuss in psychology and in design. Maybe we'll get to some of that. But let's talk about another one that is, 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 Zigernik 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, you sign up for Dropbox, for example, and there's the setup checklist that you have to go through and there's the setup checklist that you have to go through in order to achieve your additional 250 megabytes of storage space, right? Yeah. What that checklist is essentially doing is burning itself in your memory 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. It's going to be a lot easier. You haven't completed it yet. And I think that that's a, you know, it'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. And there are people and this is so here's an interesting kind of side effect. 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. Oh, wow. And I can't imagine. So, the interesting part of that is, you know, that obviously is not having the same psychological impact. But I can imagine that people are going to be more likely to read my five or ten 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 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 it's important. Yeah. So, I think at a certain point, you do kind of start to drown it out just like you would the hum of a refrigerator or, you know, any 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're not going to be able to see it. Yeah. You're going to be able to see it. Yeah. And that's 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 I'm fond 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? Well, let's see. I think one that came to my attention recently, and maybe this is because I'm a halt and catch fire fan, is the dotary. The dotary threshold. The dotary threshold. Which really 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 the 80s at IBM, but productivity soars when a computer and its users interact at 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. Interesting. And so by productivity soaring, what did they use in that scenario to kind of measure that? Do you know? Well, they were really, they were looking at users and because of the computing power and 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 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 Dotary actually realized was that the shorter amount of time that feedback took, the more time it took for the user to figure out what it is that they wanted to do next. Yeah. And so the faster 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 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? It's kind of like I recently took a fitness test and if you've never done one, I highly recommend it. We'll show 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 had me walk out of the room and walk into the room and walk into the room and walk into the room. And I was like, I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. At least for mine, they had me walk at a four and a half mile an hour pace. 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 it'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 at me on the show right now. But in any case, there's this weird sense that 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 that 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 Doherty threshold. We covered the Zygarnik effect, the Tesla's law, and of course the Fitts and Hicks. Are there any other interesting laws that you feel like, again, especially for developers, may not necessarily be as intuitive as some of the others? Well, I think there's a lot of things that I think are interesting. I think there's a lot of I think that, you know, definitely one 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, 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, you know, the screen is a little bit more transparent. And then you have the screen that's going to be the landing page. You're going to see a lot of information regarding, you know, various things like, you know, its charging capabilities and, you know, really information that's less relevant to the selling proposition to users. But then they end it strong. They end it with call to actions to, you know, iPhone 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, you know, that's a great example of the serial position effect. Another simple, 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, you know, 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, some further psychological research that has kind of echoes of similar things. So, for example, the anchoring effect, right? This is something that, that Kahneman studied, Kahneman and Tversky. And they, 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, right? And so for, 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 about, you know, how do you set that bar? 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 in traffic in the morning, right? Because you've, 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, right? They're 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 is something that humans needed that ability for, right? 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, there's a lot of things that we can really point to. Right? 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 the fact that they're not going to be able to do it. Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? 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, you know, to your point, a lot of these, you know, what can be seen as somewhat psychological limitations and boundaries that we have are evolutionary, you know, features of being humans that have served us very well for a very long time. And now that they really, I think, you know, define, you know, how we both interpret data and, kind of define a lot of, you know, how we see the world and even, you know, make relationships with other humans. So, and to your point, I mean, you know, the example you give is a great example of that. Yeah. I think, I think all of these things can be extrapolated and seen in so many different areas and they really are, you know, sources for behavioral guidelines, not just for, you know, when you're creating product, but for yourself, you, it's not just your, you know, it's not just your, you know, your, your, your, your, your, your, your, your users that have the, this isn't the, the laws of UX for people that, that don't know about them. It's the laws of UX for everyone, including yourself. Exactly. And so you, 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, once you've kind of been bitten by this cognitive psychology bug, like I believe John 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. Absolutely. Thanks so much for listening to today's episode of Developer Tea, my interview with John Jablonski. 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 Linode for sponsoring today's episode. If you have an idea for an app or a microservice or anything else that can run on Linux, I encourage you to check out Linode. Head over to spec.fm slash Linode to get started and get that $20 worth of free credit for being a developer tea listener today. Thank you so much for listening, and until next time, enjoy your tea.