The Case Against Marathon TechWork Hours

Dec 12

At times being a software engineer can be tough. The deadlines, pressure and distractions of agile working (to name but a few) have led some software engineers to leave the profession entirely.

Yet it can feel even tougher when influential industry figures like Uncle Bob insist that working as a software engineer means you must work extreme hours.

So, I’d like to say that working hard does not mean working long, and effectiveness is about what you do and not how many hours you spend doing it.

This article has the receipts.

Long Hours Negatively Impact Productivity

I like coding. I have to say that I like coding a lot. Unfortunately, even I have to admit there is more to life than sitting at a computer.

I need time to wash my clothes, exercise and cook and complete other essential tasks. Only then, if I have time, can I do some fun things that I actually enjoy. If I work something like 40 hours+ commuting, I usually have some time for fun in my life.

When I work a 60-hour week (as is infrequently required) I don’t have time for fun. I put off washing clothes to another time. I begin to feel like a machine, and an unhappy one at that. I start to get tired and make mistakes in my work.

Commentators like Uncle Bob insists a software engineer needs 60-hour workweeks “to be considered professional”, and this does not align with my experience as I’m much more professional and sharp when I’m well rested and it can feel like I’m going backwards in my work aims.

Stanford University, have actually produced evidence that I’m not the only one who feels a negative impact on productivity with long hours.

“[our observation tells us that] … productivity during 60-hour weeks would be less than two-thirds that of what it was when 40-hour weeks were worked”

Essentially working 60 hours means producing less than during a 40-hour workweek. The Harvard Business Review have come up with similar findings, if you required more evidence that long hours just don’t work.

The more I moderate my working hours the better quality my work!

Think Quality Over Quantity

Those who advocate 60-hour workweeks are missing the point.

I’m a developer who has spent much too much time in meetings and waiting for the CI to be fixed — and I’ve worked a long time without really producing anything. It’s important that the time you spend working is actually spent well since it matters what you do with your time.

I’m currently working with a software developer who has 10 years of experience as a contractor. They’re not great honestly and have even struggled to set up their work environment in good time. Knowing something about them, I know the problem. They haven’t pushed themselves in their chosen career and have simply repeated a single year’s experience ten times. When we work long hours without a qualitative filter the same happens to our workweeks, we work longer hours without becoming a better developer.

We should embrace a quality-over-quantity mindset.

This means we should target:

less rework
strong delivery of what you’ve promised
a deep understanding of what you should be doing at any point

Even better is the fact that valuing a job’s quality over quantity (hours) matters for an employee’s mental health.

Maintain Sustainable Development Practices

Instead of spending additional hours on haphazard learning, software developers benefit more from targeted, high-quality learning interventions that fit within the regular workweek. This could be through code reviews, pair programming sessions, or dedicated time for online courses and training during work hours.

You can do this stuff and learn while working normal hours. To put it another way, working 40 hours doesn’t preclude learning. That’s good, isn’t it? I believe that jobs should give you a chance to learn deeply about topics.

Focus on what really matters

Instead of fixating on the number of hours, focus on what you achieve during your work, avoiding overwork.

I remember working until midnight in the office to finish a feature before a customer was due to review the product the next day. I also woke up and came into the office at 5 am, and I suppose I don’t need to tell you that the customer delayed their review. I felt not only stupid but quickly got ill later that week. The rush last-minute strategy just didn’t work for me, I could have just delivered what I could and then explained the issues with the rest of the code.

Overworking is damaging and can be mitigated with the following strategies:

Efficient Learning: Mentors and colleagues at work can help you achieve great results in a limited time. Talk to others and learn from them.
Work Smarter: Automate repetitive tasks. Pair program for tricky tasks. Remember that the best line of code is the one you remove, not the one that you write.
Maintain Work-Life Balance: A well-rounded life supports better cognitive function and creativity, so you’ll find everything easier. Plus, you’ll find it easier to learn new things and be able to focus on what really matters.

Conclusion

The idea that more hours equate to more professionalism is outdated and potentially harmful. If you were to ask me what really matters in your software engineering career (and you’re here, so I guess you have some interest in my opinion) I’d say make sure you protect your health.

You aren’t a good software engineer without good physical and mental health so put those first. Only then will you be able to focus on productivity and producing great code.

The Secret Developer