Live data from Hacker News

Productivity and the Workweek (2000)

groups.csail.mit.edu

41–50 of 233 posts

Re: Productivity and the Workweek (2000)

#41
post #18

Earlier quoted context omitted.

Well for starters, looking at the charts in the link 30 hours is still much more productive than the 40hr 1975 worker. As a programmer I'm not doing focused programming for any more than 30 hours a week anyway

You might be productive, but you can't produce 6 hours a day from nothing.

——

For immediate release.

CERN is proud to announce it will resume LHC operations shortly after a major system sensitivity upgrade and is poised to launch a new set of tests on behalf of their corporate donors.

This year marks the first time scientists will seek proof of the (not-yet-)theorized “anti-second”.

According to the head of the program, Dr. Ismadeup:

“When the efforts of our labors are successful, the rules of physics will fundamentally change! This discovery will allow corporate taskmasters and mindful spouses to extract even more productivity from those under their sway.”

Athletic organizations, alcohol distributors, and adult media companies are eagerly awaiting the commercialization of any resulting technological enhancements derived from the research.

Re: Productivity and the Workweek (2000)

#42

I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…

Yeah, I also see this issue. It's made worse by Agile/Scrum that assumes during the planning poker meeting that every dev has 8 hours per day available of constant flow while the real value being maybe 5-6 if you're lucky so you end up cutting corners or burned out due to the stress of meeting the target velocity.

Your planning system is bad. This was the original origin of using story points instead of days, because the designers of extreme programming found that the work of 1 "ideal day" (8 hours of uninterrupted productive coding) could be done in about 3 days.

And don't get me started on measuring velocity, especially across teams. Your environment sounds like its poisoned by middle management.

Re: Productivity and the Workweek (2000)

#43

I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…

Another phenomenon that makes most programmers unable to achieve flow state is technology diversity - brain can get into flow state only when one is using familiar tools - and than happens rarely, at least for me (I work on a project for 6-12 months and ten move to other and tools and main technologies aren't chosen by me usually).

Re: Productivity and the Workweek (2000)

#44

The interesting thing is that wages have remained stagnant as productivity has increased dramatically. Which means that our labor has been valued less over time. What needs to happen is that the work week shortens while the minimum wage increases in kind. Top execs need to be comfortable making less, as they are the only ones profiting off these productivity increases.

We live in a global economy now. Like a billion people have been raised out of abject poverty. It's an absolute falsehood that only the top earners have prospered. The middle class is shrinking in the US, because they're moving up. We brought in millions and millions of foreign workers from impoverished countries, did their wages remain stagnant?

Re: Productivity and the Workweek (2000)

#45

I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…

I don't know that either. I can be REALLY productive for 2-3 hours a day but rest is socializing with other devs, answering emails etc... I try to structure my day so that I learn some stuff in those 8 hours, do some personal stuff (pay bills, call doctor, arrange stuff after work). I am regarded as quite productive but sometimes I feel really bad for not putting 100% in all those 8 hours but I find it impossible. I…

I think you achieve a lot being really productive for 3 hours and it's kind of difficult to increase that amount because your brain is used to that amount already. It's pretty good if you can put another maybe 1-2 hours of study into it. I find exercising helps me to enter the flow more quickly, but not necessarily INCREASE the time. The total amount is probably defined by genes and health condition in general. I see people who can be high productive for 6-7 hours WITHOUT stop back in high school but that's rare.

Re: Productivity and the Workweek (2000)

#46
post #24

The interesting thing is that wages have remained stagnant as productivity has increased dramatically. Which means that our labor has been valued less over time. What needs to happen is that the work week shortens while the minimum wage increases in kind. Top execs need to be comfortable making less, as they are the only ones profiting off these productivity increases.

Is this (wage stagnation) true for tech? It seems a special case. I wonder what the exec-pay/wage/productivity growth charts look like if we exclude tech. (Less disparity? More? Less productivity?)

Maybe? I know I make about the same as my uncle did working for Ernst & Young (in DC) during the late 90s early 2000s.

However, neither of us were/are in development.

Re: Productivity and the Workweek (2000)

#47

I reduced my time at work to 80% at the beginning of July. Every Friday is my day now. This week I had to switch it up so today is my day off. It's 1pm and I have already worked out, ran some errands that had been bugging me and am now reading this in one of my favorite diners which I for some reason almost never found the time to go to before. If you have the chance and it seems intriguing to you I encourage everyon…

It's certainly something I'd love to trial. I think most people probably look at their take home pay and imagine that taking 20% off of that figure would be a big cut. In the UK at least, as a higher-rate tax payer (40% tax) it wouldn't be nearly as bad as that seems.

At the moment we're looking at nursery for our 7 month old 2 days per week. If instead I could work 4 days a week it would be a wash financially. I'd get the benefits of spending more time with her but obviously looking after a < 1 year old isn't 'a day off' by any stretch.

Re: Productivity and the Workweek (2000)

#48
Unfortunately, the mid-noughts vintage of this page is showing. After about 2010, productivity growth has not kept up with the page's 1.7% estimate (https://fred.stlouisfed.org/graph/fredgraph.png?g=oGgn).

Also, this page neglects the influence of heterogeneous productivity changes. Some fields don't experience the same kind of productivity growth that we've seen in manufacturing (and services aided by technology); for example a doctor now is not seeing four times as many patients as a doctor in 1940. A barber now is not cutting the hair of four people at once.

You can't productivity-gain your way out of the costs of dedicated attention from individuals.

Re: Productivity and the Workweek (2000)

#49
post #42

Earlier quoted context omitted.

Yeah, I also see this issue. It's made worse by Agile/Scrum that assumes during the planning poker meeting that every dev has 8 hours per day available of constant flow while the real value being maybe 5-6 if you're lucky so you end up cutting corners or burned out due to the stress of meeting the target velocity.

Your planning system is bad. This was the original origin of using story points instead of days, because the designers of extreme programming found that the work of 1 "ideal day" (8 hours of uninterrupted productive coding) could be done in about 3 days. And don't get me started on measuring velocity, especially across teams. Your environment sounds like its poisoned by middle management.

It's not my planning system but it was broken indeed even though they brought in a licensed scrum master as a consultant but he was more interested in running things the way middle managers wanted it as that guaranteed his job security.

Anyway, thank God I left, but from what I hear from other mates in the industry it's not better in other companies in my area since they're all run by middle managers.

Maybe it's a problem specific to Germany where managers are always right and their authority is unquestionable.

Re: Productivity and the Workweek (2000)

#50
post #42

Earlier quoted context omitted.

Yeah, I also see this issue. It's made worse by Agile/Scrum that assumes during the planning poker meeting that every dev has 8 hours per day available of constant flow while the real value being maybe 5-6 if you're lucky so you end up cutting corners or burned out due to the stress of meeting the target velocity.

Your planning system is bad. This was the original origin of using story points instead of days, because the designers of extreme programming found that the work of 1 "ideal day" (8 hours of uninterrupted productive coding) could be done in about 3 days. And don't get me started on measuring velocity, especially across teams. Your environment sounds like its poisoned by middle management.

Agree. From the agile manifesto's principles [0]:

> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

> Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

If either of these requirements are not met, you're not being agile.

[0] https://agilemanifesto.org/principles.html

Post reply on HN