I have tests but changing existing behaviors feels exhausting. Even a small refactor, even with good tests in place, feels exhausting and I just don't want to pick this up anymore.
Part of it feels like I've tried to do too much at once instead of building piece by piece, but even building piece by piece doesn't work because at some point you realize a new feature requires you to revisit the architecture of a prior decision, and that just puts me off from ever picking it up again.
I'm tired, I'm exhausted, I want to finish, but this is a recurring problem for every project I start. It just feels like I'm unable to ever find a way to wrap things up and I'm always working in a spiraling circle instead of the meme about drawing a wolf with some circles, add some details, etc.
Is there a book or article one recommends? It feels like I never learned how to code properly, even though I've been coding professionally over 10 years.
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!
You can then iterate step by step improving the things that sucks the most, playing the game as it improves.
The huge advantage is that you will be playing the game right away and have years to refine the gameplay and come up with better ideas. And if the game is fun to play, even with ugly boxes, you know the final game will be great. It’s a great motivator.
Maybe decide to release by the end of the weekend, and be brutal about dropping anything that's not absolutely necessary for release.
Yep. KISS and YAGNI.
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.
Even if this project is not valuable to anyone, shipping in its current form or some semblance of it means that it can be iterated on and improved. There are very few projects that are overnight successes on initial release. Better to try and test interest with something tangible and to try and iterate.
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.)
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.
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.)
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.
The last thing was that I learned to polish the chores. For 'the fun of it' I completed a side-project with landing page, posted to Product Hunt, and even automated setting up a new customer and billing. I never did much sales/marketing for it, but to this day I have an automated monthly Paypal payment of $0.02 to myself to show that everything's still working as it should. I'm glad to have done it once to know it's all there to copy/paste if I need it for something I really do want to put the effort into marketing.