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.
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!
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 :).
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.
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
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
“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.”
If you need to go to a café and create a new user for each new side project, you’re not gonna work a lot. I understand needing separate contexts for separate projects but this seems like overkill. The context is in your mind, not your environment.
I have my share of past and ongoing side projects, including hobby websites [1], funny tutorials [2], an ebook [2], coding references [4] and a CSS framework [5].
Like the blog says, the motivation is always here at the start. It’s the second part, when this motivation fades, that is hard. What you need is discipline. I work from home so discipline is key, even in my professional work. How you acquire it is through time management: you need to dedicate time to a project. I do this through predefined 2-hour slots each day or week where I have to work on a project. That way I don’t have an endless timeframe in my kind (because endless would mean “this is never be finished”) and provides me a repeatable and reproducible pattern. And by scheduling it in advance, it provides me with a plan to look forward too, and not end up sitting in front of my computer during a break and asking myself “What should I do now?”.
Discipline doesn't work for everyone. I suspect most folks who are reading this article are doing so because they failed at self-discipline (like myself).
Instead, I suggest observing how long your motivation tends to last (~2 weeks for me). Then at the very start of the project ruthlessly cut down the scope to something you think you could actually get done in that time period.
This will probably require you to simplify some of the stuff you were planning to develop
Maybe you'll adopt just one new tool you need to ramp up on instead of five.
But by embracing the ticking motivation deadline you can modify the work you take on to something that you'll actually finish.
I wrote about this recently, and how I applied this technique to a project I was working on.
Alongside discipline there's also simply losing interest. There are projects I could maintain over a long period because I still believe in them, but most I stop caring about. I've probably picked up and dropped music the most, often for something else.
I think Bukowski's aphorism "don't try" is useful. He means that he was always compelled to write, and that if you have to force yourself consistently, it's probably not for you. That being said, discipline is still forever important. There's a difference between my laziness and general interest in something.
Great that works for you, but your argument sounds akin to asking why someone couldn't score high on the exam when you did. Different people, different motivations. I relate more to the OP than you. Just saying "be disciplined" doesn't help. This isn't the army, it's a voluntary side project I want to do when I can be watching Netflix.
I don’t think it’s fair to believe I’m just saying “Be disciplined” when I explain how to manage your time.
I do watch Netflix too. But it’s time boxed during the day, the same way working on projects is. And in a day, I don’t work more than 6 hours. I’m always done by 6pm and can do anything in the evening. The key is to manage your time during the day and stick to a plan.
As a matter of fact, OP’s rules feel more like the army to me: having a different user or even laptop for a project, going to a different location, blocking websites like reddit… These are harder restrictions. If I really want to quit a project, I always can. I just need to close my code editor and my terminal. But in my mindset I don’t want to. Because the project is not a burden like the army: it’s 2-hour slots where I’m focused, not overwhelmed, and I know there’s an end to it.
The door to leave is always open but I don’t want to take it. It’s different.
People like me and OP can't do what you say, which is just timebox things. I suppose we are not disciplined that way. I know how important exercise is, but I still cannot bring myself to work out every day or even every week. The only solution that works for me at least somewhat sometimes is to throw money at it or put external methods of forcing me to do the thing I actually want to do long-term. As a matter of fact, I go a step ahead of OP and have a separate laptop for personal projects. It's crappy and can't do much other than ssh so it's perfect. I suppose as long as one finds a system it's okay?
Perhaps if I get electroshock therapy and/or go to an ashram and meditate I might get more internal self-control, but I'm 32, and can't be bothered with it. Thats partly because I'm also not convinced it's that important that I become disciplined: sometimes being lazy feels good and maybe it's a part of what makes me who I am. I'm not self-sabotagingly lazy (except in exercise which I need to work on), so as long as I and others find a system why not?
That's interesting.
I saw once Timothy Feriss interviewing Neil Gaiman, and it was about focus and whatnot, and Gaiman said: "whenever I'm blocked, I stop, and start doing nothing. I can't watch a movie, read a book, I do nothing. I have only two options: I work or I do nothing - I cannot do anything else. After a little while, things get really boring, and I think 'might as well go back to work' - and that works as a charm.".
I guess that's a very good way of setting your focus straight, to obey your commands, instead of the other way around.
I used to do that technique for studying for the GRE. And it worked like a charm for sure (aside: Barron's GRE word list had the word <n-word>dly as meaning lazy in 2007 still. I was a kid in India but even to me it sounded wrong). Neil's full time work is to write. I'm sure this is what he does 9-5 or whenever he writes profesdionally. I doubt he just sits without doing nothing in the weekend when he could be playing with his kids. Thats the issue. If I was demotivated to do this in my day job that's one thing. Motivating yourself for extra work is where it's hard.
To refame that comment a bit: almost every single resource you find on motivation will mention that motivation is not a matter of passion, it's a matter of discipline.
In every hobby there is always a sense of discipline, it's just usually implicit. For myself: composing orchestral scores started off as a fun little "oh this melody would sound neat". Ever since then, there have been times when I need to sit down and do some "real work" to turn that idea into an enjoyable, fulfilling result. Could I have just wrote things when I want to? Of course. But now, after years of composing, I have the skill to make things that sound great when I really just threw it together.
In software engineering, a beginner or even intermediate programmer is going to lose a lot of their initial motivation to build their idea (game, app, website) -- because in finding the skill to execute on their initial side project idea, they realize they need to develop that skill from scratch, which takes work.
I think there's a good balance between investing skills between "basic knowledge" and "career capital". What that balance is varies from person to person, but I also believe that no matter what, even if it's implied, there is always a certain amount of work that needs to be put in.
Nope. Almost every single resource you find on motivation will mention that motivation is not a matter of passion, it's a matter of habit. Discipline and motivation is pretty much the same in this context, and wears off easily.
> you need to dedicate time to a project. I do this through predefined 2-hour slots each day or week where I have to work on a project.
I'm glad this system works for you; it wouldn't work for me - my professional coding life is regimentalised enough.
When I step away from "work-stuff" to spend some time with a project I want to work on, I can't approach it like a job; instead I need the work to be challenging and engaging and loosely structured. I'll have vague aims and hopes for the project but I'll also be hoping for unexpected turns. I give myself permission to get sidetracked, to let go of the project's purpose (for a while) so I can explore new thoughts and ideas along the way.
It's all very unprofessional, yes. It's also fun - which is the main reason for me tackling any side project.
And when it stops being fun? I stop working on the project: save it, put it somewhere safe, go entertain myself on a different project for a while. I can do this because I know the first project will still be there, waiting for me to become interested in it a few months (or years) later.
It helps that I keep my side-projects very open-ended - none of them will ever be "finished". Horses for courses, I suppose.
First of all thank you for creating bulma. I love using it and I use it for all my projects. And for me it’s much better than bootstrap because it doesn’t come with any js
I never knew you are doing so many things apart from bulma. Please keep bulma active. Thanks for the insights.
I would argue that switching the location is by far the most impactful of all those recommendations, based on how brain is clustering data. It comes with a rather big overhead for sure, but that might as well pay off quite quickly.
Part of discipline is knowing which contexts work for you. For some this is mindset, while for others it’s a virtual or physical environment. To each his own.
The "Separate User Account" idea sounds especially odd to me, since that seems like it could only ever slow you down.
The quickest way to build something is to have built it already. So let's say you're working on your new side project and you want to implement "Forgot Password" functionality. How do you do that? You open up your last project, copy it out, and plonk it down into the new one.
Now imagine you had to do that, but you had isolated yourself completely from the filesystem that held that old code (and all your other old projects, notes, etc. too). Do you have to switch accounts six times back and forth as you remember more bits of the old that you need to grab? Do you write a whole new system from scratch? Clone that whole other project from source control into this new users' filesystem? It seems like a lot of work that you've made yourself.
I agree. If you're doing that as a way to somehow hack your focus so you don't get distracted, you're already lost.
I create new user accounts for different projects too, and I don’t see why you think it’s so hard.
> Do you write a whole new system from scratch?
Do you really think that if you’ve written code before, that a reasonable option is that you "write a whole new system from scratch" just because it’s a separate user account? It seems like you’re just reaching for the most ludicrous straw man you can think of. "Oh no, I wrote this great account management system", but I did it in a different user account, so I guess it’s lost to me forever and I’ll have to start from scratch!"
> Clone that whole other project from source control into this new users' filesystem? It seems like a lot of work that you've made yourself.
`hub clone JimDabell/foo` – one command gets me whatever repo I want immediately. Or `hub browse JimDabell/foo` to open it in a browser if I only want to refer to some other project quickly. How is that "a lot of work that I’ve made myself"?
> If you're doing that as a way to somehow hack your focus so you don't get distracted, you're already lost.
It’s just a form of organisation, not the moral failing you seem to think it is. My documents directory contains only the documents that are relevant to the project I’m working on, the applications in my dock are all the ones specifically for the project I’m working on, command-line history, notification settings, browser plugins and tabs, application configuration, etc.
I find that the best way for me to finish a side project (for some definition of "finish") is to work on something that I want to use. Sometimes my motivation will flag for a few months until I want to use it; then the motivation kicks in and I'm productive while I improve/fix the project to make it work better for me.
Relatedly, it’s about working on something that will be useful quickly and you can polish after you’re already using it every day.
E.g. I got really fed up with how clunky the AWS assume-role workflow was at work with multiple AWS accounts so I wrote a little tool using Lispworks’s CAPI for a GUI that would handle authentication and embed a webkit browser so I could control the cookies more precisely. I got an MVP that improved my workflow working in a weekend and I’ve been iterating on it over the last several months. I find this sort of process works much better than spending months working on something that I may eventually use.
It’s a matter of picking slow-changing technologies: so, not the latest JS framework or whatever, but something like Clojure or Common Lisp that has a track record of maintaining backwards compatibility. And then learn to solve problems in ways that can easily be adapted to solve related problems.
Yes, this a thousand times. I couldn't find the right way to articulate but you did the job.
I'm sure many of us want beauty, conciseness, and every other quality in our writings but it's 99% of the time a neverending rabbithole.
On side projects a little bit of quick'n'dirty is extremely valuable to progress in assembling the bits of a system and see it operate for real.
It's a hard balance because no one wants to come back and fix things later but the fact that you walked forward into building the system means you have more concrete knowledge of what is required and this will make it a lot more clearer and motivating to adjust and fix the previous modules.
There's also a different kind of pleasure involved. I can be proud of super clean code in a project that is never done.. but the feeling of having finished a tool that is actually useful is so much nicer. And it makes you want to keep doing it this way.
Are you signing in with AWS users or STS AssumeRole? My company does the latter: there’s a user management account and then each project gets their own account. To access a particular account, we have to use a user in the user-management account to assume a role in the account we want to access. This makes the AWS CLI tooling annoying and it also makes the AWS console annoying to access: you have to generate a sign-in link programmatically and use that link in the browser to sign in. However, if you’re already signed into an account, this pops up a page that says “you’re already signed in, please click here to log out before switching accounts”. Then you have to logout and regenerate the link before you can access the account you want.
My solution was an app with a minimal embedded webkit browser, so that I can programmatically clear the cookies every time I login to a new account: that way, the sign-in link works first try. Since then, it’s grown the ability to list Cloudformation stacks and their parameters and outputs.
This is probably the best way to keep "motivation" up... and why I don't even start side projects. All of my "itches" can be scratched with existing products.
The problem with this, for me, is that almost anything I want to do can either be accomplished with existing tools or is too complex for a doable side project.
I used to feel the same but in the last year I got sick of saying, "that sounds too big" and just started hacking. By focusing on small bits at a time I've been surprised at how far I've gotten. I'd encourage you reevaluate what's too complex. You might surprise yourself.
Funny, I usually go in the other direction. I'll find something to automate and I'll think, "That sounds buildable in a weekend," before realizing after the weekend that it would actually be a multi-week, sometimes multi-month effort.
It especially helps motivate learning new tools. I find that if I want to learn a new tool, I look for something I'd want to do with it and use that to drive the project.
This comment really speaks to me as someone who just got a software project into a minimum-viable state after two years of this exact kind of off-and-on burst programming. I threw away several prototype approaches in that time and am left with something that should serve my needs for a long time without significant maintenance investment. It's nowhere near the most complicated thing I've ever written but is easily the thing I'm proudest of. I used to feel a lot more like the OP author, have only recently experienced what you describe, and really hope I can channel and maintain this as a way to avoid burnout and demotivation.
Yeah! This is also the same advice I discovered for open source contributions. Browsing for a cool-looking project on GitHub is nowhere near as motivating as a breaking bug as you start working with a library, haha.
I often get into side projects that start from "it would be cool if this exists", but, if I actually think about it, I have no interest in them beyond yeeting them off into this vague coolness.
Someone once told me: don't talk about your idea to others until you're done building it and have something to show (at least an MVP). Surprising how motivating this was for me to finish my projects even if they're not perfect.
That way you don't mentally feel like you're accomplishing things by just texting the idea around. The discussion bloats your senses and conflates self-reassurance with getting things done.
And secondly, sometimes its easier to communicate an idea by building it than to try to use words to describe your intangible hallucinations. Translation from your head to words to someone else's head is pretty lossy (esp on things like Twitter, though I do think its a great creative exercise)
They say the difference between a vision and a hallucination is that other ppl can see a vision (h/t Ben Horowitz). But no matter what, everyone can see cold hard product.
Totally agree. When you explain your idea, you "live" in it, giving you a false sense as if future is already here and you achieved what you want. You get your portion of positive emotions without doing any work, so every next idea you do more talking and less walking.
Don't do it, keep it to yourself until there is something tangible to show.
One brainhack I like to use on myself is to think of them as "Side Quests!" rather than "Side Projects."
My main quest is my day-to-day life. When I'm feeling bored, bogged down, and tired of the daily grind -- I head out in search of a side quest.
A side quest can be easy (1 hour), or hard (14 days). But the goal of a side quest is to distract me from my daily grind, and help keep me learning and motivated.
While this difference in perspective is subtle, I feel like it's enough to give me the headspace to stay more deeply engaged with interesting topics I'm trying to learn or understand.
Also noteworthy: for me it feels like any time a "side project" turns into a "side hustle" -- the ideas usually fizzle out very quickly.
Sometimes it's worth remembering that side projects can be "just for fun", and it's okay if you're going to spend a few dollars on it. The value can come from the learning process, and creative input/output generated.
I don't finish 95% of my side projects and that is OK. Most side projects start because I have some interesting problem in my head that I want to solve and then I start obsessively solving it for a few days until it is solved or...until the next problem comes along and I lose all interest in the first problem.
I read Refuse to Choose by Barabara Sher because someone recommended it here on HN and it showed me that I am a scanner always looking for new problems to solve and the act of working on an interesting problem is what makes me tick, not the finishing of an actual project or product.
Usually I learn a thing or 2 by starting and working on a side project that I can use in my day to day freelance work. And sometimes when the planets align the interesting problem I am obsessing over is that bug I need to solve for a client and the satisfaction is double. Working on an interesting problem and making the client happy.
The question seems to be how to keep your project top of mind. Once you're forced to stop working on your project, the context file this post mentions acts like a save point to return your project to top of mind.
I'm sure there are other similar hacks. Maybe review your context file before showering each day?
Hmm, why is it so important to "finish" a side project? Can it not be something that you work on whenever you have time, for many years? As long as there are users, software projects are rarely "finished" completely.
I just released the first public version of my first real side project [1] and I don't expect it to be "finished" for years. I have so many ideas for the domain and I am sure new users will bring continued input. Are there popular examples for successful side projects like this?
I find the most important thing is that you really want the thing you're building to exist. Everything else is secondary. If you want to use the thing, but can't because it's not there, you'll find time to work on it.
My most successful side project from last year is this climbing community that I built for my wife:
We live in Fontainebleau, France and have arranged our life around the bouldering here, but she had always struggled to find good projects because the climbers who travel here tend to be mostly gym-strong men who power and lank their way through the problems here that suit that style. But there's a ton of other stuff that needs good technique and benefits from being able to bear down on small holds. Women are good at that sort of thing, but there was never a way to find information on those boulder problems.
It made a perfect "Side Project" because the core idea was buildable in a single day, leveraging the same framework I'd used for S3stat, Twiddla, Unwaffle, and the other "Real Business" projects I'd been doing. I was able to avoid silly Javascript build systems and other time-sink pitfalls that normally plague everybody's side projects (presumably because they seem fun and you're trying to learn stuff in addition to building something). The only real "reactive" stuff it needed was in a little "Project Finder" that lets you adjust sliders for grade, popularity, style, climber height, etc. and would benefit from having the list of climbs update in real time:
... and that was just a few hundred lines of vue.js, again minus any build system.
I still stick new stuff in regularly (like the "remoteness" filter so that you can find boulders deep in the woods where no plague-carrying-zombies will find you), but since it's built on a polished and time-tested architecture, I can get an awful lot done in a couple hours, so it's just a matter of disappearing off to the office on a rainy saturday morning, then coming back and announcing a few improvements.
> having a "context" log, where you write the current progress, and what to do next
yup critical. I do this and even if it gives me a 10-minute head start at the beginning of a work session, that means way more successful work sessions in a crazy week
I've started splitting my high-level todo list (tradeoffs + optimization) from my 'stream' todo list (next 5 linear things) -- the latter is useful for context + obstacles.
Writing down obstacles + setbacks also helps here.
We are used to put what we have done in git messages. But for WIP commits, it makes sense to also put what to do next. This way git log is your journal.
I've had people get mad at me for 'nextup' comments in commits, but at minimum, given how central git is to our workflow, the commit is the right time to track work
Like a world-changing pandemic and riots? I'll be honest, it is getting hard to focus on building my cute little software bullshit project when a voice in the back of my head is telling me to spend my time prepping for social collapse.
UFO means Unidentified Flying Object. The word "unidentified" doesn't fit well with the word "confirmed".
US navy has seen flying objects which it has not identified. I would be more surprised if they could identify all the objects they have ever seen flying. I often have trouble identifying certain objects which aren't even flying!
I wanted to comment on this since I've been through many disruptions.
During the dot-bomb implosion in 2000, most people threw their hands-up. Even VCs threw in the towel and moved from Calif. to southern states with no state income tax. (The metaphor was, "they're rolling up the sidewalks in Palo Alto.)
To this day, business people look at the start date of some of my projects and say things like, "Wow, you started a project in 2000?" Then they go mum since they realize what a silly thing that was to say.
Business and life are cyclical. Since it takes 7-10 years for a startup to mature, the passing of crises has very little effect in the early stages of a startup.
Now is the perfect time to do a startup or project.
Here is some simple advice for sustaining a side project over a long period of time.
1)
Work on it consistently. Ideally, work on it every day. It doesn't have to be a big block of 2 hours each day, browsing through bug reports for 10 minutes can also be enough. But it has to be consistent.
The benefits are:
* It keeps the project fresh in your mind and ready to go. No time wasted on figured out where you were at the start of each session.
* It avoids the that demotivating feeling of guilt that may creep in when you think that you've neglected your project, or once again "started something, but not finished".
* It provides a consistent sense or forward progress which helps generate motivation.
2)
"Motivation" is a resource which needs to be managed. Projects will have a mix of interesting tasks (motivation generating) and dull tasks (motivation consuming) tasks. Be aware of this, and mix these two types of tasks so that you don't bottom out on motivation. Developing some self-knowledge of how you work as a person pays off here too.
Demotivating tasks can also be chipped away at by working on them a little bit per day over a longer period of time. Consistency is the key here too!
I've found the #1 trick to finishing a side project is to build it out in the open by writing a blog (or podcast) about it and building up an audience who are interested in seeing you finish it as you go along.
It also gives you an in built audience to launch with who will use it - rather than launching to a loud thud of silence - which sucks and feels like the long dark night of the soul.
Then you’ll just have a bunch of indie hackers following you. Not the actual customers?
Real customers only care about your journey in hindsight. People want to know how Apple etc started, not many will care for journey of a new tech until it’s released.
That's exactly the reason why the indiehackers website is going circles publishing products which are used within their own audience. If you are building something not targeting this demographic, that's not going to help you get more customers.
This was exactly my experience with my last side project, the standard PH, HN, indie hackers channels didn't work at all but niche subreddit communities worked really well. I now write updates about my progress in my projects own subreddit which has it's own followers.
You have to click a second time on the revenue for their sort to work but that's clearly what I had in mind when I was saying this.
A lot of the highest revenue products (with a few exceptions of course, I'm not saying it's only that) on this website from this list are SAAS targeted at the startup world.
In the past five years, I've had several side-projects that were never "finished" in the literal sense, but taught me important things that helped me ace job interviews, getting me two jobs that I probably wouldn't have got otherwise.
At some point I had a mental shift and decided that a side-project that doesn't get finished but gets me a new job is a huge success and not a failure.
This had a big impact in me continuing to explore new personal projects as long as I can learn something interesting from them.
That's an interesting data point: personally I've never found side projects to have any effect on getting a job - recruiters and interviewers don't care in the slightest about your side project, Github profile or whatever and will just "follow the script". I just see side projects as interesting for their own sake and a way of learning about things you'll never get the chance to in your day job because it's not in the company's wheelhouse.
I should stress that it is not the side-projects themselves that got me the jobs but the knowledge I acquired while working on them.
I usually do side-projects on topics that interests me, and usually apply on jobs that also interests me, and I just hope for the two to converge: at some point the interviewer will ask a question about a technical topic I never worked on professionally, but on which I have intimate knowledge thanks to those side-projects.
And then I'll be able to give an interesting answer while my previous jobs and education would not have prepared me for that question.
Sure, I think we're in agreement here. The $dayJob is usually too limited in scope - you can't just drop in, say, GraphQL into a project because you want to learn it (and nor should you). Plus in a large enough company backend devs are kept away from touching frontend code and vice versa. Companies usually don't like to invest in training either so side projects are often the only outlet developers have to learn and explore.
I have a side project that I've been working on for more than 2 years already, and it still hasn't reached the point where I'm ready to show it to people.
What I find useful to do when I get stuck with some problem that I don't have the time or the patience to solve, is to leave it alone and just let my subconscious continue digesting the issues. A few days, weeks or months later, the solution would spontaneously reveal itself, and with it new drive and inspiration will fill me, and then I'll dive right back to the work.
I've also had other side projects that I pursued for a while and then abandoned because I had other more pressing or interesting stuff to work on. They're still there on GitHub if I ever feel like revisiting them.
In other words, don't worry about it. Sometimes it fizzles out, sometimes it sustains itself.
I started a lot of side projects like many and didn't finish most. For me the secret of finishing a side project was to start a small one, something that I can finish within a weekend or even less, a few hours.
My completed side projects have been the one that took me less than a week. Some of them was less than 100 lines of code.
I've found myself stuck in that endless cycle for years. I find myself highly motivated for the first few weeks, thinking about a future where I can work on this full time.
As the project shapes up, I lose interest and start to doubt my idea, wondering why people would ever pay for this. Eventually I work on it less and less until one day I decide to not work on it anymore.
It sounds like working on something full time is what motivates you.
To get people to pay for anything is usually a different side project. If you can't see the path to profit no one probably will pay. Find people who will pay and use that as motivation and product guidance.
He emphasizes waning motivation as one of they key factors, but there's a logical consequence of this which he didn't point out.
Instead of trying to keep your motivation up, figure out how long your motivation tends to last for (mine is ~2 weeks). Then at the very start of the project ruthlessly cut down the scope to something you think you could actually get done in that time period.
Perhaps this will require you to simplify some of the stuff you were planning to develop
Maybe you'll adopt just one new tool you need to ramp up on instead of five.
But by embracing the ticking motivation deadline you can modify the work you take on to something that you'll actually finish.
I wrote about this just a few days ago, and how I applied this technique to a project I was working on.
+1 vote for creating a different system login. This cleaned up my dev environment as I experimented with new tools, and decluttered my brain when I context switch. Not to mention every time I login I am guilted when I choose a different profile to login with.
and if you don't want to go that extreme, just using a different virtual desktop can work wonders.
Ironically one of my todos is to hack my xfce to swap out panels (and maybe somehow browser profiles?) when changing to certain named workspaces. So I could have my 'coding' workspace with a panel of work-only applications ready to go, only work-related bookmarks in the browser, etc.
The idea of logging out and in as another user seems to have just a bit too much friction for my tastes, but maybe I should just embrace it.
From my personal experience, it took me years of discipline to build up the skillset to finish a project. It took me years to be able to learn what I can do and what I can't do given a specific timeline and be able to set tangible and achievable goals and focus on that to complete them. (And tangentially, if you ever want to offload your side project, here's a place to submit if you like :) https://www.sideprojectors.com)
For me it was learning to limit the scope of the projects, each time making it smaller until I planned projects small enough that I could finish them in under 3 months.
Personally one of the highest motivators to finish a side project is not doing it alone. My mindset automatically changes from focusing on perfection, to focus on it being viable. It's launched, there's a defined plan to make it work long term. Guess I'm ok with failure if it only affects me (also because it's never a failure, it's training, it's fun...), not if it affects others.
I'm glad this person has found something that works for them, but I think there is something far more simple yet harder to track down. None of these "brain hacks" are going to fix the underlying problem of long term motivation. Many have said it's a discipline issue. I disagree. I'm very undisciplined with my gym habit yet I still show up 5-6 times per week. I go very often, but because I want to, not because I'm "forcing myself".
I've been studying how this affects people with ADHD for my book. Everyone I've interviewed concludes in some way or another that there needs to be a far deeper, compelling reason to do something for them top do it long term.
Discipline is just a routine way you develop to execute something. Some people (usually not those with ADHD, I've found) are able to continue riding the wave of discipline until the project is complete, but they are doing so despite wanting to do other things. Is the conclusion that you have to suffer through some unhappiness while "forcing yourself" to complete projects?
I have been working on NearBeach for nearly 4 years. I have always done it in small steps.
- Implement projects functionality
- Implement customer/organisation functionality
- Implement tasks
- etc.
I find this helps me keep myself motivated. That and I couple it with a set goal - a very achievable goal.
Currently NearBeach is a minimal viable product currently going through a UI/UX and backend refactoring, with the goal of improving UI/UX and backend readability of the code.
My problem is not finishing something. Because the context around a project always evolves, you can't really say it's ever finished. I can (now) easily get to the phase where a project is ready to accept users (which is what I suppose is meant with "finished").
My biggest problem is finding the energy to market the thing/find users outside of the ones I built it for.
I've worked on a tool for product managers (I built it for myself first) that attracts about 5 to 10 users every month (it's free).
I released a tool for a lab manager friend of mine. I wanted it to attract more users than his (enthousiast) staff, but I can't be bothered marketing the thing (except a lame post on LinkedIn).
And so on... Now I'm building a niche appointment planner, hoping I can get other sites to do the user recruitment for me (through affiliate marketing).
So it's never been about getting the project in a state where it's ready to accept user feedback but more about finding the motivation to go and market it.
I resonate a lot with this article and I wanted to share a tool I've been working on to help exactly with with context switching. I talked to so many people on how they use their computers - nobody finishes a task in one sitting.
This line perfectly states the reason why context switching is such a drain:
> With the limited amount of mental energy, is crucial to reduce the number of setup tasks required to do a working session on your project.
Setup is like one of those hidden costs that we take for granted.
Anyways, I built amna, and it's an information manager. It's organized like a to-do list rather than disparate documents. Amna allows you to do research, document compilation and quick app access. I'm not quite done with the website to launch broadly, but this seemed like a great thread to post early on. (open to feedback, and would love to chat if you're interested)
Just like when studying or doing homework getting started and setting yourself up is the hardest part. Keep your IDE and relevant tabs open, if you're on Linux set up a workspace for it and just push the rest aside. Once you start tackling some code you'll be in the zone and will probably have to test yourself away from it.
Back a few years ago when I first started dabbling in side projects and wanted to grow some side income, I found the greatest motivator was wanting to get out of my day job (which I hated). I wasn’t organized and in retrospect nothing was well thought out, but the need to survive and the desire to escape was enough.
I've found that quite simply writing about a side project can be enough to help "finish" it. There's something almost cathartic about the process of writing up and publishing. It isn't about other people reading what you have written, and personally I don't mind if no-one else does actually read it. Rather, it is about gathering your thoughts on your objectives and how it has turned out, documenting it so it is left in a state where it would be a lot easier to pick up at a later date, and that sense of finality or closure (it means that, if nothing else, I at least got it complete enough to write about and also completed the writeup).
I love working on endless projects. Releasing something has never been high priority for me. If I get bored then so be it. As long as the journey is fun I'm good.
I love completing things, but I tend to see sub projects/tasks more fun to complete than the entire project.
People are different, but I can totally imagine I would be depressed if releasing something was my goal.
Composing music is similar to me. I've got around 1000 unreleased music ideas with varying degrees of complentess, but I've only released around 50. Interestingly though this viewpoint of not being able to release something was something I mostly saw with people starting out, and eventually it fades.
I would say, like in the article small steps, having a clear goal for each session and consistency are crucial to shipping anything. I've been moonlighting on https://bullish.email for a couple of months following pretty much the rules outlined in the article, 1.5h Monday to Thurs sometimes Friday, and I just shipped a big update on my service. Time will tell if I'll lose motivation, but this is the first time I can manage a day job and a fully functional side project.
At least for myself, I found it detrimental to set milestones that were based in features. The main reason was I'd rush to finish a feature, get all excited about shipping it in "only 1 week!", then tell myself I deserved a week off. That week turns into a month, then you lose mental context.
What I found key was making it a habit to work on it. Side projects, especially solo ones, take a long time to complete. If working just a little on one is part of your daily habit, you'll have ongoing steady progress that won't come with burnout.
Ironic, considering that his new Netflix special is mostly material he's been doing for years, but this does sound kind of cool:
> He told me to get a big wall calendar that has a whole year on one page and hang it on a prominent wall. The next step was to get a big red magic marker. He said for each day that I do my task of writing, I get to put a big red X over that day. "After a few days you'll have a chain. Just keep at it and the chain will grow longer every day. You'll like seeing that chain, especially when you get a few weeks under your belt. Your only job next is to not break the chain."
Sounds like the visual commit history on github, now that I think of it. My side project is on a local git, and that's the only thing I miss - the calendar.
Seinfeld denies it: "This is hilarious to me, that somehow I am getting credit for making an X on a calendar with the Seinfeld productivity program. It's the dumbest non-idea that was not mine, but somehow I'm getting credit for it." - https://www.reddit.com/r/IAmA/comments/1ujvrg/jerry_seinfeld...
My solution is probably bad advice, but I found effective to commit either financially or to someone so I have to do it, I put myself in a position where I don't a way out other than deliver.
Lots of people mentioning tricks and "hacks" that work for them, and seconding techniques from the article, which is helpful.
But after reading a lot of these sorts of articles and threads over the years, the most consistently useful advice that I've seen is simple:
Learn discipline, because motivation will always fade.
It's like getting yourself to exercise regularly, or read at least a half-hour every day. Easy to get started, but even easier to skip a couple of days, then a week, then to stop altogether.
I've trying these methods and hitting the same motivation wall on my app for the past few months. Managing context and working in small steps is helpful.
A continuous drip or spaced repetition of similar work also helps. Reloading the context of your work can take a lot of mental energy if you've already forgotten where you were. Keeping the context in memory partially reduces the cost of getting started again.
One of my tricks is to relax into it. I'm just gonna write some code and get something (anything) done. If it's shit I can "git checkout -- ." and walk away. If I don't get it done it doesn't matter. I need to depressurize it so it feels different to normal work. If something fucks up in prod, do the minimum to fix it, schedule the refactor for "mañana".
Do you use some kind of project management tools (kanban,todoist etc) for your side projects or maybe just some plain text todo files? I find that whenever I’m trying to start a new side project I’m spending disproportionately long time searching for perfect tools and often end up doing nothing and agonising over project management instead of working on actual tasks.
I used to have trouble doing the work. But when I got honest with myself, I had a very specific problem that was preventing me from doing the work. Once I fixed my problem, I was able to do the work. My side project pays salaries now. "Everyone has at least one big thing that stands in the way of their success; find yours and deal with it" Ray Dalio
Splitting into small chunks is the biggest (ironic) help for me honestly. With kids now, I only have a half hour or so every few weeks I can work on something so I try to make it a nice achievable task I can actually accomplish! Otherwise I seem to just pick up a movie or just read online...
Re not sure why, but switching location works: in brain, these things are interconnected and clustered together after some time. Therefore switching the location (and your system user) is a great way to immediately switch your brain to the right context. Great recommendations!
I am always motivated to start a side-project to generate some extra income, but then I decide my time is better spent studying for job interviews. Eventually, I get sick of leetcode and go back to working on my side projects. It's a vicious cycle.
I think awesome side projects are at least just as valuable as leetcode, and so you should do side projects exclusively unless you have an interview next week.
Factor out smaller projects. Try to break up the next step if there is no progress for a while. Separate task definition, implementation and testing into separate steps. If the last project got stuck, try something with a smaller scope.
My motto is make it easy to start but hard to stop. Stopping can be hard when you have built up some momentum and have a clear view of what needs to be done but I think it’s good to leave something for tomorrow.
- writing down the ideas after finishing a working session. Besides, I never understood why, but doing that using pen and paper works way better to me. I have an inclination to overthink, which uses being much more exhausting than the actual, productive work itself. Writing the ideas down somehow convinces my brain that they are safe and won't be forgotten, freeing resources for other important things like slowing down and resting;
- planning for interruptions. Whenever I can, I write a slightly detailed plan containing tasks I have to perform. Not necessarily the steps needed to _finish_ the project: sometimes I just have to learn some fundamentals before I'm able to have a slight idea of where to start. In such cases, I try to define some steps with things I have to learn, tests I have to perform to validate an idea and so on. Planning for the smallest tasks as possible allowed me to cope with interruptions. Sometimes I could simply pick a half-hour task and do something productive while I was waiting for somebody, for instance.
I successfully applied many of the ideas in the article on my masters. After wasting some months being stuck, I could eventually finish everything. A ~15k loc custom application to support a set of experiments + analyzing and interpreting data + writing the dissertation. I feel really proud now for seeing my work serving as a basis for further studies.
But my takeaways are:
- it's not always fun. It feels fun and rewarding now that everything is finished and I'm seeing my hard work being useful, but at the end I just wanted to finish and meet my deadlines. It works for some people to keep the end goal in mind. For me, it was detrimental: the end goal was huge and to think about it would only overwhelm me. On the other hand, having a plan with small, achievable tasks, helped;
- keep your mind in shape. Besides having healthy food, sleep and so on, try to create conditions for a good emotional environment;
- plenty of time was detrimental. I had always dreamed of an opportunity of having 8 or more hours in a row, for many months, thinking that, then, I would do lots of meaningful work. I ended up procrastinating everything else, other important tasks started to pile up and I faced what is the worst feedback loop of my life so far. I came to realize that I was more productive on 4-hours or even less work days;
- I keep collecting unfinished projects, but, as another commented said here before, it's OK. That might not impress recruiters and the community, but I learned something from them, have some reusable code and knowledge, and I can finish them whenever I feels like.
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.