321. Saying Yes Means Saying No - Understanding Opportunity Cost

Why would it be a bad thing to build custom software? How do I say no to good things? Why would adding a new feature be a bad thing? Why do open source maintainers not accept some pull requests? These are the questions we will answer in today's episode of DevQuestions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Smart developers turn down work all the time. Good open source maintainers will often turn away a fully developed pull request for a new feature. Wise software development managers will build as little as possible in-house. But why? Well, it all comes down to opportunity cost. Let's talk about it in today's episode of DevQuestions.

SPEAKER_00 0:32

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:36

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about opportunity cost. Now, too often, we look at a decision on its own. We ask, is this a good thing or a bad thing on its own? And we base our answer off of the specific thing we're looking at. But that's not how the real world works. We need to look at the bigger picture for anything we do. Here's a quick example. When I was a kid and I had a little bit of money and I went to the toy store, man, it was like the whole world was in front of me, right? There were so many different things that I wanted to buy. But let's say I had $10 in my pocket, and most of toys cost between five and $10. Well, if I decide to buy a $10 toy, it's not just whether or not I get that toy. It's do I get that toy and turn down the other ones that I want? I can't get all the ones that cost $10, only one of them. So by saying yes to one, I'm saying no to the others. That's opportunity cost. It's not just about whether or not this specific toy is a good thing or not. It's about is this a good thing compared to the other things I could buy instead? Now, that's kids and toys. And my goodness, I spent a lot of money on basically comic books and food as a kid. But let's take those lessons and apply it to our everyday lives as software developers. Let's say you work at a job where you're scheduled to work 40 hours per week. We'll come back to that whole more than 40. But for now, 40 hours per week. And your boss wants you to build an application that will take 100 hours to complete. You need to be done in three weeks. So in the perfect world, you'd complete this project with about 20 hours of spare. Because you've got two weeks, that's 80 hours, and half the next week, so two and a half weeks, would get you to your 100 hours in the perfect world. But that's not the real world, right? And you probably know this because you've tried to do this. The real world is you need to attend a 15-minute daily stand-up plus 15 minutes to get back in the groove. That's seven and a half hours over the three weeks. And maybe you have to attend a two-hour all-hands meeting. And you have one-hour status meetings of the stakeholders once a week. That's three hours total. All of a sudden, your 20 hours of buffer time is down to seven and a half hours. That technically still leaves you enough time. But meetings aren't the only thing that takes your time. Your boss needs you to fix some serious bugs that made you production. That's let's say three hours a week for a total of nine hours. There is a bad update on your machine and it takes IT four hours to fix it. And you're asked to add a quick feature to an app, which took you only four hours. I can go on, but these are just a few examples of how you're over your time budget because of these other things. In this case, you're about 10 hours over. That means instead of deploying in three weeks, you're going to spill over into the fourth week. Now, I want to say a quick pause right here to say, yes, I know that what's going to happen instead is your boss is going to say, we need that done in three weeks. So therefore, work an extra 10 hours. But the reality is, every one of those things, what it did is it took away from the time that you could have spent on the project. And it's just like that kid in a toy store where by doing this thing, you can't do that thing. And even if you say, well, we're going to work overtime, we're going to get it done, what you're doing is you're taking away then your boss is taking away your personal time, or you're burning your employees out. But you're doing something in exchange because of the fact that you decided that two-hour all hands meeting was important. And it could be, but that's an opportunity lost towards your project. It pushes your project out two hours. And all these things, you know, they're probably okay in their own right. And if you say, is it good to fix those bugs? Yeah, it's really good to fix those bugs. But you have to know it's pushing out the project by that many hours or more. And you know what? Someone's gone away and we're gonna celebrate with a long team lunch. Really good thing. It is an opportunity lost towards the project. That can be okay, but it is an opportunity cost. So every decision we made had an opportunity cost. And because you're fixing those critical bugs, the time frame for launching your app got pushed back. So again, bosses can try to make you work more, and there can be some of this pressure, and this is what happens a lot of times. But it at some point you can't go any further, right? You cannot keep pushing employees to work 80 hours a week. At some point, the decisions you make impact the date at which something can be shipped. You can't just say forever, well, I don't care, it's all a top priority. So, how should we understand opportunity costs and how it affects software developers? Well, we need to learn to say no in order to say yes to something better. Now, again, you cannot control everything. You can't control your boss. And your boss may say, I hear you, we can't have five top, you know, top priorities, but we have top five top priorities, just get it done. Like you can't always control that. But what you can control, you need to work on controlling by saying no to certain things in order to say yes to something else, even if it's in your personal time. Because maybe you want to learn a new language, but also deepen your skills in a current language while also looking for new jobs. Well, everything you do is an opportunity cost. If you decide, hey, that's that cool new technology, let me learn more about that. Well, by doing that, that's could be fine, but you're not deepening your skills in your current language. You're not out applying in those hours. So everything you do has an opportunity cost. Just watching Netflix is an opportunity cost. Again, not necessarily a bad thing. Because you do need to have a break. You do need to have downtime, but you need to think about how much downtime, how much of a break, because everything you do has an opportunity cost. So let's give some examples here in a software developer's life. The example I had mentioned, the open, an open source project, where they turn down pull requests. It may feel like that's a bad thing. Like, I just gave you free work. I just built a new feature which your app definitely needs or your project definitely needs, and you decide not to implement. All you have to do is hit merge and it's done. Well, the reality is, no, that's not true. Because first of all, that pull request has to be reviewed. And it probably has to have work put into it to make sure it's up to speed and it has the right formatting and it's gonna merge with the rest of the code and it doesn't have duplicate code or bad code or anything else. But even if all of that is done, they still may not want to merge it because it's still an opportunity cost. Every feature that you add to a project, every line of code you add to a project is another line of code or another feature you have to support long term. The more features, the more code you have to support, the less new features you can add. Because you don't have time. You're just fixing bugs, you're just maintaining what you have. At some point, you transitioned from adding new things to just only keeping your head above water to maintain what you have. And so what you've done is you've said, these are the features I'm gonna support because that's all I can support. So turning down pull requests sometimes is a way for an open source maintainer to say, you know what, that might be a great feature. I can't put that in my pile of features of support. I'm gonna choose a better something. Because maybe a better something is just not having any feature. Or maybe it is a different feature that they support instead of this one. For your side projects, a lot of developers start a project and then kind of get tired of it and you know, they get close or they they do the one thing, but they just, you know, it's so hard to get stuck in a place, and there's something new, like a new idea pops up in their brain, and they start building a different side project and a different one and a different one. Well, that's opportunity costs because what happens is by not finishing the first one, what you do is you never finish that first one. And so all that work that you put into it is kind of lost. And so you then put it in the second one, and that one's never finished, and the third one, the fourth one, instead of putting all that energy into one and having one done. So by skipping from one to the next to the next, you lose the opportunity of having anyone actually make it into production. With learning, it's the same thing. When you chase new features, where you have this, like, oh, that's new. I want to learn about that, I want to learn about that. And you keep kind of skipping from thing to thing to thing instead of taking your time, practicing, applying it. What happens is you know about a lot of things, but you don't know how to use a lot of things. You don't have experience using those things. And so you're never actually making any progress as a developer. Because, yeah, you've watched a lot of training and you you know a lot of buzzwords, but you don't actually have the experience of applying those things and understanding how they actually work. So your opportunity is lost because you spent a little bit in a whole bunch of different areas instead of spending a lot in one area. Now, at work, this is where, again, coming back to the idea of maybe you don't have control over everything about setting us setting the priorities, but you can have the conversation where you say, Listen, I can only work on one thing at a time. So let's order these things. Because if I stop doing what I'm doing on this project to work on this other thing for a couple hours, that means the first product loses a couple hours of progress and it pushes it out a couple of hours. And have that logical conversation with your boss where you say, Listen, I can only work on one thing at a time. Therefore, if you say, step away to do this other thing, because that's top priority, well, then that's fine. But what you're saying is the project is not a top priority. It gets number two in line. And that's going to push it back. And it's have that logical conversation where you say, I can only do one thing at a time, and try and work with your boss and helping them understand that. Now, if you're in leadership, budgeting time is like budgeting money. So if you have $1,000 to spend, or if you're that kid in the Toy Story has $10 to spend, well, you have to budget it. You have to figure out what's most important because you only have a limited amount of money. Well, the same thing is true when it comes to your employees' time. You only have a limited amount of that time. It does not matter how much you say, when you get all of it done, we all this is top priority. It doesn't matter how much you say that. The reality is your employees only have so many hours in the day. And if you try and push them too hard, they rebel. They they leave, they go find a better place to work. So at some point you burn them out, you make them go slower because you're just working them too hard, and you're not actually getting what you want done anyway. So you have to work on setting up a budget for your time, just like your money. You just say, this is most important, then this, then this. Because that way you get the opportunity to do the right, the best thing first and get something completed. So, in general, ask yourself, what am I giving up in order to get this? Always ask yourself, what am I giving up in order to get this other thing? It can be good, it can be great, but you are giving up something. If you spend a day at the beach, that's great. I love going to the beach. But I also give up a day in the mountains, or I give up a day, you know, working, or I give up a day, you know, with my sons. Like I'm giving up something that may be okay. And you may say that's the right choice for this day. But just know that everything you do means you're giving up something else. You're always gonna pay the opportunity cost. The only question is if you're gonna do it intentionally or if you're gonna do so randomly and inefficiently. Because if you don't choose, then it just happens. So the more efficient you can be about choosing the best thing over just good things, the better off you will be. Make sure to look for what is the opportunity cost and what am I willing to pay? All right. Thanks for listening. As always, I am Tim Corey.

SPEAKER_00 14:44

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.