[tardigr8]

Another study here that uses an estimate for productivity.

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.

[hyperpape]

It's been a minute since I read this study, and I didn't take perfect notes, but iirc, the top line result is that (among munition workers) productivity per hour peaks below 40 hours a week, but total productivity peaks above it.

[jodrellblank]

> “my defects went through the roof after a couple of days of 2 hours sleep.”

2hours sleep or 2hours less sleep? Because 2hrs is approximately none, that would not be at all surprising.

[ajnin]

Could you share some details about that defect metric and how you implemented it? Sounds interesting.

[tardigr8]

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!

[bandyaboot]

I’m impressed that you can produce any code at all on 2 hours of sleep.

[lifefeed]

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.