Productivity and the Workweek (2000) • Hacker News Board

Re: Productivity and the Workweek (2000)

#81

Post by UglyToad » Thu, Aug 22, 2019, 1:20 PM UTC

TheCoelacanth wrote: post #78

brixon wrote: post #68

Earlier quoted context omitted.

As a Scrum Master the final comment bugs me. The Sprint is a team effort, you might have been assigned user stories, but if your velocity is higher than others then you need to improve your estimations and you need to help others finish their user stories. Your scrum team does not sound like a team, but a collection of individuals.

This is exactly the attitude that causes anxiety. You are done with the thing you were working on, now go "help" one of your teammates somehow regardless of whether that will actually increase the amount of value the team is delivering. Baseball is a team sport, but that doesn't mean you have two people swinging one bat.

This is a nice metaphor.

I think it's similar in many ways to the complaints one overhears about roadworks. "Why do they take so long!? It's just 5 people stood around watching another dig a hole!". Software is a lot like that, you can't have everyone run off and work on all parts of the stack and domain at once, there's only a certain amount of parallelizable work.

Re: Productivity and the Workweek (2000)

#82

Post by anonymousJim12 » Thu, Aug 22, 2019, 1:22 PM UTC

Consultant32452 wrote: post #44

firepoet wrote: post #15

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?

Executives live in a global economy. The rest of us might "operate" in one but we don't get to take advantage of that privilege the way the wealthy do. You are right, world wide poverty is on the decline. But given the choice between:

- better for 1 billion people

- worse for 2 billion people

- really outstandingly fantastic for 200 people

and

- really good for 5 billion people

- worse for 200 people

I know which way I'd lean in that spectrum.

Re: Productivity and the Workweek (2000)

#83

Post by knightofmars » Thu, Aug 22, 2019, 1:26 PM UTC

d4nt wrote: post #17

I think many people would work less if they could afford to. But we're not getting paid for all this extra productivity[1]. [1]: https://www.forbes.com/sites/timworstall/2016/10/03/us-wages...

Ah yes, Tim Worstall. Every time I read one of his articles I end up thinking, "He touched on this important related aspect of his topic but then failed to actually detail how it impacts his claim, both for and against." I this article, he mentions "total compensation" includes benefits and suggests that those benefits somehow make up the missing wages. From a pure numbers perspective, the increase in benefits is an increase in total compensation. But it doesn't call out that most of those "missing wages" have been absorbed into handle rising healthcare costs. The people who are receiving these "increased benefits" haven't received anything other than the same healthcare but now they pay more for it.

Re: Productivity and the Workweek (2000)

#84

Post by tonyarkles » Thu, Aug 22, 2019, 1:31 PM UTC

brixon wrote: post #68

ckosidows wrote: post #59

Earlier quoted context omitted.

I feel the exact same way. I come home and exercise and make food and I feel just beat. All I want to do is sleep by 9pm. I wish I had a few extra hours a day to study or spend time on leisure activities. As it is I study or read until it's time to sleep and if I want to spend time with friends something has to fall off my schedule even though I sit at work and try to look busy most days. Once my work in a sprint is…

As a Scrum Master the final comment bugs me. The Sprint is a team effort, you might have been assigned user stories, but if your velocity is higher than others then you need to improve your estimations and you need to help others finish their user stories. Your scrum team does not sound like a team, but a collection of individuals.

“Fix your estimates”

I have, for a long time, been very opposed to single point estimates, especially when those estimates are going to be interpreted like this. For any task that has any kind of uncertainty to it, there’s a range of time for how long it’s going to take. If you take longer than your single point estimate, you’re going to be punished for it in some way (work late, etc). If you take less time than your single point estimate, you’re going to be... punished for it?

What I’ve settled on in my consultancy work is doing 3-point PERT-style estimates. If I finish a task earlier than the range that drops out, I make a mental note to be more optimistic in the future on that project. If I’m nearing the far end of the range, I take pause and reassess what happened. Did the scope of the task blow up? Did I miss something up front? Is there too much technical debt in this project?

When you use SPEs, there’s no way to tell retrospectively (except in extreme cases) whether an estimate was actually good and the completion time was within an expected statistical variation, or if the estimate was bad and some part of the estimation process needs to be tuned.

Re: Productivity and the Workweek (2000)

#85

Post by brixon » Thu, Aug 22, 2019, 1:32 PM UTC

ThalesX wrote: post #74

brixon wrote: post #68

Earlier quoted context omitted.

As a Scrum Master the final comment bugs me. The Sprint is a team effort, you might have been assigned user stories, but if your velocity is higher than others then you need to improve your estimations and you need to help others finish their user stories. Your scrum team does not sound like a team, but a collection of individuals.

So... what does the scrum master do then? If the developer needs to figure out how to work things out so he aligns with the rest of the team?

It depends. For me it's a 20% role, I focus more on the sprint flow. We have a System Engineer and they do most of the Product Owner cat wrangling that I would assume a lot of Scrum Master's have to handle.

The scrum team should be acting as a team and the developer should work with the team to figure out how he aligns. That is part of the "Self Forming" stuff. The Scrum Master is not their boss and does not weigh in on the project implementation. They are more of the advocate for the team and the advocate for Agile/Scrum. e.g. Dealing with the Product Owner when they try to add stuff to the current sprint or Management saying everything is top priority. Technically we call that coaching the Scrum process, but I'm going to make sure my team has steady/predictable work and are not going to burn out.

Re: Productivity and the Workweek (2000)

#86

Post by brixon » Thu, Aug 22, 2019, 1:34 PM UTC

TheCoelacanth wrote: post #78

brixon wrote: post #68

Earlier quoted context omitted.

As a Scrum Master the final comment bugs me. The Sprint is a team effort, you might have been assigned user stories, but if your velocity is higher than others then you need to improve your estimations and you need to help others finish their user stories. Your scrum team does not sound like a team, but a collection of individuals.

This is exactly the attitude that causes anxiety. You are done with the thing you were working on, now go "help" one of your teammates somehow regardless of whether that will actually increase the amount of value the team is delivering. Baseball is a team sport, but that doesn't mean you have two people swinging one bat.

Examples are: The tester is always backed up (1 tester for 4 developers), so a developer can help test a user story they did not write. A developer can take on a user story that was originally assigned to someone else.

Re: Productivity and the Workweek (2000)

#87

Post by scroot » Thu, Aug 22, 2019, 1:39 PM UTC

dustinmoris wrote: post #70

UglyToad wrote: post #21

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…

> Software to me is extremely mentally demanding and draining, it requires short burts of extreme concentration, but what is more draining is making up the remaining 4-5 hours looking busy. Well said! I haven't met a single software engineer who hasn't described something similar to me. I'm the same, I like to wake up early, enjoy my first coffee and then I feel the most productive for the first 4 hours of the day. I…

The future struggle for people in these kinds of jobs is to get the wider culture to admit to itself that the latter 4 hours are unnecessary and even detrimental to workers.

Re: Productivity and the Workweek (2000)

#88

Post by brixon » Thu, Aug 22, 2019, 1:40 PM UTC

tonyarkles wrote: post #84

brixon wrote: post #68

Earlier quoted context omitted.

As a Scrum Master the final comment bugs me. The Sprint is a team effort, you might have been assigned user stories, but if your velocity is higher than others then you need to improve your estimations and you need to help others finish their user stories. Your scrum team does not sound like a team, but a collection of individuals.

“Fix your estimates” I have, for a long time, been very opposed to single point estimates, especially when those estimates are going to be interpreted like this. For any task that has any kind of uncertainty to it, there’s a range of time for how long it’s going to take. If you take longer than your single point estimate, you’re going to be punished for it in some way (work late, etc). If you take less time than your…

I agree, I am assuming you know how we implemented Scrum.... We do point estimates very early to know if a story is too big and needs to be broken down and for rough release planning. The developer that volunteers for a user story will do an hours estimate when the user story is fairly well fleshed out.

We do not use estimates and actual's for any management metrics, this is for the developer to gauge their workload for the sprint. We know from our history that once a developer estimates about 40 hours of work for a two week sprint we don't allow them to take any more.

For us, estimates are the developers gauge to know when the sprint is full.

Re: Productivity and the Workweek (2000)

#89

Post by muzani » Thu, Aug 22, 2019, 1:41 PM UTC

UglyToad wrote: post #21

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…

At my workplace we do recognize that there's a lot of unproductive time. The best programmers seem to watch YouTube a lot, the least productive ones seem to come early and leave late.

The company culture has sort of spotted the correlation and we're more or less free to do what we want at work. There's just enough pressure to not spend the day on DoTA and social media, which is probably the optimum pressure. Some of the team goes for two tea breaks a day. Some go for long prayer breaks. Some sleep at their desks.

The CTO doesn't use agile; we just tell each other what we want, and poll them on it after 2-3 days if it's not urgent, or the CTO just reads git commits to watch progress.

We still go to work 8.5 hours a day, because it's in the contract, but it's quite relaxing. Best job I've had so far.

Re: Productivity and the Workweek (2000)

#90

Post by barefoot » Thu, Aug 22, 2019, 1:45 PM UTC

UglyToad wrote: post #21

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…

After you collapse on the sofa for a few minutes you then get back to work keeping yourself current, right?

A reasonable measure of what it takes to stay current and relevant in this industry is twenty hours of dedicated reinvestment per week. Often times this reinvestment time is not afforded at work and as much as employers want to provide this as a benefit to developers, few offer the resources or time to allow developers to get anywhere close at work alone. Therefore, that time is likely your sole responsibility at home.

If you're like most developers you should be budgeting four hours each day M-F (or three if you include the weekend). I know many that push for even more.

Since our jobs tend to be sedentary and it's probably helpful to budget at least an hour for the gym a day to help mitigate the severe health effects of working a desk job, don't forget to factor time at the gym in your scheduling. Also, if you're like many developers I know you're likely on call and answering e-mails at home as well which is easy to forget about when calculating available time.

This then quickly becomes a challenging schedule even for eight hour days. Those selecting ten hour days are probably not reinvesting as much as they should and will potentially burn out or become irrelevant in the long term. I've attempted a sustained schedule of 12 hour work days with 4 hour reinvestment and an hour at the gym and found it unworkable in the long term.