We're continuing our discussion on mental models in today's episode, but I do want to take a moment to credit an excellent resource where you can learn more about mental models. Pharnam Street, the Pharnam Street blog, the podcast is also excellent. That's F-A-R-N-A-M. But the URL is fs.blog slash mental-models. You can also probably Google Pharnam Street mental models. And a lot of these models also can be found by doing a bit of research on Charlie Munger. That's the business partner of the extraordinarily wealthy Warren Buffett. And a lot of these things apply, certainly apply outside of software development. So I encourage you, if you're not a software developer, to still continue listening to this episode and share it with other non-software developers. So many careers now depend on the same kind of principles that software developers depend on. And software developers depend on principles that have long been in existence outside of software development. So certainly do some cross-training here and share these ideas and have conversations about these ideas with non-software developers in your life. You're likely to see some very good, unique perspectives that those people have because they have different experiences than what you have in your career. My name is Jonathan Cutreller, I'm a listening to Developer Tea and my goal on the show is to help driven developers connect to their career purpose and to do better work. So they can have a positive influence on the people around them. In the last episode of Developer Tea, we talked about two mental models and just a quick reminder, mental models are a way of seeing the world, their vantage point. These are not perfect. They're not truth with a capital T. These are lenses through which you can see the world. And different lenses, different vantage points, provide you with different types of leverage, giving your specific context. So understanding how you should spend your time is highly contextual to you. But putting on these lenses helps you see the world in new and sometimes very useful ways for accomplishing whatever it is that you're trying to accomplish. So don't try to see these things as hard and fast laws of the universe. That's not the point of this. Instead, it's a ways that you can shift your thinking. And your thinking is really kind of where your action and decision come from. Okay, so the two models that we talked about in the last episode, first was compound interest. And the second was second order, third order, fourth order thinking. You can think about this as developers in order thinking, I suppose, in plus one order thinking, going beyond the initial effects of whatever your decisions are. In today's episode, we want to continue our discussion. In today's episode, we're talking about two different mental models that can help you think about better ways to approach your work. And we're going to jump straight in. We're not going to spend any time today introducing this topic. We did plenty of that in the first episode. In the previous episode, rather, the first mental model is criticality, criticality. This is a way of understanding certain types of events that you encountered, the criticality of those events. And more specifically, criticality is referring to the moment of a phase change. And one of the most commonly referred to examples of this is changing the state of a given material from, for example, a liquid to a solid that happens in a single moment. If you've ever seen pictures of, for example, a lake that is frozen, there is a moment in time, right before that ice became solid, where it was liquid. Now the interesting reality is that as the water decreased in temperature, let's say from five degrees Celsius down to four degrees Celsius, and from four to three and so on, this decrease was probably a linear decrease. The amount of energy that that water was holding was decreasing at a linear rate and yet the phase of the water remained the same. That is all until that last degree. That last degree changed the phase of the water. So the concept is that the last degree holds a particularly different meaning, a utility that is particularly different from the other degrees of change. And this is true in many other areas. One of my favorite examples of this is completing a college degree. If you've gone for three and a half years and you have a half year left of classes, and you get all the way to the end and you're missing the equivalent of a single semester of a class. Well, it's easy to imagine that you essentially have a degree. In your mind, you have all of the information except for that one class. The problem is that having a degree or not having a degree is not a continuous function. In other words, you can't really put almost a degree on your resume. It's a binary, complete or incomplete. And a lot of things that we do as developers, this is true for. If you spend all day working on a feature and you go through the process of testing it, you have somebody look at the code over your shoulder, but it's five o'clock and at five o'clock you have to walk out the door, but you forget to push the code. Unfortunately, this last step happens to be a critical step. Actually shipping the thing that you worked on is a very highly important step. It's that last step that phase change from not shipped or local on my computer to shipped. So as a developer, I encourage you to constantly be aware of those final critical steps, those last pieces of the puzzle that take you from, for example, incomplete to complete. A good way of thinking about this is imagining that you actually have three steps remaining that actually launching something, actually completing something is not the final step, but in fact verifying that it is complete is the final step. Perhaps this can change the way that you view that timeline. Ultimately, understanding the lens of criticality is key to realizing that some of the actions that we take hold more utility than others. More specifically, not all of our work has continuous functions that describe the value of that work. The work that you're doing may not become valuable at all until it's public, for example. So even though you may have learned something from it, that value is much harder to recognize and much harder to justify. And the extended value that you get, the additional value, the additional utility you get from making that public far exceeds the utility of the learning that you personally had. Absolutely from your employer's perspective. So that's the first mental model for today, criticality. You can also think of this as completeness or as non-continuous value. All of these are ways of thinking about this mental model. We're going to talk about today's sponsor and then we'll get back into our discussion with our second mental model for today. Today's episode is sponsored by Century. It's very likely that you have code that is broken in your application right this second. And you may not even know where it's going to come from. You may have no idea. And that code can go unnoticed for a long period of time, especially if only a few users are encountering it and even worse if users who encounter it leave your product altogether. Relying on those customers to report errors when they're leaving, that's a bad idea. You're kind of treating your customers as an offsite QA team. This is not a good plan. And it's pretty rude to those customers. Ideally, this would be solved with tests. You just cover all your code and tests and then you're good, right? But the problem is you're not going to cover every scenario with tests. Life would be perfect, but it's not reality. Humans are actually pretty bad at writing tests. Only bad at trying to cover your entire code base is just not going to happen. So relying on tests to catch every single bug is a bad plan too. Beyond the fact that we're bad at writing tests that cover all of our code, we're also bad at predicting how people will interact with our code in the future and how external products will interact with our code in the future. This is why Century tells you about errors in your code before your customers have a chance to encounter them. Not only does Century tell you about the errors, but it also gives you all the details you'll need to be able to fix them. For example, you can get a stack trace. You can get the number of users who have actually encountered that bug so far. You can even get the commit that the error was released as a part of and go and collaborate with the engineer who made the decision to write the code in that particular way. You can get started with Century right now by going to Century.io. It integrates with all of your existing platforms, and I've been using Century since before they became a sponsor of this show. Go and check it out, Century.io. Thank you again to Century for sponsoring today's episode of Developer Tea. The second mental model that I'd love to talk to you about today, and as it relates to testing we're just talking about with Century, is Gresham's Law. Before we talk about the law, I want to paint a picture for you and you'll probably understand this picture all too well. You start working on a code base with a bunch of good developers, conscientious developers, developers who all agree that there should be tests and we should follow a similar code style that we should have standards for the way that we write our code and standards for the way that we test our code, standards for the way that we deploy our code. You even go through the process of writing those standards up and maybe even setting up some of this stuff, some ways for people to test and ways for people to lint their code, and you start working. You start developing features and product people come along and they get involved and sales people and customer service people come along and they get involved. People start using your application and things are going well, at least at first. Nothing you have real customers and money is flowing and you have too many things to do for the amount of time that you have available, people start to cut corners where they would have written four tests. Now they're writing three and where they would have written three tests. Now they're writing one or maybe even none. The customer service team is thinking the developers who are moving so quickly, sales are going through the roof and even though you have a few late nights here and there because of an unexpected bug, things seem to be still pretty smooth. The problem is that all of those standards that you had in the beginning, all of those starting to crack, things are starting to fall apart. And even though you're profitable and even though you're shipping features, you can see the signs that you're starting to build up tech debt. And starting to get into a situation where the code is a little bit harder to read. As new people come on to the team, they're recognizing those problems and it's taking them longer to onboard. You and other developers begin to be a little bit afraid to change code because it doesn't really have any coverage. You're not really sure how it works and you weren't the one who wrote it in the first place. So we're constantly having to go and ask the person who wrote that code how it works. Unfortunately, those people start leaving. They start getting different offers at other companies and now the person who originally wrote that code is gone and nobody knows how it works. Your company isn't failing but your sanity is starting to slip away and the developers all still agree that we should have tests. The problem is everybody views it as something they wish they had rather than something they need to have. This is a picture of Gresham's law. Or it's similar to Gresham's law at the very least. Gresham's law states that when given the opportunity to do something bad that gives you some kind of competitive advantage, a system that is ungoverned will select the thing that gives the advantage even if it's against your standards. In the case of our story of the startup that is increasing their technical debt every day, the competitive advantage is, oh, we're getting things shipped. We're able to sell to more customers because we have more features and we're able to be more responsive. And so this gives us an advantage and at a personal level the developers are able to complete tasks faster, able to complete more tasks. And this is a deceptive speed that initially takes hold. The problem that we end up facing is that that competitive advantage in the short term is traded for sustainability in the long term. This lens is particularly important to carry as a software engineering manager, as any kind of leader role, but it's also important for the individual Developer To carry. The reason for this is recognizing that it's very likely that if we allow poor practices to result in an advantage for too long, those poor practices will replace our less advantageous good practices. As a general rule, these poor practices need to be policed and governed. These can be governed by ourselves, but even better if they are governed by the team as a community. Incinives need to be aligned with relying on and continuing to practice the things that we know increase sustainability rather than simply looking at velocity, for example. Very simple way to think about this is what you celebrate is what you create. The things that you praise people will do more of them. The things that you ignore will naturally die in favor of the things that you praise. It's critical that you create a culture where the things that you want to continue to prevail are the things that you focus on, that you applaud, that you hold up on a pedestal, you create values, and then you discuss those values. You call those behaviors out in a positive way. This is one way of governing those behaviors as well. Those are two more mental models, lenses for seeing the world. I hope you enjoyed today's episode. Once again, the first lens was criticality, the idea of moving from one phase to another and that the phase change and the changes right before the phase change have a higher value, a higher utility, a higher importance than the other moments in that phase change. The second lens is Gresham's Law, the idea that if you have a poor practice that yields an advantage over a good practice, then the good versus bad nature of those practices ends up being lost. You must find ways to celebrate the good and negating the advantages of the poor practices. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Century for sponsoring today's episode. Head over to Century.io to start finding bugs you didn't even know you had in your code base today. If you enjoyed these two episodes on mental models, there are plenty more mental models that you can go and learn about at fs.blog. This is not my blog, this is Farnham Street, excellent content. They also have a wonderful podcast where they do extended interviews with people about the way they think about the things that they're reading. These are leaders in various industries. I encourage you to go and check it out. Fs.blog and Farnham Street on whatever podcast player you're using. If you're enjoying these kinds of topics, encourage you to subscribe to the Teabrag Challenge. Head over to teabragchallenge.com. This is a daily soft skills challenge that will help you improve in your career and in your life. And just a few minutes a day gets delivered directly to your inbox. Thank you so much for listening and until next time, enjoy your tea.