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. 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 Cutrell, you're listening to Developer Tea, my goal on this show has helped driven developers like you find clarity, perspective, and purpose in their careers. We talk on this 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 in 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. Of course there's some caveats we can't talk about rhetorical questions that are not actually seen as questions but questions involve other people. They are the entry way to collaboration. This is especially true if your questions are not closed-ended questions. In other words, if you don't ask yes or no 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? Maybe 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 are 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 question to think about. Why are you 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 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? That's the simplest form that I see this question being asked. Or I hear this question implicitly being ignored. Because when we ask if code that we've written was good enough, when we ask if code that we've written is acceptable. The question is, what's 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 or 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 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 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 earn engineering leader listening to this right now, manager, a CTO, or even a tech lead on a project, then 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, 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, in 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 more like a moving average. 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, and then the company makes cuts back down to $110,000, but 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, that 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 Cutrell. You've been listening to Developer Tea. If you enjoyed today's episode, if you found it valuable, then please subscribe and 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 episode of Developer Teacan be found at SPEC.FM. This episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.