I remember my first difficult project as a consultant. We were missing every deadline due to sprint timetables and stress. The client was basically letting us go while we migrated to Angular but wanted to keep maintaining Ember code while this all happened. I was charged with managing the Ember code and was essentially removed from the sprint cycle. I flourished and have fought to stay out of the sprint cycle ever since. :P
It’s time to embrace slow productivity (2022)
91–100 of 202 posts
Re: It’s time to embrace slow productivity (2022)
#92Earlier 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…
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.
Re: It’s time to embrace slow productivity (2022)
#93I 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…
Sometimes software engineers forget coding should be the final step, and not the main step. Defining as much as you can,80/20 before starting will save you time. Certainly there are cases where you have an idea and you dive right in and it will work out but usually that won’t work out well from my experience
On the flip side, a lot of exploratory coding is often necessary to learn exactly what needs to be done. "Oh this API sometimes returns garbled garbage results, guess we need to write a sanitizer for its output" isn't something that is going to be known until at least some code is written.
Re: It’s time to embrace slow productivity (2022)
#94Earlier quoted context omitted.
> whoever owns the means of production This 19th rhetoric century doesn't work in modern world, especially when you're talking about creating software. To "produce" most of what HN readers do, you don't need anything more than a laptop and some cloud services — which you would need to scale up proportionally to load, and, therefore, revenue. If you need capital to hire others, it's also never have been more easily av…
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?
I think you'd take anything anyone says as proving your point just on the basis someone is responding to you at all.
Re: It’s time to embrace slow productivity (2022)
#95I 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…
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, regardless how terrible the engineers view the build process. So people love to lament how awful the early choices were and how far in outer space we'd be, should some shiny late-stage idea have been applied. But it's a lot more like the x86 CPU architecture, in spite of all the detractors, it endures.
Ahh, and I've also worked for a company that did rewrites. A lot of them. Like every time the product reached some 80-90% of functionality, they'd throw everything away and redo from start. Never shipped anything in my entire stay there. Again in my life I never seen such a thing, it's like the managers were not right in the head and developers were lacking any common sense. So it shouldn't come as a surprise that now (after some 5+ years of this) they closed and fired everyone.
Re: It’s time to embrace slow productivity (2022)
#96Comments 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 normalize it. To make it clear that that is ok.
I'm extremely lucky because my company has a culture where people can, and routinely do, say things like "My brain's fried. I can't do anything else productive today so I'm leaving early." or "I didn't sleep well, so I'll be late today and I'll make it up later." And people ask for help almost every day. And we watch out for when someone's stressed and do not pile more things on them.
Everyone agrees that none of us wants somebody just adding bugs because they're too overwhelmed, and then wasting time afterward reverting and fixing them. That's not productive.
I know, that is rare. It requires everyone involved to create that culture of acceptance and assistance. Management alone can't do it, but also, if all the employees are doing it, they can't stop it.
It's a duty of all of us senior employees to set the right example.
Re: It’s time to embrace slow productivity (2022)
#97I 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…
Agile processes is an oxymoron.
"Agile" coaches scammed you
Re: It’s time to embrace slow productivity (2022)
#98More importantly, I think, with AI automation coming in full force, we need to decouple one's working hours with their right to live a comfortable life, especially for the lower and middle class.
Right to live a “comfortable life”?
What does that mean?
Re: It’s time to embrace slow productivity (2022)
#99[flagged]
Re: It’s time to embrace slow productivity (2022)
#100Earlier quoted context omitted.
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…
You imply that all companies add value to society and all jobs are meaningful. That’s simply not true. Most people also don’t and won’t have the power to fix these issues even if they wanted to. Even if the company as a whole adds value there are lots of pockets of politically charged actions e.g. for promotions. Like are we doing anything meaningful to society by building 1 of those Google projects that gets killed…
If you are lucky enough to work on one of those google projects chances are you have options working on more meaningful things or freedom to steer in that direction.