7 ms·

I relate heavily to the author's dilemma. My projects span from math, to programming, to pinball repair, to amateur radio, to gardening, to mycology, to who kno

I relate heavily to the author's dilemma. My projects span from math, to programming, to pinball repair, to amateur radio, to gardening, to mycology, to who knows what else. I personally enjoy the process of bike-shedding and endlessly exploring the solution space for a problem. That said, there is a point where you need to make hard decisions and button up projects. As long as I don't care what project gets completed at what time, I've found a little trick to broadly move the needle. I jokingly call it "Sol's fast five" but the name is actually pretty on point. I take a step back, look around me, and pick out the first five things I can reasonably achieve in less then a day prioritizing things where I have all the tools and materials at hand. These 5 things are never entire projects, the goal is to maximally decompose the projects until each action is as close to trivial as possible. Once I have my list of 5 things I stop thinking about anything else and strictly work towards those 5 goals. There is a sense of relief in having reduced the scope and the tasks tend to be finished very quickly. Checking them off the list always feels good. Once I have completed my 5 items I start a new list and pick out the next five items. This can feel like a huge reward. I've used this system to great effect in the past few years.

exe34 2y ago
would the five tasks be a single project or across multiple?
- solomonb 2y ago
  It depends on the circumstances and how you want to prioritize things. Generally I'll take on the 5 easiest tasks across all my 'active' projects.
  - exe34 2y ago
    that makes a lot of sense. I've noticed myself, whenever I'm procrastinating and avoiding working on a project, it's because I don't actually know what the next step is. if I make figuring out the next few steps as a time-boxed task in itself, suddenly I don't procrastinate anymore, I just sit down and do it.
    - solomonb 2y ago
      I think this gets back to what I said about being okay with bike-shedding. Researching and exploring the design space is a critical part of every project. Its okay to commit time to thinking, planning, and exploring. I feel that as engineers we generally react negatively to the idea of bike-shedding or "building cathedrals" but the reality is that there is always a bike-shed. The question we should be asking is not should we deliberate over the design of the project, but rather to what degree does this project (and consequently the business in paid situations) benefit from deliberation. In the case of personal projects, I am far more concerned with the process then the outcome and will allow myself to indulge in bike-shedding maximally.
      - exe34 2y ago
        My preference is to think deeply about it alone, and either take the results of that to the team or even come up with a very rough mockup/prototype and/or some working code for the bits that I initially have no idea how to implement (again, in a time-boxed manner)- and only then have a proper bike-shedding session. Otherwise I find so much time is wasted on tiny details that don't matter, and the overall picture still fails to emerge (aka a definitional bike-shedding session).
zafka 2y ago
Your interests sound similar to mine. My email is in my profile if you ever care to compare notes.
lovegrenoble 2y ago
Thanks!
Syntonicles 2y ago
Same approach: I call it "Ten Tiny Tasks"
- assadk 2y ago
  Sounds interesting, could you elaborate on this please?
  - merlincorey 2y ago
    I'm not the GP you asked, but distilling my own personal organization practices into the alluring "Ten Tiny Tasks" title, here's my take on it: - Make a list of the 10 tiniest tasks with the least amount of estimated effort you can find or think of that need to be done - Maybe save task 10 for a super quick prioritizing of the other 9 tasks, or don't because they are tiny tasks, after all - Complete the 10 tiniest tasks - Repeat the process until there are no more tasks (of course, there are always more tasks)
    - fragmede 2y ago
      And like, tiny. Open terminal to project directory. Opeb browser window/tab to SDK/API index. Shit so easy that you can't help but do them. Repeat until you get to tasks that aren't quite so trivial, and by then, you'll be going.
      - solomonb 2y ago
        IME as you approach the limit you can create an infinite number of tasks. The key for me is to pick tasks which balance expedience and bang for buck value, but if you are experiencing intense writers block then I see no problem with a task like "open editor."
        aldanor 2y ago
        Yea. It's like falling down the recursion with a stack size of 5. Do the task. Plan doing the task. Start planning doing the task. Plan starting planning doing the task...
ants_everywhere 2y ago
> the goal is to maximally decompose the projects until each action is as close to trivial as possible This is a big part of the GTD framework that is almost always dropped in the retelling but which I think is fundamental. The tasks should be broken down to the next physical thing you can do so you don't have to think to act. Also you have cool interests
- solomonb 2y ago
  Thanks. I have heard a lot about GTD but never sat down and read it. I definitely want to read it one of these days but I also must say that after years of trying different productivity systems I find that the absolute simplest systems are the best for me.
  - _xiaz 2y ago
    Then stay away from it if you can. GTD is great if you're a manager with a wive and kids and maybe a foundation to run on the side. If you don't usually forget tasks/events or freeze up because of analysis paralysis, you can get by just fine without it. GTD definitely brings an overhead that doesn't pay off in a reasonably simple life
    - TeMPOraL 2y ago
      I'm not a manager, but have a wife and kids and used to run a foundation on the side. The overhead of GTD only got more painful, while my ability to sustain focus diminished, so the whole thing broke down.
    - bluGill 2y ago
      GTD is supposed to be a pick and choose the parts that will make the most difference in your life and adjust to what works for you. If your not "a manager with a wive and kids and maybe a foundation to run on the side." then you don't need the full, but there are often useful things in there that are useful. GTD is not religion (or at least it should not be - with some people it is), you won't go to hell or something if you don't do everything perfect.

exe34 2y ago

would the five tasks be a single project or across multiple?

solomonb 2y ago
It depends on the circumstances and how you want to prioritize things. Generally I'll take on the 5 easiest tasks across all my 'active' projects.
- exe34 2y ago
  that makes a lot of sense. I've noticed myself, whenever I'm procrastinating and avoiding working on a project, it's because I don't actually know what the next step is. if I make figuring out the next few steps as a time-boxed task in itself, suddenly I don't procrastinate anymore, I just sit down and do it.
  - solomonb 2y ago
    I think this gets back to what I said about being okay with bike-shedding. Researching and exploring the design space is a critical part of every project. Its okay to commit time to thinking, planning, and exploring. I feel that as engineers we generally react negatively to the idea of bike-shedding or "building cathedrals" but the reality is that there is always a bike-shed. The question we should be asking is not should we deliberate over the design of the project, but rather to what degree does this project (and consequently the business in paid situations) benefit from deliberation. In the case of personal projects, I am far more concerned with the process then the outcome and will allow myself to indulge in bike-shedding maximally.
    - exe34 2y ago
      My preference is to think deeply about it alone, and either take the results of that to the team or even come up with a very rough mockup/prototype and/or some working code for the bits that I initially have no idea how to implement (again, in a time-boxed manner)- and only then have a proper bike-shedding session. Otherwise I find so much time is wasted on tiny details that don't matter, and the overall picture still fails to emerge (aka a definitional bike-shedding session).

zafka 2y ago

Your interests sound similar to mine. My email is in my profile if you ever care to compare notes.

lovegrenoble 2y ago

Thanks!

Syntonicles 2y ago

Same approach: I call it "Ten Tiny Tasks"

assadk 2y ago
Sounds interesting, could you elaborate on this please?
- merlincorey 2y ago
  I'm not the GP you asked, but distilling my own personal organization practices into the alluring "Ten Tiny Tasks" title, here's my take on it: - Make a list of the 10 tiniest tasks with the least amount of estimated effort you can find or think of that need to be done - Maybe save task 10 for a super quick prioritizing of the other 9 tasks, or don't because they are tiny tasks, after all - Complete the 10 tiniest tasks - Repeat the process until there are no more tasks (of course, there are always more tasks)
  - fragmede 2y ago
    And like, tiny. Open terminal to project directory. Opeb browser window/tab to SDK/API index. Shit so easy that you can't help but do them. Repeat until you get to tasks that aren't quite so trivial, and by then, you'll be going.
    - solomonb 2y ago
      IME as you approach the limit you can create an infinite number of tasks. The key for me is to pick tasks which balance expedience and bang for buck value, but if you are experiencing intense writers block then I see no problem with a task like "open editor."
      - aldanor 2y ago
        Yea. It's like falling down the recursion with a stack size of 5. Do the task. Plan doing the task. Start planning doing the task. Plan starting planning doing the task...

ants_everywhere 2y ago

> the goal is to maximally decompose the projects until each action is as close to trivial as possible This is a big part of the GTD framework that is almost always dropped in the retelling but which I think is fundamental. The tasks should be broken down to the next physical thing you can do so you don't have to think to act. Also you have cool interests

solomonb 2y ago
Thanks. I have heard a lot about GTD but never sat down and read it. I definitely want to read it one of these days but I also must say that after years of trying different productivity systems I find that the absolute simplest systems are the best for me.
- _xiaz 2y ago
  Then stay away from it if you can. GTD is great if you're a manager with a wive and kids and maybe a foundation to run on the side. If you don't usually forget tasks/events or freeze up because of analysis paralysis, you can get by just fine without it. GTD definitely brings an overhead that doesn't pay off in a reasonably simple life
  - TeMPOraL 2y ago
    I'm not a manager, but have a wife and kids and used to run a foundation on the side. The overhead of GTD only got more painful, while my ability to sustain focus diminished, so the whole thing broke down.
  - bluGill 2y ago
    GTD is supposed to be a pick and choose the parts that will make the most difference in your life and adjust to what works for you. If your not "a manager with a wive and kids and maybe a foundation to run on the side." then you don't need the full, but there are often useful things in there that are useful. GTD is not religion (or at least it should not be - with some people it is), you won't go to hell or something if you don't do everything perfect.