The world of software development has a strange reputation, both for insiders and outsiders. One thing many people have wrong ideas about is how many hours software engineers work, or should work. I’d like to dive a little deeper into this subject: What is the reality and what should you do?
What Many People Think
Many people think that software engineers work almost all the time. When you ask about average work hours per week, numbers between 60 and 80 hours per week are not an uncommon response. This idea lives among both developers and non-developers. Among some developers, there is also a strong feeling that you can only be a great developer if you work this much.
I’m not sure where the idea comes from. Maybe it originated from the image of the asocial nerds that spend all their time sitting behind a computer. Or maybe the immense pressure that Silicon Valley startups have put on young developers created this idea. In some cases, developers like to cultivate this image out of some peculiar macho reasoning of what it takes to be a “real” developer.
Apparently, things have improved over time. A CNET article talks about how companies and individuals have evolved to more realistic work weeks and room for a personal life. Companies have also realized that overtime doesn’t necessarily mean developers will be more productive. And with the advent of working from home, developers can increase their productivity without crunching extra hours.
The reality is complicated. Just like in other professions, there are people that work a large amount of hours every week.
Maybe they’re working for their own company and are laboring away to make it successful. Or they might be hoping for a raise, extra perks, or a promotion. Or maybe they’ve agreed to work this hard to meet a deadline, so working more hours is just temporary.
The 2020 StackOverflow survey found that “globally, 75% of developers work less than 45 hours per week.” You can also look at the numbers per country: They range from 39.2 to 41.8 hours per week. All in all, I don’t think these differ spectacularly from other jobs or industries.
The average amount of hours worked in one week differs across countries. There are many different datasets to compare countries:
The exact numbers are less relevant to us. The important thing to note is that the difference between the two extremes in each data set can be up to 10 hours a week.
Company and Industry Differences
Not only do people work more or less hours depending on where they live, it also differs by company and industry.
I can imagine that a software engineer in a privately owned startup will be expected to work more hours than someone in the same position at a government agency—not because civil servants are less motivated, but because some industries have been regulated more and have a stronger trade union representation. Throughout history, this has reduced the amount of hours employees are expected to perform in some organizations.
The world consists of many different people, so we can’t expect everyone to be passionate about software engineering. That, too, is diversity.
Every now and then, someone writes an article about “the 9-to-5 developer.” This term is often meant as derogatory because it portrays an image of a developer who clocks in at 9 a.m. and leaves for home at 5 p.m.
When people write or talk about this type of developer, they mean that these developers aren’t passionate about the job, have stopped learning, and are generally not good developers.
Don’t worry if this narrative doesn’t sound appealing, because it’s just plain wrong.
It assumes that every developer has the time. This isn’t always the case. What about people with children? Or single parents? What if the developer spends a lot of their free time volunteering for some charity? Maybe they need to combine software development with another job.
So, it’s quite condescending to assume that everyone can spend as much time on software development as you can.
But even if they could, maybe they just don’t want to spend all their time on software development. That should be a valid choice.
Sometimes, a company will have to meet a certain deadline and might have no other option than to ask people to do overtime. As long as this isn’t the case every week or month, personally, I’m fine with that.
But again, software engineering isn’t very different from other jobs. You should be able to find a job in software development that matches your expectations and where you have to work overtime only on rare occasions.
A 2012 survey among 3,000 developers found that 38% of developers code after hours. The survey doesn’t go into details, but my guess is that this is often not work-related. Because many programmers love programming but can’t always work on things they love at work, they do so in their own time. It’s also a way developers learn and improve their skills.
I’m no labor expert, but I don’t know many professions where companies expect you to learn new skills in your own free time. Not to the amount that is expected from software engineers.
The field of software development is evolving extremely fast and has so many aspects that it’s hard to keep up. To make matters worse, many companies hesitate to invest a lot of time, effort, and money in expanding the knowledge and skills of their developers.
This leaves us in the situation where many software engineers learn in their free time. They do this, in part, because they like to do so, but also because their free time is the only time when they learn what they want to learn.
And companies probably also expect this because we’ve been doing it for so long.
I would recommend you spend some extra time learning new things or doing the things you love. Because the programming in the job won’t always be what you’re passionate about.
But don’t be afraid that you’ll have to spend hours and hours of your free time studying because there is so much to learn. Accept that you can’t know everything in the software engineering space. If you keep an open mind toward new technologies, techniques, and languages and play around with them now and then, you’ll be fine.
So, Which Is Best?
Is one culture better than the other? Are software engineers who only work 32 hours a week lazy? What if they work 38 hours? Or 40? Or more than that?
You can see how it’s impossible to provide a simple answer to this question. Software engineers around the world work in different circumstances and they all have their own motivations. And even in the same country or city, hours will differ.
I’m also sure that you can’t correlate programming proficiency with the amount of hours people spend on programming.
So, what should you be aiming for?
We’ve seen that average working hours differ based on culture, industry, company, and individual. So then how should we answer the question of how many hours a software engineer should work?
This all depends on you. If you love programming so much that you want to spend all your free time on it, go ahead. If you have other obligations or hobbies, that’s fine, too. Don’t feel bad.
Will the developer crunching 60 hours every week be a better software engineer than the one working “only” 30 hours? Not necessarily. There are so many factors that make someone a good software engineer:
- Technical knowledge
- Speed of learning something new
- People skills
- Domain knowledge
- Efficiency when working
I’ve worked with software engineers who work 50 or 60 hours a week with little business value to show for it. And they definitely weren’t the best developers. On the other end of the scale, there are genius developers who work a lot less but make every hour count. If I had to make the decision, I’d know who to hire.
In this regard, software engineering is a profession like many others: The exact amount of hours you perform doesn’t really matter. Your skills and what you deliver are what’s important. Take what feels like a normal work week for you and maybe tack on some extra hours for learning new things now and then. Do that, and I’m sure you’ll do fine as a software engineer.
This post was written by Peter Morlion. Peter is a passionate programmer that helps people and companies improve the quality of their code, especially in legacy codebases. He firmly believes that industry best practices are invaluable when working toward this goal, and his specialties include TDD, DI, and SOLID principles.