As a developer, you're often told all of the things that you should be doing. And that list can get long very quickly. In fact, it can get so long that it really becomes impossible to accomplish. So in today's episode, I want to talk about things that you shouldn't be doing. And the hope is that you can create the space to do only the most important things, only the things that matter. My name is Jonathan Cutrell listening to Developer Tea. My goal on this show is to help driven developers become better at what they do. The ultimate reason for this goal, which I don't know that I've ever shared this on this show before, but the ultimate reason for this is because I believe driven Developer That have a strong sense of values, they're going to create tomorrow that you as the developer, the software developers who are listening to this show, you have an opportunity to make a big impact in the work that you do. And that means that your job is not just a job, that your development interest is not just a hobby, and that you're not just working for a paycheck. You're going beyond that. You're diving into your personal values. You're understanding how to best organize your time and stay mindful of what you're doing and the effect of what you're doing. All of these things are so important. So we're going to talk about all this stuff on every episode of developers. He from a different angle, from a different facet of the same ultimate underlying mission really for this show, which is to enable you as the driven developer to become better at what you do so that you can go and make a positive impact on the world. Not just so you can raise your salary, not just so that you can get a title or accomplish some kind of personal goal. Those things are all certainly perfectly fine. There's nothing wrong with getting a higher salary or accomplishing a personal goal or getting a new title. All of those things are perfectly fine. But the ultimate goal that we have on this show is to help you create a positive impact on the people and ultimately the world around you. That's why it's okay that if you have only selfish motivations that you don't listen to this podcast. That's why it's okay for you if you're looking to only hack your way to the top or take shortcuts and reduce your effort and try to stop working or try to retire as early as possible if there's no passion or appreciation for the work that you're doing, then you're probably not going to enjoy this podcast. We want to encourage you to believe in the work that you're doing and to walk into your workplace every single day with a drive and a passion for what you do. That's part of becoming better at what you do. That's what we're doing. We're enabling you as a driven developer to become better at what you do so that you can create a positive impact on the people and ultimately the world around you. We've done a lot of episodes of this show. We're well into the 400s. I think we're around 450 episodes at this point. Some of the most popular episodes that we've done are the ones with digestible focused points that you can take away, practical points. That makes total sense. This is the way that we understand information, we can categorize it, we can create. If you're journaling, if you're writing notes about these episodes, you can create points in your journals and you can actually write them down and take them away and use them. The practical value of these episodes certainly correlates with their popularity. What I've decided to do is every few months or so, we're going to do a week that is solely dedicated to practical takeaways. These weeks are going to be called three by threes. We're going to have three episodes where you have three practical takeaways. We may have a bonus takeaway here and there, but three by threes and this week is the first three by three week. We already mentioned what we're talking about today and we're talking about things that you should stop doing, things you should stop doing as a developer. Some of this is behavioral, but some of this is also things that you may think are proactive but they're actually not. Within these three by three episodes, because you can't split three and half, we're going to take a moment before we talk about those three takeaways to talk about the sponsor for today. Today's sponsor is Linode. Linode has been a sponsor of Developer Tea for quite a while and you can thank them for a significant portion of this shows ability to continue doing what we do. One of the things that you definitely should stop doing is searching for a Linux service provider. Spending time comparing different providers and you haven't looked at Linode, I recommend you go and check them out. Linode provides the best dollar per gigabyte service that I've found on the market. They have a one gigabyte plan for five dollars. That's an incredible entry level price. No matter what level of developer you should be able to afford five dollars per month. They also have higher level plans. Linode is not just a hobby service. They provide much higher gigabyte plans. They have incredibly fast internal network for networking multiple nodes together and they have a service called node balancer to do exactly that. So I recommend you go and check out Linode if you are looking for a Linux service provider. Basically you can get a Linux box up and running in just a few minutes. It's very easy to do and they have excellent customer service. So many reasons to take a look at Linode. Spectat FM slash Linode. Now here's if you don't have enough reasons already, here's kind of the final reason that should push you over the edge. Linode is going to provide you with $20 worth of credit that you can use on any Linode service just for being a Developer Tealistener. If you use the code Developer Tea2017, check out it will get that $20 worth of credit. Thank you again to Linode for continuing to sponsor Developer Tea and helping developers everywhere have access to excellent Linux boxes for less. Thank you again to Linode. So we're talking about things that you shouldn't do in today's first episode of a three by three week. This whole week we're going to be doing these three point takeaways. Today's episode is three things you should stop doing as developer. Number one, staying up late. Being up late. At first, in my career, I thought I was doing a good thing by staying up late. I felt creative. I felt energized. I felt like I could get a lot done. And I felt like burning the midnight oil. That was something that was kind of followed the lore of being a developer. It was part of being a developer in a lot of ways. To speaking, people know developers as the guys who stay up late and drink energy drinks, and eat pizza and hack things out. Fix problems, build stuff, build side projects, and all of that was attractive to me. On top of that, I have a natural tendency to want to stay up a little bit later rather than wake up early. And as it turns out, this doesn't really work out. And for a few reasons. When most businesses actually run normal business hours. So even if your company is progressive and you work remotely and you work asynchronously and you get to choose your hours, most other businesses run from nine to five. This doesn't necessarily create a problem, but it might create one in the future. You may end up needing to have that productive time that overlaps with that nine to five. If you set up your schedule and you set up your rhythm to be a late night worker, then eventually that could become a problem. Now, that's not the main reason that it's a problem actually. As it turns out, the main reason it's a problem is because most of the time for most people, their best work is done first. Now let me explain the basic science behind this. Your best work is going to be done in the morning when you haven't done anything else yet. When you wake up in the morning, your brain essentially is fresh. There's a lot of other ways of explaining this, but you haven't fatigued your brain yet. You haven't made a bunch of decisions yet. You haven't had to do a bunch of thinking yet. And so your brain is not fatigued. And you can actually solve creative and important problems better first than you can later. And unfortunately, when you stay up late working, those are the last things that you're doing with your brain. And this is a problem, right? This is a mismatch because if you're a highest capacity, at least from a neurological science level, if your highest capacity is early in the day, when you haven't made a bunch of decisions in that particular waking cycle, then it only makes sense to wait your day towards the front. It's also important to note that as it gets later, you become more and more sleepy, right? And there's a very simple and practical reason not to stay up and work late. And staying up late on its own may not necessarily be a problem, but you're very likely to get less sleep if you stay up late. And then if you were to go to bed at a somewhat earlier time, for me, my schedule has recently shifted. You know, I have a newborn. So I don't get as much sleep as an average person does anyway. He's no longer newborn, but you know, the sleep cycle has been a little bit off. But I've set up myself up for early mornings. And this means going to bed more like 10, 30 my time and waking up more like 4, 30 my time rather than, you know, consistently going to bed at 12 or 1. Here's another anecdotal piece of evidence. At least for me, I found that staying up late, typically, you know, the later I stayed up, didn't really have any effect on my productivity or my happiness. You know, I usually would waste that extra time. I would waste the extra time because my brain is already tired and I just want to relax when it's late. I just want to spend that time on doing nothing productive, right? And so what I found was a lot of that wasn't even valuable to me. It wasn't really adding extra positive value or extra positive mental perception of my day. And I would go to bed feeling extremely tired. I would go to bed having wasted a bunch of time doing kind of mindless activities to recuperate from the day. And I wouldn't get as much done as I'd hoped I would get done. So this is definitely an opinionated thing. Some people find that staying up late is actually a really positive thing for them. And I can't prescribe to you perfectly whether this is going to work for you or not. What I will say is on the average case, for most developers who are listening to this, staying up late is not going to be as effective for you as getting up early would be, right? Going up a little bit early, going to bed a little bit earlier. Really the coinciding factor here is that you need to get a positive amount of sleep. That means you need to be getting the recommended amount of sleep every single night. Now we aren't going to go into exactly how much that is because the ranges are pretty large. But I will say that I go with the recommended number, which is six hours at the minimum. I'm not spending a lot of my energy trying to figure out how to regain the one or two hours of sleeping time by hacking my sleeping schedule. I don't really find a lot of value in trying to optimize my day down to that level. Instead I want to optimize my energy and focus more than my time. Let me say that again. This is kind of like a side bonus piece here. I want to optimize my energy and focus rather than my time. Essentially what that means is I want to put my energy and my focus on the right things at the right time. My motivation isn't to try to regain extra minutes in every single crack that I possibly can, but rather to put my energy and focus on the right things at the right time. All right. So moving on to number two of the three things that you should stop doing is developer number two. Going with your first gut for estimation. Going with your first gut for estimation. This is a totally different subject than staying up late. This is more about your working processes. We've talked about estimation in the past before. We've talked about estimating sandwiches. I recommend you go and listen to that episode. That one really kind of changed the way that I think about estimation fundamentally. Here's the reality. Your gut believes that you are better than you are. This isn't a bad thing. Your gut is not prideful. It's not a problem of humility, but rather it's a problem of perspective and the ability to forecast. Your gut is not a good forecaster. Here's what ends up happening. Unexpected things occur. Even in the average case or even in the most predictable work style, the most predictable work environment with the most predictable work tasks, unpredictable things can happen. For example, you may run into traffic. You may get the flu. The client or the user or some other stakeholder may be indecisive, so you may have to shift directions. You could get called in for jury duty. There are a hundred maybe a thousand variables that your gut doesn't really take into account when you ask it how long is this going to take. Going with your first gut estimation, even though your gut may be able to estimate, even here it's probably wrong, but even though your gut may be able to estimate the actual work, in other words, the amount of energy that it's going to take to do that particular thing, it's not estimating all of the inefficiencies and interruptions that you face every single day. Now, we've talked about trying to control for those. We've talked about trying to protect our focus and build our days so that we can focus on one thing at a time and limiting our work and progress, but ultimately, unexpected things are still going to happen, even in the most controlled scenarios. Now, if you go to the average case where the amount of control over the actual work itself is also variable. We have unexpected features and we have bugs that we can't figure out for a full day and as it turns out, it was just a syntax error. There's a hundred other things and perhaps a thousand other things that you can add in and you're not talking about linear variables. This is unfortunately kind of an exponential growth curve. If you remember from your complexity analysis practice, if you have these variables and they're combined with each other, you could end up in a scenario where those variables really greatly extend the amount of time that you expected, that your gut expected for this particular thing to take. That is going to be completely blown out of the water once you start compounding some of these variables together. The reality is what we do and we talked about this in the same which is episode, but what we do when we do gut estimation is we ask ourselves, how easily can I see a path to success? Seeing that path, it's kind of looking at a map or getting directions on Google Maps, it seems like it's a very easy trip. It can be two turns along the way, but that doesn't give you an idea of how long it's going to take. It only tells you how complex it is. Our gut tells us that it will be simple and we translate that simplicity to a time factor and this is a problem. These are not on the same scale. Even if it is simple, it still is going to take an amount of time and we shouldn't be using simplicity to determine the amount of time. Now does it affect the time? Does complexity affect time? Absolutely. But we shouldn't use those on the same scale. That's the reason you shouldn't be using your gut to estimate. Number three, and this is the final one for today's three by three. Optimizing the small things before fixing the big things. I see this all the time, optimizing the small things before fixing the big things, especially in web development, for example. I think the reason for this is because we perceive those small things to be bigger than they really are. Or perhaps we don't really have the right metrics in front of us. I'll give you a basic example. If you are spending your time trying to minify and compress your JavaScript, and this is a web development example, compress your JavaScript and try to move everything into the footer so it's non-blocking and you're trying to make your CSS smaller. You have, let's say, 10 images on the page that are uncompressed and there are three megabytes of piece. Well, chances are that your biggest gains are going to be from compressing those images. There are very few instances where compressing your JavaScript is going to provide you the same gain as compressing an image. The simple factor there is that the image is much, much larger, compressing an image may bring you a significant, maybe even a 10X lowering on the number of bytes that you had to deliver to the user's browser. That's a really specific example, but this really generalizes to a lot of other problems that we face. For example, how we place priority on different views in our applications. If a user is really heavily using one view, perhaps 90% of the time, then optimizing that view should be of utmost importance over optimizing or polishing a view that they only use a fraction of the time. Let's say 0.1% of the time. How much more should we be focusing on that primary view, that utility of the 90% view is so much more important in terms of the overall effect. Now am I saying that you should just totally forget the small stuff? Absolutely not. But you should be prioritizing the big stuff before the small stuff. This really generalizes to your life too. This is something that you can apply as a life philosophy. You can get the most important things done first. If you don't have clarity on what the most important thing is, then that is the most urgent task that you have right this moment. You should be able to pull out a notebook. I challenge you to do this. Pull out a notebook and write down today's most important thing. This is a good practice to get into every single day and you should be able to answer that question. Thank you so much for listening to today's episode, the first 3x3 episode for this week. The first 3x3 week that we've had, I hope that you enjoy this particular type of episode. If you are enjoying this, if you want me to do more 3x3 episodes, please send me an email. You can email me a developer to you a Gmail. Of course, you can also reach me on Twitter at at developer to you or at jktrell and let me know that you're enjoying these particular types of episodes. Thank you again to Linode for making today's episode happen. If you are a developer and you're looking for a Linux service provider, you can stop looking head over to spec.fm slash Linode. They're going to give you a $20 bill, well at least it's $20 with credit on their services. Thank you so much for listening. Make sure you rate and subscribe to this podcast. That helps us reach more developers. If you believe in the mission, you can become a part of the mission of helping other developers, driven developers just like you, go and make a positive impact on the world by becoming better at what you do. Thank you so much for listening and until next time, enjoy your tea.