What if personal projects are not meant to be finished? Journey and destination and all that? Perhaps for some it's more about the endless noodling about and whittling away bits and pieces, and a "project" is just a convenient excuse do do it?
But because finishing is hard (and not fun) it’s also easy to make up reasons for why you don’t finish things, without scrutinizing the underlying motivation.
Sometimes i look back and say “I’m glad I moved on” but I think a lot of the time I also just wish the thing was done.
Exactly. I do side projects because they are fun. No pressure,
no expectations. Simply and pure knowledge gaining and programming… which I love.
I already have a boss asking me 9-5 when I will finish project X, so I don’t need that pressure when doing things by myself. Besides, some things are never meant to be finished (e.g., eating healthy, doing exercise, gaining knowledge, etc.)
> What if personal projects are not meant to be finished?
The key is deciding on 2 things before you start anything:
1. What is the goal?
2. How will I know it’s done?
With this approach you can start side projects purely to have fun for an afternoon or to learn a thing or to see how a technology or approach feels. Then you can drop it and move on. Goal achieved, thing learned, no need to keep going.
The worst projects in my experience come from unclear goals and fuzzy definitions of done. Those projects tend to drag on forever, burden your life, and fill up your days with busywork.
Note that it’s always okay to add additional goals to the same project once you’re done.
Agreed completely. Sometimes I've worked hard to put the finishing touches on side projects to make them usable by others and have been pleasantly surprised by the interest. But in most cases, even when I finish, almost no one cares.
And while finishing is an important lesson early on, just so you know how hard that "last 20%" is, it's grueling and not typically very informative or unique after that first couple times.
So I'm now squarely in the camp of do what I want and finish what I want on the side, with no guilt. If I enjoy the journey I call it good. Finishing is for the day job.
I always thought of the journey as the reward and that was very sustainable and I have picked up a diverse skillset.
I think one doesn't need to finish a project. One should be able finish milestones or reset milestones appropriately.
This matters to me personally to feel good about myself. A society favors art or progress. Depending on which effort you identify with finishing may not matter.
Without the "convenient excuse", the journey starts looking like pure procrastination; how do you enjoy it without the guilt about not doing more important work that leads to more important results?
What if it's a bit of both? Something dawned on me today when mulling on another related idea "systems vs goals", popularized by Scott Adams in "How to Fail at Almost Everything and Still Win Big"[0]. It was a widely popular book at the time, even here on HN, but the core idea never worked for me. Nor even resonated.
Quoting from the book[1]:
"A goal is a specific objective that you either achieve or don't sometime in the future. A system is something you do on a regular basis that increases your odds of happiness in the long run. If you do something every day, its a system. If you're waiting to achieve it someday in the future, it's a goal."
Boring, ain't it?
For me, the problem with project, systems, and enjoying journey over destination is that:
1) Projects don't motivate me for long; past initial excitement, I'm rarely able to muster enough motivation from the dream of finishing something (and enjoying the spoil) to move me past static friction.
2) "Journey over destination" - I mean, if I'm doing a project, I care about benefits and (my imagined) experiences given by whatever it is that I've built or completed. Journey is just a distraction at best; typically, it's a source of stress and many yaks to be shaved, most of them stinky and ugly. If anything, I get motivation from ways to shorten the journey.
3) Systems are even worse. If journey is just distracting me from the goal, systems are about putting the goal out of mind entirely, automating it away through habits, changes to environment, etc. While probably[2] effective, systems give me zero motivation - they're too arbitrary, generic.
It's a problem that, even in this formulation, I've been trying to solve for almost a decade now. Recently, I've started thinking about what actually motivates me about a project in an ongoing fashion; the insight I had today is that it's a combination of the "project" and "journey" factors:
- The base / fallback motivation is the goal - the benefit I'll get when I reach it. Often, the major one is that someone will be satisfied or impressed. Even more often, it's the relief of getting the consequences of not completing it of my mental threat board, and/or shutting up people who pester me about it. However, that alone is only able to keep the project on my mind; it's not enough to motivate sustained work.
- The immediate-term, ongoing motivation is the journey, or specifically the experience of proficiency, and all the interesting tangents I find along the way. It's a necessary condition for me to stay on the task, but I can't treat it as the main motivation itself - when I try, my mind evaluates the value of the activity as zero and pulls emergency brakes; after all, there are much easier ways to get immediate gratification, and there are more important things to do, so if I don't care about reaching the goal, what's the point of going for it in the first place?
Systems don't even enter the motivational equation here[3].
I guess what I'm trying to say here is that, in terms of motivation, the completion of a project and the journey to it are two different things entirely; treating them as alternatives is a category error.
Also my rambling here is saying that, at this moment, nothing for me has the right combination of "project" and "journey" factors - otherwise I'd be doing something else than writing HN comments.
(And yes, finishing projects completely is hard, because that last 20% of work contains the 80% of chores and annoying tangents that completely ruin the experience of the journey.)
> Without the "convenient excuse", the journey starts looking like pure procrastination; how do you enjoy it without the guilt about not doing more important work that leads to more important results?
Procrastination is how I do all my best work. The secret is to set up some boring obligation, bonus points for triviality, and then not do it until the last minute. Meanwhile, work furiously at something else.
> how do you enjoy it without the guilt about not doing more important work that leads to more important results?
This is a serious suggestion: look into therapy to help you examine what and why you think and feel. For example, seeing some things as more important than others (including one's well being) and reacting to the situation with feelings of guilt are not a given.
One way to think about it is to ask yourself, is your personal project actually _playtime_? Playing is not goal oriented and therefore very relaxing. There is nothing wrong with that! I am happy to "play" programming and I learned a lot of techniques that I used years later - and then actually finishing it. Do not deny yourself playtime!
Agree completely. Reframe recreational programming as your favorite video game, and you’ll feel much more satisfied after a session that produces nothing, because that was never the point.
Its not overwhelming clear that finishing is an important piece of a side project. Real work at your job is the place where you can prioritize finishing over other outcomes. By not forcing yourself to finish everything in your side projects you open yourself up to greater levels of exploration and learning which is, after all, the point of side projects to begin with.
I think it's all about prioritization. There are ideas that come to mind while implementing something you have in mind that are unnecessary right now by some definition (could be infamously performance- or perhaps convenience-related). If you have a list of all the subcomponents you need (or rather, want to have) I think it's healthy to first sit down and triage everything into some priority buckets and only zoom in on the absolute base functionality first for you to be able to move on to the next step on top of it for it to be able to ship. Note that this step is completely different in nature than what we have already one. After that you can go back and do the next bucket and so on and so forth.
I used to find myself under the effects of this curse as well, so I would recommend the author look into why he embarks on such a thicket of unfinished side projects. In my own case, it boiled down to a mix of several imperfectly aligned factors:
1. Genuine intellectual interest
2. A desire to improve particular skills
3. A vague sense, acquired by osmosis, that industriously working on side projects during one's free time is what a Real Engineer does
Disentangling these motives and identifying a clear primary drive behind each project clears up the "hydra" feeling wonderfully, as most of the heads simply disappear once you realize that you never had a strong reason to pursue them in the first place. (3) in particular is often merely the self-castigating whisper of the internalized "should" rather than a valid reason to embark on a long and open-ended project.
I’d like to add 4. The inertia and feel good sense of being in the flow when programming. The mind gets into a single track and wants to continue.
Fun but also exhausting.
So I stopped all that. I started learning Argentine Tango instead - lifelong project and an invitation to limitless mastery of multiple aspects of self and relationships.
F number 3. I feel we all give more than enough in our jobs.
A family of tango dancers, husband and wife, returned to the tango practica at a local tango school. It’s a garden practica and they bring the baby. Beyond adorable.
But yes, when I look at the people at a milonga, one of my thoughts is - you people clearly don’t have kids do you.
Hope you can bring some of its magic back to your life, even if it’s in small doses.
Once our kids were old enough to go to bed and stay there we started dancing by ourselves in the sitting room. Salsa rather than tango. Don't do it so much these days because the kids are now teens and once again NEVER GO TO BED, but it was fun while it lasted
this is really insightful, i am nearing ten years as SWE - i've always loved passion projects and learning outside of work. This has historically got me really far in my career. However I just started a new role as a team lead on k8s platform. I rushed out got a few NICs and started setting up a homelab to learn but havn't spent more than a few hours working on it in weeks.
for the first time in my life i'm starting to think that my hobbies outside work (and the majority of my identity) has very little to do with software.
i had never thought about how much my work was tied to my identity and it's extremely jarring.
Nearing 35 years and it started with side projects and will end with them. However, now I care more about getting high and hiking than I do about my side projects.
I actually shipped a product back in 2007 and supported it for years. Haven't shipped anything since but I am working on a scoped project that I hope to release across macOS, Windows, iOS and Android. Not looking forward to ironing out the cross-platform wrinkles as I'm so brutally lazy anymore.
do you find that the side projects are for: fun, learning, or some external pressure like the parent suggested?
what I find is that picking up a new hobby causes me a lot of mental anguish. there's a lot of very basic elementary blocks to learn. however with tech, i always have this hard skill in my back pocket that avoids those initial difficulties. if I want to learn a new language or framework, i'm not starting from scratch but a vast web of other learnings (and I slightly like the stuff so that helps.)
If your inner motivation is satisfying intellectual interest or improving skills, you actually finished the real project behind the facade without a need for finishing the official project.
So, the mistake boils down to making up a fake official project as kind of a justification for satisfying your real needs. Maybe you would feel better if you are true to yourself and say "I do this to explore and learn, I don't actually ever intend to deliver a presentable product with this activity.".
This. I felt much better once I realized it and learned to 'delete' projects. These are like sketches an artist makes to practice for the real thing, which often never comes. But it is a satisfying learning experience.
Working backwards from the end result is a good practice to see where you want to take it. And the end result is not the deliverable itself, but how, for what purpose and by whom it is used. Will you want to charge money? Do you offer it for free to anyone? Will you take feedback? Does it solve a personal problem? If you can't answer these kind of questions, then maybe it really is the journey and you never intend on finishing a product anyway, which is fine.
> I used to find myself under the effects of this curse as well, so I would recommend the author look into why he embarks on such a thicket of unfinished side projects.
The why is easy: my brain is a damn traitor!
HN, Reddit, Wikipedia and (especially) tvtropes: a single click on any one of those sites, and 3 hours of fascinated clicking later I realise that I actually haven't got any work done, but now know a lot about spidermonkeys and the Magnificent Bastard character.
Strangely enough, instragram, tiktok, youtube and other social sites have never managed to hold my attention for more than a few minutes.
> Strangely enough, instragram, tiktok, youtube and other social sites have never managed to hold my attention for more than a few minutes.
Same for me. I guess the difference is that HN, Reddit, Wikipedia, and even TV Tropes are giving you some knowledge, occasionally even useful one; every now and then you'll stumble onto something that solves an immediate problem you have, or is otherwise transformative. That's variable ratio reinforcement right there, the basis of gambling addiction, made extra potent because the occasional win you get is actually real and lasting.
Same! For me its some combination of paradox-of-choice for what to go learn about or work on next combined with variable-ratio-reinforcement compelling me to practically do a depth-first traversal of all the cool possibilities.
I think at some point I'll need to turn it all off.
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.
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).
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)
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.
Yes, I have a series of nested systems/methods that are designed to build and maintain momentum. The Ten Tiny Tasks are for overcoming inertia and eliminating the small barriers that keep you from starting. I do the tasks before I have my coffee in the morning.
Everyone else presuming you need a list to keep track of them is missing the point - spontaneous and immediate action with minimal commitment.
> 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.
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.
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.
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.
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...
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.
I recall GTD doesn't say break each task down into all the pieces.
I thought it said to define the "next action" for each task.
It makes sense to me - you really just want the next concrete action to get the task moving.
If you had to itemize every part of a project, I think that would lead to a procrastination-evoking roadblock.
If your task was "do your taxes", it would be easier to start with "get the tax form out", than "get the tax form, every other tax form, and list all your itemized deductions".. just to put "do your taxes" on your todo list.
Perfectionism is the enemy of done. It’s a good principle to keep in mind when you’re working on any project so that your valuable time isn’t wasted.
Sometimes it is fun to explore something and sometimes it’s better to never start. I have a running list of ideas i will never work on until the opportunity of time and savings align.
I’m not sure if it’s common but i heard this quote from an entrepreneur: “There’s nothing worse than a mediocre business “. A bad business will die of its own, a good one sustains itself, and a mediocre one grinds you down.
I find it’s easier for me to finish physical products, like woodworking, rather than software. I’m building a door right now for my patio, and let me tell you that it’s next to impossible to redo the design of a piece of wood once you’ve milled it down to a certain size or shaped it, so you learn to think very clearly about the goals of a project and the design before you cut anything. In my off time, I don’t want to endlessly struggle to finish things, so I don’t do software. I also do simracing, which also has bite sized goals, like “improve my safety rating to X” or “post three clean laps on a new track”. Though, no matter the hobby, you have to be able to set a small goal and achieve it pretty quick, so I’ll tell myself “just finish the tenons on these frame parts rough, then you can finish them tomorrow.”
Edit: To add, I don’t expect perfection from my wood projects. There are gaps and cracks, I use the wrong wood or don’t orient the grains properly, etc. That doesn’t matter, though, because everyone who sees my projects are amazed at my skill, partly because they don’t know where to look for the errors, but also because just finishing anything physical like a door represents a great feat that most won’t even try. It’s different for software, there’s a greater expectation for some reason, or perhaps a virtual product isn’t as tangible as a physical one.
> ... you learn to think very clearly about the goals of a project and the design before you cut anything.
Software engineers have been putting serious effort into trying to do that for the last 50+ years with mixed results - one major result being the existence of agile. Software is different to inert physical objects.
I've started doing physical things I'm my free time, like making plushies, and I can confirm that it feels a lot easier and more rewarding, because you get to the end of the steps given to you, and its done, and you have a thing you can cuddle. And sure I see all the errors I've made, but like you say, other people don't
Finishing is super important. Just focus on completing a version 0. Then, you can improve it if you feel like it. It doesn't have to be perfect, just finished under a reasonable timeframe.
Not finishing and endlessly moving from one project to another is bad because it prevents you from making meaningful progress. You end up spreading your efforts too thin and never see the results of your hard work. This can lead to a lack of closure, decreased motivation, and a cycle of unfinished projects that never reach their potential. Moreover, without finishing, you miss out on valuable feedback and the sense of accomplishment that comes from completing a project, which can be crucial for personal and professional growth.
there's probably some cost to having a bunch of unfinished projects occupy my mental bandwidth but I think there are some benefits:
- having unfinished projects gives my mind a comfortable place to go think itself out when I'm tired and need to sleep.
- each project doubles as a kind of lookout tower providing some perspective on other related projects or relevant technologies, and this keeps me interested in paying attention to new developments in non-superficial ways.
- every once in while a spark of motivation will appear for a project I haven't touched in years and it'll be something I recently learned backpropagating constructively, tightening the whole mess up a bit and helping me retain it all.
I really like the orientation of that chart. Next time I put a long time series chart in a document I'm doing time on the Y axis starting from the top.
The revised content on that topic, found in the Boss Fight book [1], is even better than the blog post. A teaser:
> I'm obsessed with finishing as a skill. Over the years, I've realized that so many of the good things that have come my way are because I was able to finish what I started.... Irrespective of how big the project was, each one I finished gave something back to me, whether it was new fans, a new benchmark for what I could accomplish, or new friends that I could work with and learn from.
I think it's worth differentiating between personal projects done to learn or just for interest, and those that are trying to accomplish something. If I do a project for myself to try things out and learn something I don't feel any pressure to finish the project. Once I've learned something or had some fun, who cares if it's "finished" or if anyone else will use it. On the other hand, sometimes I'll pick up something interesting that helps a friend or family member, or just that I need for myself, and there I'm pretty careful about scope. If I can't finish it in a couple weekends I'll look for the closest commercial solution unless it's a major once-in-a-decade passion project.
Definitely agree with this. Most of my personal projects are just to prove that something can be done. Once I know it's possible then the fun and interest is no longer there. I'm not trying to product a "finished" product or something that is polished enough for someone else to use.
I think this is an excellent point. For those projects that are needed by myself or others I prefer to look at the closest commercial solution first rather than last too see if I might spend more time than it's worth. Or to see if I might be able to sell my own solution to more than the target client (myself or others).
I’ve mastered this. I’ve finished 12+ projects in the last year. 1 even made money.
How? My projects are tiny. If you’re building solo, you have to tackle projects reasonable for a solo dev.
I primarily build chrome extensions because the simplest ones can be finished in one night, and the hardest a month or two. It’s frontend only work, so you minimise the project surface area. I’ve only been building them for a year but I finish all of them.
And I focus on getting an MVP out, and only polish if I can be bothered.
Now that I’ve mastered the finish, I’m moving on to different projects:
- API only projects
- Scripts
- NextJS projects (simple backend)
- static pages
That's sound advice, but not foolproof, because of two things:
(1) what seems, at first, to be a tiny project can turn out to be a big project.
(2) with the right mindset, what seems at first to be a large project can turn into a tiny project.
And the confusing thing, when trying to reason about this and work more effectively, is that it isn't completely clear to what extent (1) and (2) aren't the same thing.
I tried monetising one extension but no one liked it lol, the extension was shite! But I sold one of my popular extensions (hundreds of thousands of users)
Interestingly, I’ve learned more from learning to let go from this idea of finishing a useless idea. A “project” doesn’t inherently mean “useful”. Sometimes I’m just dillying around on something useless and eventually I recognize it as such and cancel it.
It’s better to just not do things than to do something unnecessary really well.
Somehow, I feel like if a project hasn't become incredibly boring to work on, then it's not even close to finished.
The hardest part is finishing a project pre-revenue. There's just little motivation to do it because, at that point, it's too boring to be about the 'journey' anymore; it becomes all about money... Yet you don't know if the project will be able to generate revenue so it's about 'hypothetical money'. As someone who has a huge number of failed projects under their belt, for me it feels like working for 'magic unicorn money'. I rely 100% on the enthusiasm/delusion of my non-technical co-founder to keep me going. In my mind, it's not going to make it... Though I like the fact that my current project is in a niche that I would never have chosen on my own because it's so damn boring (it's in HR search/recruitment sector *vomits*). I was literally optimizing for boringness.
I wish I could come up with one of these startups which can be monetized straight away, no free tier, no complex sales funnel but I think these opportunities are very limited and highly competitive.
From Drake’s Prayer: “…grant us also to know that it is not the beginning, but the continuing of the same unto the end, until it be thoroughly finished, which yieldeth the true glory”
169 comments
[ 3.1 ms ] story [ 325 ms ] threadSometimes i look back and say “I’m glad I moved on” but I think a lot of the time I also just wish the thing was done.
I already have a boss asking me 9-5 when I will finish project X, so I don’t need that pressure when doing things by myself. Besides, some things are never meant to be finished (e.g., eating healthy, doing exercise, gaining knowledge, etc.)
The key is deciding on 2 things before you start anything:
With this approach you can start side projects purely to have fun for an afternoon or to learn a thing or to see how a technology or approach feels. Then you can drop it and move on. Goal achieved, thing learned, no need to keep going.The worst projects in my experience come from unclear goals and fuzzy definitions of done. Those projects tend to drag on forever, burden your life, and fill up your days with busywork.
Note that it’s always okay to add additional goals to the same project once you’re done.
And while finishing is an important lesson early on, just so you know how hard that "last 20%" is, it's grueling and not typically very informative or unique after that first couple times.
So I'm now squarely in the camp of do what I want and finish what I want on the side, with no guilt. If I enjoy the journey I call it good. Finishing is for the day job.
I think one doesn't need to finish a project. One should be able finish milestones or reset milestones appropriately.
This matters to me personally to feel good about myself. A society favors art or progress. Depending on which effort you identify with finishing may not matter.
What if it's a bit of both? Something dawned on me today when mulling on another related idea "systems vs goals", popularized by Scott Adams in "How to Fail at Almost Everything and Still Win Big"[0]. It was a widely popular book at the time, even here on HN, but the core idea never worked for me. Nor even resonated.
Quoting from the book[1]:
"A goal is a specific objective that you either achieve or don't sometime in the future. A system is something you do on a regular basis that increases your odds of happiness in the long run. If you do something every day, its a system. If you're waiting to achieve it someday in the future, it's a goal."
Boring, ain't it?
For me, the problem with project, systems, and enjoying journey over destination is that:
1) Projects don't motivate me for long; past initial excitement, I'm rarely able to muster enough motivation from the dream of finishing something (and enjoying the spoil) to move me past static friction.
2) "Journey over destination" - I mean, if I'm doing a project, I care about benefits and (my imagined) experiences given by whatever it is that I've built or completed. Journey is just a distraction at best; typically, it's a source of stress and many yaks to be shaved, most of them stinky and ugly. If anything, I get motivation from ways to shorten the journey.
3) Systems are even worse. If journey is just distracting me from the goal, systems are about putting the goal out of mind entirely, automating it away through habits, changes to environment, etc. While probably[2] effective, systems give me zero motivation - they're too arbitrary, generic.
It's a problem that, even in this formulation, I've been trying to solve for almost a decade now. Recently, I've started thinking about what actually motivates me about a project in an ongoing fashion; the insight I had today is that it's a combination of the "project" and "journey" factors:
- The base / fallback motivation is the goal - the benefit I'll get when I reach it. Often, the major one is that someone will be satisfied or impressed. Even more often, it's the relief of getting the consequences of not completing it of my mental threat board, and/or shutting up people who pester me about it. However, that alone is only able to keep the project on my mind; it's not enough to motivate sustained work.
- The immediate-term, ongoing motivation is the journey, or specifically the experience of proficiency, and all the interesting tangents I find along the way. It's a necessary condition for me to stay on the task, but I can't treat it as the main motivation itself - when I try, my mind evaluates the value of the activity as zero and pulls emergency brakes; after all, there are much easier ways to get immediate gratification, and there are more important things to do, so if I don't care about reaching the goal, what's the point of going for it in the first place?
Systems don't even enter the motivational equation here[3].
I guess what I'm trying to say here is that, in terms of motivation, the completion of a project and the journey to it are two different things entirely; treating them as alternatives is a category error.
Also my rambling here is saying that, at this moment, nothing for me has the right combination of "project" and "journey" factors - otherwise I'd be doing something else than writing HN comments.
(And yes, finishing projects completely is hard, because that last 20% of work contains the 80% of chores and annoying tangents that completely ruin the experience of the journey.)
--
- [0] - sevensor ↗ > Without the "convenient excuse", the journey starts looking like pure procrastination; how do you enjoy it without the guilt about not doing more important work that leads to more important results? pickledoyster ↗ > how do you enjoy it without the guilt about not doing more important work that leads to more important results?
Procrastination is how I do all my best work. The secret is to set up some boring obligation, bonus points for triviality, and then not do it until the last minute. Meanwhile, work furiously at something else.
This is a serious suggestion: look into therapy to help you examine what and why you think and feel. For example, seeing some things as more important than others (including one's well being) and reacting to the situation with feelings of guilt are not a given.
1. Genuine intellectual interest
2. A desire to improve particular skills
3. A vague sense, acquired by osmosis, that industriously working on side projects during one's free time is what a Real Engineer does
Disentangling these motives and identifying a clear primary drive behind each project clears up the "hydra" feeling wonderfully, as most of the heads simply disappear once you realize that you never had a strong reason to pursue them in the first place. (3) in particular is often merely the self-castigating whisper of the internalized "should" rather than a valid reason to embark on a long and open-ended project.
Fun but also exhausting.
So I stopped all that. I started learning Argentine Tango instead - lifelong project and an invitation to limitless mastery of multiple aspects of self and relationships.
F number 3. I feel we all give more than enough in our jobs.
But yes, when I look at the people at a milonga, one of my thoughts is - you people clearly don’t have kids do you.
Hope you can bring some of its magic back to your life, even if it’s in small doses.
for the first time in my life i'm starting to think that my hobbies outside work (and the majority of my identity) has very little to do with software.
i had never thought about how much my work was tied to my identity and it's extremely jarring.
I actually shipped a product back in 2007 and supported it for years. Haven't shipped anything since but I am working on a scoped project that I hope to release across macOS, Windows, iOS and Android. Not looking forward to ironing out the cross-platform wrinkles as I'm so brutally lazy anymore.
what I find is that picking up a new hobby causes me a lot of mental anguish. there's a lot of very basic elementary blocks to learn. however with tech, i always have this hard skill in my back pocket that avoids those initial difficulties. if I want to learn a new language or framework, i'm not starting from scratch but a vast web of other learnings (and I slightly like the stuff so that helps.)
So, the mistake boils down to making up a fake official project as kind of a justification for satisfying your real needs. Maybe you would feel better if you are true to yourself and say "I do this to explore and learn, I don't actually ever intend to deliver a presentable product with this activity.".
Working backwards from the end result is a good practice to see where you want to take it. And the end result is not the deliverable itself, but how, for what purpose and by whom it is used. Will you want to charge money? Do you offer it for free to anyone? Will you take feedback? Does it solve a personal problem? If you can't answer these kind of questions, then maybe it really is the journey and you never intend on finishing a product anyway, which is fine.
The why is easy: my brain is a damn traitor!
HN, Reddit, Wikipedia and (especially) tvtropes: a single click on any one of those sites, and 3 hours of fascinated clicking later I realise that I actually haven't got any work done, but now know a lot about spidermonkeys and the Magnificent Bastard character.
Strangely enough, instragram, tiktok, youtube and other social sites have never managed to hold my attention for more than a few minutes.
Same for me. I guess the difference is that HN, Reddit, Wikipedia, and even TV Tropes are giving you some knowledge, occasionally even useful one; every now and then you'll stumble onto something that solves an immediate problem you have, or is otherwise transformative. That's variable ratio reinforcement right there, the basis of gambling addiction, made extra potent because the occasional win you get is actually real and lasting.
I think at some point I'll need to turn it all off.
It takes months of full time effort to built something that resembles a working application.
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.
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.
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).
Everyone else presuming you need a list to keep track of them is missing the point - spontaneous and immediate action with minimal commitment.
It really is liberating.
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
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 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.
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.
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.
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.
I thought it said to define the "next action" for each task.
It makes sense to me - you really just want the next concrete action to get the task moving.
If you had to itemize every part of a project, I think that would lead to a procrastination-evoking roadblock.
If your task was "do your taxes", it would be easier to start with "get the tax form out", than "get the tax form, every other tax form, and list all your itemized deductions".. just to put "do your taxes" on your todo list.
Sometimes it is fun to explore something and sometimes it’s better to never start. I have a running list of ideas i will never work on until the opportunity of time and savings align.
I’m not sure if it’s common but i heard this quote from an entrepreneur: “There’s nothing worse than a mediocre business “. A bad business will die of its own, a good one sustains itself, and a mediocre one grinds you down.
Edit: To add, I don’t expect perfection from my wood projects. There are gaps and cracks, I use the wrong wood or don’t orient the grains properly, etc. That doesn’t matter, though, because everyone who sees my projects are amazed at my skill, partly because they don’t know where to look for the errors, but also because just finishing anything physical like a door represents a great feat that most won’t even try. It’s different for software, there’s a greater expectation for some reason, or perhaps a virtual product isn’t as tangible as a physical one.
Software engineers have been putting serious effort into trying to do that for the last 50+ years with mixed results - one major result being the existence of agile. Software is different to inert physical objects.
Not finishing and endlessly moving from one project to another is bad because it prevents you from making meaningful progress. You end up spreading your efforts too thin and never see the results of your hard work. This can lead to a lack of closure, decreased motivation, and a cycle of unfinished projects that never reach their potential. Moreover, without finishing, you miss out on valuable feedback and the sense of accomplishment that comes from completing a project, which can be crucial for personal and professional growth.
Why?
> You end up spreading your efforts too thin and never see the results of your hard work.
What if the result of my hard work is the lessons I have learned along the way? Or the skills I picked up? Or the time spent entertained?
Is anyone aware whether Randall Munroe "invented" this style of graphic or if it was pre-existing?
> I'm obsessed with finishing as a skill. Over the years, I've realized that so many of the good things that have come my way are because I was able to finish what I started.... Irrespective of how big the project was, each one I finished gave something back to me, whether it was new fans, a new benchmark for what I could accomplish, or new friends that I could work with and learn from.
[1] https://bossfightbooks.com/products/spelunky-by-derek-yu
How? My projects are tiny. If you’re building solo, you have to tackle projects reasonable for a solo dev.
I primarily build chrome extensions because the simplest ones can be finished in one night, and the hardest a month or two. It’s frontend only work, so you minimise the project surface area. I’ve only been building them for a year but I finish all of them.
And I focus on getting an MVP out, and only polish if I can be bothered.
Now that I’ve mastered the finish, I’m moving on to different projects:
- API only projects - Scripts - NextJS projects (simple backend) - static pages
(1) what seems, at first, to be a tiny project can turn out to be a big project.
(2) with the right mindset, what seems at first to be a large project can turn into a tiny project.
And the confusing thing, when trying to reason about this and work more effectively, is that it isn't completely clear to what extent (1) and (2) aren't the same thing.
2) I’m yet to run into this
- Ad blocker/s
- Site CSS overrides
- Salary revealer for job sites
- API blocker
- Extended devtools
- AI powered UI design feedback tool [0]
… and many more
[0] - https://chromewebstore.google.com/detail/ui-copilot/hgaldpfd...
It’s better to just not do things than to do something unnecessary really well.
The hardest part is finishing a project pre-revenue. There's just little motivation to do it because, at that point, it's too boring to be about the 'journey' anymore; it becomes all about money... Yet you don't know if the project will be able to generate revenue so it's about 'hypothetical money'. As someone who has a huge number of failed projects under their belt, for me it feels like working for 'magic unicorn money'. I rely 100% on the enthusiasm/delusion of my non-technical co-founder to keep me going. In my mind, it's not going to make it... Though I like the fact that my current project is in a niche that I would never have chosen on my own because it's so damn boring (it's in HR search/recruitment sector *vomits*). I was literally optimizing for boringness.
I wish I could come up with one of these startups which can be monetized straight away, no free tier, no complex sales funnel but I think these opportunities are very limited and highly competitive.