As we pointed out many times on the show before, a senior engineer, a great developer, someone who has a lot of experience, you will very often hear their answer to almost every question, starting with it depends. And while this can be the right answer, it may also leave you feeling paralyzed. In fact, in some ways, this might make younger or less experienced developers seem like they move faster because they don't have these weights from their past experiences. They don't have to go through all of the things that it depends on. So what can we do to empower our senior developers to empower ourselves to make decisions, even though we have all of this context that makes us feel like we are paralyzed? That's what we're talking about in today's episode of Developer Team. My name is Jonathan Gatrell. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in your careers. Now, just a quick recap. The idea that it depends comes down to a very simple reality that context is always critical. And when you ask a question that doesn't have context built into that question, well, a good developer is always going to ask for that context. This is a good strategy, for example, just as a kind of a bonus points, a good strategy for showing that you are a thoughtful developer, that you may have this senior level experience. When you're an engineer. And in an interview is to ask for that kind of context. When you have a question that doesn't have context included, if it's a even somewhat vague question, ask for more context. Ask for the edges of the problem. Try to understand the problem thoroughly. However, on the flip side, you're in your job and you're trying to make decisions in the face of uncertainty. A lot of what you're trying to do is take vague requirements. Take vague requirements. Take vague requirements. Take vague requirements. Take vague requests and turn them into highly clarified tasks or turn them into code. So how do we deal with this seeming paradox where, on the one hand, we know that operating as if there wasn't context is a terrible idea. But on the other hand, when we ask for all of the context that we might need to make the perfect decision, we end up paralyzed gathering that context. And we never actually move the ball forward. We're going to talk about a way to address this problem, both from a managerial perspective and as an individual contributor. Right after we talk about today's sponsor, Vetteri. Speaking of interviews and hiring senior engineers, it's hard to hire and it's hard as an engineer to find the place that you want to work. There's a lot of wonderful places out there that are. Looking for engineers, obviously, it is a good time to be a software engineer, but finding the right place is not easy. There's so much information out there and much of it is just not very useful to you. There's a lot to wade through and it takes a lot of energy, a lot of time. Vetteri is an online hiring marketplace that is changing the way people hire and get hired. Access to Vetteri is exclusive. And once you're live on the marketplace, top employers can view your profile. And extend interview requests via email. Vetteri specializes in the tech space. That means the people that are on Vetteri are software developers, data scientists, product managers, etc. And with Vetteri, you set your preferences. For example, you might set your desired location, the things that are in your top skills, your years of experience, maybe your professional background and salary requirements. That's a really critical one, isn't it? So that you'll receive interview requests. Only for roles that match what you're looking for. Vetteri partners with over 20,000 companies. 20,000 companies. From innovative startups to Fortune 500 firms across the United States, Canada, and the UK. And on top of all that, Vetteri is free to join. Now, if you join on Vetteri.com slash developer T, you'll get a $300 bonus if you accept a job through Vetteri. That's Vetteri.com slash developer T. And remember, going to that link, signing up through that link helps the show. Thank you so much to Vetteri for sponsoring today's episode of Developer T. So you're faced with some requirements. They may seem vague. They may seem like you need a lot more context. There's so many unknowns. And you, as a responsible developer, you feel like it's necessary to seek that context. And that's exactly the intuition. That. That great developers develop in themselves. That great engineers end up building for themselves. They develop a sense for finding the right context. But the problem is that we very often can end up feeling paralyzed. So how can we address this? Both as a manager and as an individual contributor. The technique that managers can provide their teams. And this is kind of an ongoing. Basis, right? Let's say you have iterations that you do. Maybe you do sprints in your company. If you're a manager, it's important to think about the functional assumptions, right? Think about this for a second. Functional assumptions. And what a functional assumption allows you to do is create the necessary context and explicitly outline it. In other words, you're going to have a set of work, right? So the engineers that are reporting to you and they're being assigned this worker, they're self assigning. However, the work gets handed to the engineer. They have some work to do before they start coding. In almost every scenario, the engineer has to digest whatever that work is first and gain the necessary context to begin working. And if every engineer starts from ground zero and tries to gain the same level of context every time. Then not only is every sprint going to feel like it's not starting until two or three days into the sprint. But it's also going to be difficult to hire new developers or onboard new developers into that team. So as a manager, you can provide functional assumptions. And here's what a functional assumption can work like. You may tell your engineers that they don't need to worry about an entire team. You may tell them that they don't need to worry about an entire section of this problem. Or maybe you can tell them that they can assume that we're going to have another sprint to work on this feature set. There are a handful of these functional assumptions that can be incredibly helpful. And many times, these functional assumptions, they come as a result of working on a product for a period of time. So for example, your product may have users that can tolerate. Longer load times than other products. So a functional assumption may be that anything under a certain load time is acceptable. So these functional assumptions may prevent you from doing something like over-optimizing. Or maybe they can prevent you from building an entire section of the UI that you don't necessarily need yet. What these allow you to do is create the proper scale. Scope. For the engineers to be thinking in. Now for ICs. It might be necessary for you to create your own functional assumptions. And this might be worthwhile to do with every decently sized task that you have on your list. But for a lower overhead kind of approach. It's probably good to create functional assumptions. For. The company. That you work at. And interestingly, these functional assumptions that you make at the company level. At your job level. At your team level. They're going to likely be related. Or a. Some expression of. The values of that company. And the reason for this is because. Functional assumptions are not about. Doing something that is obviously good or obviously bad. They're about drawing the line in the sand. When things are not necessarily. Certain. They're about figuring out. A default. Context. Building. These boundaries. That. Are not necessarily hard boundaries. In fact. The values. May change over time. The functional assumptions certainly. Will change over time. As the work changes and as. Your audience changes. As your team changes. But this. Skill. Being able to make decisions in the face of uncertainty. Is. Not just one decision. But. Having a tactic. A tool. For making decisions in an ongoing way. In the face of uncertainty. In the face of a lack of context. This skill. Will make or break. Your career. This is how. You. Go from being thoughtful. To being productive. Thank you so much for listening to today's episode of. Developer Tea. Thank you. Again to today's sponsor. Vetri. Head over to. Vetri.com. Slash. Developer Tea. To get started today. You can get a $300 bonus. If you end up accepting a job. Through. Vetri. If you enjoyed today's episode. If there was anything valuable. In this episode. I encourage you to subscribe. In whatever podcasting app. You're using to listen today. Today's episode wouldn't be possible. Without spec. FM. And our wonderful producer. Sarah Jackson. My name is Jonathan Cottrell. And until next time. Enjoy your tea. Thank you.