4 ms·

Sounds like the underlying reason is a link between performance and endurance. If you're achieving very high productivity, you can't do 8+ hours per day every d

by nikanj 5y ago

Sounds like the underlying reason is a link between performance and endurance. If you're achieving very high productivity, you can't do 8+ hours per day every day. I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.

Silhouette 5y ago
I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work. There have definitely been experiments along those lines with successful results. I can't immediately find the original source, but I remember reading a few years ago about a business that switched to working 9-3 Monday-Friday, with resulting benefits to both productivity and morale. One advantage that was emphasized in the interview was that people were no longer distracted by non-work concerns like who would pick the kids up after school or needing to book medical appointments in the middle of the working day. With shorter working days and everyone being around during the same hours, collaboration and maintaining focus were also easier.
- papito 5y ago
  Microsoft tried the 4-day work week, for example: https://www.npr.org/2019/11/04/776163853/microsoft-japan-says-4-day-workweek-boosted-workers-productivity-by-40 https://www.npr.org/2019/11/04/776163853/microsoft-japan-say...
  - Silhouette 5y ago
    I'm not so surprised that they got such good results in Japan, where traditionally the business culture has been extremely demanding compared to most places. It would be interesting to know whether they did ever try similar experiments in other parts of the world with more "normal" working hours, and if so, whether they managed to repeat the successful result.
    - papito 5y ago
      The Japanese work ethic of working yourself to the bone is puzzling to me. A culture driven by deep traditions, they need to stop once in a while and re-evaluate some. Not all traditions are worth keeping, like working all day every day, or using fax machines - another tradition that is refusing to die in Japan.
- tonyedgecombe 5y ago
  Shorter days makes much more sense to me than shorter weeks. Wherever I've worked those last two hours of the day are always a waste.
  - Silhouette 5y ago
    I agree. If I'm working on something particularly interesting, I can code for much longer for a day or even a few days and still be making useful progress. However, for routine grunt work over the long term, I don't think I ever sustained much more than 6 hours of productive work per day when I was programming full-time. Past that, I would start to either slow right down or make mistakes that ended up taking more time to fix later. I did find that as I started taking on other responsibilities as well as the technical stuff I could make use of the extra time for that without affecting my programming much, but I suspect if I ever move to full-time on the business side the lack of variety will be a factor again.
tartoran 5y ago
8+ hours is not okay not every other day or even less frequently. Ok, once in a while is ok if one is in a good rhythm and they are enjoying themselves. But after 4-6 hours productivity drops sharply and starts to erode from the following days: fixing up poorly made design choices, etc If your employer expects you to be productive 8 hours a day I’d look for something else
- marcus_holmes 5y ago
  This is something that I find very hard to explain to non-technical managers when I run dev teams. There's the expectation from non-technical managers that time away from the keyboard is "wasted" - that coding is a matter of pushing the buttons constantly, and that code is of a consistent quality, so more of it is better. There's also the bullshit long-hours work culture where leaving work before the boss does is somehow unacceptable. The best approach I've found is to explain that the codebase is an asset that can be damaged. And the code itself is a liability - it must be maintained in the face of changing requirements and technology. "More code" is worse, not better, for the company. So having tired developers write bad code is both damaging our asset and introducing more liabilities. We need our devs rested and on their game to avoid that. We need them thinking deeply about the code they're going to write. And that thought doesn't have to occur at the keyboard. Good devs think about their code while going about the rest of their lives. It's better if a tired dev goes home to rest rather than continuing working on the code, because they'll just end up damaging it if they work on it tired. It's better for a dev to go for a walk to think deeply about what they're doing rather than write code that they're not sure about. We don't want devs working on the codebase after ~8 hours, because they probably haven't thought enough about what they're writing. It can work. Depends on company culture. There's also so much bullshit in dev culture itself about "marathon hacking sprints". I bought into this myself, did a 32-hour sprint to meet a deadline. It was a complete mess. I would have been so much better off getting some sleep, a decent meal, and going for a walk in the middle. I think most devs go through this lesson at some point.
  - jacques_chester 5y ago
    > And the code itself is a liability - it must be maintained in the face of changing requirements and technology. A nitpick: the better analogy is that code is an inventory asset. It can decay or rot, it costs money to acquire and money to maintain. But it is not a debt owed to someone else, as a liability is.
admissionsguy 5y ago
> I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work. It might be possible, but it definitely would not be acceptable!

by nikanj 5y ago

Silhouette 5y ago

I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work. There have definitely been experiments along those lines with successful results. I can't immediately find the original source, but I remember reading a few years ago about a business that switched to working 9-3 Monday-Friday, with resulting benefits to both productivity and morale. One advantage that was emphasized in the interview was that people were no longer distracted by non-work concerns like who would pick the kids up after school or needing to book medical appointments in the middle of the working day. With shorter working days and everyone being around during the same hours, collaboration and maintaining focus were also easier.

papito 5y ago
Microsoft tried the 4-day work week, for example: https://www.npr.org/2019/11/04/776163853/microsoft-japan-says-4-day-workweek-boosted-workers-productivity-by-40 https://www.npr.org/2019/11/04/776163853/microsoft-japan-say...
- Silhouette 5y ago
  I'm not so surprised that they got such good results in Japan, where traditionally the business culture has been extremely demanding compared to most places. It would be interesting to know whether they did ever try similar experiments in other parts of the world with more "normal" working hours, and if so, whether they managed to repeat the successful result.
  - papito 5y ago
    The Japanese work ethic of working yourself to the bone is puzzling to me. A culture driven by deep traditions, they need to stop once in a while and re-evaluate some. Not all traditions are worth keeping, like working all day every day, or using fax machines - another tradition that is refusing to die in Japan.
tonyedgecombe 5y ago
Shorter days makes much more sense to me than shorter weeks. Wherever I've worked those last two hours of the day are always a waste.
- Silhouette 5y ago
  I agree. If I'm working on something particularly interesting, I can code for much longer for a day or even a few days and still be making useful progress. However, for routine grunt work over the long term, I don't think I ever sustained much more than 6 hours of productive work per day when I was programming full-time. Past that, I would start to either slow right down or make mistakes that ended up taking more time to fix later. I did find that as I started taking on other responsibilities as well as the technical stuff I could make use of the extra time for that without affecting my programming much, but I suspect if I ever move to full-time on the business side the lack of variety will be a factor again.

tartoran 5y ago

8+ hours is not okay not every other day or even less frequently. Ok, once in a while is ok if one is in a good rhythm and they are enjoying themselves. But after 4-6 hours productivity drops sharply and starts to erode from the following days: fixing up poorly made design choices, etc If your employer expects you to be productive 8 hours a day I’d look for something else

marcus_holmes 5y ago
This is something that I find very hard to explain to non-technical managers when I run dev teams. There's the expectation from non-technical managers that time away from the keyboard is "wasted" - that coding is a matter of pushing the buttons constantly, and that code is of a consistent quality, so more of it is better. There's also the bullshit long-hours work culture where leaving work before the boss does is somehow unacceptable. The best approach I've found is to explain that the codebase is an asset that can be damaged. And the code itself is a liability - it must be maintained in the face of changing requirements and technology. "More code" is worse, not better, for the company. So having tired developers write bad code is both damaging our asset and introducing more liabilities. We need our devs rested and on their game to avoid that. We need them thinking deeply about the code they're going to write. And that thought doesn't have to occur at the keyboard. Good devs think about their code while going about the rest of their lives. It's better if a tired dev goes home to rest rather than continuing working on the code, because they'll just end up damaging it if they work on it tired. It's better for a dev to go for a walk to think deeply about what they're doing rather than write code that they're not sure about. We don't want devs working on the codebase after ~8 hours, because they probably haven't thought enough about what they're writing. It can work. Depends on company culture. There's also so much bullshit in dev culture itself about "marathon hacking sprints". I bought into this myself, did a 32-hour sprint to meet a deadline. It was a complete mess. I would have been so much better off getting some sleep, a decent meal, and going for a walk in the middle. I think most devs go through this lesson at some point.
- jacques_chester 5y ago
  > And the code itself is a liability - it must be maintained in the face of changing requirements and technology. A nitpick: the better analogy is that code is an inventory asset. It can decay or rot, it costs money to acquire and money to maintain. But it is not a debt owed to someone else, as a liability is.

admissionsguy 5y ago

> I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work. It might be possible, but it definitely would not be acceptable!