When Does Work Actually Get Done?
priceonomics.com
priceonomics.com
Anecdotally, I am an active user of multiple project management platforms and do my best to keep them actively up to date. When I am in a state of flow and being productive I almost never break it to update the project management platform.
I'm honestly not sure there's much of a pattern to when it gets updated. Sometimes it's when I'm trying to get into a work mindset and remember what I did the day before. Sometimes it's when I'm winding down at the end of the day and making note of what I did. Sometimes it's in between tasks.
A better measure might be when git commits were made to repositories, but even that is a pretty imperfect measure. I often don't made small commits as a I work, but large ones once a cohesive portion of the task is complete (or several small ones as the same time using git add -p).
Or if you took git commits, but also measured their size, and came up with an average size of commit per hour of work. That way you could use the size of the commit to roll the clock back and determine when most of that work was done?
Fundamentally, this data just looks like "people update tickets before lunch and before the end of the day", which is hardly interesting.
In fact, I think any quantitative measure of tangible results would be flawed, at least when it comes to open-ended and creative work (research, exploratory data analysis, software design, ...). In my work as a PhD student I often have a full day, damn, even a full week without any tangible result. But when the results eventually do arrive I usually realize that those seemingly unproductive hours actually were valuable, perhaps even necessary.
As such, I suspect most of it is bullshit generated whenever the people who do the actual work decide to key in the minimum amount of info in order to keep the "project management professionals" off their backs.
Monday mornings are a great time to get "boilerplate" work done to satisfy PM's.
When the _actual_ work gets done depends on the individuals, their teams, and the projects.
If I complete a task at 11 a.m. I've probably worked on it the day before and just wrapped up final testing before 11 a.m. Same with Monday being the "most productive".
Lots of people operate on schedules like "think of a good answer to the problem at 8 PM, crank out two hours of work, roll in at 11 AM to test the fix and update the ticket". As far as this study knows, that work pattern equals "high productivity at 11 AM", even though all of the actual work happened during the "low productivity" timeframe.
That sponsored article should be categorized using their book titles advertised at the bottom: "The Content Marketing Handbook", "Hipster Business Models" and "Everything is Bullshit".
That said, without actually describing in more detail how they measure it, yes, it's very, very circumspect. I'd wager even more so than just asking people "hey, when do you feel most productive?" Because the time I mark something done in JIRA, say, is barely correlated to when I spent the most time and focus on it (and even that correlation is not being picked up here. That is, I'd say "The time I spent the most effort on a problem is within 4 working hours of the time I marked it done, unless I completed it first thing in the morning, as I might wait until the end of the day to mark it done, and also barring a whole flurry of initial effort, it not getting me anywhere, I take a break, realized I was thinking about it wrong, go back and get it done in minutes").
This feels like intentional exaggeration to me. If the lowest value started at the base line, like they do e.g. in currency exchange plots, there would be no doubt about offset. This way, the initial impulse is to compare areas of the bars.
The first one starts from 5.5 which makes it look nearly identical to that in the blog post
https://i.imgur.com/n0LZJd8.png
The second one is where I let the y-axis run from 0 to 10 instead of from 5.5 to 10. In my opinion, this changes very little
https://i.imgur.com/cmrnbDp.png
The third one is with the y-axis from 0 to 100 which makes the effect significantly less pronounceable
https://i.imgur.com/pk9Bs9n.png
Matlab code:
m = 1:12;
tasks = [7.2 7.6 8.3 8.1 8.2 8.4 8.6 8.4 8.8 9.5 9.0 8.0];
bar(m,tasks);
% axis([0 12.5 0 100]);
% axis([0 12.5 0 10]);
axis([0 12.5 5.5 10]);
title('In which month do people complete most tasks');
xlabel('Month');
ylabel('Percentage people reporting completing most tasks');If you measure the time I commit code, you'll find the most happens just before I go home every evening; if you measure the time I mark tasks as complete in a task-tracking system it's at a scheduled daily stand-up meeting. So different data sources would show different results.
Commit times would have been a decent metric, though devs obviously vary a lot in how they structure and time their commits. But this study used ticket-completion, and finds lots of work gets done at 10-11 AM and 4 PM. Which looks suspiciously like a whole day's work has been logged during morning standup and before-leaving ticket checks.
Usually my periods of high productivity are 10am-12pm, 3-5pm, and 7-9pm. (I'm not usually in the office after 5pm so my employer doesn't benefit from the last burst. But they would if I did.)
Friday is my day to get backlog stuff done. Depending on how you define productivity, I'm either highly productive at solving old bugs, doing documentation updates, etc. or not productive at all on Fridays.
I have to echo others' sentiments: the analysis is severely flawed.
[EDIT: Added paragraph starting with "Friday is...".]
Am I missing something, or is this data so aggregated that it has become useless?
My guess would be from these observations, that the most success happen Thursday around 3 pm. But maybe software development is special since there are few tasks that could be done in 1.5 hours anyways.
Looking at hourly data, number of completed tasks should be a measure for low productivity.
They produced getting this post to front page of HN and hence thousands of views, the simpler the analysis/data, the lower the cost of those views :)