Running the Stack
Look at the image here:
https://en.wikipedia.org/wiki/Stack_(abstract_data_type)
After looking at that image, you understand the concept well enough to use it as a mental model.
Hard-won lessons —
(1) I joke that “meditation is having exactly one thing on the stack.” One thing at a time on the stack might seem oppressive, but it’s actually joyful. I think you more-or-less can only do one thing at a time.
(2) But okay, the stack is more full. You just popped the top item off. Now what? IME, life goes better if you go down the stack unless new information compelling obsoletes it (unless you’re just messing around, in which case “messing around” is on the stack and you’re good). When an irrelevant tangent hits in a conversation, once it concludes, go back to where you were (if it was useful). When you realize you got distracted putting the groceries away, typically you want to finish putting them away.
(3) It’s entirely true that oftentimes, going down the stack is short-term worse than whatever newly catches your attention. But it trains you to both recognize tangents and navigate conversations intelligently (again, in a non-pure-social-hangout conversation—like at work or when exploring an important topic).
(4) Even more true: often super sucks to go back down the stack on physical task stuff after you got distracted. But! I believe — I don’t have any research, but my observation bears it out, it’s a hypothesis — I believe that consistently running down the stack after you got distracted makes you less distractible going forwards, because there’s less payoff to doing so.
(5) Some people can literally “run the stack” in their minds. Not a metaphor. Literally.
(6) I couldn’t do this before. Now I can.
(7) What changed is that I used to be able to comfortably juggle 5-7 items at a time without running a stack, but I recently calculated out the work I’m committed to in the near future— like, “almost all of this work will get done” — and it’s 300+ hours. Employees, administration, ops, software development, sales, finance. There’s dozens of projects that stretch off into infinity going on. Suddenly, I was just running the stack all the time. I don’t recommend it, but that’s what happened to me.
(8) You can get better about refusing to add things to the stack.
(9) You can get better about “closing the thread” (popping things off the stack) before changing gears. “Yeah but wait, let’s talk about that, but can we calendar that thing before we move on?” (can say it shorter, exaggerating for clarity)
(10) You don’t need to do a task or complete a conversation to remove it from the stack. You can just delete it. But the act of explicitly doing so — and communicating it to anyone else relevant that needs to know — is what keeps your stack from overflowing.
And the most important lesson —
(11) When you have multiple items on the stack and “start feeling ambitious and motivated”, COMPLETE THE ITEMS ON THE STACK RATHER THAN ADD NEW ITEMS TO THE STACK.
The all caps there isn’t shouting at you — it’s regret for lost years of my life. Alas. Bigger stack isn’t better. Faster throughput is better. That’s typically less stuff on the stack at any one time.
Anyway, the concept doesn’t work for everyone, but a surprising number of people who are effective I know actually literally “run a stack” in their minds. It’s… more common than I’d thought it. Probably the mix of being on software development and having an amount of work that’d be insanely overwhelming if I didn’t take things one-thing-at-a-time is what generated it.
Thanks for writing this.
I’m actually not sure what you mean by “running down the stack.” Do you mean “when I get distracted I mentally review my whole stack, from most recent item added to most ancient item”? Or do you mean “when I get distracted, I ‘pop’ the next item/intention in the stack (the one that was added most recently), and execute that one next (as opposed to some random one).
I originally read you as saying the second thing, which seems like it would entail running one’s life as a series of nested open loops (sort of like lisp).
In any case, I immediately implemented the second thing, on a trial basis. I’ll see how it goes.
Less payoff to getting distracted? To being distractible?
Why is that? Because if you get distracted you have to complete the distraction?
Thanks. Awesome.
Well, of course, it’s whatever works for you.
For a simple example, let’s say I’m (1) putting new sheets on my bed, and then (2) I get an incoming phone call, which results in me simultaneously needing to (3 and 4) send a calendar invite and email while still on the phone.
I’ll pick which of the cal invite or email I’m doing first. Let’s say I decide I’m sending the cal invite first.
I’ll then,
(4) Send cal invite—done—off stack.
(3) Send email—done—off stack.
(2) Check whether anything else needs to be done before ending call, confirming, etc. If need to do another activity → add it to stack as new (3). If not, end call.
And here’s where the magic happens. I then,
(1) Go finish making the bed.
I’m not fanatic about it, but I won’t get a snack first or anything significant until that done.
This, yes. Emphasis added.
Well, I can speculate on theory but I’ll just say empirically — it works for me.
But let’s speculate with an example.
You’re midway through cleaning your kitchen and you remember you needed to send some email.
If you don’t really wanna clean your kitchen deep down, you’re likely to wind up on email or Twitter or LessWrong instead.
Now that’s fine, if I see a second email I want to reply to, I’ll snipe that.
But at the end, I have to go finish the kitchen unless things have materially changed.
Knowing there’s no payoff in “escaping” is probably part of it. It probably shapes real-time cost/benefit tradeoffs somewhat. It means less cognitive processing time needed to pick next task. It makes one pick tasks slightly more carefully knowing you’ll finish them. It leads to single-tasking and focus.
Umm, probably a lot more. I’m not fanatic about it, I’ll shift gears if it’s relevant but I don’t like to do so.
Cool. This clarified what you’re pointing at, for me.
Hmm, I think I agree, but a queue instead of a stack.
Is that a description of an ideal, or a how you naturally operate? My experience is that things naturally fall to the top of the stack and while I can put them into a queue and then do the queue, that’s a different action than the one my brain is actually doing.
I mean i just naturally operate like a queue. Or at least I do now, maybe I used to be more stack like. But definitely things in the queue can get reordered, but queue feels more natural to me than stack, stack being some kind of degenerate case where the queue is malfunctioning.
I feel like a priority queue applies best to me.
Typo?