Working Evenings and Weekends Damages Teams and You. NOT for the Reason You Think

I don’t work overtime in my software engineering role for a host of great reasons. However, there is another reason software engineering overtime is all types of bad — and this time it is something that impacts teams.

Your Rights As A Software Developer

Working for free isn’t something any professional software engineer should consider.

The fact is that you are paid for your knowledge, experience, and time. If your knowledge and experience are insufficient for you to produce functionality in a reasonable time your employer should help you to reach that level with some sort of plan.

Did someone say training?

Certainly, you should not be making up deficiencies in your company by funding their software development with your own time.

Which is a compelling way to say working overtime isn’t in your interest. It isn’t the most compelling reason for you to avoid working overtime that would affect an entire team.

Look After Your Health

I’ve previously covered why your health is important as a software developer. You might think that looking after your back and general health would be important for a whole team as it is something that affects each and every developer.

It isn’t as important as the issue we are going to cover in this article.

The Agile Angle

Here we go. This is it.

If you throw time at a problem and solve it, the Agile methodology will punish you in subsequent sprints. Let me explain.

In Agile the team estimates the amount of work that can be delivered in a sprint, and this estimate is based on the work that has been achieved in previous sprints. When a developer brings in work that is not measured they effectively increase a team's velocity without properly accounting for the effort they are putting in.

Why should I care about the accountancy of work? I just deliver (excellent features).

If you flood a sprint with unaccounted overtime, subsequent sprints assume that you have the same amount of available time. As a developer, you are setting the expectation that you will continue to work overtime. You’re setting yourself up for toxic work conditions, and perhaps giving your colleagues the same expectations for their work.

The result of this can be to introduce a cycle of overcommitment and under-delivery into your feature team. If you’ve ever wondered where toxicity and a culture of unproductive teams start, you now have your answer. It starts with a single developer.

Are you saying it’s my fault?

Agile is about a constant, sustainable pace of work. Undermining that becomes a root cause of issues within the team. If you don’t care about sustainable working practices, it seems you don’t really care about your collegues. That can’t be right.

I don’t care about people.

Conclusion

Overtime is a quick fix for a specific problem. I’m actually not against fixing problems in your own time that are “your fault”. The definition of “your fault” gets smaller and smaller over time as having insufficient experience for a task actually isn’t “your fault”.

Moreover, overtime can undermine the principles of the Agile methodology. It’s not about you, it’s about working in a team and managing a workload well beyond any individual developer. 

Remember: you should always be thinking about your team and not just yourself. If everyone did that I suspect that the software development industry would work rather better.