Hacker News new | comments | show | ask | jobs | submit login
Ask HN: Do you get more done working longer hours?
17 points by shifte 104 days ago | hide | past | web | 18 comments | favorite
I've been wrestling with this idea for a while that pulling long hours at the office doesn't increase the chances of us meeting a deadline. For whatever reason there's rarely more than 4 hours in the day that I write solid working code. The other hours are either meetings or replying to emails. The latter I mostly skip and read HN or Reddit.

What's your experience? Can an engineering team be successful only working 4-5 hour days?

Brain-intensive work is fatiguing just like physically demanding work, and if you regularly push past your limits mentally or physically there will be consequences. Yes, over the short term you can get away with it. But it's gonna cost you, and the longer you do it the more it's gonna cost.

With that in mind, not all coding is equally brain-intensive. If I put in a serious intense hardcore 3 hour session of gnarling code wrangling, I'm pretty much done for several hours. Conversely I can do minor refactoring and code cleanup all day.

It's well known that pushing developers to work more hours isn't effective. It might (might!!) get a product to deadline faster, but it will be at the cost of burned-out developers who will have greatly reduced productively, and a decreased quality in the codebase and more defects at the time of launch. And the better developers tend to leave for a healthier environment.

Regarding skipping meetings and emails, figure out (if you haven't) why you're doing that and take appropriate steps. Maybe it's having a discussion about why a particular meeting is unproductive, or alternate forms of communication. Maybe it's finding a reason to go to a meeting other than its stated purpose.

My company operates during business hours and then some (6 AM - 2 AM). I think, for the most part, they have decent hours, but I'd say we could be just as productive with working 10 hour days, 4 days a week, instead of 5 days a week at 8-9 hours. But generally, I work 9 hour days 5 days a week. About 4 hours of my day is somewhat busy, but not always. Once in awhile, my entire shift is busy.

Luckily, my company doesn't have a policy that anything I work on during my shift is theirs. They don't mind me doing me during downtime, and in fact, they encourage it. I believe its right in the handbook that they encourage us to go on social media if we have nothing else to do and have gotten all of our work done. I work for a media company, so it kind of makes sense that they would want us to be up to date with social media trends and news.

I've built several successful websites during downtime and off-hours (after I leave work and continuing on it). I think much of my success outside of work has to do with the hours I've had downtime at work. We can definitely get busy... but we pretty much sit around, waiting for an inbox to have work in it, and we just get it done when it comes in. After it's done, I return back to what I was doing before.

While I definitely procrastinate, it's rare for me to not do anything. Always working on something. In my early days, I had started up a side gig freelancing, building, maintaining, and editing websites for clients, and then I started up a side business while working for my main job and currently in the process of starting up a second side business.

None of my side businesses steal away any business from my company, and if anything, only compliment their work and mine. In fact, I try to reel in business for my company so that I can keep doing what I do. Everyone wins.

When I was working full time and working on my doctorate I had very long days for 27 months. Several months I was only averaging 2 hours of sleep. I can say for me, working longer hours was not ideal. I had trouble concentrating. At times I could not complete simple tasks. I had leg cramps that were excruciating. We had a very short timeline to complete a ridiculous amount of work.

I firmly believe that obtaining a doctorate is as much about jumping through hoops that they have set on fire as it is mastery of your academic field of study. I just wonder the quality that was surrendered because sleep was in critically short supply.

In business, I believe it is better to work smart than to work hard. I acknowledge that when I was working on my doctorate had I taken a step back even for a solid day, I would have recharged and likely saved myself 5x that in lost productivity. Unfortunately, it is hard to see that when you are under intense pressure to produce huge volumes of work on a very brief timeline.

Each person is somewhat unique in this regard, but generally speaking there is a peak number of hours you can work and be effective. Beyond that, you're working longer and less effectively, and more likely to make mistakes. And that can be very counter productive.

On average, I think that number is about 6-8 hours per day for most people. But even that length isn't functioning at your peak, just high enough to be generally worthwhile. Peak effectiveness would be more like half that.

You need to do your research and find out what works best for you and your team, but the larger the group, the more likely you are to fall into the typical pattern.

Certainly. I get a lot more done on days when I work 6 hours than I do on days when I only work for 2. In fact, I probably get more than 3× the work done, which is nice. On the other hand, if I worked for 18 hours a day I would certainly not get another 3×; I would soon hit the point of diminishing returns. Where that point is must certainly vary from person to person, for I have noticed that it also varies from project to project and day to day.

Sounds to me like you need to reduce distractions rather than working more hours.

The first few days of working longer hours, I get a ton done. By day 10 of working 55-hour weeks I'm about as productive as I was doing 40 hours. By day 15, I'm getting less done in 55 hours than I do in 30 hours when not burnt out.

Nowadays, working long days is something I do a few days a month when stuff happens to pile up that will slow other people down if I don't complete it.

I recommend thinking more about why you're not productive in the hours you're working. My solution to excessive distractions was to switch my schedule two hours earlier. I now get a solid 2-plus hours of uninterrupted concentration every morning before the office begins to fill up. Then I spend a few hours doing things that require interfacing with other people. And if I'm lucky I get a few more concentration hours later in the day too. I also work from home whenever possible to minimize distractions - those days are blissfully productive.

I have seen a few individuals work longer hours and succeed. But more often it's the kind of project they would sneak away to do, instead of sneak from. Software is one of those industries that runs so efficiently on passion, although passion is a limited resource.

I do think progress is proportional to time spent on it. The only question is how much time you can get in and at what cost. You can always push harder, but it can lead to burnout and deplete passion.

Given overhead of chatting with coworkers, meetings, planning, hiring interviews, etc., I would indeed expect most programmers just write code productively for 4 to 5 hours and that longer hours don't produce any more value.

My personal experience: for past few years I have been at least as productive as most programmers, while only working 28-35 hours a week. And not all those work hours were spent coding, obviously.

I'd take it a step further: I believe enforcing a shorter workweek makes you more productive. It forces you to prioritize, instead of going off on yak shaving expeditions, it forces you to spend more time thinking upfront, since you can't (badly) compensate by working longer hours. More here: https://codewithoutrules.com/2016/11/10/work-life-balance-so...

I do, but it seems to be less about the hours being longer and more about my being in the office when it's quiet and distraction-free. Therefore I am hoping that noise cancelling headphones will help me be more efficient during the normal workday. It won't be the same as having the whole office quiet and the room to myself, but it might be an improvement.

There was a time that I could put in more hours and keep my productivity up. But it wears you down, and after two years of many hours I'm quite worn out. So, yes, short time you could probably get more done if you push yourself. But it will run you, and any developers, into the ground leading to lowered productivity over the long term.

I think the connection is loose at best. Personally, yes, I'm wired so I can mostly turn more hours into more progress. That's great when I'm working alone. But I don't think I've ever been on a paid project at a company where the bottleneck was straight-ahead serial work. It feels like teams have a way of divining when's the absolute latest they can deliver something, and will pad any length workday with slacking, as needed.

Working is like running, consistency and staying healthy are key. You can train/work your ass off and get better results short time, but you will pay for it later and geat injured/sick.

Plan your day so you can use those 4 hours of focus the most! For me that means no meetings, phone calls and email in the morning if possible.

I get less done with longer hours. I try to eliminate meetings, phone calls, emails.

We have Jira at work as well as some legacy Bugzilla systems. I have been trying to get everyone sending requests to my group to put them in Jira.

I prefer a structured process so I can minimize interruptions of developers.

The problem with 4-5 hours days is that you will not be efficient 100% of the time. You need those extra hours (for breaks, communication, coordination, mentoring, etc) to be able to code 4 hours in a day.

Very much so. I work 9AM-5PM, with an hour for lunch, and sporadic 5minute breaks as I pace, or make coffee.

Some days I'm on fire and I'm working at 95% from start to finish. Other days I'm maybe 60% productive, things just "don't go well". On average I assume I'm a productive and useful employee, as I've never had any performance warnings, or criticisms.

It's just the nature of the industry. You can't perform at your peak 100% of your working life. Some days you need to mull problems over, try different approaches, cancel them debug random failures, and so on.

I love my job, I love my colleagues, but I can't be 100% efficient and if I were I suspect I'd get annoyed about it. I need to wander, to pace, and to scribble on note-pads.

No, since I've reduced my day to ~6 work hours I am much more productive.


To answer your question - Yes.

In point of fact, the observation of no interruption for the team (by anyone including management) means more work is done in less hours. This observation, which I have found to be true, was made in the late 80's.

Any interruption in thought processes when doing engineering/technical work requires the person to spend a significant amount of time returning to the place where the interruption occurred.

Management practise since the late 80's has ensured that all technical staff (engineering, programmers, etc) must be interruptible at all times (especially by management itself). The team/team members have no ability to redirect phone calls, email messages or management meetings to management PA's to deal with.

The experience that I and my technical colleagues had was that if we could have a non-interrupted period of 2-3 hours to work on any project, we would achieve more than we could in any normal interrupted 8 hour day. Often we found that an extended uninterrupted period of 4-6 hours would allow us to complete technical work/projects that would normally take us a week to complete. This was based on a total effective 1 hour due to the continual interruptions we normally received during our normal days. This lead us to start work early and finish late when we could work uninterrupted. Of course, this worked against as this was in effect unpaid time.

The common management practise of the last 30 years has ensured that every technical/engineering team works at its lowest efficiency. There are some managers who will protect their engineering teams from such interference and as a consequence get a much higher efficiency out them in a normal work day of 7-8 hours. Unfortunately, these kinds of managers are few and far between.

I would say that any team that works beyond this number of hours will still not achieve anywhere near the same results as a corresponding team that has the unfettered ability to block out all interruptions.

In addition, it also requires group offices for this to work. Open plan layouts are an instant cause of inefficiency, especially with technical/engineering groups. Two to three team members per office would be ideal.

As an office is considered a status symbol within management circles, we should not expect any sensible outcome in this area. All of this was documented and published in the late 80's.

In relation to your comment that in any day there is only 4 hours that you write solid code, I would suggest that if you had an uninterrupted 4 hours that the amount of code produced would very likely double or even triple and be even better.

Just don't expect any management or management guru's of today to see it this way.

The comment regarding brain-intensive work being fatiguing is certainly true when you have to deal with multiple interruptions. From my experience, mostly the fatigue is from having to get yourself back to the place you were at before the interruption. A uninterrupted period of time devoted to a brain-intensive activity is less stressful than the same period that has had interruptions.

I am also saying that such periods of time need to be regulated by oneself so that burnout doesn't occur. Good physical activity, good food, rest, relaxation and good non-work related socialising make one able to keep at peak efficiency.

Have made some edits about to fill in more explanation and correct spelling and sentence structure.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact