Ask HN: How to finish last 30% of a side project?
58 comments
I work on games as a hobby. Each game takes around 2 years or so to finish, which means I need to be able to sustain PRODUCTIVE development over a long time and resume paused development (for when life gets in the way of the hobby or I just need a break).
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!
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!
Another approach that might work for some people is to quickly build a “block” prototype game. Basically the complete game but using boxes and quick prototype box levels to make a “completely finished” game that is ugly and unsellable but playable.
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.
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.
There are no rules for side projects. Consider just removing or skipping the test parts if they are slowing you down. Sometimes project progress and fun is more important than industry best practices.
Maybe decide to release by the end of the weekend, and be brutal about dropping anything that's not absolutely necessary for release.
Maybe decide to release by the end of the weekend, and be brutal about dropping anything that's not absolutely necessary for release.
>be brutal about dropping anything that's not absolutely necessary
Yep. KISS and YAGNI.
Yep. KISS and YAGNI.
It sounds like you no longer see value in the work. What were your original motivations and goals? How have they changed? From a distance, it's easy to guess that you're not confident the project will be useful to anyone. If that's true, it would make sense that you're demotivated--nobody likes doing work that isn't useful to themselves or others.
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.
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.
This is horrible advice. Getting burnt out is very natural. The first thing that should be attempted is to get space to recharge. If, after there's been some distance, the OP feels the same way, then, yes, consider abandoning the project is valid but it sounds like this is a deeper issue of not being able to complete projects and finding strategies to help.
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.
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.
Maybe we should work together, because I find the first 30% impossible. A slog of annoying setup bs; to me it's harder to start stuff than it is to fix/add to something working and somewhat usable/testable.
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.)
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.)
I think the key is to just do it as badly as possible. And make as small of a project as possible, MVP.
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.
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.
I've been in a similar place. Here's what I found helped:
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.)
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.)
Taking a break can be very helpful. I design board games and that is what I do. Go do some other hard thing for a week and see how you feel. For me, if one project stalls or doesn't excite me, I switch to one that does. Design and development can be a slog and I don't want my hobby to be that. Some games never make it back to the active state. Some games do. But maintaining any kind of momentum allows me to stay productive, even when it is baby steps.
I am more guilty of this than anyone and I don't have any solid advice that has worked in the long-term so I'll be following this thread.
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.
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.
What worked for me is a change in perspective and how to mentally track progress. If you're thinking of the development being 95% done the remaining work is going to be a slog. OTOH if you look at the remaining items as a burn down list and ignore whatever the percentage completed may be, then progress feels more apparent. Going from 11 to 10 items feels better than going from 96.4% to 96.9%. You also have to change your sights to a farther goalpost. Instead of thinking that completing development is the target, think that completing development unlocks the next phase which is sharing the work broadly and interacting, getting feedback, making a landing page for exposure. It's a whole new area to explore a new 0% to 30%. Similarly change from a developer/devops hat to more infrastructure/ops one, etc. Enjoy the journey--and don't think about how slow the last y% is compared to the first X% (that really only means your percentile estimates are way off).
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.
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.
Quit your job with no money to fall back on, and make your side project your only potential source of income.
Seems to be working for me.
P.S. Pls send pizza :'(
Seems to be working for me.
P.S. Pls send pizza :'(
That's ok OP, I think feelings like this are inevitable when working alone. Especially on long projects.
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...
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...
Unfortunately, it's usually the case that the last 10/20/30% of a side project takes 90% of the work.
This is my experience too.
For any of my day job projects. Which is the best explanation to your title question
Yeah this is exactly it, you might think you are close but you actually just started, and the actual work is still to come.
Whether you want to push through the initial honeymoon phase, where you are done with the fun part that you started the project for, and do all the rest around it that makes it an actual 'product', is up to you.
Whether you want to push through the initial honeymoon phase, where you are done with the fun part that you started the project for, and do all the rest around it that makes it an actual 'product', is up to you.
> I want to finish
A personal project (and many professional ones) are never "finished".
Or are you sure that when you finish that last 30% your web page editor is PERFECT and will never need any new features?
Are you using it already[0]? Do you miss any features? If not, just stop working on it, it's good enough.
Release it, put it out there and let other people help and maybe tell you what features it might need.
[0] https://en.wikipedia.org/wiki/Eating_your_own_dog_food
A personal project (and many professional ones) are never "finished".
Or are you sure that when you finish that last 30% your web page editor is PERFECT and will never need any new features?
Are you using it already[0]? Do you miss any features? If not, just stop working on it, it's good enough.
Release it, put it out there and let other people help and maybe tell you what features it might need.
[0] https://en.wikipedia.org/wiki/Eating_your_own_dog_food
I say - release it and get feedback from real users. I get motivated by other people finding my work useful, maybe you will too?
On the flip side, if nobody uses it - including yourself - why bother improving it?
On the flip side, if nobody uses it - including yourself - why bother improving it?
This is also my first thought. If the thought of new features is paralysing, it's because you're not sure they're needed. Feedback will tell you what to build next.
> I have tests but changing existing behaviors feels exhausting.
Tests freeze your design and purposely makes big architectural changes difficult. This is why they're so good/important for libraries, services, and finished products because you don't want to break things for the clients.
If this side project is supposed to fun then why bog yourself down with that ceremony. Put the tests aside and just do what needs to be done to get it finished.
I used to have a similar problem finishing and deploying projects. My projects now go through 3 stages:
1. The initial fooling around and figuring out the product -- this is the funnest part of the project.
2. Taking that initial mess and turning it into something end-user viable to use. I try and decide before starting this part the minimal viable feature set. Sometimes this involves designing the UI and resisting the urge to add more to it later.
3. Deployment. I stop working on the project as it's own thing. Instead it's now "done" and this is a new project dedicated to getting that other one out. This might involve writing documentation, creating web pages, installers, etc. By making this a separate in my mind, it helps make it happen.
I'm currently on stage 3 on one of my personal projects and I hope to get it out next week. I finished stage 2 several weeks ago and it's taken until recently to get back to it.
Tests freeze your design and purposely makes big architectural changes difficult. This is why they're so good/important for libraries, services, and finished products because you don't want to break things for the clients.
If this side project is supposed to fun then why bog yourself down with that ceremony. Put the tests aside and just do what needs to be done to get it finished.
I used to have a similar problem finishing and deploying projects. My projects now go through 3 stages:
1. The initial fooling around and figuring out the product -- this is the funnest part of the project.
2. Taking that initial mess and turning it into something end-user viable to use. I try and decide before starting this part the minimal viable feature set. Sometimes this involves designing the UI and resisting the urge to add more to it later.
3. Deployment. I stop working on the project as it's own thing. Instead it's now "done" and this is a new project dedicated to getting that other one out. This might involve writing documentation, creating web pages, installers, etc. By making this a separate in my mind, it helps make it happen.
I'm currently on stage 3 on one of my personal projects and I hope to get it out next week. I finished stage 2 several weeks ago and it's taken until recently to get back to it.
It's been well said here already but side projects can be so different. Some are for learning, some are for trying out certain approaches, and some are really to find out if it's a good day to go to a park.
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.
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.
>> I want to finish
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."
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."
I have made significant sideline money over 15 years making a saas product where testing was, "oh look, that didnt work", or Chris, "the website crashed".
I had no idea what I was doing when I nade the site. I bought an html4 book and copied code from the PHP manual.
Stop beating yourself up and get something out there. The truth is you haven't got to the hard bit yet, selling it (which I'm guessing is your direction of travel).
I can guarantee from your comment the code you are writing is better than mine. There is joy in making something that you can call your own.
When I first showed my website to people a few said it was rubbish. That rubbish site has paid for deposits for my kid's houses, many family holidays, and much more.
Get it done and look forward to the next challenge :-)
I had no idea what I was doing when I nade the site. I bought an html4 book and copied code from the PHP manual.
Stop beating yourself up and get something out there. The truth is you haven't got to the hard bit yet, selling it (which I'm guessing is your direction of travel).
I can guarantee from your comment the code you are writing is better than mine. There is joy in making something that you can call your own.
When I first showed my website to people a few said it was rubbish. That rubbish site has paid for deposits for my kid's houses, many family holidays, and much more.
Get it done and look forward to the next challenge :-)
There is a way to finish any unfinished project without doing anything: reduce the scope until you consider it finished.
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!
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!
Hobby projects, like any other projects, never finish. "Finishing a project" is an illusion created by marketing and project managers. The world changes too fast for any software service or project to ever be even remotely finished.
The trick is to shelve it indefinitely until you feel like touching it again
Two things I do to help me ship. I write down the list of features required to complete the project and then ruthlessly pare it down to the absolute minimum. Nothing gets on that list unless it is absolutely required. For example, if I were shipping a car, I would not consider doors to be required.
The second thing I do is to bribe myself. I promise myself a treat but only on the condition that the project is complete. It is usually something small but I hold myself to not getting it unless the project is shipped.
Those usually help me get over the finish line.
The second thing I do is to bribe myself. I promise myself a treat but only on the condition that the project is complete. It is usually something small but I hold myself to not getting it unless the project is shipped.
Those usually help me get over the finish line.
Maybe don't finish! Maybe you did the interesting part and that's enough.
Is there something about finishing that's interesting? Some value intrinsic to you in finishing?
Is there something about finishing that's interesting? Some value intrinsic to you in finishing?
Something I could recommend would be working alongside others to get it done.
I’ve actually been running a little group[0] that gets together every week over the course of 6 weeks to push their products over the finish line. The weekly accountability really helps keep the motivation going. It’s actually a ton a fun! We’re just about to start our next 6 weeks and always welcome more people.
[0] https://lmt2.com
I’ve actually been running a little group[0] that gets together every week over the course of 6 weeks to push their products over the finish line. The weekly accountability really helps keep the motivation going. It’s actually a ton a fun! We’re just about to start our next 6 weeks and always welcome more people.
[0] https://lmt2.com
"Embrace the suck"
Learn to process the feeling of exhaustion as economically as possible. Meaning, re-frame exhaustion as a normal part of the journey. You really have to push through it, barring mental health concerns, to get stronger and more resilient. You will feel mental exhaustion many times in your life, and it's better to face it early, in less-consequential circumstances, than to try to learn to cope when life is actually bad.
Learn to process the feeling of exhaustion as economically as possible. Meaning, re-frame exhaustion as a normal part of the journey. You really have to push through it, barring mental health concerns, to get stronger and more resilient. You will feel mental exhaustion many times in your life, and it's better to face it early, in less-consequential circumstances, than to try to learn to cope when life is actually bad.
TL;DR: Cut scope and call it done?
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.
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.
Agree. Calling it done and using it might be the best approach.
If this is truly a "small project for myself", start using it.
If the app mostly does what you want, and you enjoy using the app, anything in the last 30% that you feel like you need - you'll be motivated to fix.
Also, drop the tests. I'm not sure there's a lot of benefit in doing that for a web page editor you wrote for yourself.
If this is truly a "small project for myself", start using it.
If the app mostly does what you want, and you enjoy using the app, anything in the last 30% that you feel like you need - you'll be motivated to fix.
Also, drop the tests. I'm not sure there's a lot of benefit in doing that for a web page editor you wrote for yourself.
Hey, if you're interested in pairing on the project together, I'm interested and available (especially if it's open-source). I'm a "full stack" web app developer, and "coach" other developers (a common situation is a senior developer who got promoted into a team lead / architecture role, and haven't coded for awhile, got laid off, and - oh shoot - code skills are dusty & rusty), and get code skills and project back on track.
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!).
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!).
Whenever I get to the slog part of a project I have to remind myself: "If it was easy, everyone would do it". Getting through the slog is what makes something an accomplishment.
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.
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.
Hire someone to finish it. Once you see how slow they are working you'll just finish it yourself.
Some say it's impossible to 'finish' a project ;)
Generally I like to decrease expectations and requirements for MVP, then release.
After that, I stop working on it. It feels like abandonment, but it's not if it's finished.
You need to justify how it will improve your life after it's done. This could be by skill improvements, income, community growth, job opportunities, etc. If it isn't going to help you then it's hard to justify doing it.
Find a friend to work on it that is less technically good, but more motivated.
You will each bring something to each other.
The solution is to start a new side project.
On a more serious note, most of my side projects that do get finished fall into one of two categories:
1. I wrote the whole thing in a single frenzied sprint, and it worked.
2. I developed it in such a way that I could easily abandon it for months at a time, and seamlessly continue where I left off.
For me, the latter involves writing clean, well-documented code, with tests. Maybe even some amount of CI building+testing. (This is all relative, most of my code is neither clean nor well-documented, by any absolute measure)
You also have to ask yourself why you're doing this. Do you actually care about the finished product, or are you just enjoying the process? Or maybe just the problem-solving? (A lot of my projects end at the point where I can say "I know it's possible now", even if I don't have functional code)
1. I wrote the whole thing in a single frenzied sprint, and it worked.
2. I developed it in such a way that I could easily abandon it for months at a time, and seamlessly continue where I left off.
For me, the latter involves writing clean, well-documented code, with tests. Maybe even some amount of CI building+testing. (This is all relative, most of my code is neither clean nor well-documented, by any absolute measure)
You also have to ask yourself why you're doing this. Do you actually care about the finished product, or are you just enjoying the process? Or maybe just the problem-solving? (A lot of my projects end at the point where I can say "I know it's possible now", even if I don't have functional code)
michael seibel will quote me on this one
release whatever you have already worked on. after that, the shame of not doing the remaining 30% will gnaw on your fucking soul like a madman. that's called the iteration process aka boring improvements.
release whatever you have already worked on. after that, the shame of not doing the remaining 30% will gnaw on your fucking soul like a madman. that's called the iteration process aka boring improvements.
Users are my main motivation drivers. Can you get any? Even if that's you!
If not: why?
If not: why?
Start using statically typed languages and don't write tests.
What’s stopping you from releasing it as is right now?
No help from me - I usually get to 95%.
There is a proven methodology that will work. It requires only one ingredient: you.
It's called JFDI.
Another one also works well.
It's called elbow grease.
It's called JFDI.
Another one also works well.
It's called elbow grease.
You finish by finishing features. Not the whole thing. Can you edit a web page with your web page editor? If yes, congrats! You finished it. If not, focus on that first.
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.
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.
The articles that are most relevant are probably ones from YC itself, along with ancillary material on startup woes, pitfalls, etc. Among the advice is how to validate ideas, is how to maintain momentum, knowing when to ship, when to wringing your hands and stop adding features, etc. Obviously geared towards startups and businesses but also applicable to projects.
The pieces of advice that I try and follow (and often fail at following) are:
* Commit to completing projects, not time. I'm bad at estimating time and putting time limits stresses me out. I prefer to work towards a goal rather than a time limit.
* Be vicious about removing features that are superfluous to the main project in order for it to ship. "Nice to have" features can be added later. A mediocre project that ships and can be improved later is better than a perfect project that never ships.
* Get some space. Getting a little burnt out is easy to do and almost inevitable. Even taking a day or week away sometimes recharges my batteries. The hopelessness I feel about the amount of effort required to complete seems less daunting once I've recharged. This is even better if it ships because the daunting extra "nice to have" features, refactoring or complete architecture overhaul seem less daunting when I'm rested and recharged.
* Don't get into "all or nothing" elements. Break up large projects into smaller manageable pieces as much as possible. Insofar as is possible, have smaller "shippable" elements that contribute to the larger project so that progress is apparent and, in the tragic event that the big project doesn't ship, there are smaller gains that have been done in its wake. Large projects also tend to shift during development so having smaller "wins" helps both with morale and provides tools to help shift course more easily.
* Don't be daunted by work. Rewriting parts of the architecture or even the whole thing might seem depressing but its a lot easier the second time around as the first attempt is exploring the ideas. A project with a clear specification is a lot easier to write than one where the specification is being written through trial and error. Elements of the project can also be used to accelerate the re-architecture/rewrite. Pixar famously scrapped many of their movies because they didn't work, only to rewrite it to be much better but they were able to re-use a lot of work and get back to the same point much faster the second time around. If what's had can be shipped, ship it, but in the case that it does need a rewrite, this often seems much more daunting than it is.
* Isolate complexity. Sometimes architectural elements need to be ugly for a variety of reasons (lack of knowledge about the domain, experimentation, exploration, effeciency, etc.). Beatiful code and proper abstraction is its own form of optimization and one should not prematurely optimize. Instead, give up the idea of writing beautiful code and let the code be ugly. The interface must be clean (or API, or resulting data) so that it can compose with the rest of the system and so that the ugliness doesn't infect other parts of the archicture, but the element itself need not be pretty.
* Make 'todo' lists. A minor hack but one that helps me a lot. There are different todo lists for different scopes. One big todo list for long reaching broad and underspecified goals ("epics" in agile language?) and smaller todo lists for day-to-day elements (fixing bugs, making functions, developing UI elements, etc.). The day-to-day todo also helps with morale as tangible progress can be seen as the items on the list get crossed off each day (I think PG is the original person I heard this from).
Completing projects is hard work. There's no real hack that will get you through it. To make sure you're in a position to do hard work, make sure the basics of the Maslow hierarchy are taken care of (food, sleep, cleanliness, shelter, money, social relationships, etc.).
The above list are what helps me complete projects but the overall one is that I'm of the mentality that it's a slog and that I should be prepared for it.
[0] https://youtu.be/CBYhVcO4WgI?si=5iMC6crzmPM3xfGe
The pieces of advice that I try and follow (and often fail at following) are:
* Commit to completing projects, not time. I'm bad at estimating time and putting time limits stresses me out. I prefer to work towards a goal rather than a time limit.
* Be vicious about removing features that are superfluous to the main project in order for it to ship. "Nice to have" features can be added later. A mediocre project that ships and can be improved later is better than a perfect project that never ships.
* Get some space. Getting a little burnt out is easy to do and almost inevitable. Even taking a day or week away sometimes recharges my batteries. The hopelessness I feel about the amount of effort required to complete seems less daunting once I've recharged. This is even better if it ships because the daunting extra "nice to have" features, refactoring or complete architecture overhaul seem less daunting when I'm rested and recharged.
* Don't get into "all or nothing" elements. Break up large projects into smaller manageable pieces as much as possible. Insofar as is possible, have smaller "shippable" elements that contribute to the larger project so that progress is apparent and, in the tragic event that the big project doesn't ship, there are smaller gains that have been done in its wake. Large projects also tend to shift during development so having smaller "wins" helps both with morale and provides tools to help shift course more easily.
* Don't be daunted by work. Rewriting parts of the architecture or even the whole thing might seem depressing but its a lot easier the second time around as the first attempt is exploring the ideas. A project with a clear specification is a lot easier to write than one where the specification is being written through trial and error. Elements of the project can also be used to accelerate the re-architecture/rewrite. Pixar famously scrapped many of their movies because they didn't work, only to rewrite it to be much better but they were able to re-use a lot of work and get back to the same point much faster the second time around. If what's had can be shipped, ship it, but in the case that it does need a rewrite, this often seems much more daunting than it is.
* Isolate complexity. Sometimes architectural elements need to be ugly for a variety of reasons (lack of knowledge about the domain, experimentation, exploration, effeciency, etc.). Beatiful code and proper abstraction is its own form of optimization and one should not prematurely optimize. Instead, give up the idea of writing beautiful code and let the code be ugly. The interface must be clean (or API, or resulting data) so that it can compose with the rest of the system and so that the ugliness doesn't infect other parts of the archicture, but the element itself need not be pretty.
* Make 'todo' lists. A minor hack but one that helps me a lot. There are different todo lists for different scopes. One big todo list for long reaching broad and underspecified goals ("epics" in agile language?) and smaller todo lists for day-to-day elements (fixing bugs, making functions, developing UI elements, etc.). The day-to-day todo also helps with morale as tangible progress can be seen as the items on the list get crossed off each day (I think PG is the original person I heard this from).
Completing projects is hard work. There's no real hack that will get you through it. To make sure you're in a position to do hard work, make sure the basics of the Maslow hierarchy are taken care of (food, sleep, cleanliness, shelter, money, social relationships, etc.).
The above list are what helps me complete projects but the overall one is that I'm of the mentality that it's a slog and that I should be prepared for it.
[0] https://youtu.be/CBYhVcO4WgI?si=5iMC6crzmPM3xfGe
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.