Breaking down tasks
jacobian.org
Breaking down tasks
1–10 of 118 posts
Re: Breaking down tasks
#2I don’t know.
I think that’s the main truth about software engineering. Maybe an open source version of that Streak app exists and OP is re-inventing the wheel.
I think the brain doesn’t like task list. It may be pleasant to do, but most of entrepreneurship or coding is exploring.
And a task list blocks you from exploring.
Re: Breaking down tasks
#3The best way to estimate is to start work and benchmark your progress against your estimates
Re: Breaking down tasks
#4I don’t know. I think that’s the main truth about software engineering. Maybe an open source version of that Streak app exists and OP is re-inventing the wheel. I think the brain doesn’t like task list. It may be pleasant to do, but most of entrepreneurship or coding is exploring. And a task list blocks you from exploring.
Agree, the entire point of a task list is to block yourself from doing other things. That makes sense until it doesn't. "The map is not the territory".
Re: Breaking down tasks
#5This gets a lot of teachers - the task is so ingrained in them that the only part they consciously understand is the trivial bit that everyone already gets. Breaking down a task and estimation are almost equivalent - once the breakdown is done, assigning estimates to the chinks of work takes a few minutes as anyone with a few years experience has some standard estimates for small tasks. In my experience I break down a task by biting off chunks that I can estimate, then ask for opinions on anything I can't.
Although I don't even believe the real path to mastery is the task breakdown. Anyone can come up with a bad breakdown. The real point of mastery, which he didn't talk about here, is identifying when the evidence suggests a task breakdown is incorrect enough to cause problems and communicating that / doing a re-estimate [0]. And being comfortable that it will happen so not getting stressed up front putting out a schedule that is likely to change. Managers generally want an accurate roadmap up front. This is them asking for the impossible. IMO Good management is about flexibility and understanding that the expected nature of the work changes as time passes and developers learn.
He has a little example at the end. Ponder that if someone had come to him with an accurate estimate ("you can do this in a few evenings as a plane trip") he'd have rejected that as too risky. That illustrates that estimating isn't even about accuracy, there are many unspoken factors here around risk management, expectation management, task familiarity, etc, etc.
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - he has a post on the topic
Re: Breaking down tasks
#6Breaking down work works great until the breakdown is unknowable. Things like research, that require creative experiments to POC things that are not known apriori. That’s when task breakdown breaks down.
Re: Breaking down tasks
#7This gets a lot of teachers - the task is so ingrained in them that the only part they consciously understand is the trivial bit that everyone already gets. Breaking down a task and estimation are almost equivalent - once the breakdown is done, assigning estimates to the chinks of work takes a few minutes as anyone with a few years experience has some standard estimates for small tasks. In my experience I break down…
Really great, honest and refreshing link - my thanks for posting it.
Re: Breaking down tasks
#8Maybe I’m just lazy/undisciplined/a cowboy but having to break things down into “pointable” tasks feels like busy work just so management can “see” progress.
I mean, thinking through a problem you’re trying to solve before starting makes sense, and having rough milestones is important - but a majority of the time there’s so many unknown unknowns that fully breaking it down is totally useless, if not impossible.
If I spent the same amount of time it took me to break a project down just working on figuring out a solution or building it, it’d get done way sooner. At least, that’s how it feels.
Re: Breaking down tasks
#9> Delivers change because, in a work context, a task only “matters” if something is different because of the work.
I think maintenance tasks may require more effort / more expansive qualification when it comes to the meaning(s) of "something is different".
I think the topic of "breaking down tasks" could very well be its own book genre or even podcast genre. My experience with self-help and organization titles has been that the activity of breaking down tasks is a sort of known primitive human operation that many authors assume their readers to have. However, my own personal experience and the accounts of others I have heard while participating in group sessions is that breaking down tasks can be very difficult and provoke emotions of avoidance and despair.
The most broadly relevant advice that I have come across when it comes to breaking down tasks is to keep breaking things down until I am 90% certain that I can successfully complete the task. The certainty here would vary on how much self-confidence an individual has and their risk tolerance, so some people may break down tasks to 70% certainty of success.
Re: Breaking down tasks
#10Breaking down work works great until the breakdown is unknowable. Things like research, that require creative experiments to POC things that are not known apriori. That’s when task breakdown breaks down.
...and then you break out the actuarial models :)
And at some point, you just gotta do it.