[HN Gopher] The Art of Finishing
___________________________________________________________________
The Art of Finishing
Author : emmorts
Score : 632 points
Date : 2024-09-02 20:51 UTC (1 days ago)
(HTM) web link (www.bytedrum.com)
(TXT) w3m dump (www.bytedrum.com)
| btbuildem wrote:
| 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?
| whiterknight wrote:
| 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.
| detourdog wrote:
| Sometimes one needs to reset the goals and failure suddenly
| looks like a success.
| dakiol wrote:
| 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.)
| Swizec wrote:
| > 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.
| sopooneo wrote:
| 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.
| detourdog wrote:
| 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.
| TeMPOraL wrote:
| 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.
| sevensor wrote:
| > 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.
| pickledoyster wrote:
| > 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.
| drewhk wrote:
| 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!
| sevensor wrote:
| 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.
| jdeaton wrote:
| 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.
| super_linear wrote:
| Similar to "The Cult of Done Manifesto" (2009)
| https://designmanifestos.org/bre-pettis-and-kio-stark-2009-t...
| wseqyrku wrote:
| 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.
| Krasnol wrote:
| Somebody should send it to Neal Stephenson
| xianshou wrote:
| 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.
| andrei_says_ wrote:
| 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.
| d0gsg0w00f wrote:
| God I miss tango. 2 kids put our 2 years of lessons to a
| screeching halt.
| andrei_says_ wrote:
| 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.
| circlefavshape wrote:
| 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
| rustyboy wrote:
| 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.
| threatripper wrote:
| 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.".
| Lutger wrote:
| 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.
| lelanthran wrote:
| > 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.
| TeMPOraL wrote:
| > _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.
| morning-coffee wrote:
| 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.
| alva wrote:
| Just what i needed to read today, thanks.
| andrewstuart wrote:
| The problem is, writing software is REALLY time consuming.
|
| It takes months of full time effort to built something that
| resembles a working application.
| solomonb wrote:
| I relate heavily to the author's dilemma. My projects span from
| math, to programming, to pinball repair, to amateur radio, to
| gardening, to mycology, to who knows what else. I personally
| enjoy the process of bike-shedding and endlessly exploring the
| solution space for a problem. That said, there is a point where
| you need to make hard decisions and button up projects.
|
| As long as I don't care what project gets completed at what time,
| I've found a little trick to broadly move the needle. I jokingly
| call it "Sol's fast five" but the name is actually pretty on
| point.
|
| I take a step back, look around me, and pick out the first five
| things I can reasonably achieve in less then a day prioritizing
| things where I have all the tools and materials at hand. These 5
| things are never entire projects, the goal is to maximally
| decompose the projects until each action is as close to trivial
| as possible.
|
| Once I have my list of 5 things I stop thinking about anything
| else and strictly work towards those 5 goals. There is a sense of
| relief in having reduced the scope and the tasks tend to be
| finished very quickly. Checking them off the list always feels
| good.
|
| Once I have completed my 5 items I start a new list and pick out
| the next five items. This can feel like a huge reward.
|
| I've used this system to great effect in the past few years.
| exe34 wrote:
| would the five tasks be a single project or across multiple?
| solomonb wrote:
| It depends on the circumstances and how you want to
| prioritize things. Generally I'll take on the 5 easiest tasks
| across all my 'active' projects.
| exe34 wrote:
| that makes a lot of sense. I've noticed myself, whenever
| I'm procrastinating and avoiding working on a project, it's
| because I don't actually know what the next step is. if I
| make figuring out the next few steps as a time-boxed task
| in itself, suddenly I don't procrastinate anymore, I just
| sit down and do it.
| solomonb wrote:
| I think this gets back to what I said about being okay
| with bike-shedding. Researching and exploring the design
| space is a critical part of every project. Its okay to
| commit time to thinking, planning, and exploring.
|
| I feel that as engineers we generally react negatively to
| the idea of bike-shedding or "building cathedrals" but
| the reality is that there is always a bike-shed. The
| question we should be asking is not should we deliberate
| over the design of the project, but rather to what degree
| does this project (and consequently the business in paid
| situations) benefit from deliberation.
|
| In the case of personal projects, I am far more concerned
| with the process then the outcome and will allow myself
| to indulge in bike-shedding maximally.
| exe34 wrote:
| My preference is to think deeply about it alone, and
| either take the results of that to the team or even come
| up with a very rough mockup/prototype and/or some working
| code for the bits that I initially have no idea how to
| implement (again, in a time-boxed manner)- and only then
| have a proper bike-shedding session.
|
| Otherwise I find so much time is wasted on tiny details
| that don't matter, and the overall picture still fails to
| emerge (aka a definitional bike-shedding session).
| zafka wrote:
| Your interests sound similar to mine. My email is in my profile
| if you ever care to compare notes.
| lovegrenoble wrote:
| Thanks!
| Syntonicles wrote:
| Same approach: I call it "Ten Tiny Tasks"
| assadk wrote:
| Sounds interesting, could you elaborate on this please?
| merlincorey wrote:
| I'm not the GP you asked, but distilling my own personal
| organization practices into the alluring "Ten Tiny Tasks"
| title, here's my take on it: - Make a
| list of the 10 tiniest tasks with the least amount of
| estimated effort you can find or think of that need to be
| done - Maybe save task 10 for a super quick
| prioritizing of the other 9 tasks, or don't because they
| are tiny tasks, after all - Complete the 10 tiniest
| tasks - Repeat the process until there are no more
| tasks (of course, there are always more tasks)
| fragmede wrote:
| And like, _tiny_. Open terminal to project directory.
| Opeb browser window /tab to SDK/API index. Shit so easy
| that you can't help but do them. Repeat until you get to
| tasks that aren't quite so trivial, and by then, you'll
| be going.
| solomonb wrote:
| IME as you approach the limit you can create an infinite
| number of tasks. The key for me is to pick tasks which
| balance expedience and bang for buck value, but if you
| are experiencing intense writers block then I see no
| problem with a task like "open editor."
| aldanor wrote:
| 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...
| TeMPOraL wrote:
| 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.
| agumonkey wrote:
| It's a method of building up and keeping momentum ?
| Syntonicles wrote:
| 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.
| ants_everywhere wrote:
| > the goal is to maximally decompose the projects until each
| action is as close to trivial as possible
|
| This is a big part of the GTD framework that is almost always
| dropped in the retelling but which I think is fundamental. The
| tasks should be broken down to the next physical thing you can
| do so you don't have to think to act.
|
| Also you have cool interests
| solomonb wrote:
| 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.
| port19 wrote:
| Then stay away from it if you can. GTD is great if you're a
| manager with a wive and kids and maybe a foundation to run
| on the side.
|
| If you don't usually forget tasks/events or freeze up
| because of analysis paralysis, you can get by just fine
| without it.
|
| GTD definitely brings an overhead that doesn't pay off in a
| reasonably simple life
| TeMPOraL wrote:
| I'm not a manager, but have a wife and kids and used to
| run a foundation on the side. The overhead of GTD only
| got more painful, while my ability to sustain focus
| diminished, so the whole thing broke down.
| bluGill wrote:
| 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.
| soco wrote:
| 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?
| targafarian wrote:
| 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.
| soco wrote:
| 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...
| solomonb wrote:
| 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.
| TeMPOraL wrote:
| 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.
| bluGill wrote:
| 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.
| itqwertz wrote:
| 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.
| ok_dad wrote:
| 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.
| theteapot wrote:
| > ... 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.
| ok_dad wrote:
| 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.
| voidUpdate wrote:
| 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
| goatmanbah wrote:
| When the cost of making a change gets close to zero, it's easy to
| keep fiddling endlessly...
| vjeux wrote:
| Love the illustrations, really great usage of excalidraw!
| fsndz wrote:
| 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.
| krisoft wrote:
| > 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?
| gfody wrote:
| 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.
| brikym wrote:
| 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.
| andyferris wrote:
| 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?
| blueblimp wrote:
| 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....
| RhysU wrote:
| 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
| psidebot wrote:
| 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.
| iamflimflam1 wrote:
| 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.
| daveguy wrote:
| 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).
| purple-leafy wrote:
| 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
| thomassmith65 wrote:
| 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.
| purple-leafy wrote:
| 1) this is true, I've run into this!
|
| 2) I'm yet to run into this
| alex_suzuki wrote:
| What kind of Chrome extensions? Genuinely curious - it would
| never occur to me to build one.
| purple-leafy wrote:
| 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...
| alex_suzuki wrote:
| Monetized much?
| moridin wrote:
| Seen !
| adamtaylor_13 wrote:
| 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.
| jongjong wrote:
| 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.
| dr_dshiv wrote:
| 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"
| fracus wrote:
| This was a great read. I think the "define finished" at the
| beginning to be useful advice for me.
| anonu wrote:
| "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
| saltcod wrote:
| > a hydra of new challenges
|
| Well put.
| lifeisstillgood wrote:
| I completely agree, finishing matters, and this reminds of a joke
| where I said to
| xyzzy4747 wrote:
| 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.
| hungie wrote:
| 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.
| decasia wrote:
| 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).
| anonu wrote:
| 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.
| 65 wrote:
| 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.
| october8140 wrote:
| Obsidian.md
| Joel_Mckay wrote:
| "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
| morning-coffee wrote:
| 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!
| Joel_Mckay wrote:
| 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, =)
| ww520 wrote:
| 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.
| jonstewart wrote:
| 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
| fabmilo wrote:
| 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.
| ilrwbwrkhv wrote:
| ya maybe you have a point here. i did a lot of work on
| modafinil back in the day.
| voidUpdate wrote:
| 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
| ChrisMarshallNY wrote:
| 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/
| SubiculumCode wrote:
| The trick is to have a money so that when it becomes boring, you
| can just set others to finish it... Lol..if only
| quercus wrote:
| Cheers to the author for finishing this brilliant essay even if
| he can't finish his software projects!
| richrichie wrote:
| Frontend work is demeaning endless drudgery. My personal trick is
| not to bother with styling and call it "homemade, organic".
| alex_suzuki wrote:
| ,,functional aesthetic"
| shafiemukhre wrote:
| I have a feeling that the author procrastinated on their project
| by writing this blog
| hluska wrote:
| 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.
| whartung wrote:
| 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.
| langsoul-com wrote:
| 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.
| gjadi wrote:
| Congrats to the author for finishing their article!
| k2so wrote:
| 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.
| laodabi wrote:
| instead of finishing my side project, i am reading this post
| surfingdino wrote:
| 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.
| caporaltito wrote:
| My guy discovered what Agile really means
| ts330 wrote:
| 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.
| justinclift wrote:
| 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. :)
| abdussamit wrote:
| Lol, I'm not the only one who struggled to finish the article
| even! God, do distracted.
| codr7 wrote:
| 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.
| iamflimflam1 wrote:
| 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.
| dailykoder wrote:
| >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
| drewhk wrote:
| > 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.
| jondot wrote:
| 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)
| myth2018 wrote:
| > 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.
| Ilasky wrote:
| 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
| sevensor wrote:
| 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?
| A4ET8a8uTh0 wrote:
| << 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.
| pickledoyster wrote:
| Yeah, setting deadlines for a hobby is how I used to kill any
| joy I'd get from the hobby.
| metacritic12 wrote:
| 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.
| packetlost wrote:
| > 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.
| yard2010 wrote:
| 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.
| packetlost wrote:
| 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.
| jckahn wrote:
| 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.
| Foreignborn wrote:
| 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)
| atoav wrote:
| 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.
| loughnane wrote:
| 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.
| Rugu16 wrote:
| Great read ! May be this js why #buildinpublic helps many
| creators
| maupin wrote:
| > 1. Define "Done" from the Start
|
| Impossible for almost any non-trivial project.
| mikesabbagh wrote:
| 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
| morning-coffee wrote:
| 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.
| sandworm101 wrote:
| 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.
| chiefrubberduck wrote:
| 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.
| mrbluecoat wrote:
| > Define "Done" from the Start
|
| This has helped me tremendously. Great article.
| Nifty3929 wrote:
| 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.
| khy wrote:
| 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.
| jolt42 wrote:
| 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.
| shahzaibmushtaq wrote:
| 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.
| pigcat wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-03 23:01 UTC)