Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and in today's short episode I'm going to be giving you a simple tip to make people like your estimates a little bit more. I'm sure that you have experienced this just as much as I have if you have been working in software development for a long enough time, but it tends to be the case that I overestimate my abilities and I end up needing to estimate higher. And that always frustrates people when I estimate that I'm going to be able to get something done in five days and then it takes me seven. I've mentioned on the show before that estimation is notoriously difficult. In fact, we are incredibly bad at estimating things, particularly on a time scale. It turns out that we are overestimating. We're okay at estimating things on a relative scale, but we're pretty bad on estimating them in an absolute scale. So there's a lot of intricacies involved with estimation. And in fact, I recommend trying to move away from estimation when possible. But even still, you're going to need to give some kind of number to explain what it takes for somebody to get you to do some amount of work. And that is what an estimation is. That is what a computer is. A quote is somebody else providing you money for the work that you do. Now, we aren't just bad at estimation in that we are all over the board. The way in which we are bad at estimation is that we typically undershoot our projects. We typically think that we can get way more done in a given amount of time. I did an episode about estimating sandwiches. Go and check it out if you want to learn a little bit more about why that is the case, about why we tend to underestimate. The amount of effort required to get something done. But the reality is that we tend to underestimate the amount of energy it takes to get something done. And as it turns out, this happens with just about everything that takes longer than half a day. We're pretty bad at estimating anything that takes longer than half a day. We can actually estimate half a day tasks pretty well. But if we're trying to estimate a larger project, something that's going to take a week or something like that, we typically don't. We typically underestimate the amount of energy necessary to accomplish whatever that project is. So how do we avoid upsetting people? How do we avoid a situation where our client or our boss or our customer thinks that we're trying to cheat them out of money or thinks that we're being lazy? How can we avoid these situations? Well, the first one, of course, is to act with integrity. This is a very important part of today's episode. Act with integrity. So don't be lazy. That is important for other people to believe that you aren't lazy. You need to not be lazy, of course. The second part has to do with your estimation process. And very simply, you need to not underestimate in order to avoid a situation where you have to tell that client or that boss that you've underestimated the amount of time and that it's going to take longer than expected. I'm going to take a quick sponsor break and then I'm going to come back and give you some information about a cognitive bias that you need to avoid. So I'm going to take a quick sponsor break and then I'm going to come back and give you some information about a cognitive bias that you need to that can actually work in your favor in this arena, especially when you feel that you have done everything right and things are still going wrong. Right after the sponsor break, we're going to talk about how to fix this problem. Thanks so much to today's sponsor, Harvest. One thing that all great programmers and really anybody who's successful has in common is that they know where their time is going and they spend it intentionally. Now, ask yourself, how do I know where my time is going? And I'll tell you Do you know where your time is going every day? Do you know how much time you're spending on every feature, every tweak or bug fix for a given client? Harvest is a time tracking tool built for understanding where your time is going. For developers, it takes the pain out of time tracking because you can start a timer right from your Trello or GitHub or Jira without searching for your time sheet. And there's browser extensions for pretty much every browser. Not only will you understand how much time you're spending on client work, but you'll be able to turn your billable hours into an invoice from Harvest in minutes. Harvest integrates with PayPal and Stripe to make it easy to get paid. Harvest regularly offers a 30-day free trial at getharvest.com. But after your trial, you can enter the code T-TIME, that's T-E-A-T-I-M-E, to save 50% off your first month. Check it out at getharvest.com and use the code T-TIME. Of course, you can always come back to the show notes for links and for that coupon. Again, it's getharvest.com. So we've been talking about the issue of underestimating and frustrating a client or a boss or a customer with that underestimation, having to go back to them and let them know that things are changing and they're changing in a negative direction. Now, I need to tell you about something that will change the way you think about this forever, I think, and that is the anchoring bias. Now, I found this on cogload.com. You can find this specific page in the show notes. It's cogload.com slash gems slash anchoring dash bias if you want to go directly and check it out. But the bias is very simple, and it is that we tend to rely too heavily on the first piece of information seen. I'm reading this directly off the page here. That first piece of information that we tend to rely on is the anchoring bias. That's the anchoring bias. That's the anchoring bias. That's the anchoring bias. That's the anchoring bias. That's the anchoring bias. That's the anchoring bias. That's the anchoring bias. So, for example, this is how car sales work. If you walk on the lot and you see a sticker price, and then a car salesman comes out and offers you a lower price, the way that you are thinking, the way your brain is wired to think, is that they are giving you a deal because that first price is going to be the way that you compare everything else that you hear from the salesman. So, how can you take advantage of the anchoring effect in your project? Well, quite simply, you need to start estimating that things are going to take way longer than you think they are. The reality is, things will take longer than you think they will. And it's difficult to determine how much longer. Estimating how much longer it's going to take than you originally think is a difficult process. But if you're going to be wrong, which direction should you be wrong in? Should you underestimate or should you overestimate? In the long run, it's going to take longer than you think. So, if you're going to be wrong, the client will be much happier if you overestimate and then you come back and let them know that the project is going to take less time than you originally anticipated. Of course, as we've already discussed, the client is not going to be very happy if you come to them and ask them to extend the timeline or extend the budget. So, from the start, you should be overestimating the amount of time that you think it's going to take to accomplish a given set of tasks. So, if you're going to be wrong, you should be overestimating the amount of time that you think it's going to take to accomplish a given set of tasks. So, if you're Because the reality is, your brain is wired to underestimate and overestimating is a more accurate perspective of how long a given project or a given set of tasks is actually going to take in reality. Now, to be clear, you should never try to hide these kinds of things from your customers. You should never try to tell them that you know exactly how long something is going to take because you don't. This is only an estimate. You should never try to hide these kinds of things and you always want to explain that you are estimating safely, that you are estimating in a way that prevents the exact situation we discussed early in this episode, the situation where you have to ask for more time. Most customers prefer the safety of the padding that you provide by overestimating. Most customers would prefer to know and have clarity than to experience uncertainty and their budget having to change. So, if you're going to be overestimating, you should never try to hide these kinds of things from your customers. You should never try to hide these kinds of things much rather have a safe timeline, one that takes into account all of the uncertainty of the estimation process. The added benefit of overestimating the amount of time it will take for you to do a given project is that you get to come to the client or your boss and let them know that things are going better than you anticipated. In the end, all of the math can be the same. The client can pay the bill. The client can pay the bill. The client can pay the bill. The client can pay the same amount of money. You can deliver the same product on the same date. And if you start it by overestimating, the client will be happier because of the anchoring bias. So, start estimating that your projects will take longer than you originally thought and your clients are going to be happier. Because if there's one thing a client hates more than a project that takes longer than they had hoped for, it's a project that takes more money and runs than they were told it was going to run. I'd love to hear your experiences with estimation. I'd love to hear your overestimation practices and how you keep your clients and your boss and your customers happy when it comes to estimating and when it comes to uncertainty. You can send me an email at developertea at gmail.com or you can go to developertea.com. That's where the show notes can be found for this episode. And there's a contact form. You can find me on there. Fill it out and it'll send me an email. And I hope that you have a wonderful day. Thank you again for listening to Developer Tea. And until next time, enjoy your tea.