Hey, everyone, I'm Monkhamtu Developer Tea. My name is Jonathan Cutrell. In today's episode, we talk about realistic working hours. Today's episode is brought to you by spec.fm. If you are a designer or a developer, and you're looking to level up, go and check out spec.fm. We've got tons of content that's locked and loaded, waiting for you hundreds and hundreds of hours of podcasts that you can dive through, tons of value there. Go and check it out, spec.fm. Today's episode is also brought to you by our wonderful sponsor, Heap. If you are still using old school Google Analytics as your only analytics source, then Heap is for you. We'll talk more about what Heap does. Later on in today's episode, but first, I want to jump straight into this email from Naren. Naren asks, I've been listening to Developer Tea and love all the episodes. I have a question for you about Scrum in our team. Our sprint planning starts by the Scrum Master noting the names of all the engineers and accounting six hours of working for a given day. And then the stories and work get assigned to yourself or by others with expected time to complete. That's how they assign the stories. My question is, what is the ideal working hours in the real world? When you have meetings and sessions and emails, concepts switching and food and tea time as well. Also, from a focus perspective, what is the ideal duration for teams and individuals to account for working in a given day? Thank you, Naren, for sending in this great question. I think this is a really important question for Developer To ask, how long can I work in a given day? Because we typically think in terms of nine to five. Don't we? The 40-hour work week has become the standard for the working professional. And that 40-hour work week breaks down to eight hours a day for five days. And that ultimately means nine to five if you don't take a lunch break. So that's kind of how we've set ourselves up in terms of the standard working week. And some people end up working 60 hours a week. And then others work less than 20. So how can we standardize a little bit better? How can we use information that we know from statistics or from studies? What is the best way to figure out a working duration? Let me start by laying out a little bit of a value statement here. At Developer Tea, we believe both in hard work as well as balance. In other words, I strongly believe that you should pursue the things in your life that you enjoy outside of work as well as pursuing the things that you enjoy at work. And ultimately, that means that both sides need to be willing to compromise. In other words, sometimes you need to be willing to take a vacation day or sometimes you need to be willing to work an extra day over the weekend. This is a value statement that I believe in. I believe that you should be able to, for example, take a day off just for your hobby. But I also believe that when it comes down to it, you should be willing in response to having the flexibility to take that day off. You should be willing to also work when you're not necessarily quote unquote supposed to. And ultimately, this ends up evening out, but you end up adding more value because of your flexibility. Let's focus on that for a second. If working nine to five from Monday to Friday, if that is your only standard, then if something goes wrong on Saturday, well, you're not available, right? Additionally, if you work nine to five as a rule from Monday to Friday, then anything that would require you to do something between the hours of nine and five from Monday to Friday, you've automatically eliminated the possibility of that happening unless you take your vacation time or unless you lie to your boss and you take six time. Neither of those seem like a good idea. So the beauty of being a software developer is that our jobs ultimately, the substance of our jobs very often, not all the time, but very often provides flexibility in the schedule on both sides of the schedule. So that's a value statement that I want to kind of approach your questionnaire and I want to approach that question from that perspective. The idea that flexibility is ultimately key. And we're gonna take a quick sponsor break to talk about heap and then I'm gonna come back and continue talking about the idea of how much you should be working, how long can someone focus? We'll talk about a little bit of research that's been done and ultimately hopefully give Nair an a good answer to his question. Today's episode is sponsored by heap. If you're using Google Analytics for your primary source of analytics, then you may be missing out on some really incredible functionality that heap offers. Instead of having to set up Google Analytics manually, where you have to ask a developer to go and add some kind of integration just to track a button click, you can use heap and allow your project managers or even your clients in certain cases to set up that data tracking themselves. If you're a developer, this means more space to focus on things that haven't been solved already. You get to actually write the code. While the analytics just kind of performs for you, I signed up and I could easily grab the script tag to put on my website, but heap also works on iOS. It takes just a few seconds to sign up. Go and check it out, spec.fm slash heap. I highly recommend you check this out, particularly if you are a developer and you're looking for a alternative to Google Analytics. Go and check out heap spec.fm slash heap. Of course, that link and every other link necessary from today's episode can be found in the show notes at spec.fm. You should be going there anyway because there's so much great content over at spec. Once again, this show is brought to you by spec. Let's get back to Naren's question. Naren has asked us what is the ideal working time in a given day. Naren is working on what appears to be an agile team. We have a scrum master who is helping us sign tasks and they're estimating about six hours in a given working day. Naren, I would actually say that's not a bad estimate for the average amount of focus time that you could possibly expect from a developer. Here's the thing a lot of people from the outside looking in don't necessarily understand about development. When you are doing development work, it is incredibly taxing and there's only so much of that that you can do in a given day. Now you can do email management for probably a longer period of time. You could probably do some design work depending on what level of cognitive load that design work is requiring from you. But ultimately, the cognitive load of software development is taxing and it takes a lot of attention to be able to work even as long as six hours. I would say that's on the upper scale of the amount of time that you can actually be productive as a developer on a daily basis. My recommendation would be to split up those six hours into kind of mini sprints. This has been shown time and time again to work very well for people. They use something called the Pomodora method. We've talked about that on the show before. Essentially, you set up your set of tasks and you set a timer for 20 minutes. You work for those 20 minutes on the number one task on the list, take a five minute break, do another 20 minutes, take another five minute break, do that for an hour to two hours depending on how long you can stay motivated and concentrated. Usually in the morning, you're gonna be able to stay a little bit more motivated and concentrated. So I like to do longer sprints in the morning and a little bit shorter sprints in the afternoon. Once you've reached that hour or two hour breaking point, take a little bit longer of a break. This is a 20 to 30 minute break, maybe take a walk. The point of this is to totally clear your mind. Don't think about the project that you're working on. This is actually a good thing for the project. You're not actually stealing time away. It's a brain health kind of thing. It's similar to resting, even though you think that, intuitively, we might think that going to the gym seven days a week is going to help us get stronger. Ultimately, a lot of research shows that the rest portion of that week is just as important as the actual workout portion. So our brains are going to do much better. The next sprint, if you give them a 20 minute break, and actually make it a resting period for yourself. So, Nair, and that's kind of the structure of the day, but you're asking about the length of the day, the six hours versus some people say that they can work 18 hours all in a row. Some people say that they don't productive, but two to three hours in a given day. And really, this is a very personal thing. Not everybody's brain works the same way. Not everybody has the same stamina. You could probably expect an average of four to seven hours of productive time from an individual. I would say that it's pretty difficult to actually hit eight hours of real productivity as a software developer. You may be able to do that for a short period of time, but for extended periods like two or three or five or 10 years, it's unlikely that you're going to be able to have a heavy cognitive load and perform well for more than seven or so hours a day. Furthermore, there has been some research on this subject. Particularly, there was a article that I will link to in the show notes and it was a peer reviewed and all of those good things. It was a legitimate study that essentially said that 60 hour workers were significantly less productive than 40 hour workers. And this doesn't mean that they were only slightly less productive per hour. It meant in a net situation. In other words, over the course of time, you're going to get more work done in 40 hours if you cut your work week to 40 hours, then you would get done if you were to constantly work 60 hours a week. Now, this is statistics and there's plenty of anecdotal evidence from various people that I'm sure you've heard that essentially says the opposite. I'm working hard is ultimately the path to high levels of productivity. In my opinion, the best workers are those that work towards an excellence level rather than an hour number. Let me say that again. The best workers, Naren, are those who work towards excellence rather than hours. In the Agile world and in a lot of software development, it is significantly easier to talk about hours than it is about excellence. But ultimately, the best workers are going to be those who work towards excellence. And if they hit a block, by the way, this is important to understand. If you hit a block at three hours, then what good are you doing trying to get past that block in that day if you're just kind of sitting at your desk? If you work for eight hours, but only three of those were productive, then you might as well have just stopped working after those three hours. So my recommendation is to work as much as you can be productive with and also have rest and balance in your life. Some days, that may mean that you do actually get 12 hours of real productive work in. You may have some crazy amount of energy and excitement about a project. And it's important as a good developer to harness that energy and excitement. Don't treat yourself as a machine because there will come a time, there will come a season when you are too tired, when you're not energized. When you don't have that extra little bit of motivation to carry you through, that you need the break. So balance that out and harness the energy when you have it. Don't treat yourself as a machine. We talked about this on the show before. We'll put a link in the show notes. You're not a machine, you are a human. You should treat yourself as a human. And humans go through different stages of motivation. We have mood swings, we have tons of chemicals that we don't really know how to control perfectly, even with the most advanced diet, the most advanced supplements, we can't control everything about the way our brain works. So we have to respond to the way our brain works and take advantage in the good times and respond appropriately in the not so good times. Naren, I hope this episode has been helpful to you. And thank you so much for sending in your question. If you are looking to have a question answered on the show, you can email me at Developer Tea at gmail.com. Of course, you can join the spec Slack community by going to spec.fm slash Slack. There's over 6,000 members in the Slack community. By the way, the shows on spec are getting downloaded over 100,000 times a week. That is a ton of downloads. Quite a few of those are for Developer Tea. So thank you so much for listening to the show. If you're enjoying today's episode, and if this is your first episode, go ahead and subscribe. Those of you who have subscribed, you know that you get the episodes automatically delivered to you whenever they air. That's three times a week, by the way. So if you don't want to miss out on future episodes, go to whatever podcasting app you are using right now and subscribe. Thank you again to today's sponsor, Heap. If you are looking for an alternative to Google Analytics or any other analytics for that matter, go and check out Heap, spec.fm slash Heap. Thank you so much for listening, and until next time, enjoy your tea. Here's a next video.