Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It’s time to embrace slow productivity (2022)

newyorker.com

Post reply on HN
Print view View original

61–70 of 202 posts

Re: It’s time to embrace slow productivity (2022)

#61

Post by crazygringo »

Chris_Newton wrote: post #46

I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…

> and fundamentally it requires that each individual doing the work understands what needs to be done

Which is precisely what agile is about, specifically the estimation process. No story enters the sprint unless there is unanimous consensus among the engineers as to its point value, and it's the process of coming to that unanimity that makes sure each individual understands what needs to be done.

A lot of people like to complain that agile slows down their coding, and this is by design -- to achieve exactly what you're asking for.

> But now we often seem to have one-paragraph tickets, maybe spend a few minutes thinking of some class names that look about right for each one, and then dive into coding.

That isn't agile. If you're estimating a new story the team hasn't discussed before, it's usually going to take between 5 and 30 minutes to come to consensus on its size and what it is conceptually.

So the main problem you're describing is what Agile solves.

Then you seem to have a secondary problem which is about different team members working in incompatible ways in terms of coding architecture. That require a team lead who is in charge of architecture decisions, that team members consult with whenever they start a story that there's no precedent on how to build. And code review ensures code is written as planned.

Re: It’s time to embrace slow productivity (2022)

#62

Post by gffrd »

golergka wrote: post #31
gffrd wrote: post #3

This glosses over the fact that jobs are a central piece—if not _the_ central piece—of many people's identities in the States. We've lost religion and communities as things that define and provide structure and purpose, leaving us clinging to jobs. Is this good? No! It's terrible! We should fix this! However, I'm not convinced that workplace stress is a matter of hours … it may be a symptom of lack of life beyond wor…

Work is where you provide value to the society, create something for other people and make world better, while simultaneously applying and improving your main set of skills. Why wouldn't you want tie your identity to something like that? Just to be clear: I have a few hobbies aside from work — I make music, DJ, paint, cook, hike sometimes. I have friends, and I'm also not a productivity maniac (I actually work in a 4…

> Why wouldn't you want tie your identity to something like that?

Because conflating _need for purpose_ and _need to pay rent_ can be tricky business: they don’t always join neatly.

Happy they do for you!

Re: It’s time to embrace slow productivity (2022)

#63

Post by nostrademons »

deet wrote: post #40

Comments here so far seem to be missing Newport's key point (in the second half of the article)... For many modern (knowledge work) jobs, it's volume of tasks, not duration, that seems to induce burnout. For instance, if you have 1 central task for the week--say, write a report--but there are ten subtasks (hold 5 meetings to prepare, read 3 background papers, ...), and then each of those have a bunch of subtasks (Sla…

It's both. Burnout is when you invest too much emotionally in something or someone and don't get anything back from it. That can be because you have a steady stream of work items and none seem particularly important but you feel obligated to do each one. Or it can be because you labor on the same project for years and never complete it. Or it can be because you work hard and deliver but events outside your control make that delivery pointless.

I'm an eng manager at a FAANG. I view my primary job to be saying "No, that doesn't matter." New bug comes in - if it's not a production outage or security bug, it can go in the bug queue and we can forget about it. Engineer says "But what about [edge case], now I have to worry about that too", I can say "No you don't. Ship it anyway." Request from another team comes in - "Sorry, we don't have engineering capacity for that." UX designer has a great new idea - "That's not feasible in the time and resource constraints we have."

Probably doesn't make me very popular with other teams, users, or cross-functional partners, but my team (which had had recurrent problems with burnout and spinning their wheels before I joined) is being productive and delivering stuff and seems reasonably happy at work now.

Re: It’s time to embrace slow productivity (2022)

#64

Post by uhtred »

crazygringo wrote: post #61
Chris_Newton wrote: post #46

I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…

> and fundamentally it requires that each individual doing the work understands what needs to be done Which is precisely what agile is about, specifically the estimation process. No story enters the sprint unless there is unanimous consensus among the engineers as to its point value, and it's the process of coming to that unanimity that makes sure each individual understands what needs to be done. A lot of people lik…

>No story enters the sprint unless there is absolute consensus among the engineers as to its point value, and it's the process of coming to that point value that makes sure each individual understands what needs to be done.

I call bs.

Are you telling me that the less experienced / less confident devs on the team don't cave to pressure from the team lead or whoever happens to be the most forceful / loudest to agree that, ok, this is only a 5 pointer and we all understand what needs to be done, because DAVE says it's easy, 30 minutes work tops, and DAVE is tired and has better places to be.

You write as if the team is all top engineers with equality and not one leader and his minions.

Re: It’s time to embrace slow productivity (2022)

#65

Post by efitz »

I didn’t read the whole article because it had too many words. Probably some editor was demanding a certain length by a certain deadline.

I think that the last 100 years or so have seen the west frequently go too far in optimizing everything, not just productivity.

From time motion studies on early assembly lines to modern voice response driven customer service, the ability to measure things has caused us to often optimize for the wrong things, or fail to balance optimizations, or over-optimize past the point where it’s good for humans as well as the business.

And it’s catchy- nowadays with half the people you talk to, you have to constantly speed up to avoid attention wandering. Maybe I’m just a long winded old fart but honestly attention spans have gone to shit. Maybe that’s not an optimization per se but it evokes the same feelings as IVR mazes and long queues everywhere (airports etc.). It’s the feeling that I’m a burden or tax on someone’s attention rather than a valuable interaction.

Re: It’s time to embrace slow productivity (2022)

#66

Post by tjr225 »

efitz wrote: post #65

I didn’t read the whole article because it had too many words. Probably some editor was demanding a certain length by a certain deadline. I think that the last 100 years or so have seen the west frequently go too far in optimizing everything, not just productivity. From time motion studies on early assembly lines to modern voice response driven customer service, the ability to measure things has caused us to often op…

[dead]

Re: It’s time to embrace slow productivity (2022)

#67

Post by re-thc »

uhtred wrote: post #64
crazygringo wrote: post #61

Earlier quoted context omitted.

> and fundamentally it requires that each individual doing the work understands what needs to be done Which is precisely what agile is about, specifically the estimation process. No story enters the sprint unless there is unanimous consensus among the engineers as to its point value, and it's the process of coming to that unanimity that makes sure each individual understands what needs to be done. A lot of people lik…

>No story enters the sprint unless there is absolute consensus among the engineers as to its point value, and it's the process of coming to that point value that makes sure each individual understands what needs to be done. I call bs. Are you telling me that the less experienced / less confident devs on the team don't cave to pressure from the team lead or whoever happens to be the most forceful / loudest to agree th…

That’s not an agile problem so where’s the bs? If your team is not following agile you can’t just blame it.

Re: It’s time to embrace slow productivity (2022)

#68

Post by nonethewiser »

jamies wrote: post #48
Chris_Newton wrote: post #46

I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…

I love that you quoted “slow is smooth and smooth is fast” -- I learned it as a volunteer firefighter! It's a great saying, and can be applied to just about anything.

Sex?

Re: It’s time to embrace slow productivity (2022)

#69

Post by asdfman123 »

Chris_Newton wrote: post #46

I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…

At my company we have a nightmarish combination of a lot of docs and meetings but also the pressure to produce a lot of artifacts, so we have “planning” but it could be a lot better, uh, planned.

Re: It’s time to embrace slow productivity (2022)

#70

Post by asdfman123 »

uhtred wrote: post #64
crazygringo wrote: post #61

Earlier quoted context omitted.

> and fundamentally it requires that each individual doing the work understands what needs to be done Which is precisely what agile is about, specifically the estimation process. No story enters the sprint unless there is unanimous consensus among the engineers as to its point value, and it's the process of coming to that unanimity that makes sure each individual understands what needs to be done. A lot of people lik…

>No story enters the sprint unless there is absolute consensus among the engineers as to its point value, and it's the process of coming to that point value that makes sure each individual understands what needs to be done. I call bs. Are you telling me that the less experienced / less confident devs on the team don't cave to pressure from the team lead or whoever happens to be the most forceful / loudest to agree th…

And also, do people actually plan it out or do they just approve every idea that doesn’t sound terrible?

Software is complicated. Half the time I don’t know what the hell anyone is talking about due to labyrinthine requirements, but I’m not going to stop the meetings to ask questions unless I’m the main guy working on it.

Post reply on HN