Live data from Hacker News

On finishing projects

alexreichert.com

81–90 of 103 posts

Re: On finishing projects

#81

Reposting an old Reddit comment of mine that I think agrees with much of this article: I'm in my 40s and for most of my life I had an unending series of unfinished projects that I felt guilty about. Today, I am able to finish some stuff, including some pretty large, hard projects. Better, I don't feel guilty about the stuff I don't finish. The trick for me is to be deliberate and mindful about why I'm embarking on a…

So you’re saying in order to finish projects I just need to learn how to be honest and clear with myself? Seems like a reduction to a harder problem :) Joking aside, I came to believe that various form of procrastination are a response to pursuing wrong or unclear goals - even when I don’t state them clearly, my brain still somehow knows that I’m not aligned with what my goals should be. Good job, brain!

> Seems like a reduction to a harder problem :)

Yes, but there may be other positive benefits to solving it as well. :)

Re: On finishing projects

#82
My approach for finishing projects: team up with a Finisher. I found one at work, and we became good friends along the way.

I'm a typical Starter, and all of the side projects we've been working on together were my idea. All of the projects that we completed and released were solely because of his endurance, discipline and focus. And his constant reminders to not start a new project before the current one was done.

Re: On finishing projects

#83

Not to nitpick, but in this blog post, mostly every first sentence after a heading doesn't add anything, but simply repeats the heading in a longer, more rambling format. Are you bumping your word count to achieve some imagined length goal/page count? Brevity and Ruthless Editing should be incorporated into your final cycles of 'finishing' working on projects.

This is so very unhelpful and completely against the spirit of the post.

The author knows their work isn't perfect, but they're sharing it anyway. This is covered in the first paragraph.

Regardless, I found this post to be perfect. There are good takeaways, it was easy to read, and it wasn't too long.

I'd imagine that the author would happily consider your opinion if you posed it in a more constructive manner.

Re: On finishing projects

#84
Here's another approach not mentioned: have an accountability partner. Promise that person something specific to be done, with a delivery date.

My observation: a promise I made to someone else is harder to break than a promise I made to myself.

Re: On finishing projects

#85

I really disagree that releasing a project publicly is a necessary step to deem something done. I have so many projects in my src/ directory that are (in my mind) finished, but that I will never release to the public. I wrote them for my own education and entertainment, not as things that I think the rest of the world would benefit from. And certainly not as a way to build some kind of (ick) -personal brand- among th…

I just put these in a big GitHub repo so that I consider them shared and therefore finished.

https://github.com/shepherdjerred/practice

https://github.com/shepherdjerred/archive

Re: On finishing projects

#86

My approach for finishing projects: team up with a Finisher. I found one at work, and we became good friends along the way. I'm a typical Starter, and all of the side projects we've been working on together were my idea. All of the projects that we completed and released were solely because of his endurance, discipline and focus. And his constant reminders to not start a new project before the current one was done.

You really lucked out, and ended up with a great partner there! If i am honest with myself, on most things i would say i'm 75% the starter and 25% finisher...but at current $dayJob, oof, i'm surrounded by all starters (and not that great at starting either), but not a single finisher. Congrats to you! :-)

Re: On finishing projects

#87
post #79

One thing that works well for me is going working-to-working. Get a simple, de-scoped, incomplete, probably crappy version done end-to-end. Now it's not about finishing, it's about improving. And if it was worth building in the first place, it will beg for improvement. And then it's easier to just keep turning the crank, working-to-working.

In Pragmatic Programmer, this is called the "tracer bullet" approach. Basically just another word for end-to-end, but with the emphasis that by completing a slice end-to-end you'll get feedback much faster (as in the feedback tracer bullets provide when shooting a target).

So... MVP?

Re: On finishing projects

#88

Here's another approach not mentioned: have an accountability partner. Promise that person something specific to be done, with a delivery date. My observation: a promise I made to someone else is harder to break than a promise I made to myself.

Until you figure out the first excuse that works.

Re: On finishing projects

#89
post #9

Over the years I’ve noticed that I’m often operating in various “modes”. Some of this is related to depressive episodes, but often it’s just a more neutral ebb and flow. I’ll have a week where ideas are flowing and connections form easily. I’ll have a week where it feels like I can’t engage so deeply - like my system is cooling off after exertion. And this is one of the reasons writing things down has been such a use…

I've come to a similar conclusion lately. I used to spend a lot of time jumping on my latest idea, researching and even writing a bit of code to get started. I'm much better off writing my ideas down, hopefully in a form where I can consolidate the ideas into a few projects, but even if it just stops me wasting time on an idea that I'll lose interest in soon, it's worthwhile.

On the other hand, I've got one large ongoing series of projects that are relatively pointless, and that is the whole point of them. I'm learning from them and I don't have the pressure of completing anything (although I would really like to). From time to time they have been really important for my mental health, and I value them for that.

I'm also quite aware now that I need to feel achievement to keep me motivated, and if I have a plan and can check off an item on that plan then that counts as a good day. Work doesn't always give me that sense of achievement, so having something else that does can be really valuable.

Re: On finishing projects

#90
post #79

Earlier quoted context omitted.

In Pragmatic Programmer, this is called the "tracer bullet" approach. Basically just another word for end-to-end, but with the emphasis that by completing a slice end-to-end you'll get feedback much faster (as in the feedback tracer bullets provide when shooting a target).

So... MVP?

Hmm, how about... End-to-end: "can really implement?". Tracer-bullet: "can adjust aim?". MVP: "can make user happy?". Though there's more to each.

So then market fit exploration benefits from tracer-bullet, but you might do iterative reimplementation instead. And it might be overkill for a one-shot market test. MVP is largely orthogonal to end-to-end - "Submit button emails founder who does the thing by hand over breakfast" is fine MVP but isn't very end-to-end. And a non-MVP non-product end-to-end can be tracer-bullet or not. A soundly architected low-debt end-to-end yes, a hackathon high-debut "to adjust, rewrite", or a throwaway end-to-end exploratory spike, no.

Post reply on HN