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.
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
But! Breaking down tasks to small pieces is a huge task by itself! Many people can't ever use that framework because well they cannot get themselves to that point. Is there any framework you know which could help applying this framework?
For me this is a set of general strategies for breaking down problems. Here are some I use. (Apologies if these aren't all orthogonal to one another; they just feel different when I'm thinking of how to break a problem down.)
1. Break down the steps. Can you find a recipe of steps for achieving the thing? Then start with the first step. Maybe that's a small enough task. Maybe you don't have to perform all steps in order, and you can find a small-enough step to do next.
2. Isolate the fundamental challenges. There is often a tough nut to crack within the problem. Can you isolate that from the rest of the project, and turn it into its own thing (I like to cast this as a "toy" problem)? When I say "isolate," I mean to remove all unnecessary complexity to getting at the fundamental issue. Suppose I want to figure out how to create a robust messaging network. There might be user interfaces and caching and different kinds of messages and different networks and different failure mechanisms and performance issues and ... So just create a "toy" at each step: First, simply send & receive a message. Don't worry about performance or worry much about robustness. You now have a small task but whose completion achieves a fundamentally necessary part of the larger task. Finishing that will feel good--you have something that works!--and you've made real progress. You might find examples of others doing something similar to this basic task as well, so you can work on your own but then compare notes to others to gain insights on why others have solved similar problems differently than how you solved it (you might have come to something better, or not; either way, you now have understanding of the fundamental problems involved). Now you can grow that toy or take what you learned from the toy and apply it to the larger task.
3. Similar to 2, but maybe a different POV: The physics joke is approximating a cow as a perfect sphere to study its dynamics. Simply the hell out of a problem! Maybe it feels ridiculously simple. Fine; now you are working with something completely tractable. You can then add in complexity to your model one wrinkle at a time.
4. Do something that's actually easy even if i might not be "significant" from the "big challenges to getting this project working" POV. Maybe you've been frustrated for a week or two trying to solve the tough-nut-to-crack bit of the problem. Even your toy problem remains (what feels hopelessly) broken! Switch over to creating the GUI or something superficial but that is easily tractable yet yields something satisfying to you when you finish. Simply stepping away from the hard problem for a day or two can re-motivate you when you come back to the hard problem. That time can also give your mind time to process solutions in the background (many people--myself included--have an "a ha!" moment when not thinking directly about a hard problem). And you are still being productive, moving towards the end goal. You had to make a GUI anyway at some point. Might as well be when you are stuck on the hard thing and feeling frustrated.
Getting good at breaking down problems took me many years. I credit my physics education as being particularly helpful (training thinking of problems & solutions in their extremes and always connecting solutions back to "does it make sense"). But much of the above is also learning my own psychology of how I work and what/when/how I am motivated to work and in the best position psychologically to solve a problem. I expect this isn't too different for many people, but the details can vary from person to person.
Thank you for the extensive explanation. The problem I mentioned starts rather earlier: say I have X big tasks. I need to split them (applying your described process or otherwise) into smaller tasks. BUT now I'm looking at X x2 tasks: the original X ones, each one getting another task of splitting it into smaller ones. The whole stack becomes only more overwhelming like this...
You end up with more smaller tasks.
A big part of the idea with my system is that you only identify 5 tasks at a time. Anything more then that and it becomes overwhelming. So the idea is to peel off the first 5 actionable tasks from your project(s), deal with those before thinking further about the project.
Yes this implies having a general sense of how to accomplish the project and the tasks involved, but no it does not mean you need to have a master plan with every step mapped out. Every 5 steps you get to re-assess and course correct.
Indeed; also, I must be doing something wrong, because when I start breaking tasks down to the point of triviality, I end up with a rather big pile of them, which becomes its own challenge to manage - and then two or three simple tasks in, some result invalidates most of the rest of the breakdown.
The key is to figure out what is the priority, break that down to a couple tasks you can do now and do them even before you break down anymore. That is you want to find the list of what you will do in the next few hours and get that done. Done means find a good stopping point, clean up and put the tools away. Sometimes you will ready to clean up and realize you have more time and so you break down one more task, that is fine so long as you leave things in a finished state - cleaned up and tools put away.
Ideally the project is complete and whatever isn't done will be a next phase you can do in the future. If a project must be over several days you need more planning and you need to get the whole thing done. For your daily driver car you have to complete each phase and have a drivable car at the end of each day, for a project car you can have 42 years (real number for a project car a friend of mine is working on) between starting and a drivable car - but phases are still things you complete in a few hours either way.
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.
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
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.
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.
Same approach: I call it "Ten Tiny Tasks"
Sounds interesting, could you elaborate on this please?
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:
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.
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."
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...
Recursion isn't necessarily the problem per se - it's the sheer number of tasks. When you're at the level of "open terminal to project directory", it takes less time to do it than to write it down, but more importantly, you'll end up creating a 100 of those tiny tasks, and the overhead of keeping them up to date can easily suck all your motivation (and time) dry.
It's a method of building up and keeping momentum ?
would the five tasks be a single project or across multiple?
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.
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.
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.
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).
Your interests sound similar to mine. My email is in my profile if you ever care to compare notes.
Thanks!