Ask HN: How to finish last 30% of a side project?

Maybe decide to release by the end of the weekend, and be brutal about dropping anything that's not absolutely necessary for release.

That being said... in the short-term.... I'd suggest taking a break from the project for at least a few days. Go for a long boring walk around your neighborhood if you are able to. Get your senses stimulated. Try not to think about the project during this time but you will find when your brain invariably goes back it doesn't feel quite the same. Possibly new connections are made or decisions to let things go are made. Or not. At least you got away for a bit.

These sound like you're trying to build something with professional polish when you wanted to have fun:

> Part of it feels like I've tried to do too much at once instead of building piece by piece

> writing the tests for these and going back and forth on different decisions has killed all productivity and drive within me.

Why not build something awful and silly? Alternatively: add an awful plugin system and say it's left up to the user.

While it's good to "finish" something, maybe there's an earlier start line, or finishing point you can release, and continue to add to? Sometimes launching can be it's own feedback loop, if you were going to put in.

If it's a side project, unless you're learning testing, do you want to skip some of that? Might just be overdoing it in terms of novelty per feature.

Depending on the personal project, I sometimes will only do tests on the most complex or sensitive parts first. If I can't fetch data from a database by this point...

On the other hand if it was for something professional in the future, maybe I'd want to pay more attention to it.

The fun with personal projects is you don't have to do everything right, you can do it all wrong, because it's up to you and for you.

If it's a side project for others, sometimes the simpler approach with a boring tech can be surprisingly sturdy.

I rewrote something last week, and when deciding to do it in JS or Python, I shrugged and picked python because it could play with something else I was going to try out later. If I thought about it another way I'm sure I could have done it in JS too. Luckily the technologies can often call each other.

In any event, I try to find good stopping points so it's easier to pick up, or start what I can easily finish in one sitting, and maybe thinking about the next step before I walk away to come back to that.

Is there something about finishing that's interesting? Some value intrinsic to you in finishing?

Why? Will there be financial benefit?

What I've discoevered is that, as an adult, I realized that these kind of projects need 2 things:

1) Must have financial viability, a way to escape wageslavery.

2) That on my death bed, even if this project fails, I will be like "Yeah, man I'm glad I tried. I might have failed, but I tried. So then I moved to the next thing."

Here's my tips (based solely on my own experience, but maybe some of them will be useful to others):

1. Make a plan to decide what is in scope, what you want to make (at least for now). This plan can be revised, but you want to stick to it unless you have a very good reason to change. Avoid scope creep. (One way I manage this is to set goals. If I exceed my goals' deadlines, I can afford a bit of creep. Otherwise, I stick to the plan.)

1b. DESIGN your systems up front. You want to be adding modules to a well-architected system, rather than chipping away in the dark hoping a sane structure takes form by luck or genius.

2. From the outset, break the project into a series of medium-sized, high-level chunks. In my case, this is things like "create level 1", "complete weapon model 1", "create player gameplay code". Generally, I avoid moving off a chunk until it is completed, and each chunk is broken down into subtasks.

2b. Find a SIMPLE way to track these chunks and tasks. I use Trello, but don't use anything fancy lest the tool become its own side project (I speak from experience...).

3. Try to make some progress most days (unless I'm on a prolonged break). When I'm really not in the mood, I'll settle for just 25 minutes work (and often when you've done the 25, you'll find you're able to do more).

4. While you want a plan, and you want to design things before you implement them, especially architectural aspects, don't worry about being perfect. Get things done. You will be able to fix problems later. This is especially wise to remember if you're stuck – just get something that works there, and maybe tomorrow you'll figure a way to refactor or do it better, or maybe you'll even find that what you had was actually sufficiently decent.

5. Don't feel bad about taking prolonged breaks. For creative projects, this really refuels the tank, but I imagine it'll be useful for any significantly complex project. Absence makes the heart grow fond.

These things work for me at least!

That said, when I get to that point is also when I evaluate whether an accomplishment is truly important to me. If it's not worth the slog it can't be that important.

If the goal was simply to learn and stay sharp, then perhaps an incomplete project is a success——you did some coding, and learned something about what motivates you. If the goal was more specific, then perhaps you've (subconsciously) re-evaluated the requirements for success, and it no longer feels achievable or worth the effort.

I could be wrong, of course, but this sounds less like a problem of technical ability than one of deepening your understanding of your own motivation. If that sounds right, maybe check out https://x.com/scottdomes — I like his writing about how to identify what you want and why.

I wrote an article on the mental side of developing alone [0]. The gist of it is: You're racing against yourself when working alone.

You're the limiting resource, and so, whatever you're building has to account for where you're in life and how you're feeling.

Good luck!

[0] https://www.idiotlamborghini.com/articles/how_to_prevent_sta...

Also if a lot of architecture is changing, you might have put in too many classes and abstractions? Look into data driven design. Think about data and how that needs to be caressed to get what you want.

Think in features. And think in data. That's my two cents.

It's called JFDI.

Another one also works well.

It's called elbow grease.

1. Hiatus from the project. A few days minimum; more likely weeks or months. Doing other things with my life clears my thoughts, recharges my motivation, and sometimes provides new experiences that spark inspiration.

2. Add this to the top of my todo list: Break my components into smaller pieces. This would ideally be listed as several distinct steps, so it doesn't become an overwhelming monolith of its own. It's important because having smaller components tends to make development changes smaller as well, and therefore more approachable. I'm more likely to sit down and work on a project when I know I can make progress with just a handful of work, rather than a truckload at a time.

3. Be willing to walk away. Sometimes a project turns out to be a lot more work than expected, or an easier solution presents itself, or the original problem ceases to exist, or I discover a good reason to rebuild from scratch, or something comes up in my life that I feel is a better use of my time. It's never time wasted, because I have undoubtedly learned things and expanded my toolkit regardless of reaching the finish line I originally imagined. Realizing that this is normal and perfectly fine takes the burden of obligation off my shoulders, and leaves me in a good state of mind for the next project. (And I can always come back to it if I change my mind later.)

For the past couple months, I've been pair-jamming with friends & colleagues on side projects. We'll often order in pizza, build a backlog of features we can ship in the next week or two, and work on it together (alternating who's coding using pomodoro timers). It's a lot of fun.

For what it's worth - I get the same feeling about my own projects, and frankly - helping someone else with their project can often unblock your own. Team work makes the dream work.

If that's something you're interested in, my contact details are in my HN profile. I do it for fun (& pizza!).

The smaller/quicker you do it, the quicker you can test your business idea, or whatever you're trying to test.

If you have success with that MVP version, then you will feel more motivated to refactor and make the code better.

My programmer friends hate it when I talk like this...but if you are the only one working on a project, it often makes the process much more fun and you get feedback much quicker to do it badly/lazily OR to do it in a non-scalable way.

Seems to be working for me.

P.S. Pls send pizza :'(

I'm curious if you still - I assume you must, since you're here asking - have a reason to want it done? You still want the finished project, for your own use or portfolio, but just not to work on it any more?

Because with my opposite (lack of) motivation, it's that I want the product, I want to work on it, further it, maintain it, market it, grow it; it's just getting it to MVP that I struggle with. (Similarly over a few things I've done/tried.)

Congratulations, your project is now finished! Ship it and show it to the world!

You think it is still missing something? Great, add it to your next milestone and finish your project a second time!