8 ms·

Valuable prospective, but (as is the gist of half my comments here): People are even more different than you think. RescueTime wrote a similar post, but +100 d

by orzig 5y ago

Valuable prospective, but (as is the gist of half my comments here): People are even more different than you think. RescueTime wrote a similar post, but +100 data: https://rescuetime.wpengine.com/work-life-balance-study-2019/ https://rescuetime.wpengine.com/work-life-balance-study-2019... Look at the second histogram. The average is roughly aligned with OP’s summary, but there is huge variance. These comments have already devolved into people telling each other they are lying, or about to burn out - all I ask is humility in the face of our messy shared reality. Thank you for listening to my TED Talk, I guess

jvanderbot 5y ago
I think that you are right to point out the large variance, but you could have also have said that the 90th percentile was approx 7 hrs of work per workday, and 75th was probably 5-6
Noumenon72 5y ago
And that's a self-selected group of people who have enough trouble focusing on work that they went to find an app to monitor whether they're focusing.
KnobbleMcKnees 5y ago
I think you're completely right, however I'd love to see a graph of average work time claims on HN plotted against this. There's no denying that there are far more people claiming they work 60-80 hour weeks than would collate with the data that you and OP have provided. I think these people are generally overworked but are also poor assessors of their own performance, taking worst cases as averages and calling a day in which you finish at 5pm but answer a slack message at 9pm, a 12 hour day. Not to be too sardonic, but: I'm on call frequently but I don't tell people I've been working for 24 hours because I got a page at midnight, even if it can feel a bit like that by the end of the next day.
- tardigr8 5y ago
  We tracked work hours using a custom desktop app in our team (made by the team over several iterations to make it not burdensome), and insisted that devs log time against the downtime category (only during work hours of course). Some of the more senior devs were very honest about their downtime. Some days they would log 4 out of 8 hours downtime. Usually after a strenuous week or late night deploy. Examples of this are shooting the breeze for an hour, going on a wiki binge etc.. We were all surprised by the actual numbers coming through and the numbers in the various categories. Emails and project admin would average 20% of total team time. “Firefighting” which was attending to unscheduled troubleshooting was 15%. If you don’t believe someone who says they work X hours per week, you are probably right. We found there is a lot of minutiae, and a lot of down time when tired. Which we didn’t realize until we spent the time to log it. If you do work long hours, I can heartily recommend implementing an easy time tracking system for yourself with categories. From our experience, it reduced the hours you worked, forced you to get some sleep and exercise, and made you more productive in the hours you do work.
tardigr8 5y ago
Another study here that uses an estimate for productivity. https://ftp.iza.org/dp8129.pdf https://ftp.iza.org/dp8129.pdf His models show peak productivity between 5 and 6 hours a day. In my own experience, I have found productivity more related to sleep and exercise than anything else. Getting 7 hours good sleep (which means winding down for at least 30 minutes before sleep, a stretching exercise or meditation), and enough exercise every day to get the heart rate up. If I don’t do this for a couple of days, I can be unproductive from hour 2 after waking! We managed to implement a defect metric in my previous team that worked well, my defects went through the roof after a couple of days of 2 hours sleep. There is a lot of literature on this correlation, but just thought I would share my own experience.
- bandyaboot 5y ago
  I’m impressed that you can produce any code at all on 2 hours of sleep.
  - lifefeed 5y ago
    In college I learned that after 36 hours I was coding in circles. A fix to package A broke package B. Fixing package B broke package A. Repeat. I went through the loop three times before I recognized the pattern, and decided it was a good time to pass out.
- ajnin 5y ago
  Could you share some details about that defect metric and how you implemented it? Sounds interesting.
  - tardigr8 5y ago
    Nothing very automated I am afraid, but we had enough people who cared to do the admin work to make the figures reliable. We wanted to get a handle on how often work went backwards in our life cycle, and why it went backward. We had a JIRA lifecycle hook that asked for the reason for moving from SIT state back to Development state, or from UAT state back to Development state etc.. One of which was defect. A defect either being a confirmation that wasn't implemented as per the spec, or an edge case bug. Test failures were different, we had automated testing so test case failures were picked up before the ticket moved on in the lifecycle. We could also move completed tickets from Deployed to Review, if a production error was linked to a ticket. This movement could also be tagged as a defect in the same way. We would then just query the jira database and report on it, by project, by assignee etc.. It wasn't a blame exercise, we were more interested in the % of tickets that moved backwards, and the relative percentages of causes for the move. Another category for example was 'Requirements Changed', we worked with banks, so we had a LOT of these!
PragmaticPulp 5y ago
I’ve logged my work time (automatically with time tracking apps) for over a decade. I’ve also done a significant amount of hourly-rate consulting where I’m very careful to only bill for actual working time. When I was younger, one of my early challenges was that I had been misled to believe that only time spent in the editor, writing code counted as “working”. There’s a somewhat pervasive idea among devs that meetings, e-mail, communications, team discussions, and other such facts of business do not count as work when you’re a programmer. It led to some anxiety before I accepted that collaboration and communication is also work, something that seems obvious in retrospect but was difficult to swallow as a young programmer raised on Internet forums. Some people default to the other extreme, where they seem to count every hour as “work” if they did anything remotely related to work during that hour. By now, I’ve worked with a lot of people who claim 60-80 hour work weeks simply because they check their phone and type out single-sentence replies in Slack or e-mails on evenings and weekends. Some of the laziest, least productive people I've worked with are the same people posting on LinkedIn on Sunday morning about their 80 hour grinds every week. Two better metrics I’ve found for gauging productivity are total hours spent in work mode (in the office, or sitting at my home office desk) and total time spent in time wastes (Hacker News, non-work Slacks, Twitter, and so on). If I’m accumulating more than 30 minutes commenting on HN or scrolling Twitter, it’s a sign that I’m not really engaged with work and I need to shake things up. I’ve shared my time tracking tools and techniques with a lot of people that I’ve mentored. It’s some times shocking for someone to realize that they’ve been spending 4 hours on social media (Discords, HN and Reddit are social media) during a what’s supposed to be a workday. Many of them gauge their own level of focus as average or better than average before actually tracking it. They might even be surrounded by friends or peers who engage in the same amount of distraction during the day, reinforcing their own behavior. Usually once they see what they’re doing as a hard number they can take steps to break the habit, but for some it’s so deeply engrained that they don’t understand what they’re doing until they see it as a number.
- steve_adams_86 5y ago
  You and I seem to have a similar history and current practices. I’m curious, how do you track your active time on your computer? I use Qbserve on MacOS and I like it, but I haven’t reviewed options in maybe 5 years. It “just works” so I haven’t felt the need to explore.

by orzig 5y ago

jvanderbot 5y ago

I think that you are right to point out the large variance, but you could have also have said that the 90th percentile was approx 7 hrs of work per workday, and 75th was probably 5-6

Noumenon72 5y ago

And that's a self-selected group of people who have enough trouble focusing on work that they went to find an app to monitor whether they're focusing.

KnobbleMcKnees 5y ago

I think you're completely right, however I'd love to see a graph of average work time claims on HN plotted against this. There's no denying that there are far more people claiming they work 60-80 hour weeks than would collate with the data that you and OP have provided. I think these people are generally overworked but are also poor assessors of their own performance, taking worst cases as averages and calling a day in which you finish at 5pm but answer a slack message at 9pm, a 12 hour day. Not to be too sardonic, but: I'm on call frequently but I don't tell people I've been working for 24 hours because I got a page at midnight, even if it can feel a bit like that by the end of the next day.

tardigr8 5y ago
We tracked work hours using a custom desktop app in our team (made by the team over several iterations to make it not burdensome), and insisted that devs log time against the downtime category (only during work hours of course). Some of the more senior devs were very honest about their downtime. Some days they would log 4 out of 8 hours downtime. Usually after a strenuous week or late night deploy. Examples of this are shooting the breeze for an hour, going on a wiki binge etc.. We were all surprised by the actual numbers coming through and the numbers in the various categories. Emails and project admin would average 20% of total team time. “Firefighting” which was attending to unscheduled troubleshooting was 15%. If you don’t believe someone who says they work X hours per week, you are probably right. We found there is a lot of minutiae, and a lot of down time when tired. Which we didn’t realize until we spent the time to log it. If you do work long hours, I can heartily recommend implementing an easy time tracking system for yourself with categories. From our experience, it reduced the hours you worked, forced you to get some sleep and exercise, and made you more productive in the hours you do work.

tardigr8 5y ago

Another study here that uses an estimate for productivity. https://ftp.iza.org/dp8129.pdf https://ftp.iza.org/dp8129.pdf His models show peak productivity between 5 and 6 hours a day. In my own experience, I have found productivity more related to sleep and exercise than anything else. Getting 7 hours good sleep (which means winding down for at least 30 minutes before sleep, a stretching exercise or meditation), and enough exercise every day to get the heart rate up. If I don’t do this for a couple of days, I can be unproductive from hour 2 after waking! We managed to implement a defect metric in my previous team that worked well, my defects went through the roof after a couple of days of 2 hours sleep. There is a lot of literature on this correlation, but just thought I would share my own experience.

bandyaboot 5y ago
I’m impressed that you can produce any code at all on 2 hours of sleep.
- lifefeed 5y ago
  In college I learned that after 36 hours I was coding in circles. A fix to package A broke package B. Fixing package B broke package A. Repeat. I went through the loop three times before I recognized the pattern, and decided it was a good time to pass out.
ajnin 5y ago
Could you share some details about that defect metric and how you implemented it? Sounds interesting.
- tardigr8 5y ago
  Nothing very automated I am afraid, but we had enough people who cared to do the admin work to make the figures reliable. We wanted to get a handle on how often work went backwards in our life cycle, and why it went backward. We had a JIRA lifecycle hook that asked for the reason for moving from SIT state back to Development state, or from UAT state back to Development state etc.. One of which was defect. A defect either being a confirmation that wasn't implemented as per the spec, or an edge case bug. Test failures were different, we had automated testing so test case failures were picked up before the ticket moved on in the lifecycle. We could also move completed tickets from Deployed to Review, if a production error was linked to a ticket. This movement could also be tagged as a defect in the same way. We would then just query the jira database and report on it, by project, by assignee etc.. It wasn't a blame exercise, we were more interested in the % of tickets that moved backwards, and the relative percentages of causes for the move. Another category for example was 'Requirements Changed', we worked with banks, so we had a LOT of these!

PragmaticPulp 5y ago

I’ve logged my work time (automatically with time tracking apps) for over a decade. I’ve also done a significant amount of hourly-rate consulting where I’m very careful to only bill for actual working time. When I was younger, one of my early challenges was that I had been misled to believe that only time spent in the editor, writing code counted as “working”. There’s a somewhat pervasive idea among devs that meetings, e-mail, communications, team discussions, and other such facts of business do not count as work when you’re a programmer. It led to some anxiety before I accepted that collaboration and communication is also work, something that seems obvious in retrospect but was difficult to swallow as a young programmer raised on Internet forums. Some people default to the other extreme, where they seem to count every hour as “work” if they did anything remotely related to work during that hour. By now, I’ve worked with a lot of people who claim 60-80 hour work weeks simply because they check their phone and type out single-sentence replies in Slack or e-mails on evenings and weekends. Some of the laziest, least productive people I've worked with are the same people posting on LinkedIn on Sunday morning about their 80 hour grinds every week. Two better metrics I’ve found for gauging productivity are total hours spent in work mode (in the office, or sitting at my home office desk) and total time spent in time wastes (Hacker News, non-work Slacks, Twitter, and so on). If I’m accumulating more than 30 minutes commenting on HN or scrolling Twitter, it’s a sign that I’m not really engaged with work and I need to shake things up. I’ve shared my time tracking tools and techniques with a lot of people that I’ve mentored. It’s some times shocking for someone to realize that they’ve been spending 4 hours on social media (Discords, HN and Reddit are social media) during a what’s supposed to be a workday. Many of them gauge their own level of focus as average or better than average before actually tracking it. They might even be surrounded by friends or peers who engage in the same amount of distraction during the day, reinforcing their own behavior. Usually once they see what they’re doing as a hard number they can take steps to break the habit, but for some it’s so deeply engrained that they don’t understand what they’re doing until they see it as a number.

steve_adams_86 5y ago
You and I seem to have a similar history and current practices. I’m curious, how do you track your active time on your computer? I use Qbserve on MacOS and I like it, but I haven’t reviewed options in maybe 5 years. It “just works” so I haven’t felt the need to explore.