The Art of Finishing | Hacker News Reader

The Art of Finishing

bytedrum.com

711 pointsemmorts165 comments

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.

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!

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:

    - 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.

It's a method of building up and keeping momentum ?

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.

I think you and I are on the same page, the point of a limited list of tasks is... to have a limited list of tasks. : )

It really is liberating.

> 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

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

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...

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.

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.

Simply evaluate the breakdown lazily, although you are free to yield extra sub-tasks if it turns out to be cheap.

Or, you could stop beating yourself up about it and reframe the whole activity as a creative release. Nobody else cares if you finish it, why should you? My neighbor died with a project car parked in his driveway. It had been there for years. Every so often he got out there and worked on it with his grandson. Who among us would call that time wasted? Why not dust off Project Foo on a Saturday afternoon, and just tinker with the fun parts?

<< Who among us would call that time wasted?

I will admit that the longer I live, the more I realize this is one of the few things that actually matter.

<< Why not dust off Project Foo on a Saturday afternoon, and just tinker with the fun parts?

I think it is a good way to avoid burnout. I don't know if it is the same for everyone, but if something like that is planned for me, I get kinda bored fast and 9/10 abandon the project. When I am really into it, the plan doesn't matter, because it mostly just flows. I am trying to trick myself into the state of flow, but maybe I am simply trying too hard.

Yeah, setting deadlines for a hobby is how I used to kill any joy I'd get from the hobby.

That's a good way of framing the project. Especially if what the article author says is true: which is that most of the energy comes from brainstorming and fantasizing about what the project could be.

The flip side is that you have to really buy into the activity as creative release -- and be OK not finishing when you start. For some people, their subconscious gets excited during the brainstorming phase most when they have a justified knowledge that they will likely finish the project. If these people start a project knowing they won't finish, it can take a lot away from the excitment of doing a project.

The article's author probably falls into the latter camp.

> Or, you could stop beating yourself up about it and reframe the whole activity as a creative release.

I think for some people this isn't better. If I feel like I'm not being productive in some capacity, I get depressed. It would happen frequently to me over the summers between school semesters, and it happens to me now by the end of a 1-week vacation. It might sound like a burnout path, but that's not what has historically lead me (personally) to burning out and I've been at this for like 10 years.

When I'm setting deadlines for myself, working fast to ship, making compromises due to time constraints I get depressed.

When I'm working on a project for years and it has not yet shipped, I get depressed.

Personally, I think the problem is not with each strategy, but with the context - time is money and money is time and I have pretty much none to spare.

Yeah, context is definitely important. I also tend to work on projects that I personally find useful instead of trying to build products for other people, which probably plays heavily into it.

I like endless projects. Building something the way I want to build it is fun. Why would I ever want that to stop?

I release updates to my various endless open source projects (such as https://www.farmhand.life/ and https://chitchatter.im/) regularly to the public. They are "complete" in the sense that they are fully-formed enough to be worth playing/using. But they're not complete. They will never be complete. I don't want them to be complete. I want to build them for the rest of my life, because building them is what I love to do.

In this context, I would say *finishing things* is the actual creative release. The "not finishing" is getting in the way of it.

(also, I highly doubtful that this is the author's one creative release, and and even more doubt he's coding up a project with his hypothetical grandson)

Exactly. Unless you do it to earn money who gives a damn if you have a hundred draft projects?

Who except yourself that is.

Never finishing anything sucks, as it gives you the feeling that you.. well.. can't finish anything.

My tip is to embrace the fact that a big part of what we start does not need to be finished. I sometimes code a way just for the joy of doing it, that is okay. Not only is it okay, it is also necessary to try out things and play around. Playing is a very good way to learn. And if you give yourself that slack for some projects it is easier to go all strick and I need this done on others.

Other than that you need to ask yourself what blocks you from finishing things. E.g. a wise old audio mixing engineer once told me: a mix is never finished, you can always go back and optimize things, forever. Ultimately you need to say it is finished for it to be finished.

Software can be similar. Many junior programmers will adjust the scope of their software as they build it and wonder that it never goes anywhere. my tip is to select a problem you profit from being solved. Make a realistic scope what the goal is and do it, so you can go back to your fun project. Boom you just got a thing done.

I agree with the conclusion, but using what other people care about as a standard for what you ought to care about is a path that leads straight to despair.

I meant that the obligation to finish is not externally imposed, so you don’t have to pursue completion out of a sense of duty. But I can see how you could read it the way you did, and it’s a fair point.

Ah, I see. Got it.

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.

God I miss tango. 2 kids put our 2 years of lessons to a screeching halt.

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 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 suffer the same problem. It is all about conserving mental energy. The way I see it, each person has 2 different mental power gears. A high power one, that drains you and makes you excited at same time. You need this for planning and thinking big or learning about a new tool. And a Low power gear that allows you to fix bugs and create a small feature for a known tool. We mostly use this low power gear in our daily life, in meetings, while driving or preparing coffee. The high power gear is used sparingly, when we can't sleep at night because of an idea, when we try to learn something new. it is exciting, but draining and painful at the same time. We want to do it again only after forgetting the pain.

I think proscratination is because we use a high power gear too frequently, we are exhausted mentally, and it is too painful. so we say let's do it later. But what if you have a small task that does not need a lot of thinking to do? something not painful? Well this is easy. I can do it. The trick is, it needs to be easy. you should not waste 1 hour to set up your environment to be able to start. it has to be easy.

So to advance on a project, I need to make sure I always have low energy, easy tasks ready for me when i am not in my mental capacity to use my high power thinking.

It is as if I am 2 persons. a developer and an intern. you need to make sure there is enough easy tasks for the intern to work on. You have to accept this about youreself

Dont waste days planning and creating issues for youreself. This is too draining. you need to write the big plan only and make sure you have few tasks ready. not all of them defined from day 0. do a big planning every 2 to 3 weeks (looks similar to a sprint)

It is all about conserving your mental energy

I really like this take! I've been doing software professionally for over thirty years, and really relate to all of the discussions here and the root post. I typically beat myself up about "why is this task taking me so long?! it should be easy by now!", etc. But it's likely because I typically take the "focus on the next hardest problem first, otherwise I'll only have all the hard problems to solve at the end" route, and have to use the high-power gear all the time.

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.

Sometimes one needs to reset the goals and failure suddenly looks like a success.

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.)

- [0] - https://en.wikipedia.org/wiki/How_to_Fail_at_Almost_Everythi...

- [1] - Via https://www.goodreads.com/quotes/973029-a-goal-is-a-specific...

- [2] - Hard to tell, I'm clinically unable to hold a simplest habit to save my life. Forget "it takes 30 days to ingrain a habit" - even after months or years of doing something "habitually", a smallest disturbance to the daily life is enough to undo all that work and get me back to square one.

- [4] - Exception: when I can reframe setting up a system as a kind of a project. Even then, it just makes it easier to build a system; it doesn't help maintaining it over time, which is the whole point of systems in the first place.

> 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.

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.

> Finishing is super important.

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?

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.

1) this is true, I’ve run into this!

2) I’m yet to run into this

What kind of Chrome extensions? Genuinely curious – it would never occur to me to build one.

I’ve built all the following:

- 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...

Monetized much?

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)

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.

That’s the whole point I was trying to make, of course. Physical objects are easier to complete. Software never becomes complete, in many cases.

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

Those strategies for finishing projects are exactly why I’ve been running a six-week group[0] where we all work on our projects together.

Setting goals, time-boxing, accountability, celebrations — it’s all built in.

I’ve definitely found that during the 6 weeks that I find a laser focus on what I want to do and how I want to do it.

It adds a fence to the green field project, so to speak.

Highly recommend building alongside others, if you haven’t tried it yet.

[0] https://lmt2.com

Great description of the problem. I enjoyed reading it, it’s almost like prose, great writing.

The solution I’m afraid is only one: solve smaller problems. There is no way a single person can solve a team’s problem as a side project. A small problem does not mean small codebase. It means small as in: focused, simple pain, simple solution, low amount of open questions.

Yes there is value to all of the other strategies mentioned. But if you want the root cause and the solution for this hydra effect it is the one I mentioned.

If you were born anywhere in the 80s, you might have spent the 90s and early 00s building side projects that you actually finished and felt no remorse over. That’s because scope was naturally small, problems were more focused, and there were multiple order of magnitude less options to choose from (in any domain: programming languages, libraries, interfaces, user flows, business workflows — everything was less)

> and there were multiple order of magnitude less options to choose from

So true. I remember downloading a bunch of stuff to do some Perl development on Windows 98. About 3MB of files IIRC that took forever to download on my dialup connection. Yet, it was so much easier to focus, basically because there weren't many other options and the .chm files that accompanied the interpreter could keep me busy for hours during the week.

Sometimes I try to reproduce that environment by limiting my own options in terms of technologies and learning resources. Probably not the most efficient way to get stuff done, but I find it more sustainable long-term.

A phrase that has stuck with me over the years is:

  A man is measured by the things he finishes, not by the things he starts.

Since taking that to heart, I've never really had a problem with finishing things. :)

Similar to "The Cult of Done Manifesto" (2009) https://designmanifestos.org/bre-pettis-and-kio-stark-2009-t...

Just not enough time in the day. Some open projects of mine that keep me up at night are below. There's probably more but these come to mind. Somewhere between working the day job, spending time with my family, and making sure I take care of my health and stress levels through excercise: I will make incremental progress.

1. rebuild IBM Model-M Keyboard after kids spilled water on it (open for 2 years now)

2. complete floating shelves in office (open since March - 95% done - slowwww)

3. build temperature sensor network for my house using ESPHome firmware and Home Assistant. Hardware purchased.

4. repurpose old 3d printer servo motors to automate etch-a-sketch (popular project out there). Software part started.

5. split-flap display: make my own. research on CAD models for 3d-printing completed.

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.

My current project is a monster. It’s been running hot and cold for at least several years.

Progress is being made, but now and again I face something particularly difficult, I can get waylaid.

Right now I’m in such an impasse. I was moving along, making some good progress, when I turned a corner and went “oh no”. It’s like hiking a trail and you turn a sharp curve and see it gets really steep. “Ugh”

That whooshing sound is the wind falling out of the sails. Right now I’m in a dead calm.

But that’s ok. I have several, large subassemblies at the 85% mark, and others to work on that will slot into this thing.

I have “shipped” one project. Docs, releases, installers, whole thing. Getting that polished was 2-3 months. (Calendar, these are not full time projects.)

Finishing was important because I am not a finisher. I like to say I’m a framer and drywaller. Someone else needs to come in to mud, sand, paint, and trim. I’ve never worked well at that level of detail. It’s another reason I’m not very good with GUIs. Lots of detail. But, these are GUI projects.

But also, I shipped my “1.0”. I do not consider it an MVP. No, it’s done. I have no real plans to go back to it.

If I were to ship an MVP, that’s just an excuse (for me) to not finish it. And I did not want to leave a lingering carcass. My drive is already filled with those.

So I continue to push my boulder in silence. Maybe I can release this thing next year. Waiting for the breeze to come up again.

I completely agree, finishing matters, and this reminds of a joke where I said to

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.

Not going to lie, I read the title as the Art of Fishing... and spent the entire article waiting for the finale where some how this was an analogy with fishing...

came for the fish, stayed for the all-too-familiar feeling of incomplete projects.

I use the reward system with a slight twist:

I'm not allowed to start a new project until I complete my current one.

Since I have a huge backlog of ideas, my "reward" for finishing a project is that I get to work on the next most exciting idea. Yay!

This forces me to keep the scopes small.

I'm allowed to rescope my current project to something smaller/imperfect after I've started (for example if I discover that my initial vision is going to take too long), but I still have to finish it before I'm allowed to start the next one.

I used to have the same issue then started running and changed my approach. Now:

1.) When you run, you’re only finished training when your body gives out, you die or give up the sport. In software, a product is never really finished; a version is. Therefore if I forget something or mess something up, I already know what tasks to work on for the next version. Forgetting something is bad but it makes planning easier. If finality is scary, turn it into a yield sign.

2.) If you want to run well at a distance, you have to specialize in that distance. If you train for Leadville and the 100m dash simultaneously, you won’t perform as well at either. In software, I work on one version of one product at a time. If I have to choose which one to work on when I sit down, I have already failed.

3.) I’m a human so for me, running is all about pace. Anyone can complete any race if they find and keep their pace. Software is the same. So find your pace and learn how to keep it. When I’m trying to find my pace for a race, I run that pace six days a week regardless of my distance - on shorter days, I’ll add in gliders at the end so I get the workout. With software, I have to keep the same kind of consistency or it takes me too long to get back where I was to ever finish anything.

4.) If you want to run fast so you can see the stars backs for a few moments, you have to treat every single training session just like the race. If you want to run fast enough to be one of the stars, it has to be your whole life. With software, everything even silly side projects gets the same name - product - and I follow the same methods. Practice is always good but deliberate, competitive practice is better.

I like to ship stuff. I actually get pleasure from releasing stuff into the wild.

Shipping, is, by definition, "finishing." Lots of boring stuff involved.

Most of my R&D and learning is geared towards shipping projects.

I will "let stuff go," if I find I'm in a rabbithole. Learning when to do this, is important. I just let go of some ML stuff for Apple systems, mainly because I can't really apply it [yet] to the types of apps that I'll ship. It wasn't a total loss, though, because I learned that I really need to use Intents for what I want.

So, right now, I am learning Intents development for Apple systems. It's a pain, because the documentation is really haphazard, but I'm muddling through.

I'll start by adding them to a released app that I tend to use as my "pointman" for new stuff, then, I'll add it to some of my other shipping apps. While I'm doing this, I'll become "conversational" in the tech. That's how I always learn this stuff. Maybe I'll write something up on it (like I did for Universal Links[0]).

[0] https://littlegreenviper.com/series/universal-links/

I have this with learning piano pieces. The most interesting learning and development occur in the first stages of learning a piece. But "finishing" it takes a lot more time and can feel like drudgery - but if I don't push through it on at least some of my pieces then I'll never have anything that's really performable.

I have spent the last few weeks getting totally detailed to the point of losing all focus. For me it has been missing functionality in a framework. Apparently, they never anticipated .NET MAUI using SVG images for icons. They convert the SVG to PNG for you automatically, and make it easy to display but I need to alter the stroke color with theme bindings. Easy and convenient in WPF. Shit show in MAUI.

My biggest impediments to finishing in recent years has been setting too big of a scope for "done" and running into hundreds of yaks that need shaving off from some buggy-ass framework or library (literally all of them). Rarely anything is as advertised and it has major impacts on delivery.

The only frameworks that let me get shit done without six ways of hell was WPF and Swing.

There's a really important distinction that should be made between personal "fun" projects and professional "work" projects.

Yes, you should definitely learn what's involved in finishing a work project and how difficult this actually is. The old I'm 80% through and I just need to finish off the last 80% is something that can only be learned by experience.

But honestly, why ruin your fun projects by turning them into work.

    In professional settings, being known as someone who starts things but doesn’t finish them can be detrimental to your career.

I would also take issue with this. It may hurt your career, but it may also be your career. Being someone who can break new ground and start a project from nothing can be incredibly valuable and is often a very different skill from putting something into production.

>There's a really important distinction that should be made between personal "fun" projects and professional "work" projects.

I can't support this enough. And it took me years to realize this (again). I often had the same struggles as the blog post states. With my master thesis (and just out of pure curiosity) I built a risc-v CPU as a proof-of-concept (to show that my DDR- and Cache-Controller inteded for a ARMv4 core is somehow portable to a different CPU). Somehow I kept working on it every now and then, because i wanted to make it "perfect" (64 bit, FPU, linux, you name it). That ended in much frustration and it still hasn't evolved.

But then suddenly I got reminded that in august this year was a sports event that friends of us arrange. For years I wanted to build a kind-of big display which shows the score and remaining time and is visible outside (from like 10m). My perfectionism always ruined. But this time I was determined to do it and get it done. My RISC-V CPU on an FPGA was the perfect fit for this. So I built a co-processor which drives these common RGB LED matrices and shows time and score. The timing itself and a remote where realized with arduino.

The code looks utter garbage, it barely works, but I had fun and my friends loved it. And most importantly: I "finished" it, as in it worked. I had to force myself really hard to do it. But I enjoyed it and it's fine that it ain't perfect. I also learned a bunch. Now I am determined to improve it for next year and I don't even think about different projects atm.

Edit: it was so imperfect, that you couldn't really take pictures of it, because something is wrong with the refresh rate (it looked fine for the human eye): https://litter.catbox.moe/193vp5.jpg

> But honestly, why ruin your fun projects by turning them into work.

Agreed! For fun, it is completely fine to not finish things if you enjoy the process more than the actual result. You achieved your goal of having fun and likely still learned a lot from it. Of course if it bothers you then sure, improve on your ability to close things, but first evaluate if this truly an issue coming internally from yourself, or some imagined external pressure that your work is worthless if you don't finish it (in the hobby context). Is it important to show it to others for example, or is this a solitary activity purely for yourself? In some hobbies I strive to finish, because I want to show it to others, in others, I don't care at all.

The description and feelings resonate, but I've realized a huge drag on my personal projects is the accumulated accidental* complexity due to tools and dependencies. If it's been a few weeks since you were last able to code, then not only have you lost a lot of context in your working memory, but your tools and dependencies will have marched on, and what seems like a harmless update will often result in hours untangling a bug with Someone Else's Code.

Fixing Someone Else's Code is not the point of such endeavors. Reduce tooling and dependency complexity to the bare minimum, even if it means adopting a bit of NIH mindset.

*as used by Fred Brooks in _No Silver Bullet_, https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html

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.

Finishing is a construct, an escape. No project is ever done. There are always improvements to be made, bugs to be squashed. "Finished" is just a label we put on a place on the timeline, a point after which someone is morally allowed to jump ship.

Example: I'm in the middle of moving jobs (military to other military). I was given a couple weeks to train my replacement, an impossible task. My boss just asked me if I had "finished" training him. Um ... well .. I am leaving. So whatever training we are doing is certainly over. That is what "finished" actually is. Is the job finished? Certainly not. But my time as a contributor has come to an end and so I am finished with the task and am jumping ship.

I think the issue, in the author's case, is that they don't have any projects they truly and completely believe in. The part where they sit down and browse through their archive of unfinished projects is telling. To really get one across the finish line you have to wake up thinking about it and have the completed vision of it burning a hole in your brain and that's what keeps you pushing through all the yak shaving and CSS refactors day after day.

Which is to say, I believe the "productivity porn" angle - setting up certain processes/systems - is a red herring. Inspiration is the driving force.

This seems correct, and I suffer from the same issue as the author, but I'm curious if it's as simple as "you don't believe in the projects". Does Pieter Levels believe in all of his projects so much that they burn a hole in his brain, or does he just think "this seems like a good idea, I should do it and see if it works" and that's enough to get him to the finish line. I assume the latter, but it's just a guess.

I'm not familiar with his work but from a quick search it seems that he's a hustler and is very "eye on the prize." I would think that your characterization of his process is too blasé and that there's actually more conviction behind it, but of course I don't know either. Most of the time I would say that prolific people that seemingly casually whip things up have learned to affect that and there's usually a great deal of obsessiveness happening behind the scenes.

Also, I don't much like the framing of "you don't believe in the projects." It's not meant to be a fault of the person, and I'm sure Pieter and others have graveyards of half-baked projects (which may even be revived one day) - it's part of the process - but I just mean to say that you haven't yet hit on the idea that keeps you up at night (or some nights at least) until it's been realized.

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 very strongly relate to this, it's been close to 3 months, since I have started working on a blog built on Quarto, and all I have so far is a elaborate design and a half complete blog on an LLM tool I had built.

But like the comments say, I had way too much fun on the journey of a side project, just doing other things like configuring the website and playing around with the design elements like font and how the overall website looks (I'm a data scientist and never usually get to play with design as much as I want to at work). And recently, with claude's help built some cool react elements to push my story further.

Hopefully after this, I ship at least one blog and iterate on the design elements.

Now add neurodivergent executive function disorders -- easily accessible fun things being available prevents bigger picture fun things from starting. I've spent years trying to address this, but haven't found anything that consistently works.

Drives me up the wall.

If it's not a project that others rely on, you should feel free to do it anytime or spawn new projects. To finish it or not doesn't matter much, enjoy the journey and learn from the experience is a value in itself.

There're different currencies driving software development. Your work project is driven by money. Your side project is driven by passion. To push your personal projects to completion, nurture your passion, whatever your passion is.

Projects I've finished are usually always projects I want more than I want to make them.

For example, I made a notes web app that syncs to S3, has full text search, has a "daily note" button that auto creates a note for the day, etc. This app was not the most fun and exciting app to make, but I made it anyway because I wanted it to exist.

There comes a point in projects where you're in the middle of it and you want to switch and do something else. But if you constantly find the desire for the thing you're making, invariably you'll finish. And it gets more fun after the trough of boredom.

Obsidian.md

I think every project passes a threshold after which the time invested will only be considered worthwhile if you ship it.

Before this threshold, you're learning new technologies, trying new techniques, and generally developing skills that could be applicable elsewhere. After this threshold, you're becoming an expert in the project itself, which will all be for naught if you don't finish it.

So my advice would be give up on projects that are near that threshold, and only continue beyond if you intend to finish it.

It's easier to finish if your goal is to make money - then you are forced to make your customers happy and finish things.

If the rewards are nebulous, then so will the motivation to complete anything.

I decided a while ago that my personal project must either be released as Open Source or commercial software. That keeps me honest, because releasing software as Open Sources exposes it to others so I try to make those projects as good as I can make them and releasing commercial software incentivises me to make it cost me less in support cost. That approach has helped me cull the number of unfinished projects.

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.

One famous example worth checking out is this: https://xkcd.com/1732/

Is anyone aware whether Randall Munroe "invented" this style of graphic or if it was pre-existing?

Always have to keep project scope at bay. We dont have infinite time nor energy, so there's only so much we can do at any one time.

Make the goal at the start and ruthlessly discard (note somewhere else) any additional ideas. I find myself giving up projects after coming up with brilliant extensions to the project. When I look at it, it's way too big and immediately demotivating.

i'm reminded by this chapter of the tao te ching:

When people see some things as beautiful,

other things become ugly.

When people see some things as good,

other things become bad.

Being and non-being create each other.

Difficult and easy support each other.

Long and short define each other.

High and low depend on each other.

Before and after follow each other.

Therefore the Master

acts without doing anything

and teaches without saying anything.

Things arise and she lets them come;

things disappear and she lets them go.

She has but doesn't possess,

acts but doesn't expect.

When her work is done, she forgets it.

That is why it lasts forever.

The problem is, writing software is REALLY time consuming.

It takes months of full time effort to built something that resembles a working application.

Finishing things (esp. personal projects) feels really good. Leaving them unfinished starts to feel really bothersome. I think the author describes a lot of this really eloquently (while I would also note the irony of writing a meta blog post about this topic during the time when you could have been finishing something).

I have 3 categories of projects:

1. Bigger than I thought 2. Dumber than I thought 3. Too small to really be proud of

My favorite blog post on tips for finishing is this classic by Derek Yu (of Spelunky fame): https://makegames.tumblr.com/post/1136623767/finishing-a-gam....

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.

[1] https://bossfightbooks.com/products/spelunky-by-derek-yu

I'm surprised how software can be a real fight with no end in sight, and then boom, it's suddenly "done". By "done" I guess I mean "useful" as it's never done done.

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”

the keyword here is at the end of the article: alarming amount of coffee. There is something neurochemical in highly creative people that needs to be counterbalanced artificially.

ya maybe you have a point here. i did a lot of work on modafinil back in the day.

Something I've found while having ADHD is that caffeine has a very different effect than on more NT people, where it makes me more sleepy. Something about it changing brain chemical levels that for an NT person pushes them into an "alert" state, but for people with ADHD, it can push them towards a more "normal" state

instead of finishing my side project, i am reading this post

Congrats to the author for finishing their article!

Frontend work is demeaning endless drudgery. My personal trick is not to bother with styling and call it “homemade, organic”.

„functional aesthetic“

The trick is to have a money so that when it becomes boring, you can just set others to finish it... Lol..if only

Cheers to the author for finishing this brilliant essay even if he can't finish his software projects!

This was a great read. I think the "define finished" at the beginning to be useful advice for me.

"Definition of Done" is a common Agile concept. There's a wealth of documentation on how to define it. Heres one: https://www.scrum.org/resources/what-definition-done

When the cost of making a change gets close to zero, it's easy to keep fiddling endlessly...

Lol, I'm not the only one who struggled to finish the article even! God, do distracted.

I have a feeling that the author procrastinated on their project by writing this blog

> 1. Define “Done” from the Start

Impossible for almost any non-trivial project.

> Define “Done” from the Start

This has helped me tremendously. Great article.

I honestly couldn't care less about finishing my personal projects.

It's more about moving forward, and dropping projects that aren't interesting anymore.

Love the illustrations, really great usage of excalidraw!

Somebody should send it to Neal Stephenson

Honestly, it took me about 10-11 hours to finish this article just because I wanted to understand "The Art of Finishing", and I totally agreed with what the author was trying to communicate.

> a hydra of new challenges

Well put.

Great read ! May be this js why #buildinpublic helps many creators

Just what i needed to read today, thanks.

Seen !

"Art is never finished, only abandoned." (Leonardo Da Vinci)

1. Clearly identify why your are doing something.

2. Is it really a benefit to _both_ yourself and _society_ . Or are you solving someones issues for a false sense of accomplishment, and silly wages. Note, I do realize the irony of this post, but I find it entertaining so it still meets the criteria.

3. Summarize your time-bounded project goal in one sentence.

Example: “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." (John F. Kennedy)

4. Draft the probabilistic path forwards, by adding the finish line first.

https://en.wikipedia.org/wiki/Program_Evaluation_and_Review_...

5. Identify the key deliverables necessary to meet an MVP in your TRL. This narrows the scope of the project to mitigate feature creep etc.

https://en.wikipedia.org/wiki/Technology_readiness_level

6. Are there people with the right skills and motivation to finish each stage of the project? Note, statistically if you are 93% sure you are only really 60% certain on average.

7. Justify the liability of the budget is consistent with personal and corporate budgets. Solving the worlds problems for free may sound noble, but a half-baked attempt is usually foolish, hapless, or destructive to yourself and others. i.e. if the only motive is to make something cheaper, than you will likely end up worse off for the effort.

8. Landing the belly flop... Can deliverables be re-used in other projects? Does the project still meet its goals in commercial, scientific, and or entertainment markets.

9. Start testing the hardest key deliverables first with toy sub-projects. If these don't succeed, than don't bother tooling up with funding for the rest of the project.

10. toy sub-projects are sometimes regression tests, small programs, or key problems with unknown solutions. Expect these to fail or be repurposed 52% of the time, but if they don't work for the intended role than the path is non-viable.

Finally, I must observe an interesting phenomena when the probability of completing a key deliverable is below 50%, number more the 3 nodes in a PERT serial traversal, and do not have redundant options. Irrespective of a project complexity, the team will fail to reach its goal regardless of the talent pool, time window, and budget.

Best of luck, =3

Came to mention same thing I heard from a CS instructor in a freshman class way back in 1987... "Software is never finished, only abandoned."

But I'm curious to know details about what this means:

> number more the 3 nodes in a PERT serial traversal, and do not have redundant options.

Would you mind elaborating or providing a bit more context I can go search on and learn about? Thanks!

In general, the PERT longest stretch and or ideal shortest stretch of dependent events should not contain k>=3 stacking risks <=0.50.

For example, one path with best probable outcomes:

[S]->[a]->[b]->[c]->[d]->[E]

a=0.73

b=0.49

c=0.33

d=0.50

By taking the 3 lowest/riskiest key deliverables in the best case outcome:

0.49x0.33x0.50 = ~0.08 likelihood of project success

This means one should restructure the project, redefine the goal scope, or shelve the project.

People that practice this approach say "no" a lot, but the firm does survive.

Best of luck, =)

My guy discovered what Agile really means

The natural tendency is to tackle the hardest parts first, because it's intuitive that the low hanging fruit will be easy and therefore bring more satisfaction. However, I found that tackling what one knows first -- the low hanging fruit -- injects new energy and satisfaction and is critical to mustering the willpower to tackle the hard parts. I found out that solving the low hanging fruit often ends up offering insight into solving the hard problems, and thus finishing a project.

Reply on news.ycombinator.com