4 ms·

One thing I learnt in a thread on HN a long time ago and that I use a lot to just keep working on side projects : Make sure you stop half way through a sentenc

One thing I learnt in a thread on HN a long time ago and that I use a lot to just keep working on side projects : Make sure you stop half way through a sentence / line of code. Don't finish that article, or don't stop with code that compiles. The reason is stupid simple : It just removes all the blockers of starting working on the project again. It removes the initial step, which is usually the hardest. Come in, finish that function and make it compile. Boum, now you're in the flow just keep going :). Also, it's ok to stop side projects if they're not fun any more. Stop beating yourself :). You most likely learnt in the process, which was the original goal. EDIT : Not meant to be taken as a silver bullet at all! Just a small trick to keep a 'live thread' between you and the project.

maltelandwehr 6y ago
This is especially true for writing! For coding, I have found it only works for me when I have some failing tests. And unfinished line of code with more than a trivial thing missing, might actually slow me down.
- jlengrand 6y ago
  Are you assuming I am writing tests on any of my projects ? o_0 haha. I like it for writing a lot indeed, because It keeps a thread in the back of my head that just wants to refine the idea further and come back to the draft.
OhRoG9th 6y ago
I've been using most of my free time in the last decade to write side projects (for my own use, not published ones), and I strongly agree with the author that small steps are key. Although, reading your comment, I suspect that as often, generalizing this idea is probably an error, and I don't doubt what you describe works best for you and the people you mention from the HN thread (and thus, probably many others). For me, product design (both professionally and for side projects) is all about dividing features. Any time I think about a feature, it doesn't take a long thinking time to realize there are several features in there. I keep dividing until I can't anymore, and then I prioritize them in a todo list, parts of a "feature" often ending up after parts of an other feature, because it turns out they're not that important. This helped me a lot for side projects, because I've reached a point where the unit of time for writing a feature is the hour (only on side projects, the unit of time is the day, professionally, because there always are more complicated needs). And this is what does it for me for side projects : knowing that when I start something, I'll have something useful in return at the end of my session, and having a clearly organized global todo list of all tasks for all my side projects. When I open my todo list each day, I'm generally excited thinking of what the topmost item will allow me to do, and it's only a few hours away!
- jlengrand 6y ago
  200% agree. People are different, what works for one might not work for others. It's just one trick out of many others. You seem to be using side-projects as something with an end goal, which I admire :). Most of my projects are more 'let's try to use this new thing to...'. Interestingly, features have a very beneficial effect for me in the short term (few days / weeks) and a very adverse one in the long run. By building a 'feature list' when I start a side project it's almost like if I was removing half the fun and it start looking much like work again. So I try to not look ahead too much and enjoy the ride. That's why I love doing side projects with other people as well when I can : you can feed off what excites others as well and combine different motivators :).
zurfer 6y ago
I am sure this advice worked for you, but I find it ironic that to "finish" a side project, you should not "finish" sub-tasks. However I completely agree that you should make it as easy as possible for you to get started and see some success. For me that usually starts with a mockup and bit by bit the mockup becomes something more.
- jlengrand 6y ago
  Definitely. I didn't intend my comment to be taken as a 'one trick to rule them all and make sure you'll finish your side projects from now on' :). It's simply a dirt simple trick that helped me a lot because it keeps a 'live thread' between the project and me. This feature I know I have to finish, the low friction to start, ... It's not a silver bullet, and of course at some point you have to finish stuff up to complete your project. Starting small is definitely a good idea as well indeed.
s3krit 6y ago
This approach is something I actually use across a wide variety of things. Particularly (so long as there's not a super-tight deadline), not finishing a task at work before the end of the day - no 'oh I'll just get this one thing finished'. If I've got a task I'm already well into, then coming back to it the next day and jumping write in gets you back into that zone.
scandinavegan 6y ago
I agree and disagree! I've seen the comments where the issue is nuanced, but I'll add some of mine. I play point-and-click video games remotely with a friend. We always try to stop our sessions when we have an idea of what we want to try next, because it's much easier to start again next time. You know that you want to try to attach the rope to the tree, which means you immediately get back into the game next time. On the other hand, I've programmed a video game with the same friend. We programmed separately, checking out a shared file of code. This meant that I always wanted to pass on a functioning version of the game. It's obvious that I wouldn't want to check in a version mid-code line, but even more than that, I got a kick out of only attempting to add things small enough so that I could finish in one evening. Aiming to always hand off a functioning version of the game made me both take on appropriate-sized tasks, and made it more fun to check in the code so that my friend could try the latest version of the game when he started coding. There's something to be said for checking out a functioning version of the game, looking through the list of features we want to add, and then picking the one that looks easiest/most fun right now. If I had a half-finished feature to complete, I may not feel like it the next time I start, which would make me put off working on the game. A half-finished feature may make it easier to start, but aiming to always finish a feature made me keep my ass in the chair instead of switching to playing a video game or watching Netflix. A lot of authors would agree with your advice (I think that Hemingway talked about it in an interview, and Stephen King in the book On Writing), but I suggest trying both this method and the variant where you always try to have a functioning project and add new small features.
- jlengrand 6y ago
  Yes! :). I've done just that the past couple weeks building a game with a friend for a game jam. In that case, having the latest version of the game up and running was the strongest motivator so I didn't need tricks. I definitely recognize what you are saying. Things don't have to be black or white, and this is a good nuance
  - cutemonster 6y ago
    Seems to me you can do both at the same time: push a finished feature to the Git master branch, and a w.i.p. feature incl a compilation error to a personal branch
myth2018 6y ago
The thing of stopping half-way to have a clear beginning next time operated wonders for me too. Not necessarily leaving a task incomplete: in case of small tasks, it also worked for me to have the next task clearly defined.
tvanantwerp 6y ago
This only works if you can remember what you stopped in the middle of. I often come back to projects with no idea what I was last doing, so now I've got some half-finished bit to figure out rather than something that could be clearly understood.
- wool_gather 6y ago
  Parent's tip works best if you're coming back the next day so that you can easily reload the mental context you were in. If you know there will be more time before you return, you generally need to write yourself notes that are reasonably detailed to allow you to recover that context. In which case the trick may not be worth it.
- jitendrac 6y ago
  Each time I find myself stopping in middle for brief time, I intentionally leave error and comment pointing out status and next step of project. Next time just come and compile/run and see last work.
cik 6y ago
Removing all barriers to entry is definitely key. This includes spin up / spin down time to even get into the groove. To whit I usually: 1. Keep a dedicated desktop set (I'm running Linux) plugged into my side project. 2. In my editor I maintain a "where am I" document, and update accordingly. 3. I leave things (from a code perspective) committed and pushed. 4. I leave a specific note to myself on what I think I need to do next, based on my thinking at the time. 5. I book a meeting in my own calendar with the note from #4 so that it's forced to be in front of my face, and my desktop There are other things, but this gets the ball rolling.
- ar_lan 6y ago
  I do a similar process, but yours sounds better. I literally just Slack myself a list of TODOs at the end of the day, but I sort of want to try your process. Especially with being WFH, it's easier to keep my place in specific apps. Are there any other things you do to get yourself started in flow?
  - cik 6y ago
    Not really. Having a documented series of next steps, combined with current thoughts is as good as I can get. The only other key difference is that I treat sides much like work. I disable all my notifs across the board and aim for dedicated time. What do you do to get started in flow?
glaugh 6y ago
“The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.” Hemingway

maltelandwehr 6y ago

This is especially true for writing! For coding, I have found it only works for me when I have some failing tests. And unfinished line of code with more than a trivial thing missing, might actually slow me down.

jlengrand 6y ago
Are you assuming I am writing tests on any of my projects ? o_0 haha. I like it for writing a lot indeed, because It keeps a thread in the back of my head that just wants to refine the idea further and come back to the draft.

OhRoG9th 6y ago

I've been using most of my free time in the last decade to write side projects (for my own use, not published ones), and I strongly agree with the author that small steps are key. Although, reading your comment, I suspect that as often, generalizing this idea is probably an error, and I don't doubt what you describe works best for you and the people you mention from the HN thread (and thus, probably many others). For me, product design (both professionally and for side projects) is all about dividing features. Any time I think about a feature, it doesn't take a long thinking time to realize there are several features in there. I keep dividing until I can't anymore, and then I prioritize them in a todo list, parts of a "feature" often ending up after parts of an other feature, because it turns out they're not that important. This helped me a lot for side projects, because I've reached a point where the unit of time for writing a feature is the hour (only on side projects, the unit of time is the day, professionally, because there always are more complicated needs). And this is what does it for me for side projects : knowing that when I start something, I'll have something useful in return at the end of my session, and having a clearly organized global todo list of all tasks for all my side projects. When I open my todo list each day, I'm generally excited thinking of what the topmost item will allow me to do, and it's only a few hours away!

jlengrand 6y ago
200% agree. People are different, what works for one might not work for others. It's just one trick out of many others. You seem to be using side-projects as something with an end goal, which I admire :). Most of my projects are more 'let's try to use this new thing to...'. Interestingly, features have a very beneficial effect for me in the short term (few days / weeks) and a very adverse one in the long run. By building a 'feature list' when I start a side project it's almost like if I was removing half the fun and it start looking much like work again. So I try to not look ahead too much and enjoy the ride. That's why I love doing side projects with other people as well when I can : you can feed off what excites others as well and combine different motivators :).

zurfer 6y ago

I am sure this advice worked for you, but I find it ironic that to "finish" a side project, you should not "finish" sub-tasks. However I completely agree that you should make it as easy as possible for you to get started and see some success. For me that usually starts with a mockup and bit by bit the mockup becomes something more.

jlengrand 6y ago
Definitely. I didn't intend my comment to be taken as a 'one trick to rule them all and make sure you'll finish your side projects from now on' :). It's simply a dirt simple trick that helped me a lot because it keeps a 'live thread' between the project and me. This feature I know I have to finish, the low friction to start, ... It's not a silver bullet, and of course at some point you have to finish stuff up to complete your project. Starting small is definitely a good idea as well indeed.

s3krit 6y ago

This approach is something I actually use across a wide variety of things. Particularly (so long as there's not a super-tight deadline), not finishing a task at work before the end of the day - no 'oh I'll just get this one thing finished'. If I've got a task I'm already well into, then coming back to it the next day and jumping write in gets you back into that zone.

scandinavegan 6y ago

I agree and disagree! I've seen the comments where the issue is nuanced, but I'll add some of mine. I play point-and-click video games remotely with a friend. We always try to stop our sessions when we have an idea of what we want to try next, because it's much easier to start again next time. You know that you want to try to attach the rope to the tree, which means you immediately get back into the game next time. On the other hand, I've programmed a video game with the same friend. We programmed separately, checking out a shared file of code. This meant that I always wanted to pass on a functioning version of the game. It's obvious that I wouldn't want to check in a version mid-code line, but even more than that, I got a kick out of only attempting to add things small enough so that I could finish in one evening. Aiming to always hand off a functioning version of the game made me both take on appropriate-sized tasks, and made it more fun to check in the code so that my friend could try the latest version of the game when he started coding. There's something to be said for checking out a functioning version of the game, looking through the list of features we want to add, and then picking the one that looks easiest/most fun right now. If I had a half-finished feature to complete, I may not feel like it the next time I start, which would make me put off working on the game. A half-finished feature may make it easier to start, but aiming to always finish a feature made me keep my ass in the chair instead of switching to playing a video game or watching Netflix. A lot of authors would agree with your advice (I think that Hemingway talked about it in an interview, and Stephen King in the book On Writing), but I suggest trying both this method and the variant where you always try to have a functioning project and add new small features.

jlengrand 6y ago
Yes! :). I've done just that the past couple weeks building a game with a friend for a game jam. In that case, having the latest version of the game up and running was the strongest motivator so I didn't need tricks. I definitely recognize what you are saying. Things don't have to be black or white, and this is a good nuance
- cutemonster 6y ago
  Seems to me you can do both at the same time: push a finished feature to the Git master branch, and a w.i.p. feature incl a compilation error to a personal branch

myth2018 6y ago

The thing of stopping half-way to have a clear beginning next time operated wonders for me too. Not necessarily leaving a task incomplete: in case of small tasks, it also worked for me to have the next task clearly defined.

tvanantwerp 6y ago

This only works if you can remember what you stopped in the middle of. I often come back to projects with no idea what I was last doing, so now I've got some half-finished bit to figure out rather than something that could be clearly understood.

wool_gather 6y ago
Parent's tip works best if you're coming back the next day so that you can easily reload the mental context you were in. If you know there will be more time before you return, you generally need to write yourself notes that are reasonably detailed to allow you to recover that context. In which case the trick may not be worth it.
jitendrac 6y ago
Each time I find myself stopping in middle for brief time, I intentionally leave error and comment pointing out status and next step of project. Next time just come and compile/run and see last work.

cik 6y ago

Removing all barriers to entry is definitely key. This includes spin up / spin down time to even get into the groove. To whit I usually: 1. Keep a dedicated desktop set (I'm running Linux) plugged into my side project. 2. In my editor I maintain a "where am I" document, and update accordingly. 3. I leave things (from a code perspective) committed and pushed. 4. I leave a specific note to myself on what I think I need to do next, based on my thinking at the time. 5. I book a meeting in my own calendar with the note from #4 so that it's forced to be in front of my face, and my desktop There are other things, but this gets the ball rolling.

ar_lan 6y ago
I do a similar process, but yours sounds better. I literally just Slack myself a list of TODOs at the end of the day, but I sort of want to try your process. Especially with being WFH, it's easier to keep my place in specific apps. Are there any other things you do to get yourself started in flow?
- cik 6y ago
  Not really. Having a documented series of next steps, combined with current thoughts is as good as I can get. The only other key difference is that I treat sides much like work. I disable all my notifs across the board and aim for dedicated time. What do you do to get started in flow?

glaugh 6y ago

“The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.” Hemingway