Don’t get me wrong, I think quitting something dumb is a great idea 💡. And there’s a big difference between quitting and pivoting.
But what I mean is to start a coding project (could also apply to non-coding just as well) and get 75% of the way and then stop. I’ve done that lots of times and there’s no better way to burn out and kill your motivation than that.
Quitting Too Early
What I felt after jumping from one idea to another:
- lack of connection with the current project
- lack of motivation to see the current project through
- the weight of the previous project(s) still undone
- the weight of time wasted, even though I’d rationalize that it was well spent because of the coding skills gained
Usually, the projects that I couldn’t take over the finish line had something difficult (I mean, probably anything that adds value to someone else has a difficult piece to it that needs to be solved 🤦) and because of poor planning, that difficult spot would always be at the end, right before our hypothetical “launch” date.
I should add to that list a bit of shame. Whenever I’d bring up the project, I’d be proud at first that I got it most of the way, and then be ashamed when the answer to “Can I see it?” was always, “It’s almost done, you can see it in a little bit.”
There’s nothing better than telling someone about a project, giving them a link, and letting them check it out for themselves.
Sticking With It
So how can you avoid the baggage of projects left hanging?
- Plan out your project well
- Get the MVP up and running
- If you need a break, take it
- Optimize and iterate till it rocks
A bit more info about each of those…
- Sometimes it’s hard to really anticipate what your app is going to need down the line, but you’re not building for that User yet. You’re building for user #1. You’re creating your M.V.P. (minimum viable product) to test if it has a place in the market and if it’s scalable (or another way I think about this one is if enough of the market will actually pay you for it). If you foresee a hard part, try building that first. I think you’ll thank yourself later.
If you’re building for fun, then just build it to get it live and in the hands of someone, even if that someone is you. Build it to get it working. I would say don’t even worry about performance optimization, efficiency, unused packages, or anything like that. Just get that sucker up and running.
It’ hard to build something others can find value from. Start with the most basic version, get feedback, and iterate.
- Sometimes, at the end of getting a project live, you can be burnt out. It’s okay. Take a break, do some Yoga, go to your community pool. Get out and do something else that is totally different from coding. Just focus on something different enough to give your brain a chance to recoup. Maybe you won’t need a break, and that’s great too. Charge on!
- Whether you still have the energy or you’re recharged, get back to your app. If you hate it and wish it were dead, then do with it whatever you want. BUT AT LEAST IT’S FINISHED! Or you can let it hang by itself and just see what happens.
But if you ARE into it still, then look at the pieces of your app and think about how you can do them better. This is a great time to reach out to more experienced developers and see what they’d do differently. You could open source your work and then really see if others could bring something to the table. That has tons of benefits in it by itself 😉.
What I felt after a project was finished and live with User(s):
- proud — really happy that something I created was live and being used
- calm because that bit of baggage was offloaded
- smarter because I did it!
- ready to share it with friends and other developers
Heroes get remembered, but legends never die.
That has nothing to do with this (at least I don’t think so 🤔), I just like that quote.
Finishing a project is key to progression. It doesn’t matter how big or small the project is. What matters is that you follow through, learn, and have fun.