Tasks, Lists, and Promises | Hacker News Reader

Tasks, Lists, and Promises

rachelbythebay.com

50 pointszdw19 comments

It feels like this kind of dismisses prioritization. But that's only if you're not doing proper prioritization.

In reality prioritization is important, but it is affected by dependencies, effort, and "inspiration."

Dependencies: obviously if a P0 task requires a P2 task to complete, the latter is now a P0.

Effort: if a P2 can be done in an hour, it's probably higher impact than a "P0" that will take a quarter. So really what you need is some cost/benefit framework or RICE framework.

Inspiration: sometimes, someone on the team will just see a path to getting something done. They will be irrationally excited about it. You can't prioritize purely based on inspiration of the moment, but I've found leaving some flexibility in the system for capturing that inspiration can be very powerful.

> Effort: if a P2 can be done in an hour, it's probably higher impact than a "P0" that will take a quarter.

A "P0" that far out sounds to me like something with a tight (calendar vs estimated effort) deadline and some sort of fairly serious contractual or regulatory penalties for missing it.

I have trouble parsing the idea of a P0 that takes a quarter, I guess I'm too stuck in Pn as "incident" rather than planned work.

Indelibly etched in my mind is that P0 is like "patient is not breathing" / "everything else is pointless until we fix this".

Yeah, it's not the terminology I'd expect to see, but I think it's at least somewhat comprehensible even though not really correct.

It's amazing to me how many people struggle with the first issue she describes. If a task is blocked it doesn't matter that it's high priority, there is zero point in doing it because you can't actually do it. If it's blocked by a lower priority task, then elevate that task's priority and do it first (or earlier). This is project management 101, also called common sense.

It depends on your issue management system, but most offer some system (labels, tags, flags) which you can use to identify a blocked issue to be passed over without tweaking the priority directly. I'd favour using such a system over priority adjustments in most cases, because presumably when the task gets unblocked it should be seen to sooner than the "While we have time" task you were doing in the meantime.

Yup, got the same though after reading the first paragraph. Priorities should propagate transitively, obviously. Straw-man problem.

Not a straw man, it's a real thing. Some people really do not get that "high priority" doesn't equate with "can be done now". I have had to physically draw out dependencies to demonstrate why X should be put on the same priority as Y if they really want Y done, because X is blocking it (in some fashion).

Yep, priority inversion is how RTOSes handle the problem too.

https://en.wikipedia.org/wiki/Priority_inversion

I don't know these people but my presumption is that Rachel's colleagues are smart cookies. I figure it's less likely that a bunch of smart engineers don't understand dependency resolution and priority propagation, and more that there are (maybe imagined, maybe not) organizational factors that make it a problem to pick up a nominal p2 when there's a p0 on the board, factors that she can ignore due to political capital or just sheer IDGAF-ness.

I know Jira has support for linking tasks semantically (X blocks Y; is blocked by Z) but I wish more task managers had better support for this. A few do, but very few of those will actually show you a task graph.

I actually wrote about this exact thing: https://xavd.id/blog/post/my-perfect-task-app/#dependent-tas...

My hope for the perfect task tracker springs eternal.

I really wondered why this is not an explicit thing in most task / issue trackers. There should be some semantic relations between issues which are standardized and come with special feature support.

If we know the dependencies and the priorities, we could also backtrack the graph and assign an "implicit (virtual) priority" to all issues which block issues with higher prio. It would also be nice to mark if something is on a critical path (that has been defined).

The overhead to write down dependencies is imho well worth when you consider how much that information can help you prioritize and save time by not starting something that will end up being blocked later. This is an issue I see repeatedly, also in companies who use Jira.

It's a basic feature in project management tools like MS Project. If a tool doesn't even match what Project can do, that's a pretty bad sign about the utility of it.

you can use /usr/bin/tsort to sort a list of things in a makefile-esque hierarchy

tsort is one of those neat unix tools that's hard to remember it exists when you need it

This sounds very similar to the Mikado Method: https://www.manning.com/books/the-mikado-method ?

Edit: rephrased to be more passive

What Rachel has described here is essentially a topological sort

At my last job, out of frustration, I built a thing that crawls JIRA links and builds a sorted graph to tell me what to work on next.

Which tool do you use to organize yourself? Is there an alternative to jira (gets quite expensive at some point)

Reply on news.ycombinator.com