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

181–190 of 202 posts

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

#181

Post by [deleted] »

ResearchCode wrote: post #179
crazygringo wrote: post #157

Earlier quoted context omitted.

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.

Playing "poker" at work and having agile helpers sounds like extreme dysfunction.

[deleted]

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

#182

Post by crazygringo »

ResearchCode wrote: post #179
crazygringo wrote: post #157

Earlier quoted context omitted.

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.

Playing "poker" at work and having agile helpers sounds like extreme dysfunction.

Well sure, anything can "sound like" extreme dysfunction if you don't actually know what it is.

Do you know what planning poker is, and are you aware it's not a game for fun?

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

#183

Post by ResearchCode »

crazygringo wrote: post #182
ResearchCode wrote: post #179

Earlier quoted context omitted.

Playing "poker" at work and having agile helpers sounds like extreme dysfunction.

Well sure, anything can "sound like" extreme dysfunction if you don't actually know what it is. Do you know what planning poker is, and are you aware it's not a game for fun?

To be fair having demeaning names for the engineers' work activities is not the worst part of corporate agile. Unfortunately.

I have heard some third tier companies and lower play "planning poker" at work. It doesn't sound like any fun or efficient but a cheap paycheck for an "agile helper". I am not sure how many of them have remained employed during these layoffs.

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

#184

Post by ResearchCode »

chii wrote: post #152
Falkon1313 wrote: post #84

Earlier quoted context omitted.

>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 unfortuantel…

Yes. Nobody asks a mathematician to "story point" the conjectures they are working on. Nobody asks them for daily status updates. This is pure and harmful micromanagement because software engineers are not saying stop it.

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

#185

Post by tornato7 »

_gabe_ wrote: post #153
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 prob…

I've recently become a big believer in Python notebooks to plan out these sorts of designs. It allows you to quickly mock up and iterate on a few prototypes to build your expertise, and then actually document a proposed design alongside working code that demonstrates the functionality.

The bonus is, being a Python notebook, you usually avoid the common pitfall of shipping crappy prototype code to production; you are forced to rewrite it because putting a Python notebook into prod would make any software engineer shudder.

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

#186

Post by crazygringo »

ResearchCode wrote: post #183
crazygringo wrote: post #182

Earlier quoted context omitted.

Well sure, anything can "sound like" extreme dysfunction if you don't actually know what it is. Do you know what planning poker is, and are you aware it's not a game for fun?

To be fair having demeaning names for the engineers' work activities is not the worst part of corporate agile. Unfortunately. I have heard some third tier companies and lower play "planning poker" at work. It doesn't sound like any fun or efficient but a cheap paycheck for an "agile helper". I am not sure how many of them have remained employed during these layoffs.

It's not supposed to be fun. It's work, not a game. It's productive because it results in more accurate estimation of tasks, and a better understanding of the work entailed.

Are you against those things? "First tier" companies use planning poker as well, you know.

You seem to be oddly hostile to the concept without seeming to understand it at all.

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

#187

Post by ResearchCode »

crazygringo wrote: post #186
ResearchCode wrote: post #183

Earlier quoted context omitted.

To be fair having demeaning names for the engineers' work activities is not the worst part of corporate agile. Unfortunately. I have heard some third tier companies and lower play "planning poker" at work. It doesn't sound like any fun or efficient but a cheap paycheck for an "agile helper". I am not sure how many of them have remained employed during these layoffs.

It's not supposed to be fun. It's work, not a game. It's productive because it results in more accurate estimation of tasks, and a better understanding of the work entailed. Are you against those things? "First tier" companies use planning poker as well, you know. You seem to be oddly hostile to the concept without seeming to understand it at all.

I don't think there's much evidence if any at all that it provides more accuracy or understanding. First tier companies tend not to use "sprints" at all.

There's nothing to understand, the agile manifesto or worse the "scrum" pamphlet can be read on a lunch break. Somehow engineers who put ten-thousand hours into their craft need a layman agile helper to understand it?

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

#188

Post by crazygringo »

ResearchCode wrote: post #187
crazygringo wrote: post #186

Earlier quoted context omitted.

It's not supposed to be fun. It's work, not a game. It's productive because it results in more accurate estimation of tasks, and a better understanding of the work entailed. Are you against those things? "First tier" companies use planning poker as well, you know. You seem to be oddly hostile to the concept without seeming to understand it at all.

I don't think there's much evidence if any at all that it provides more accuracy or understanding. First tier companies tend not to use "sprints" at all. There's nothing to understand, the agile manifesto or worse the "scrum" pamphlet can be read on a lunch break. Somehow engineers who put ten-thousand hours into their craft need a layman agile helper to understand it?

Every sentence of your comment is factually incorrect or irrelevant. I'm not going to continue a conversation with someone who doesn't have an interest in facts.

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

#189

Post by ResearchCode »

crazygringo wrote: post #188
ResearchCode wrote: post #187

Earlier quoted context omitted.

I don't think there's much evidence if any at all that it provides more accuracy or understanding. First tier companies tend not to use "sprints" at all. There's nothing to understand, the agile manifesto or worse the "scrum" pamphlet can be read on a lunch break. Somehow engineers who put ten-thousand hours into their craft need a layman agile helper to understand it?

Every sentence of your comment is factually incorrect or irrelevant. I'm not going to continue a conversation with someone who doesn't have an interest in facts.

What you might actually mean is that you are going to try to sell agile snake oil to someone who knows less. Try a middle manager without technical background? They tend to be more receptive.

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

#190

Post by ResearchCode »

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…

The optimal sprint length is none. It's an awful concept that is misused to micromanage highly skilled professionals that often didn't learn to say no. You want to work on three to six month projects, not two week "sprints".
Post reply on HN