What questions are you asking? My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Much of our work comes from decisions. But many of the crossroads that we find ourselves at are the result of questions. These are kind of two pillars of action, or at least generators of action in our lives. Questions generate a crossroads. We determine that we have options A, B, and C as the result of asking some kind of question. And then actually choosing one of those options is that second pillar of decision-making. We talk about decision-making a lot on this show. And we certainly have talked about questions on this show, but today I want to talk about whether or not you're asking the right kinds of questions. And it's hard to know what kinds of questions are the right kinds of questions, but in today's episode I want to give you a couple of examples to kind of point you in the right direction. Let's first talk a little bit about the characteristics of a good question. How do you know, generally speaking, what are the kind of the heuristics you can use to judge the quality of your question? This kind of goes back to what we were talking about with modeling last week. The idea that you can have some characteristics of models more generally and apply them to all of your models and you'll probably improve. At the same time, you may have some evolutionij evolutionij evolutionij evolutionij evolutionij evolutionij evolutionij critical questions. Now let me be clear. Not every question needs to be run through this process. You don't need to judge every single question this way. For example, you may not necessarily have to judge the question, what do you want to eat tonight through this arduous process? But for questions that are relatively meaningful and particularly related to your career, and for questions that have significant impact on other people, and you're making decisions that cascade into the lives and the work of other people, it makes sense to focus on the quality of the question itself. A very kind of simple classic example of this is, how many hours did you work? How many hours did you work? This is a bad question for a handful of reasons. Hopefully if you're listening to this, you're going to be able to answer that question. You can kind of intuitively guess some of those reasons. Better questions might be, what did you accomplish? What did you do with your time? What kind of problems did you solve? What did you learn? There's a lot of questions that could be substituted for, how long did you work? How many hours did you work? Generally speaking, a good heuristic to look for is questions that end in a description rather than a question. A bad question elicits, what did you accomplish? How many hours did you work? A bad question elicits, only a specific kind of information or only a limited amount of information. And the reason this is not very good, the reason this can lead you down bad pathways is because these bad questions have assumptions baked in. In our previous example of how many hours did you work, the assumption that's baked in is how much value did you produce based on my kind of predetermined per hour value metric. This is something that I've decided your time is going to produce a certain amount of value per hour. A second characteristic, and this will be the last one that we focus on before we provide some examples, is that most good questions, most good questions are abstracted away from tactics. In other words, most of those questions are unlikely to start with the word what. This seems like a really basic heuristic, and it is. It's a very helpful heuristic because what typically implies some specific action. And again, going back to that first kind of heuristic of not providing that data-based answer, not providing a specific kind of data point of view. Kind of answer, but instead providing an answer with context attached. Usually why or what kind, how. Those are the kinds of questions that are likely to lead to better answers. We're going to take a quick sponsor break, and then we're going to come back and talk about a few examples of questions that could be replaced with better substitutes. This episode of Developer Tea is brought to you by LaunchDarkly, feature management for the modern enterprise, fundamentally changing how you deliver software. And here's how it works. LaunchDarkly enables development and operations teams to deploy code at any time, even if a feature isn't ready to be released to users. LaunchDarkly allows you to wrap feature code in flags, feature flags. This gives you the safety. And the environment to test features and infrastructure in your actual production environment without impacting the wrong end users. And when you're ready to actually release more widely, all you have to do is update the flag. You don't have to do another deployment or anything. Those features are made instantaneously available to your user base. You can innovate faster, deploy fearlessly, and make each release a masterpiece. Get started today at LaunchDarkly.com. Thanks again to LaunchDarkly. Thanks again to LaunchDarkly. Thanks again to LaunchDarkly.com for sponsoring today's episode of Developer Team. We're going to talk about a couple of examples of questions that could likely be improved by substituting a different question and really still answering the intention. This is another kind of processing idea. When you're asking a question, a lot of times the best way to improve the question is to peel away the question. You can peel away the assumptions that are embedded into it. I've already mentioned this in making sure that your questions are not just looking for atomic data point kind of answers, but instead are providing context. And you do this by peeling away those assumptions. And so when you're asking a question, you may ask a question about the question. This is, once again, going back to our meta-modeling, you can have meta-questions. So what is this question? What are you really trying to understand? What is the motivation behind the question? Is there another question that we can ask that accomplishes what the original motivation was better? So a simple example of this, especially for younger engineers, we might be asking ourselves, how much do I want to make? What is the salary that I'm shooting for? And the problem with this question is it's too broad. It doesn't... have any kind of context. It doesn't think about function. It just returns a number. And that number has to have built into it a bunch of other considerations. And it's important to actually take the moments necessary to consider some of those things explicitly rather than implicitly. For example, what kind of lifestyle do I want to have? This is a little bit better, but you may end up in a trap of spending to just maintain that lifestyle. But this question does provide you a better concept. You might also ask, where do I want to live? Your salary in a specific location might provide you a lifestyle that your salary, that same salary in a different location wouldn't provide. And then perhaps the most appropriate answer or the most abstract answer is, where do I want to live? And that's where you might end up in a trap of what kinds of things do I want to do with my money and time? From this point, you can kind of back your way in using kind of continuous questioning beyond this into what kind of salary you would like to make. But what specific things do you want to do with your money and time gives you the framework to answer the original intent, right? The original intent is what is the salary that I really need to do the specific thing that I want to do with my money and time? And that's where you might want to start. So what specific things do you want to do with your money and time? Another example, how should our teams be organized? How should our teams be organized? The answer to this one, once again, is kind of a data point answer. Our team should be organized like this and provide an org chart as the answer. This isn't a great question because it doesn't ask what the point of that organization of the teams is. A lot of organizations actually end up in this scenario where they just pick an organizational structure that they've seen work elsewhere. Maybe that's their underpinning reasoning, or maybe they have kind of chaotically evolved into a particular organizational structure and they haven't asked the question that is necessary to ask about why. Why are we organized this way? Or perhaps the best answer to the kind of intended answer is, why are we organized this way? Why are we organized this way? What do we want to focus on? What different areas do we want to focus on? When we create team structures, we provide an opportunity for a group of people to focus. This is kind of the point of having teams. We provide an opportunity for a group of people to focus. And what you'll notice is the focus will follow those lines of organization. The group of people, who are working on Project X, they're the Project X team, they're going to be focused on Project X. This seems intuitive when you think about it this way, but very rarely do we use the question, what do we want to focus on, to derive what our organization should be. Another example, how do I solve this very complex problem in code? How can I solve this complex problem in code? And hopefully, as an engineer, you immediately think, okay, well, we don't solve complex problems, we break complex problems down into smaller problems, into easier to solve. And that is a better, more abstract question. How do I solve the simplest case of this problem outside of code? Or how do I solve a sub-problem of this more complex problem in code? But in a product level, when you're actually facing this, kind of problem in your job, in the real day-to-day, perhaps a better substitute question might be, what makes the solution to this problem the most valuable? What parts offer the most upside and what parts offer the least upside? Is there an item on that parts that offer the least upside that's also creating a lot of the complexity? And if so, can we ignore it for now or could we eliminate it? These are the kinds of questions that allow us to solve the problem without making the assumption that the whole problem as it stands today needs to be solved. One final example of this, kind of substituting better questions, where do I want to work? Where do I want to work? This is a single word answer, right? Once again, providing not very much context. But a better question or a handful of better questions that might lead to a better answer, is the question, where do I want to work? And this is a question that might lead you to understanding what kinds of places you want to work rather than one specific place. How do I want to work? Maybe I want to work remotely or maybe I want to work at my own pace or maybe I want to work flexible hours. Who do I want to work with? What kinds of people do I want to work with? If there's only a handful of people that I want to work with and they are split between two or three companies, then that narrows down to a handful of people. So I'm going to ask you, where is my list down? What do I want to work on? And the answer to this one can be very broadly ranging and I'll let you fill in the blank, but it could go from particular areas, different domains, or it could also talk about various kinds of tech. But a great question that abstracts away from all of these specifics is, why do I want to work in the first place? Why do I want to work in the first place? If you can nail down the answer to this question, so many other questions that you have about your job, so many other specifics that you want to nail down about what you're going to work on in your career can be answered. Why do you want to work in the first place? Is the answer primarily money? Certainly that's probably a component and there's probably many different answers to this. You probably have multiple things that you would put on that list of, why do I want to work in the first place? But your list is going to be different from mine. When we really think about the answer to these kinds of questions, the higher level questions, we can derive better answers to those lower level questions. Where do I want to work? Depends very heavily on why do I want to work in the first place? Thanks so much for listening to today's episode of Developer Tea. Thank you to today's sponsor, LaunchDarkly. You can get started with feature flags and releasing your software in a much more sane and reliable way by heading over to launchdarkly.com. Thanks for listening to today's episode. If you want to join the Developer Tea Discord community, you can discuss what we talked about on today's episode, or you can discuss pretty much anything going on in your career. You are welcome in that community, no matter who you are or where you're from, or what kind of work you're doing. You can get started with the developer tea discord community. You can get started with the developer tea discord community. You can get started with the developer tea discord community. You can get started with the developer tea discord community. You have as an engineer. If you have no experience at all, anyone who's listening to this show, you are welcome to join that discord community, developertea.com slash discord. Thanks so much for listening. And until next time, enjoy your tea.