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

161–170 of 202 posts

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

#161

Post by wildrhythms »

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

On a personal level, we also have to remember to say "No, I can't stay late tonight, I have things to do." or "I had to work a double shift yesterday, so no I am not going to be in first thing in the morning." and so on. When we're young and don't have any clout, it's really hard (and scary) to do that. Which is exactly why those of us who are older and have the experience and acceptance to do so really need to norma…

+100 to this, any time I get an 'emergency request' coming in like that I flat out tell them this is not going to happen, I can't do it given the time constraint. I didn't used to do that, but I got burned too many times and it hurt my mental health scrambling to meet someone else's fabricated, and usually self-inflicted deadline. My well-being is so much more important than somebody else's lack of planning. My usual strategy for dealing with this is saying "Sorry, I can't help given the time constraint. Since it's an emergency maybe we should bring this to the attention of ?" and magically the 'emergency' goes away and I never hear about it again.

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

#162

Post by camjohnson26 »

MichaelRo wrote: post #95
Mizoguchi wrote: post #60

Earlier quoted context omitted.

Isn't changing requirements one of the key principles of the Agile manifesto? If so, why do we want to dive so much into requirements that are likely to change anyways? Not saying we should jump into design without understanding the requirements, but sometimes requirements are incomplete or not clearly defined and we cannot sit and wait until a new revision is out or someone becomes available to answer our questions.…

In 20+ years I don't think I ever worked on a "well-defined problem". It's always a fuzzy nebula and the only way to get insight is to build some prototype, see how it behaves and improve upon it. With the inevitable "suboptimal" early design somehow enduring and adapting through successive iterations, never have time or be able to afford a full rewrite from a business perspective: stuff works for the client, regardl…

On the flip side the code bases I’ve worked with that were built with exploratory coding, instead of deeply understanding the problem and designing a solution, tend to be buggy, slow, and stressful to work on. I think it’s a balance like anything else.

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

#163

Post by kiliancs »

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

I like the Spanish saying "Vísteme despacio, que tengo prisa": "dress me up slowly, since I'm in a rush".

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

#164

Post by nostrademons »

asdfman123 wrote: post #74
nostrademons wrote: post #63

Earlier quoted context omitted.

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

I’m an engineer at FAANG and it seems absurd, though, that we have so many resources but can’t apply some craftsmanship every so often. Instead, we churn out features, and everyone cheers when someone adds a new button to the UI.

It's not rewarded by the performance review system (except at Apple).

You can apply craftsmanship, it's just you won't get credit for it, your manager won't get credit for it, your VP won't get credit for it, and so on. That makes it a hard sell. A good manager's not going to penalize you for going above and beyond and fixing issues that you see, but it's hard to make a case for it when there's lots of other stuff to do and nobody important is going to notice the bugfix you just made. (And chances are, new bugs are just going to be introduced by some other team chasing the hot new feature.)

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

#165

Post by hinkley »

benji-york wrote: post #141
hinkley wrote: post #88

Earlier quoted context omitted.

MVP works when everyone on the team is seasoned. All of the members of the Agile Manifesto were seasoned. As were many of the people they tended to work with. For the rest of us “slow is smooth” means you should work on something that is analogous to the most important functionality first, to build your ability to do that work. Then as you gain skill, tackle harder and harder problems. Sometimes the rule of three let…

Might I suggest that instead of working on "the most important functionality first" you consider identifying the riskiest aspects of the project and working on those first? Some times those are the same, but often the part of a project that sinks it isn't the core functionality but some prerequisite that turns out to be much harder than anticipated.

No that’s the problem. The riskiest bits stay risky forever if you tackle them before you understand how. Junior people or new problem domains require exploratory development before committing to a strategy.

In an 18 month or three year project, it doesn’t affect your deadline much if you do the hardest bits in month one or month four. Except in how much rework you end up doing to those parts that have already started to cement bad habits.

When we have a Rule of Three situation in the product backlog, I usually recommend one of two strategies. Do the hardest one second, or do it third and allocate very little time for the first two - you’re going to rework the whole thing when you get to #3 anyway.

On one project, no matter what order we did them in, the third one took the longest time. Even when we tried to take our time on the second. Took me a year to train them to stop doing that. I’ve never seen a team so sure of their abilities yet with such a low opinion of their product. Big ol’ echo chamber.

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

#166

Post by tpoacher »

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 directly equivalent proverb in English is: "Less haste; more speed."

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

#167

Post by crazygringo »

omginternets wrote: post #92
re-thc wrote: post #67

Earlier quoted context omitted.

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

You can certainly criticize a methodology for being difficult or impossible to follow.

But it's easy to follow if a scrum master, facilitator, PM or team lead actually just does it.

There's nothing difficult or impossible about it at all.

But it's true that if the leader doesn't want to follow it that it's not going to work. It requires the person in the position of authority in the room to buy into it. No process will ever work if it's not actually being implemented by anyone.

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

#168

Post by [deleted] »

greymalik wrote: post #15
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…

More code isn’t better. As an engineering manager I don’t want 5x as many lines of code. I want the code you work on to be solving the right problems. Figuring out what the right problems and solutions are and making sure everyone on the team understands them is why you’re in meetings.

[deleted]

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

#169

Post by [deleted] »

mlsu wrote: post #43
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…

My theory is that most people don't actually want to get anything done, they just want to hang out. Meetings is how you just hang out. They want to just hang out at work because work is a very convenient and structured social apparatus with very well defined rules, boundaries, and hierarchies -- in a world where such things are becoming more and more rare.

[deleted]

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

#170

Post by wonderwonder »

greymalik wrote: post #15
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…

More code isn’t better. As an engineering manager I don’t want 5x as many lines of code. I want the code you work on to be solving the right problems. Figuring out what the right problems and solutions are and making sure everyone on the team understands them is why you’re in meetings.

This is not accomplished by holding developers in 15+ people meetings over and over again. Opening my calendar and seeing that I have 8 or 9 30+ minute meetings means I am going to get nothing accomplished today due to context switching. Its every day. I have almost no 2 - 3 hour periods where I can just focus
Post reply on HN