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

151–160 of 202 posts

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

#151

Post by datavirtue »

jasonpeacock wrote: post #14
wonderwonder wrote: post #8

Its the lack of consecutive days off, 2 is not enough. 3 would really be a change. I bet I would accomplish just as much during the week as I do now, workplaces would just have to reduce the number of useless meetings. I spend 4 - 5 hours a day in meetings and am still expected to deliver actual code. Kill the meetings, my code generation would be through the roof. There are several things wrong with the American kno…

If you're not a presenter or decision maker, then decline the meeting and say "If there's something I need to do as a result of this meeting please let me know". If you're still forced to attend then update the development schedule to reflect the impact of that time. Managers can't change physics no matter how much they want - you're either writing code or attending meetings, not both.

They believe what they feel, and they feel like the physics behave differently than they actually do.

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

#152

Post by chii »

Falkon1313 wrote: post #84
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…

>breaking creative work down into bite-sized chunks In my decades of experience in multiple companies doing 'agile', that's something that we've always ostensibly strived for, but in practice it almost never happens in reality. At least not as intended. Occasionally it happens, but only by pure chance. It seems the 'agile way' is to attempt to manage a project by taking a sizable but coherent and cohesive concept/fea…

It all stems from the desire by stakeholders (who are paying the money) wanting to know when something is gonna ship, before committing the money.

I think it should just be accepted that it is not possible to know. Unlike building a building, you cannot know. It is possible to do a feasibility study, or a prototype, and time box it, but that is as good as it gets.

The stakeholders don't want to hear this unfortuantely. They refuse to believe it isn't possible to know ahead of time how much work is needed. In order to appease, the engineers and managers have developed a set of "practises" such as agile, but in the end, it is a lie.

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

#153

Post by _gabe_ »

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 couldn't disagree more. The worst codebases I've seen in my career have been codebases that were religiously planned upfront, and then religiously adhered to The Plan. Irregardless of the revelations that popped up in the midst of development.

This usually takes the form of pattern driven developers: the developers that must fit the entire problem into a predetermined pattern (which is ridiculous because every problem is unique and there are very few patterns that are truly applicable everywhere). This will also take the form of Amazon's famous 6 page design upfront. It's funny, they wanted me to prescribe what the expected latency of a system that would be running over an unreliable network was and figure out an SLA based on that, before I wrote an ounce of code! How in the world are you even supposed to begin getting accurate measurements, without measuring!

So, planning is good yes. But the reality is every problem is unique. Unless you have somebody who's solved the exact problem you're trying to solve, planning is going to do no good and you're better off exploring first. Once you became a domain expert in your tiny niche domain you just explored, then you get to make a plan.

But enough with this nonsense that we can magically figure out what the exact requirements are for a problem before we've even begun to measure the appropriate metrics associated with the problem. And one of the key ways we can measure stuff is by exploring the problem space with code.

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

#154

Post by charlie0 »

golergka wrote: post #111
charlie0 wrote: post #90

Earlier quoted context omitted.

You are proving my point. Advances in productivity have led to a lowering to the barrier of entry. Anyone can code now. So why,(in theory) would a business owner let their workers work less when someone else is willing to work longer hours?

If somebody else is willing to do the same job for less, it means your asking price for your services is too high. Americans love to complain about stagnation of wages, while in reality it just means that people in other parts of the world have reason out of poverty competing with them on a labour market. If you value a Chinese life just as much as an American one, the fact that American worker can now afford one car…

I fully agree, but what does this have to do with letting workers work less as productivity increases? Are you implying that stage would only occur if productivity gains are spread equally across the world?

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

#155

Post by efitz »

tlamponi wrote: post #108
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…

No offense and agreeing on the there's too much "optimizing everything", often even in a misguided way going on, but reading both: > I didn’t read the whole article because it had too many words. and > Maybe I’m just a long winded old fart but honestly attention spans have gone to shit. was a bit funny. Or did you mean the attention span in general, including yours, has gone to shit?

I hate hypocrisy in others :-)

I did not fail to notice this. But in failing to read every word of the article I was not causing any other human to have a bad experience.

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

#156

Post by golergka »

charlie0 wrote: post #154
golergka wrote: post #111

Earlier quoted context omitted.

If somebody else is willing to do the same job for less, it means your asking price for your services is too high. Americans love to complain about stagnation of wages, while in reality it just means that people in other parts of the world have reason out of poverty competing with them on a labour market. If you value a Chinese life just as much as an American one, the fact that American worker can now afford one car…

I fully agree, but what does this have to do with letting workers work less as productivity increases? Are you implying that stage would only occur if productivity gains are spread equally across the world?

Letting? Nobody is forbidding workers from taking less shifts. It's workers themselves who decide that higher compensation is more important for them than leisure.

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

#157

Post by crazygringo »

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…

Well, yes, I'm telling you exactly that. That's how planning poker works, you have to speak up. You don't even have a choice because the process requires you to.

It sounds like you have a very dysfunctional team if you're characterizing it as a team leader and his "minions".

I'm sorry that's your situation.

Some larger corporations have agile facilitators precisely to nip this kind of problem in the bud.

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

#158

Post by sdoering »

turtledragonfly wrote: post #89
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…

> slow is smooth and smooth is fast Another phrase with similar meaning (and interesting history) is "festina lente" ("make haste slowly," in Latin). I named my company after it (: It's certainly an ancient concept. I feel like software is ultimately about humans organizing complex activities, and humans haven't changed that much in the past few millennia, even if the activities have gotten more complex and abstract.…

The German press agency (DPA) has (had?) a saying/motto:

> Be first, but first be right.

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

#159

Post by crazygringo »

asdfman123 wrote: post #70
uhtred wrote: post #64

Earlier quoted context omitted.

>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.

But nobody knows who will work on it and you'll stop the meeting during the blind estimation process because you have to estimate points and you don't know what anybody else is estimating.

All of the points you're raising are solved inherently by the way points estimation works with the points playing cards.

You're not stopping the meeting. But it will be your turn to explain why you think it's the number of points you chose, so you'll do that.

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

#160

Post by narag »

turtledragonfly wrote: post #89
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…

> slow is smooth and smooth is fast Another phrase with similar meaning (and interesting history) is "festina lente" ("make haste slowly," in Latin). I named my company after it (: It's certainly an ancient concept. I feel like software is ultimately about humans organizing complex activities, and humans haven't changed that much in the past few millennia, even if the activities have gotten more complex and abstract.…

Another one for the collection: vísteme despacio que tengo prisa.
Post reply on HN