7 ms·

I think the main issue on side projects is managing your own expectations. You have to be realistic and think that as the name implies is something you do on th

I think the main issue on side projects is managing your own expectations. You have to be realistic and think that as the name implies is something you do on the side and it's not your main priority. So try to work on it as much as you can but don't blame yourself if you can't work on it for a day or a few days. We all have lives and have stuff to do that are more important then side projects otherwise they wouldn't be called that way. I'm devoting a single our per day on an android app and i'm having a great progress, i'm doing a tiny feature every day. And that's fine, it's done when it's done, i'm the one doing it and managing so there's absolutely no problem. If you start looking at the side project in a very serious way, you'll end up with guilt , frustration and remorse and that just kills the fun out of it.

bgilham 10y ago
That's definitely something to keep in mind. Thanks for the reminder :) It's so easy to focus on getting shit done, to the exclusion of treating yourself well sometimes. I think I need to plan a follow-up.
0xfeba 10y ago
How, with just an hour, do you manage to get anything meaningful done? I've tried that and I have to spend 10 minutes figuring out where I was, 15 minutes researching how to do the next bit that I want (esp. for a project in a new dev environment), 10 minutes upgrading various libraries or other stuff that is needed/needs updating, and then maybe 25 minutes of actual coding. I progresses very slowly. Maybe my side projects are too ambitious, at least relative to my skill in their respective areas.
- knz 10y ago
  Isn't this one of the appeals of the "Don't break the chain"/Jerry Seinfeld approach? My working on something each day, even if only for an hour, you keep the mental tasks associated with development in the "front" of you brain. Likewise using tools like Trello - make simple lists "To do, doing, done", rank them in order, and start working on whatever is at the top of the "to do" list?
- calferreira 10y ago
  I'm doing a blogger client. Is very straight forward to think on how it should work. Day 1 - Implement Google SignIn Day 2 - Implement List Blogs. Etc. I do research during the day and save important bits on pocket or google keep, so when i have that hour i can be more productive.
- jrheard 10y ago
  One thing that's been useful for me on this topic is to keep a simple dev diary. Mine looks like this: https://github.com/jrheard/voke/blob/master/dev-diary.txt https://github.com/jrheard/voke/blob/master/dev-diary.txt . I use it to get as much project state as possible out of my head and into git. For "10 minutes figuring out where I was", I can just look at the end of my last diary entry, where I've often left a note like "this is what i'm working on: foo" or "do this next: foo, bar, baz" or "currently stuck on baz". And if I haven't left a note like that, I can usually deduce one by scanning the last few paragraphs of the last day's entry. For "15 minutes researching how to do that next bit I want", that has to happen no matter what, but I like recording that research in my dev diary so that I can search through it later if I run into the problem again or want to remind myself why I settled on a particular solution - and I find that forcing myself to write down my analysis of this research helps keep me on task during the research process and helps prevent me from getting distracted. You get the idea. I don't have any written-down rules about how to keep a dev diary, what goes in there and what doesn't, best practices about solving X software engineering problem by implementing certain dev diary techniques - I just have a freeform text file that I write my thoughts into every day when I'm working on my project. It seems to be a useful technique for me, maybe it'd work for you! I used to do the don't-break-the-chain jerry-seinfeld thing, but I find it too stressful, it starts to really affect my quality of life (and the quality of the work that I do!) when I've got a chain going that's more than a month long. Plus, if the point is to prevent thoughts/state/meta stuff around the program from slipping out of your mind over time, writing it down seems to me like a good (better?) way of solving that problem. When I find a problem that recurs in my dev diary without me coming up with a solution, or I have an idea that I'm not going to work on now and which I worry will be lost in the folds of my diary, I find an issue tracker like GitHub's (eg https://github.com/jrheard/voke/issues https://github.com/jrheard/voke/issues ) helpful.
  - tachyonbeam 10y ago
    That's very similar to what I do. I have a TODO list that includes notes, and big features that I break down into very small tasks. I can get back where I was on a project in just one minute, because the TODO list tells me. When debugging a difficult issue, I also take notes about my findings, and ideas of directions to investigate next.
- d3ad1ysp0rk 10y ago
  There are some methods to figure out where you were - I will not prescribe one, but a few are; leave work unfinished, manage a trello board with small functional pieces and prioritize the list, write lots of comments, write non-passing tests, etc. Also, if you're putting in an hour a night, why are you updating packages?
  - dwightgunning 10y ago
    I find that writing myself a note with the next couple of things I need to do or try out (if I'm stuck) really helps.
  - 0xfeba 10y ago
    True, it's more like an hour every few days.
- ryandrake 10y ago
  Funny--when you get married, have a child, etc. all of a sudden you learn by necessity how to be productive with a whole bunch of 15-minute timeslots (perforated by feeding, crying, playtime, etc.) instead of a single, peaceful 4-hour session.
6stringmerc 10y ago
Agreed. My part-time (personal time) side projects are now focused on feature length screenplays. Those clock in 80 to 120 pages. Not exactly happening in just one sitting. Takes time, planning, and also, like you say, being personally attentive and accountable without too much pressure. My third and most recent is my longest 121 pages, and it took approximately 3 months from sketching out (based on short stories) to final page final period. I can definitely state that there were 2 week stretches where it didn't get touched at all - either due to writer's block about something or 'just not feeling it' but I found my way back time and again and glad to hit the finish line that I'd set for myself.

bgilham 10y ago

That's definitely something to keep in mind. Thanks for the reminder :) It's so easy to focus on getting shit done, to the exclusion of treating yourself well sometimes. I think I need to plan a follow-up.

0xfeba 10y ago

How, with just an hour, do you manage to get anything meaningful done? I've tried that and I have to spend 10 minutes figuring out where I was, 15 minutes researching how to do the next bit that I want (esp. for a project in a new dev environment), 10 minutes upgrading various libraries or other stuff that is needed/needs updating, and then maybe 25 minutes of actual coding. I progresses very slowly. Maybe my side projects are too ambitious, at least relative to my skill in their respective areas.

knz 10y ago
Isn't this one of the appeals of the "Don't break the chain"/Jerry Seinfeld approach? My working on something each day, even if only for an hour, you keep the mental tasks associated with development in the "front" of you brain. Likewise using tools like Trello - make simple lists "To do, doing, done", rank them in order, and start working on whatever is at the top of the "to do" list?
calferreira 10y ago
I'm doing a blogger client. Is very straight forward to think on how it should work. Day 1 - Implement Google SignIn Day 2 - Implement List Blogs. Etc. I do research during the day and save important bits on pocket or google keep, so when i have that hour i can be more productive.
jrheard 10y ago
One thing that's been useful for me on this topic is to keep a simple dev diary. Mine looks like this: https://github.com/jrheard/voke/blob/master/dev-diary.txt https://github.com/jrheard/voke/blob/master/dev-diary.txt . I use it to get as much project state as possible out of my head and into git. For "10 minutes figuring out where I was", I can just look at the end of my last diary entry, where I've often left a note like "this is what i'm working on: foo" or "do this next: foo, bar, baz" or "currently stuck on baz". And if I haven't left a note like that, I can usually deduce one by scanning the last few paragraphs of the last day's entry. For "15 minutes researching how to do that next bit I want", that has to happen no matter what, but I like recording that research in my dev diary so that I can search through it later if I run into the problem again or want to remind myself why I settled on a particular solution - and I find that forcing myself to write down my analysis of this research helps keep me on task during the research process and helps prevent me from getting distracted. You get the idea. I don't have any written-down rules about how to keep a dev diary, what goes in there and what doesn't, best practices about solving X software engineering problem by implementing certain dev diary techniques - I just have a freeform text file that I write my thoughts into every day when I'm working on my project. It seems to be a useful technique for me, maybe it'd work for you! I used to do the don't-break-the-chain jerry-seinfeld thing, but I find it too stressful, it starts to really affect my quality of life (and the quality of the work that I do!) when I've got a chain going that's more than a month long. Plus, if the point is to prevent thoughts/state/meta stuff around the program from slipping out of your mind over time, writing it down seems to me like a good (better?) way of solving that problem. When I find a problem that recurs in my dev diary without me coming up with a solution, or I have an idea that I'm not going to work on now and which I worry will be lost in the folds of my diary, I find an issue tracker like GitHub's (eg https://github.com/jrheard/voke/issues https://github.com/jrheard/voke/issues ) helpful.
- tachyonbeam 10y ago
  That's very similar to what I do. I have a TODO list that includes notes, and big features that I break down into very small tasks. I can get back where I was on a project in just one minute, because the TODO list tells me. When debugging a difficult issue, I also take notes about my findings, and ideas of directions to investigate next.
d3ad1ysp0rk 10y ago
There are some methods to figure out where you were - I will not prescribe one, but a few are; leave work unfinished, manage a trello board with small functional pieces and prioritize the list, write lots of comments, write non-passing tests, etc. Also, if you're putting in an hour a night, why are you updating packages?
- dwightgunning 10y ago
  I find that writing myself a note with the next couple of things I need to do or try out (if I'm stuck) really helps.
- 0xfeba 10y ago
  True, it's more like an hour every few days.
ryandrake 10y ago
Funny--when you get married, have a child, etc. all of a sudden you learn by necessity how to be productive with a whole bunch of 15-minute timeslots (perforated by feeding, crying, playtime, etc.) instead of a single, peaceful 4-hour session.

6stringmerc 10y ago

Agreed. My part-time (personal time) side projects are now focused on feature length screenplays. Those clock in 80 to 120 pages. Not exactly happening in just one sitting. Takes time, planning, and also, like you say, being personally attentive and accountable without too much pressure. My third and most recent is my longest 121 pages, and it took approximately 3 months from sketching out (based on short stories) to final page final period. I can definitely state that there were 2 week stretches where it didn't get touched at all - either due to writer's block about something or 'just not feeling it' but I found my way back time and again and glad to hit the finish line that I'd set for myself.