A senior engineer will often answer every question starting with "It Depends..." In today's episode, we're talking about context and decision making beyond, "It Depends".
Senior engineers will often answer questions by peers starting with, "It Depends." In today's episode, we're talking about getting beyond the "It Depends" answer by challenging us to asking questions as they regard to context.
How can we provide more context and help fellow developers make decisions in the face of uncertainty?
Vettery is an online hiring marketplace that's changing the way people hire and get hired. Make a free profile, name your salary, and connect with hiring managers from top employers today.
Listeners of Developer Tea will get an extra $300 bonus when you accept a job through Vettery! Check them out at vettery.com/developertea
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
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 Developer 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 Tea. My name is Jonathan Cutrell. My goal on this show is to help different 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 point, a good strategy for showing that you are a thoughtful developer that you may have this senior level experience when you're 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 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 need to paralyze 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, Veteri. Starting 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 and a lot of time. Veteri is an online hiring marketplace that is changing the way people hire and get hired. Access to Veteri is exclusive and once you're live on the marketplace, top employers can view your profile and extend interview requests via email. Veteri specializes in the tech space. That means the people that are on Veteri are software developers, data scientists, product managers, etc. And with Veteri, 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. Veteri 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, Veteri is free to join. Now, if you join on Veteri.com slash Developer Tea, you'll get a $300 bonus. If you accept a job through Veteri, that's Veteri.com slash Developer Tea. And remember, going to that link, signing up through that link helps the show. Thank you so much to Veteri for sponsoring today's episode of Developer Tea. 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 great developers develop in themselves. The 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 an 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? 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 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. Right? 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 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, and 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, Veteri, head over to veteri.com slash Developer Tea to get started today, you can get a $300 bonus if you end up accepting a job through veteri. If you enjoyed today's episode, if there was anything valuable in this episode, I encourage you to subscribe and whatever podcasting app you're using to listen today. Today's episode wouldn't be possible without spec.fm and a wonderful producer, Sarah Jackson. My name is Jonathan Cutrell. And until next time, enjoy your tea.