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

71–80 of 118 posts

Re: Breaking down tasks

#71

Post by RandomLensman »

fmbb wrote: post #61
arnorhs wrote: post #60

Earlier quoted context omitted.

Whenever you talk about breaking down tasks, estimations etc, those usually are for multi-person teams, and/or projects that have some specific budget or something. Of course if you are exploring or building your own projects and/or don't have any other accountability, you wouldn't start planning that.. unless you are really into planning in and of itself. But as soon as you have a boss and the boss asks "how long? w…

> But as soon as you have a boss and the boss asks "how long? who does what? where do we start?" - you have to have some framework. Why? Does it work? Is it productive? Is it better than not doing that?

On average: yes, yes, and yes.

Re: Breaking down tasks

#72

Post by suriyaG »

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

Re: Breaking down tasks

#73

Post by m3kw9 »

lelanthran wrote: post #18
m3kw9 wrote: post #11

Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown

> Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown Similarly, if you don't plan enough, and get far enough into a small project, you don't change your approach because of the sunk cost fallacy.

Right, you are susceptible to it either way. In that case breaking down a task can potentially get you way further

Re: Breaking down tasks

#74

Post by m3kw9 »

petersellers wrote: post #13
m3kw9 wrote: post #11

Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown

Isn't it more likely that you can catch yourself during the planning phase if the amount of work being estimated exceeds your budget? That seems much cheaper and easier to pivot from than if you were to make that realization halfway through your implementation.

I think it’s par for the course because you can only plan so far before you run into miscalculations once you start doing it. You break down tasks for stuff very close range

Re: Breaking down tasks

#75

Post by globular-toast »

firewolf34 wrote: post #62
globular-toast wrote: post #56

What's missing here is who this breakdown should be shared with. There are three levels of breakdown and the details of lower levels should never be revealed to higher levels: 1. The "business" level. There are no "tasks". There are only needs and desires. Things like "a user can log in and press a button". These should not be broken down further than the smallest unit of deliverable value. In this example, there's n…

Can you elaborate on why we wouldn't share the carefully estimated project plan breakdown with Level 1? I'm not disagreeing, just curious - one would think that with doing all the work to achieve a solid project plan breakdown and Gantt charts and such, it would behoove you to express this to management who is salivating over tangible examples of progress... I understand we don't want to show technical to non-technic…

Reporting on progress up to level 1 is a waste of everyone's time. It's either done or it's not. It ships when it ships. If the team has committed to delivering by a date then just let them get on with doing that. Blockers and setbacks should be actively communicated up the stack if they will affect the deliverable, but otherwise it should be assumed things are on track.

Management are always salivating for details, but we know what always happens: we drop a technical term one time and management goes around repeating that like they know what they're talking about. They use these like weapons to keep other people off their back: basically say something that nobody understands and they'll leave you to it. Some managers will push for more fodder, but it's not your job to provide this. It's your job to deliver.

Re: Breaking down tasks

#76

Post by throw1234651234 »

Does anyone have a better article on this? This is ok, but it seems like there are better - I would love to share with my team.

These are things I always share with them:

On code reviews: https://mtlynch.io/code-review-love/

On simplicity: https://grugbrain.dev/

On SOLID (even though we use Python now): https://www.baeldung.com/solid-principles

I would love to have a "standard" article for planning.

Re: Breaking down tasks

#77

Post by earth-adventure »

ncphillips wrote: post #63
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 never ever end up doing the actual steps as I planned to I do the GTD thing of only thinking about the _next_ action, not trying to think of every action.

Seriously asking : how? I can't cheat my brain into not automatically seeing the next steps after that and the cascading relation between the all. Within a second or less.

Re: Breaking down tasks

#78

Post by sanderjd »

RandomLensman wrote: post #71
fmbb wrote: post #61

Earlier quoted context omitted.

> But as soon as you have a boss and the boss asks "how long? who does what? where do we start?" - you have to have some framework. Why? Does it work? Is it productive? Is it better than not doing that?

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 productive exercise; it usually costs more time up front than it earns in productivity.

But despite those two things I think it still turns out to be better on average, in a team / "you have a boss" environment. Because productivity is not the only thing that matters, legibility is also important to organizations, and worth some productivity cost. Though this will chafe me until I'm in my grave, I still think it's true.

Re: Breaking down tasks

#79

Post by rapind »

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 I'm working to hold my lists, but tbh it's unnecessary to even save them.

Re: Breaking down tasks

#80

Post by sanderjd »

zarathustreal wrote: post #67
fmbb wrote: post #61

Earlier quoted context omitted.

> But as soon as you have a boss and the boss asks "how long? who does what? where do we start?" - you have to have some framework. Why? Does it work? Is it productive? Is it better than not doing that?

Suppose it doesn’t work, it’s not productive, and it’s worse than not doing it. You still have a boss asking these questions. Any answer you provide constitutes a framework.

Well, one answer you can try is to push back on the concept of providing status updates. For many (but not most) high-trust individuals working on many (but I think not most) kinds of projects, that's totally fine. (Ideally it is an expectation set much earlier on than the point where a status update is being requested, though.)
Post reply on HN