I'm like every other developer, I start a personal project, get really invested in it for a week or so - then I give up on it. Which isn't ideal.
The last couple months I've been trying to figure out a way to actually finish some of my old projects off. I used to follow the 200 crappy words a day rule - meaning write at least one line of code a day. This worked well in the beginning, but I began to exploit this where I'd convince myself that just updating the README.md would warrant as writing code which of course, it doesn't.
I do have some pretty READMEs though.
Leaving your project in a state of doing
The one thing I've learned that keeps me motivated to do one of my side projects is leaving it in a state of doing. So when you're smashing the keyboard and get to a natural stopping point - you fix the bug, finish the feature, hack NASA - don't stop, keep on going.
The hardest part of doing anything, is starting. If you finish at a natural stopping point then you're going to have to find your next starting point, but if you finish at an unnatural stopping point then jumping back into that work is going to be much easier as you already know what needs to be done - you'll likely spend much of the following day thinking about that unimplemented feature and potential ways to improve it.
A good way I enforce this myself is to set a timer, I set the timer for an hour and when that hour is up I completely stop what I'm doing no matter how unfinished the feature is, no matter how close I am to fixing the bug. The fact that I'm so close to getting something done will give me extra motivation tomorrow to jump back into it with a fresh head full of ideas!
Thank you, if you like my rambling check out my personal blogging site at https://codeheir.com/
This blog is sponsored by Code Canvases
Make your room come alive with the coolest programming/coding canvases on the market. codecanvases.com is the number 1 seller for programming prints with 100% exclusively designed canvases. Get them now whilst they're 20% off!!
Top comments (16)
I like the idea of setting a timer. Just need to make sure I'll write down some notes of ideas I have so that I can pick up quickly the next day. While coding I also often have ideas. I will create a GitHub issue for each of them, so there is always something to work on.
Yeah I also create a number of github issues!
I like this, but I'd also offer that you should drop TODO items and post issues on your repo to give you focus on that next thing.
Yeah I do that too, Github issues usually. But just making sure youβre currently doing one of those items on the todo at a given time so you know where to jump back in!
Agreed
The timer idea is cool. I will try that soon.
I normally try to leave a failing test. The failing test in combination with the name of the test will bring me right back to where I was and what needs to be done.
I find starting half way through an unfinished feature doesn't work for me because I have to spend time refreshing my memory and working out where I was up to. Something I'm trying at the moment is making the most of jest's
test.todo
method. I'm working on a side project where all my to-do items are written up front astest.todo('item todo')
then, each day I make sure I complete at least one of my tests. Once all my to-dos are done I'll have a product that's ready to launch. At least that's the plan π€This is the one hard thing I've been struggling with especially when I'm trying to learn a new technology or build a project on something I've never approached before or perhaps beyond my skill set.
I'm gonna try the timing idea, the github issues and probably reading.
Wow this is actually a really good mind hack! I'm gonna give it a try
Thank you! Would love to hear how it goes.
Yeah, it works very well π anytime when I leave at coding stage, the motivation keeps me until I get back
Ohh I like this mind hack. I am going to try this! Thank you.
I have tried a few times to write code every day. I end up adding comments or working on something not even close to the critical path.
youβre welcome π
Yeah weβve all been there! Me especially.
Ditto to setting a timer!
allow 2 minutes per line,
time yourself
commit the code
push every tenth commit
analyse results at every daily self review
rework this very recipe as insights dictate them
kudos mr Woody Zuil
or just read dev.to instead lols