Hi HN, how do you do this? My current workflow is this:<p>1) Begin a new projects<p>2) Work in this project 1 or 2 days<p>3) ...<p>And that's it... Do you work everyday in your projects? You decide to work X days in a project and then "is finished"? Maybe you have a feature list and once everything is ready you stop working?<p>How you do this? :)<p>Thanks!
I've always lost motivation sometime shortly after starting on a new side project.So what I've done lately is when I think of something I'll then determine if there is a way to get it built and usable by the end of the day, even if it is just a simple script. This way I can actually later use the thing and when I have another idea to expand on it I can take that on later as another day's work.<p>This might not work for everyone but for me I've actually built a few useful tools that I use everyday and have been able to continue building on. The only 2 requirements needed before I undertake something is 1) that it is something I see myself using on a semi-daily basis and 2) that I can build it within a day.
Three steps to make sure you get more than 1 or 2 days out of it.<p>1.) Make it very crappy, and put it live for the world to see.<p>2.) Be embarrassed that this thing you made is so crappy.<p>3.) Use that embarrassment to make it better.<p>However, I suspect that the problem might be something else.<p>They say you should always be working on your best idea. Maybe you are jumping from project to project too fast?<p>Maybe you need to take more time to think about why you're starting certain projects.<p>Maybe the answer isn't finding more time working on projects. Maybe the answer is spending less time working on projects and more time thinking about possible projects.<p>Some random thoughts here. Sorry that it sounded a little Seth Godin-ish.
My recent workflow has been this:<p>1. Put the project in a private GitHub repo. Paying for it adds incentive to work on it.<p>2. Break up the work into small tasks and add them as issues in the GitHub project. Aggressively separate them into milestones to stay focused (Milestone 1 == MVP, less important stuff in Milestone 2, etc).<p>The reason I think this works is that it is easy to get overwhelmed by all the work on a side project, and you have limited time to work on it. Now when you have time, you grab a ticket, complete it. Each ticket should be doable in a few hours or the scope of your ticket is too broad.
Here are my suggestions:<p>1. Work on your project <i>most</i> days. It doesn't need to be long - 15-30 minutes. This is mentally doable most days, and you'll find days that you just work. After a while, this becomes part of your daily routine and it gets easier. It might be even easier if you do right after something else you do every day - yup, make it a habit.<p>2. Have a variety of tasks to choose from when you can. This helps with the motivation as well.<p>3. Be able to congratulate yourself for getting chunks done - or something similar. Whatever works for you.
I've fit this pattern for most of the things I build, though I'd replace "days" with "weeks" above.<p>The things I have finished are nearly all things I have put a price tag on.<p>They may have been done before I shipped them, but most weren't. But once there's the threat of real users sending you money and expecting things to work, that's incentive enough to actually wrap up loose ends and polish what's there.<p>Notice that what actually happened was a slight redefinition of "finished" to include all the features that currently work, with non-working features hidden and no pointy bits sticking out the sides. As distinct from "all the things I wanted to include are now working to my satisfaction."<p>Eventually you can work toward including all those other things, but step one is to polish what's there. Then it's just a matter of polishing each additional feature after they're built and before they're exposed to users.
3) Make a list of what you think your project needs before launching, but put as much as possible off until after launch, recognize that you can still work on it then<p>4) Do something on that list<p>5) Go back to #3 until you are launched<p>By postponing additional work you give those ideas time to mature while making concrete progress and finishing your project at least to some sort of functional state. By the time you're up to those tasks you will probably have identified why most of them weren't ever worth doing let alone derailing projects for.
I'm struggling to finish writing my third book right now. Here's what works best for me:<p>* Know the definition of "done" from the start. Working against a moving goalpost is a motivation killer.<p>* Have a consistent way to measure and track progress (word
count, features completed, etc), and graph it over time.<p>* Break the big project into smaller, bite-sized projects. Each time you mark a small part as complete, you'll feel a sense of relief.<p>* Make progress every day. Even if it's just a bit, it'll feel good to know that you're that much closer to finishing.
Finish the minimal viable part of the project very quickly.<p>Add the housekeeping parts and extra features later (if it's worth it i.e. being used by you or others).<p>Eventually when you do enough personal projects you will find that the housekeeping parts are the same and can be bolted on easily. That's another reason it's not worth doing anything except the minimal viable part of the project.
I've found the nature of the idea is quite important as well.<p>For example for a long time I used to do very "philosophical" projects.<p>Huge ambitious ones where before you even start you already know it's by definition going to take years for it to get to somewhere worthwhile.<p>Except I wasn't ready to commit to such things, and I knew it.<p>That tiny half-assed part of a huge project will not amount to anything.<p>So overtime I accumulated a great graveyard of "this would be cool if I had worked on it for a year instead of 2 weeks" projects.<p>On the other hand if the idea is small and practical you can work on something for 3 weeks and have something nice and practical that is a concrete achievement.<p>So if finishing is your goal and you don't have tons of time to dedicate to a project my advice is to ask yourself how practical and realistic is it for you to finish an implementation of that idea in your desired time-frame?<p>If it's a huge idea you have to accept the reality that in your amount of time you can't finish a significant % of it.<p>And 5% of a huge project is often not as useful or impressive as 120% of a tiny project.
I had never really finished a side project until recently. First one was something I was going to sell. It took over a year because of changing UI and redoing a lot of stuff (unnecessarily) but I managed some sort of soft launch. My most recent project was writing a mix task in elixir. It solved a pain point I was having and gave me a better insight into the Elixir language. I'm working on another library for Elixir that I plan to use in a website I'm working on that I want to set up in hopes of making money.<p>Bottom line, both of the projects I've started and finished have had monetary gain to it. The product and then the task. The task is helping with contracting I'm doing so making my job easier is sure a big incentive.
Two approaches:<p>1. Solve an actual problem. E.g. I built a library based on some use cases I saw at a training session I did at Cisco. Building yet-another-thing-that-has-900-implementations doesn't count.<p>2. Set a really hard deadline or limit. E.g. "must be feature complete by end of the weekend."<p>The goal either way is not to end up in place where it's 20% done: either you have problem or a deadline to keep you focused on completion<p>Longer writeup:
<a href="https://codewithoutrules.com/2016/09/09/side-projects/" rel="nofollow">https://codewithoutrules.com/2016/09/09/side-projects/</a>
1. Time box it. Pick a date that you will release, go live, ship, whatever. Pick a date.<p>2. Break it into smaller tasks.<p>3. Prioritize those tasks and start with the easiest.<p>4. This is not time to learn, this is time to build. Use only tools that you know. Even if you know there is a better way, do it the best worse way that you know than the better best way you have heard of but don't know and will have to stop and learn. This is key, separate learning and building.<p>5. Work on it everyday, at a consistent time, preferable first thing in the morning.<p>6. Since you will be waking up early, go to bed early too and get enough sleep.<p>7. Work on only one project at a time, meaning, you can't work on other projects in between. Everything else goes on hold till this is completed.<p>8. Find ways to motivate and inspire yourself when you are feeling mentally down and low and focus is hard to come by. If you really like music, don't listen to it all the time. work without it, when you find yourself drained, that's when you should turn on music. Unless you absolutely can't work without it. Whatever that gives you extra boost, hold off from it till you really need it. Coffee? Don't drink it, till you need it. Think of it like power up. Save it till you need it.<p>9. Is it ship date? Release it, only 70% done? Release it!
If I haven't launched in 3-4 months I'll dump it and work on something else that is more exciting. If you can't launch in 3-4 months you've either bitten off more than you can chew or don't give a damn about it.<p>On a day to day basis, I dedicate 2 to 3 hours to my side project (side business). This includes maintenance for previously launched projects and work on the "new" project.<p>I only ever have one "new" project going that hasn't been launched.
A few things that seem to work:<p>1) Define a single, easily understood high-level goal. Something that's easily understood and can be accomplished in a timespan of days or weeks. It's important that this is not defined technically, but in terms of <i>what the application can actually do</i>.<p>2) Repeatedly ask myself whether what I'm doing is directly contributing to the current goal, or is required to reach it. If it's not, stop doing it and figure out what's going to get me there the fastest.<p>3) Wake up early and work on my project <i>before doing anything else.</i> Every morning I wake up, take a shower, kiss my partner on the forehead and then I am out the door to work on my project at the cafe down the street. This is the part of the day where my mind is the most fresh, and it's not possible that something else has taken my attention and distracted me from the goal at hand, or tired me out so much I don't have the energy to work on it. Also once you get in the habit it's hard <i>not</i> to work on it once you wake up.
I've spent many many years half-completing things... I think it's a really common pattern. I recently, finally, completed something and launched it (<a href="https://schezzle.com" rel="nofollow">https://schezzle.com</a>). The trick is to just make yourself launch. Stop thinking about the business aspects, or scale, or really anything other than launching and just do it. I made a New Years resolution and held myself to it, and it feels great. Instead of watching TV or reading in the evening, pour a cup of coffee, make a TODO list, and start checking things off!
Just like it you do at a company..<p>1-Plan, prioritize, schedule;
2-Use a scrum.. even if you are the master, the team, the stakeholder all at the same time. Tip: don't forget the stand-up meeting.<p>I've learned it from a German colleague (and great friend) who even use scrum to manage his own house activities... yeah he was kind of sick.
If you're procrastinating your brain is telling you it's not important. You can push yourself with motivational tricks but you might won't get anywhere.<p>It might be better to get some value out of it and/or convince your brain why it's worth doing.
I treat personal projects like therapy. Doing something for me, trying something new makes me feel good. Even if I just have a working prototype I have the sense that I've accomplished something. It doesn't matter much if nobody sees it. If that were the case, those personal projects would turn to work and I have enough of that already.<p>That being said, I do finish side projects from time to time, mostly because I can still see the potential after working on it for a couple of ours.
What I do is spend a bit of time, and write down all of the features I could possibly want in my program as GitHub issues. I sort them in the order of usefulness/ones I want most, and I set a timer for 25 minutes and write as many features as possible (the code can get a little messy but you can fix it up later.) Rinse and repeat until you're burned out.
Do people find it worth the time to read books on productivity like Getting Things Done, Eat that Frog, etc.? And learning more about things like Org mode? Or are those essentially procrastination enablers? Is see that most people are working on software personal projects. Anyone have thoughts getting "hardware" projects done?
My strategy is to push out the first working version in that first 2-3 days and get feedback. I have recently, compiled and published my experience and thoughts on this exact topic as a book : <a href="http://amzn.to/2iUYaOH" rel="nofollow">http://amzn.to/2iUYaOH</a>
increase human to project ratio! Humans keep humans accountable. Find people fun to work with.<p>Choose to work on projects that help other people, or are inspired by others' passion.<p>Keep a list of tasks always visible next to your bed, to remind you to work on stuff when you have time.<p>Be okay with taking a few months break if you need it. Guilt for not working on your own projects accrues, only making it worse. You have to be able to easily alternate between actively working on it, and not.
My workflow is usually to lose interest and motivation right around the time I have it rough, ready and working. Rather than do the last polish and site to release I would end up doing other hobbies.<p>It's been frusrtating.
I suggest you read "Just F*cking Ship".<p>It's pretty good, and it goes into details on why we can't launch products/finish personal projects.