I am a junior developer so I haven't had much experience in the field, but I've two different jobs and it seems like it's normal or almost expected for developers to work more than the typical 40 hours a week. I understand that people can be very passionate about development and like doing things outside of work. I myself enjoy what I do but it's still work. I don't like bringing work home.

So with my co-workers doing all this work outside of the office and work hours, I feel like I'm a worse employee than them. But it's never been said "we need you to work more than 40 hours" or whatever.

I just want to know if this is normal and if I should get used to writing code outside the normal work hours. Or if these guys are just over achievers.

  • 1
    I'm voting to close this question as off-topic because it's operating from a questionable premise and covers a subject that's too broad, subjective and situational for StackExchange's Q&A format.
    – Lilienthal
    Feb 12 '16 at 0:12
  • 1
    It's not too broad - though the premise is questionable, there are really only a couple of reasons for the long hours: poor planning and inflexible project management.
    – HorusKol
    Feb 12 '16 at 0:21
  • It's normal in some cultures/companies, in others not at all - if I work over 37.5 hours a week, I have to justify it on my timesheet.
    – Jon Story
    Feb 12 '16 at 4:34
  • Very questionable premise. There are so many roles that work longer hours, that working "more than the typical 40 hours" actually sounds relatively part time :-) It's certainly less than half the hours expected from employees at one place I worked (nothing to do with programming)
    – Rory Alsop
    Feb 12 '16 at 8:37
  • What are the concrete things that make you think your co-workers are actually working more than 40 hours (on a normal, sustained basis)? For example, if you come in at 8 AM and leave at 5 PM every day, can you really say yo have an accurate perception as to how often and how late your co-workers stay to do "outside the normal work"?
    – Brandin
    Feb 12 '16 at 8:56

I don't think that this is specific to the development industry, but it can seem that it happens a lot, bu not all (programming) jobs are like this either.

Why does it happen?

The most common cause of this is understaffing or poor planning. There are pretty much three factors in development - features, quality, time. If you fix time and quality, you automatically limit the features you can deliver. Some places want all three - good quality features within a specified deadline. But they don't want to hire more staff (mostly for money reasons, but sometimes a new developer can end up slowing a project), so the current team end up with more hours per individual.

Tied into this is an expectation that a developer will code for 7.5 hours a day if they are contracted for 7.5 hours. This does not happen. Developers need breaks for coffee and toilet, they check emails, attend meetings. So, to get the expected 7.5 hours of tasks done, they need 10 hours to do it.

Management need to allow for the incidentals, and plan on only some of that 7.5 hours being devoted to development tasks (my personal preference is planning for about 5-6 hours "on task" each day).

Another reason - and I've seen this to be more within the gaming industry than elsewhere, but it does apply in general, too - developers are catching up for slacking early in the project (or even day). Okay - not quite slacking... But a lot of project plans from management don't easily account for research and discovery. I've heard stories from games development studios where they would try all sorts of weird and wacky ideas and programs as research for the first year or two in a two/three year plan... Then they would realise they have to deliver a product, and then spend one year doing all the work they didn't do in the previous year. This can happen in the day, where they end up catching up for doing non-productive development in the morning.

Is it common?

As I said, this practice is not universal. We have a minimum 37.5 hour working week, and almost everyone spends less than 40 hours at work, most weeks. After some changes in project planning, there's only been two separate fortnights were overtime was requested in almost three years. We also haven't missed a deadline.

There are many other places to work at, and each one has different culture. If you don't like excessive hours, you should be able to find a workplace that offers more stable working hours.

  • correct, I know lots of developers they often rush to catch up because they haven't really been working all the time
    – Kilisi
    Feb 12 '16 at 7:23
  • It's not really a bad thing, though. Most of them are programming - just not on-task...
    – HorusKol
    Feb 12 '16 at 10:01
  • yep, I don't care so long as the works done and deadlines are met
    – Kilisi
    Feb 12 '16 at 12:39
  • If you are looking to affect some change in the estimation process it may help to capture some specific data that shows the "on task" time. I've recorded significant actions in no smaller than 15 minute increments for a day for a few days, and then could tell I was (example) spending an average of 1.25 hours per day dealing with email and administrative work, .75 doing code reviews, 2.25 helping others or mentoring, .5 in meetings, leaving me with 3.25 actually on task. I do this still in order to improve my own working habits.
    – StingyJack
    Jul 22 '16 at 17:52
  • The 5-6 hours "on task" seems a genius idea. We have 9 hour days in India and finish an 8-hour task or two 4-hour tasks in one day. Interruptions are accounted for in these hours. Have the two systems been compared? I guess peer pressure makes people report they "worked" 8 hours rather than 6 hours a day. Aug 9 '16 at 7:34

Hours worked is irrelevant to your employer. What does matter is productivity. These guys may be working late to get more done, or working late to get enough done.

All else being equal, if they're accomplishing more they are better employees, for now... assuming they can sustain that pace without burning out. Working smarter is better than working harder, but given enough time you can drive a nail with a screwdriver. Of course the screwdriver's going to get pretty beaten up in the process; you may not want to take that approach.

If they are working longer and not producing more high-quality results, that's a point in your favor; you've got more reserve capacity.

The fact that someone else may be more productive shouldn't, by itself, scare you. There will always be folks who can code rings around you, and folks who struggle to keep up with you. Focus on building your own skills up to be the best employee you can be, which includes helping others succeed. Those aren't competetors, they're resources that can help you do your job better ... and possibly people who could learn some things from you, which also counts toward your value as an employee.

As we've said in other answers, this is a positive-sum game. Working with people will get you farther, faster, than working against them.

Conclusion: You're being paid for a specific number of hours. You need to work those hours. Whether you donate additional time to the company is up to you. You don't have to be the guy who's married to his keyboard to be a valuable member of the community, but if you want to go that route and can really sustain the higher pace that's one way to hit "greatly exceeds expectations". It isn't the only way, nor the best way for most people, and a simple "exceeds" may be quite sufficient if you don't have your heart set on being a VP by age 30.

  • +1 The asker is very unclear on whether the extra hours are due to poor project management or passionate co-workers
    – iabw
    Feb 13 '16 at 17:56

You have a set amount of work to be done by a deadline, and a set amount of staff doing the work. You can look at it this way for any number of projects. So take the amount of work, and divide it by the number of people doing the work: can it be done if everyone works an even 40hr week? How people handle their time will depend largely on a number of factors, but work:staff vs. deadline is an underlying principle.

For example: For some jobs, working harder during the same shift doesn't net you the same effect as working longer hours, and for others, taking your work home as opposed to burning yourself out terribly during one, long shift is desirable.

  • And this is why Agile process became popular and successful. Instead of working to the deadline you adjust the deadline to your capacity. Every week or two depending on how you setup your process you look at your feature backlog, prioritize it, rate how much effort is involved (in arbitrary points) and the work on what you 'historically' have been able to complete. We also make it a point of not pulling heroics to complete a sprint because that skews the numbers. We do buckle down and work extra though if things are not progressing on the whole as we would like. But it's a team decision. Feb 12 '16 at 16:38

I think a lot of it is hold over to early days of mindless hours of allocating memory, longs builds, and ambiguous error messages. And also pushes of a version release.

With better tools of today programmers are much more efficient and less dead time. The norm seems to be moving to a more normal work week.

In something like gaming the norm is 60+ and probably will continue.


My experience with software development is that it's a combination of things:

Not enough resources allocated to a job, combined with poor planning.

There's that joke that goes around that devs always add 50% to the time they're actually going to take doing something in a quote, and then their PMs add another 50% on top of that. This isn't totally false and it's not always a bad idea either. A job you think will take you 4 hours may in fact take you a couple days to hammer out once you fix unforseen bugs, deal with complications that new requirements bring in (and I love Agile but that is one thing that happens with it), unit testing, QA testing, code review, and so on.

The only way to fix that is to plan out enough ahead of time, and nobody wants to look like the slow dev in the group.

Setting yourself up for failure

As a contractor, one of the things that I like about going into new jobs is the change of pace and often the huge, gaping problems that I was brought in to fix. It's perfectly natural to work extra to fix those glaring issues, and on top of that I have to say that it's a lot of fun at first to deal with entirely new issues. That, I think, causes a lot of folks to work a lot of OT, paid or otherwise, at the beginning of a gig.

Where that idea breaks down is that sometimes, especially if you aren't very clear about the fact that you're working extra time to meet deadlines, etc., the non-programmers on your team - BAs and stakeholders especially - get a false idea of how much you can produce in a week. That makes it extra hard to scale back 3 months down the line, as you then have to discuss why it is your productivity has gone down.

The constant death march

One thing that I have seen a pretty good amount of as well is a team being in constant crisis mode. It's OK to work a couple 50 or 60 hour weeks to meet a particular deadline, or if there's a major bug you've got to quash right now, but I've been at places where management seems to arrange things so that there's always a looming crisis right around the corner for... reasons. Some people think that this makes people more productive (I disagree but that's the thought anyway), sometimes you're coming in at a minus because the previous team spent a year to do something that ought to have taken them six months, and so on.

It's hard to come up with a good solution for this issue as it tends not to come from developers but from management. All I can say to this is, make sure you stay in constant communication with said management so that they at least understand the amount of stress they're putting on you and your team.

Scope creep

As noted, I do enjoy Agile, and one of the things I enjoy the most about it is the constant weekly or biweekly communication you get to have with people who are going to be using your product. You show off what you've added, they talk to you about how it differs from what they wanted, you make those changes and show them off at the next sprint, etc. I think it neatly avoids the really huge problem of Waterfall, which is that you can spend months working on something only to wind up with an end product that is all wrong.

That being said, Agile lends itself really well to people coming up with new ideas in those planning / demonstration meetings, and it's once again hard to be That Guy who says "that's not in the documentation. We can add it but it will add X weeks to the project". But someone has to be That Guy if you want to avoid scope creep possibly leading to the Constant Death March.

It's just the way we work

I think this is really the least important one of the bunch, but a lot of the time if I'm presented with a problem, I'm going to just sit down and work on it until it's solved. If that requires a couple of 14 hour days, then it requires a couple of 14 hour days. And if I can't take off early some time during the rest of the week, maybe I wind up with 50 hours plus.

This isn't a normal office job where you clock in at 9am, take a 1 hour lunch, and clock out at 6. I've noticed that non-programmers tend to be a bit less cognizant of this when they see a dev taking off at 2 in the afternoon on a Wednesday (they aren't seeing, of course, that you were in at 5 that morning because there was an issue you just couldn't put to bed until you solved it), but the overall point remains: this is a job where at the end of the day you are not judged by the hours you work but by the stuff you deliver.


You aren't always going to have to work 70 hours a week at a start-up, but bear in mind that for a small company that's just getting started, you're not just working for a paycheck, you're working to keep your company in business. Sorry, but sometimes you just can't avoid this. If you want to keep yourself around the 40 hour mark, find a Fortune 500 company to work for.


Programmers are authors.

If an author was writing a book, well it would be really odd for someone else to take over mid paragraph and hand off to another author.

There are some shops were the programmers write the whole book and others where they take care of their own chapters.

However if you are good they would rather someone work 15 hours writing good than have 8 hours of good writing and 7 of gibberish.

If you want to work less hours as a programmer go to an agile shop, go to a company with a ton of programmers (better than you), go to a company with a mature product line, or get a lot faster.

  • I'm not convinced the good programmer will still deliver quality when he is approaching the 15 hour mark. So the premise of these companies is flawed imo. Feb 12 '16 at 7:56
  • @PaulHiemstra - Wrong. A good author will still know more about the story than the one that would take over for such good author. Now the author might quit before the book is over but they are still the best to write the story, hours be damned.
    – blankip
    Feb 12 '16 at 7:58
  • 1
    If the author continues to work 15 hours a day, they will burn out and the book will not finish. Letting the author work on the book for a normal amount of time per day will yield better results. I agree with you that a good author is always better, just not that letting them work for 15 hours yields good return on time invested. Feb 12 '16 at 8:00
  • @PaulHiemstra - go over to the writers stack. See how many hours authors put in the last month before a deadline. 15 hours will seem like vacation.
    – blankip
    Feb 12 '16 at 8:02

Not the answer you're looking for? Browse other questions tagged .