What was the last question someone asked you that changed the way you think in some profound or long-lasting way? Every once in a while, I come across these questions, and the questions themselves usually don't have a single answer. They aren't an easily measured question most of the time. And in today's episode, we're going to talk about one of those questions and then explain how that question plays out in many different areas in our careers as software developers. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. We talk on the show about questions quite a bit, and part of the reason for that is that questions, in many ways, are the starting point. For thinking. A question triggers our brains to solve the question. It's one of the reasons we start many of the episodes of this show with a question, so that you can get interested and involved and participating with this podcast, rather than just hearing me making statements. Part of the reason for this is that questions are, in some ways, an invitation. At the same time, they may be an evolution of evolution, evolution of evolution, evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution questions, but instead ask open-ended questions. So I'll ask you another question here. If you haven't been asking very many questions, for example, in meetings, why not? What is the motivation for not asking questions? Now, it may be that you don't know the power of those questions, but for most people, the reason that we don't ask questions is because we're in some way afraid. We're afraid that by asking a question, we will lose some confidence in the person that we are asking or the people who are observing while we are doing that asking. We believe intuitively for some reason that by requesting someone's input, we are admitting our lack of knowledge. And all of us have a lack of knowledge. Every single person who's listening to this episode. Right now knows something that another person listening to this episode doesn't. And it's easy to get caught in the trap of trying to look more confident, trying to appear more knowledgeable. So that's kind of a bonus, a bonus question to think about. Why are you at, why are you not asking more questions than you already are? For most people, this is, this comes back to some point of fear or concern that by asking questions, they're going to lose some confidence. They're going to hurt themselves in some way, hurt other people's perspective of them. But I want to get to this critical question that has changed the way that I think about my work. And this question is incredibly simple. With reference to what? That's the whole question. With reference to what? Perhaps the simplest form that I see this question being asked, or I hear this question implicitly being ignored. Is when we ask if code that we've written is good enough. When we ask if code that we've written is acceptable. The question is, with reference to what? And when we try to judge whether our code is acceptable, we create implicit references. Those implicit references might be with reference to my own internal guidelines. The company guidelines. Perhaps the existing code in the code base. Other implicit references might be with reference to whoever is reviewing the code. Now, the interesting thing about all of these implicit references is that we all have different ones that we use to judge our code by. And additionally, when those things don't line up, or if they're never made explicit, they can change our behavior sometimes in a way that we don't want to. And so, I want to get to this in undesirable ways. For example, if your reference is only based on the person who is reviewing that code, then if there's a particularly harsh reviewer, people will tend to avoid sending their code to that reviewer. And you'll notice that the way that you can kind of ask this question, or the way that this plays out, is based on some environmental feedback. We usually are not actually asking the question, is this code good enough? Instead, we're following some pathway. We write some code, we create a PR, and then we implicitly ask the question, is my code good enough, by submitting it for review. And whether or not the code is good enough is determined by whether it gets merged into the code base. If you are an engineering leader listening to this right now, a manager, a CTO, or even a tech lead on a project, then it's important to know that it's important to understand that this question makes a difference in the way that people behave. When people ask the question, is this code good enough, and they don't have references that are stable, then everyone has a different definition, and everyone will start acting differently from each other in order to get code delivered to the code base. Especially if there are incentives around shipping and not incentives around acceptability. We can see a similar problem when we talk about a more tactical problem, optimization of code. Is this code fast enough? Is it performant enough? And what's interesting about this is that this actually might be one of the questions, one of the references to answer the previous question, is this code good enough? Is the code performant enough? Well, how are you deciding what your performance threshold is? With reference to, what factors are we determining whether the code is performant enough? Similarly, there are other implicit questions we're not really asking, is something good enough, or is there some measure that meets a threshold? Instead, these questions are more evaluating a circumstance. It's easy to imagine, for example, that once you make it to a particular income level, or once you meet a particular goal, or once you reach a certain level of income, or once you reach a certain level of income, that you will see things from that vantage point with reference to your current experience in life. In other words, it's easy to believe that our happiness levels are relative to our lowest point, and that we can kind of maintain a level of happiness or a level of satisfaction once we reach a particular point in life. But, in fact, most of our happiness is determined by something that we don't know. And that's the point where we're going to be able to see things from that vantage point. And the variance from whatever your new baseline is. So you can imagine that if you make $100,000, let's say, today, and you increase your salary to $110,000, that you're going to be happier. But if you were to make $100,000 today, you get a new salary, $120,000, then the company makes cuts back down to $110,000, then you're going to be happier. So you're going to be happier. Well, your happiness wouldn't be the same because you've experienced some sense of loss. So your happiness in that scenario is relative to the loss that you experienced. It's not relative to that previous baseline of $100,000. And the outcome is the same. In both scenarios, you end up making $110,000. And here's why this is problematic. Because if we operate as if we understand our references, but our references are wrong. If we don't remind ourselves of those references, or if we always let them be implicit, then we make decisions that are based on the wrong references. We derive motivation, for example, on a never-ending climb in salary. Or we make the assumption that our code, can always benefit from being optimized more. The truth is that we need to be more aware and more explicit about our references. So ask yourself this question more often. With reference to what? My name is Jonathan Cottrell. You've been listening to Developer Tea. If you enjoyed today's episode, if you found it valuable, then please subscribe in whatever podcasting app you're currently using. And also, if you think someone else, in your life, would find this episode valuable, then share it with them. This episode and every other episode of Developer Tea can be found at spec.fm. This episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.