Hacker News Reader

Comment by ukj | Hacker News Reader

This is a perfect example of faking it! The very thing this thread is about.

Instead of figuring out how to make the hard choice between Urgent<->Important in the first place, you've drawn a distinction which lets you kick the can down the road.

Choosing between Unurgent-Important<->Urgent-Unimportant is exactly the same problem as choosing between Urgent<->Important.

You have two tasks: A or B. Which one should you work on first?

The one which is most important/urgent/crucial/paramount/valuable/critical/indispensable/pressing/essential/serious/vital/exigent/burning/paramount/<insert more synonyms here>, obviously!

Is that task A or task B?

"The first principle is that you must not fool yourself and you are the easiest person to fool." - Richard P. Feynman

If you can't assign relative priorities to things - you can't implement a priority queue ( https://en.wikipedia.org/wiki/Priority_queue ).

View on HN

Perhaps its my stupidity, but I don't see what this has to do with faking?

The point was that importance is not the same thing as urgency, which the parent comment didn't seem to understand.

>Choosing between Unurgent-Important<->Urgent-Unimportant is exactly the same problem as choosing between Urgent<->Important.

Sure, in the other formulation you simply make the assumption that the important task is unurgent, and the urgent task is unimportant, and so they are the same, as long as we're on the same page.

>You have two tasks: A or B. Which one should you work on first?

I actually did address this. If you have time for both the urgent one comes first, if you may have time for only one the important one comes first.

Urgent is not a synonym for important, and the point of drawing the distinction is to recognise that relative priorities can be different depending on context, such as how much time is available.

>The point was that importance is not the same thing as urgency, which the parent comment didn't seem to understand.

There is nothing to understand about that point. It's a linguistic distinction which makes no practical difference.

The prioritisation problem is like this: When forced to choose which task do you schedule first?

The Urgent one or the Important one?

If you always lean towards Urgent things, you will neglect the Important. If you always lean towards Important things, you will neglect the Urgent.

>Sure, in the other formulation you simply make the assumption that the important task is unurgent, and the urgent task is unimportant, and so they are the same, as long as we're on the same page.

We are on the same page. It doesn't matter how you label them, if two tasks have equal priorities you have no way to decide which task to schedule first.

Conversely: if you have a way to decide which task to schedule first, then (to you) they clearly have different priorities.

The one you've chosen to do is the task with higher priority! Obviously - because you chose to do it first.

You have no solution to this problem. You are faking the fact that you do. You are flipping a proverbial coin (like the rest of us).

>There is nothing to understand about that point. It's a linguistic distinction which makes no practical difference.

It does make a practical difference. Important tasks are higher priority under tighter time constraints and vice versa. I fail to see how this isn't a practical distinction.

>If you always lean towards Urgent things, you will neglect the Important. If you always lean towards Important things, you will neglect the Urgent.

If you do this you failed. The point is lean important when time constrained, urgent when not.

>Conversely: if you have a way to decide which task to schedule first, then (to you) they clearly have different priorities.

They have different priorities IN DIFFERENT CONTEXTS. One is higher when time constrained, the other higher when not. It is clear from reading your comments that you have not understood this.

>They have different priorities IN DIFFERENT CONTEXTS.

That's precisely your error in reasoning! You are violating the ceteris paribus principle by inventing multiple contexts.

We don't exist in multiple contexts. We exist in a single context. The one in which we schedule work - The Universe.

Ceteris Paribus either:

We are in a time-unconstrained Universe in which priority(Urgent) > priority(Important). In such a Universe we would schedule Urgent tasks first.

We are in a time-constrained Universe in which priority(Important) > priority(Urgent). In such a Universe we would schedule Important task first.

So which Universe are we in?

In what universe do you live in that you operate under different time contexts/constraints to the rest of us?

The very fact that you are forced to make a choice between Urgent and Important indicates that you ARE time-constrained within your context.

If you could do both in parallel it wouldn't be a prioritisation problem.

There is only one time context. It's called The Universe. For each worker (human!) Time is a finite resource. It is clear form your comments that you do not understand this.

Having 'different time contexts' means having multiple workers. Multi-threading.

Contrived hypothetical: It's tuesday evening, and I'm updating my to-do's before tomorrow. I have 3 hours after work, and 3 tasks:

1) A meeting (Important Urgent) 1 or 2 hours

2) Buy a gift for someone's birthday (Important - can be done any time but must be done) 1 hour

3) Check the marketplace for a limited sale (Urgent - much better if done immediately, but doesn't matter so much if not done) 1 hour

If task 1 takes only one hour, I do 3 then 2. If it takes two hours, I do 2.

There's two contexts above. Obviously as you pointed out, once you actually get to doing a task, there's only one context. But the point is that when adding a task to your to-do list you don't yet necessarily know what that future context will be.

Your choices here are to either make a priority queue for every possible future context (reasonable for this simple case, but doesn't scale to a more complex one), or mark tasks with the relevant information that will let you easily assemble the appropriate priority queue on the fly, once the context becomes clear.

And what happens if your time-estimates are wrong; or unbounded?

You have two tasks (one Urgent, one Important) and 10 days at your disposal.

If each task takes at least 4 days, which one do you do first?

> But the point is that when adding a task to your to-do list you don't yet necessarily know what that future context will be.

I am not talking about pushing tasks on the queue. I am taking about popping them off the queue.

If you don't know how long a particular task takes how do you decide whether to pop a task off your Urgent or Important queue?

Just-in-Time prioritisation under uncertainty is hard.

Your argument is A != B.

My argument is that your argument is not useful when having to choose between A and B.

If A != B is true, then go ahead and evaluate A > B.

Reply on news.ycombinator.com