Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Breaking down tasks makes the magnitude of work easier to spell out to management, this is a good thing.
Running tasks in parallel on the other hand is not always a bad thing, unless they are highly dependent or related to each other and 1 dev would be better then 2 on such tasks.
But that's a judgement call the lead should be making after discussions with the dev(s) doing the work, and explaining to management. -
@nitwhiz That's not breaking down long tasks, that's doing multiple long tasks in parallel. Learn the difference.
-
@C0D4 my project manager thinks Elixir programs use cpu more efficiently because it handles concurrency itself… He thinks it is a magical language that makes your solution parallelizable
-
@nitwhiz one can deliver 9 also. Less resource spent
-
It depends on the task. Some can be broken down, some can't.
But how do you know what could be done in parallel, if you don't break down the task?
If you don't break it down, you can't really determine what can be done in parallel and what can't.
If nothing else, I think it kind of promotes thinking ahead - doing the solution on paper first, which is a good thing.
Why the fuck is every tech lead and manager obsessed with the idea of breaking down tasks?
It's true some tasks can be broken down into smaller ones. But there are situations where a task needs to be done by 1 person in X days. Breaking it down into 2-3 tasks so that "they can be done in parallel" actually requires more efforts among devs, introducing unnecessary complexity and more risks.
9 women cannot deliver a baby in 1 months ffs. I guess these people never learn.
rant