Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking down tasks

jacobian.org

Post reply on HN
Print view View original

81–90 of 118 posts

Re: Breaking down tasks

#81

Post by sanderjd »

suriyaG wrote: post #72
Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

I'm a person who hates lists and plans for personal tasks. But, am learning to love them. Because as I often realize, things get missed in the myriad of things to remember. The plan to me is just a way of reminding my future self what I thought of as ideal output in the past. Instead of infinitely changing my plans and chasing fireflies

That's slightly different, IMO. Writing down things that need to get done as you think of them is not the same as writing down a plan.

Re: Breaking down tasks

#82

Post by RandomLensman »

sanderjd wrote: post #78
RandomLensman wrote: post #71

Earlier quoted context omitted.

On average: yes, yes, and yes.

> Does it work? Is it productive? Is it better than not doing that? >> On average: yes, yes, and yes. For what it's worth, I think it's more like: On average: no, no, and yes. It doesn't really "work" in the sense that the plan turns out to be an accurate and useful reflection of the work; that is not the case on average in my experience (sometimes it is, but not usually). And for the same reason, it isn't usually a…

The plan being an accurate reflection of what then happens is not the point.

Having people assigned to tasks, a starting point, some initial steps to follow is something that increase delivery speed in the beginning a lot.

Edit: to some extent, legibility is productivity, as it means others are aware of what is going on and can interact/refer/etc.

Re: Breaking down tasks

#83

Post by igortg »

Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

Holy... It still amuses me how much HN comments brings the reality to these kind of articles.

> the plan is never followed.

Sometimes it's even worst. As we add more tasks during execution, at the end, these tasks get twisted with the ones you created while planning. Then we end up with a messy list of undone tasks that aren't really required anymore (because they were created without having the full context, that only happens during the execution).

Re: Breaking down tasks

#84

Post by throw1234651234 »

itsgrimetime wrote: post #8

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

I mostly disagree with you if you work in a "standard" company - it's usually "make a form" or "move data / do some other CRUD". These tasks don't generally have that many unknowns.

It's absolutely valuable for managers to be able to estimate velocity as well, though the problem is that they really do stop understanding "we are not sure" once you spoil them.

I am a consultant too, so it's critical for me to say "we are delivering this, in this much time", even though we are "agile".

Re: Breaking down tasks

#85

Post by sanderjd »

baliex wrote: post #57
Scarblac wrote: post #52

Earlier quoted context omitted.

And Eisenhower's "plans are useless, planning is essential", of course. I know. But for me it's very easy to overdo it. Give me interesting chunks of about a week or two, with a tight deadline, and I'll do my best work. Remember, Linus wrote Git in two weeks. And there was no project manager in sight.

On the Linus point, I'd bet there were countless months where he was bringing ideas together in his head and planning how he'd do it before actually finding the time to sit down and write it.

It would be interesting to know whether he had devised some kind of project plan ahead of time. But I suspect not. I'm sure he had been thinking about the technical details of what he wanted to build - which yep, we all like to do that! - but I doubt he bothered to break down a set of approximately-ordered 1- to 3-day work units, which is what many of us struggle to be good at.

Re: Breaking down tasks

#86

Post by sanderjd »

RandomLensman wrote: post #82
sanderjd wrote: post #78

Earlier quoted context omitted.

> Does it work? Is it productive? Is it better than not doing that? >> On average: yes, yes, and yes. For what it's worth, I think it's more like: On average: no, no, and yes. It doesn't really "work" in the sense that the plan turns out to be an accurate and useful reflection of the work; that is not the case on average in my experience (sometimes it is, but not usually). And for the same reason, it isn't usually a…

The plan being an accurate reflection of what then happens is not the point. Having people assigned to tasks, a starting point, some initial steps to follow is something that increase delivery speed in the beginning a lot. Edit: to some extent, legibility is productivity, as it means others are aware of what is going on and can interact/refer/etc.

> Having people assigned to tasks, a starting point, some initial steps to follow is something that increase delivery speed in the beginning a lot.

It's a balance of time spent planning against the value of the plan. Immediate-term "planning" is definitely valuable, IMO. Thinking through how some immediate work can be split up so that multiple people can make progress simultaneously, without stepping on each other's toes, that is definitely valuable. Having some discussion about what the next steps might be after those immediate steps are complete, that's also pretty much always valuable. Spending a small amount of time thinking about the next next steps can be valuable. But past that, in my experience, people often put more time into planning detailed steps than ends up being valuable. It's not that it has zero value, it's that it has a pretty high cost that, in my opinion, usually outweighs that value.

Also, just to note that I think spending time thinking about a "north star" vision of what a project is trying to achieve is also pretty much always strongly positive ROI.

It's time spent coming up with a detailed plan a few steps out from the immediate term that I find dubious. I don't mind other people spending that time if they want to, but I don't like spending my time in those planning meetings; I'd rather be getting to work on the immediate term tasks.

Re: Breaking down tasks

#87

Post by ramijames »

Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

This is an accurate and insightful way of looking at work. It touches on something that I've been considering a lot lately: I love programming, but I hate doing it in a work environment. The fun thing about programming is that it is a flexible, flowing, and creative endeavor. You make things up as you go; it is an organic experience. In a work environment, this organic nature is removed mainly because there is a need for oversight and accountability.

Re: Breaking down tasks

#88

Post by M2Ys4U »

rapind wrote: post #79
Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

I make lists and break tasks in to smaller tasks, however I rarely reference these lists. They basically end up in the void. The act of making the list gets my juices flowing and reminds me of the side effects / bigger picture of my current challenge. Realizing this also helps me avoid yak shaving over list making tools, since I could care less about even saving the lists! I keep a folder of text files in any project…

Sometimes planning is more important than having a plan

Re: Breaking down tasks

#89

Post by wting »

chrisweekly wrote: post #64
Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

Tangent: I can't recall where I first heard "plans are worthless, but planning is essential", but there's definitely some truth in it.

Another perspective is that planning is a breadth-first traversal of the solution space, and coming up with a path to the solution. When reality hits and the path is often wrong, one can switch to other paths quickly since the graph was created ahead of time. It's writing the table of contents for a book before fleshing it out.

Without planning, a depth first traversal is a high risk endeavor in the likelihood that the that path is wrong but backtracking and creating the graph is comparatively expensive and susceptible to sunk cost fallacy. Depth-first traversal is writing the book a chapter at a time without a table of contents in mind.

Re: Breaking down tasks

#90

Post by RandomLensman »

sanderjd wrote: post #86
RandomLensman wrote: post #82

Earlier quoted context omitted.

The plan being an accurate reflection of what then happens is not the point. Having people assigned to tasks, a starting point, some initial steps to follow is something that increase delivery speed in the beginning a lot. Edit: to some extent, legibility is productivity, as it means others are aware of what is going on and can interact/refer/etc.

> Having people assigned to tasks, a starting point, some initial steps to follow is something that increase delivery speed in the beginning a lot. It's a balance of time spent planning against the value of the plan. Immediate-term "planning" is definitely valuable, IMO. Thinking through how some immediate work can be split up so that multiple people can make progress simultaneously, without stepping on each other's…

I think making plans/planning needs training to be good at - which in turn reduces "overplanning". Knowing what to include, discuss in which forum, what task or deliverable granularity, etc. is useful doesn't come naturally to most.
Post reply on HN