dvnc0

I stop when the work is done

Recently, I joined a call, and two junior developers were discussing their work and availability. I wasn't paying close attention at first, as I was wrapping up notes from the previous call. Then one of the developers asked what time the other leaves for the day, and the response was one you never want to hear: "I don't know, I just stop when I think the work is done." They went on to explain that the time sometimes is 8 PM, sometimes 5 PM, but it fluctuates. That immediately stopped me from scribbling down notes, and I started listening. The never-ending workday is a terrible way to work as a developer, I know, because I was that guy. I would zone out and code, working all kinds of hours because I felt like I "wasn't in a good place to stop."

This is how you burn out. This is how you lose interest in projects. This is how you end up hating your job. Working 60 hours a week doesn't make you a hero; it doesn't make you better than everyone else; it just makes you tired. This mentality is particularly evident among junior developers who are striving to advance in their careers. There is some misguided belief that working those hours means you care more or you're willing to sacrifice for the organization. Really, it means you're working at a rate you can't sustain and are just doing more work than everyone else for no reason. Eventually, you burn out and productivity drops. Camille Fournier highlights these ideas in The Manager's Path, explaining that burnout happens when you are doing more than is sustainable. You can’t just keep going forever on adrenaline. Sustainable productivity matters more than heroics.

But then what do I do?

Mentoring junior developers at this stage is crucial for senior developers and engineering managers. They need to identify the signs that someone is working in this manner and start working with them. They need to get them to a place where they understand that working at a sustainable rate is more important than working towards burnout. When developers are stuck in this hyper-work mentality, they don't see their efficiency dropping; they don't realize their maximum cognitive load is a bit lower, and the way they start thinking about features is getting sloppier. When you're burning the candle at both ends, no one wins.

Highly effective teams are not effective because they are all working 60-hour workweeks. They are efficient, have optimized workflows, incredible teamwork and communication, and know when to stop. It is challenging to find an effective, highly productive team that works more than 40 hours a week; it simply is not sustainable. To get there, you need to counter the mindset that these borderline senior developers get, that they need to be the rock stars who work all night hammering out code to get a few more points in. Firstly, you need to talk to them. They need to hear it from you that you do not expect them to work more than 40 hours, that you do not expect them to be here all night, and that you are not judging their worth based on how many hours they can work or how close to burnout they can get. They need to hear and understand that you want them to work less.

They also need tools to help combat this mindset. This is where frameworks and mental models come in, which can start to help them break this habit. Make sure to set aside time to teach soft skills and incorporate some of these techniques to equip them with the tools they need to succeed.

Hemingway Bridge or Shut Down Ritual

Hemingway talked about the importance of leaving yourself a bridge to the next session, a logical starting point. The importance of not stopping on a cliff but at a logical point where you know your next move. This applies to development too; you should stop at a point that is easy to define, and it should be easy to see where you can start again the next day. This should be relative to the end of a typical workday, not working until 8 PM. If they need to stop at 5:25 PM because they are in a logical spot to take notes on where they left off, they should. Let them pick it back up in the morning at a well-defined starting point. This is also part of developing a Shut Down Ritual. You should encourage them to create a habit of doing the same thing at the end of the day. Reviewing tasks, taking notes on where you left off, and jotting down todos for unfinished work. These all develop a ritual that helps create closure and removes these items from their brain. Your brain is not well-suited for holding onto information like this, which is why you will replay your todo list until the late hours of the night. Creating this ritual helps to shut down after work and leave at a healthy time.

Brain Dump

Brain dumping is really similar to the Shut Down Ritual, and could be part of it. I break it out because it is also helpful to focus on when context switching throughout the day. This is transferring the context stored in your brain to a more permanent storage. Dumping the context, notes, where you left off, and any other relevant information that may help you when you return to that task, dump it into a text file or Markdown file somewhere. This is also a helpful pattern to use throughout the day when context switching between projects or meetings. It helps clear your mind to focus on the next task or shut down for the day, and provides a good starting point when you return. The most important takeaway is that it lets your brain rest. Your brain will naturally want to finish tasks and keep writing code, so stopping and clearing the state is a good way to take a break and let your brain rest.

Timeboxing

Encourage developers to schedule dedicated coding time. This not only helps them dedicate time without context switches, but also creates a sustainable habit. It helps to get developers to stop before they are exhausted or before they code into the late hours of the night. Timeboxing also reinforces that progress comes from consistency and sustainability, rather than marathon efforts and heroics. At the same time, this supports the idea of a sustainable pace and reinforces that overworking is not the expectation and can cause a drop in velocity.

Parkinson's Law, Deliberate Practice, and Continuous Improvement

Junior developers need to understand that work will expand to fill the time allocated to it. So when they say they will work until they feel it's done, they are inviting Parkinson's Law into the equation and letting it balloon their work time out of control. The more time you give up, the more work there will be to fill it. Once you get into this pattern, that balloon keeps growing until it pops. The idea of deliberate practice, or making small structured improvements, helps developers understand that it is not about hours, but about the value of their work. It teaches them to see things as compounding sessions that build to a bigger part of the whole, rather than focusing on reaching a finish line every day. This ties in with continuous improvement, stop at a healthy stopping point, and make improvements tomorrow. Small incremental changes are better than unsustainable heroics.

It takes time

As leaders, we need to notice when developers are starting to fall into this pattern. We need to spend time mentoring and working with them to provide them with the tools and reassurance they need to break out of that habit. Reinforcing the expectation of 40 hours a week and providing them with tools and frameworks can enhance their quality of life, facilitate growth, and prevent burnout. The critical thing to remember is that it takes time; you need to spend time mentoring and coaching, as well as developing a relationship of trust with your team, and communicating openly and honestly. Without that base, you may never see the warning signs. Developers may not tell you they are working too much, or even worse, they may not believe you when you tell them they don't have to. So take the time.