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.
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!
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 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.
I definitely recognize what you are saying. Things don't have to be black or white, and this is a good nuance
For me that usually starts with a mockup and bit by bit the mockup becomes something more.
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.
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.
Are there any other things you do to get yourself started in flow?
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.
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.
Hemingway
Not necessarily leaving a task incomplete: in case of small tasks, it also worked for me to have the next task clearly defined.
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?”.
[2]: https://jgthms.com/web-design-in-4-minutes/
[3]: https://jgthms.com/css-in-44-minutes-ebook/
[5]: https://bulma.io/
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.
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.
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.
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.
Some people have ADD and/or anxiety and need the minimalism so they don't get overwhelmed or trapped in rabbit holes.
Your advice is akin to telling people "don't bother disabling notifications on your phone apps you can just ignore them".
The real answer is find a system that works for your particular brain. Personally I need the approach in TFA or I get analysis paralysis.
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.
I never knew you are doing so many things apart from bulma. Please keep bulma active. Thanks for the insights.
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 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.
> 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.
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.
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.
So many products I use only get me 80% of the way there and I find myself wanting to make my own version.
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.
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.
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.
Sand storms so large they are blocking the sun in the US.
Radiation forest fires in Russia.
Ufo's existance were confirmed by US navy.
Stock market crash / rapid recovery
What's next...
The way it's written, it sounds like the US Navy confirmed the existence of aliens, but it was just unexplained phenomena, right?
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!
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.
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.
I've always found that early adopters and innovators are very interested in being first customers and following your journey.
It also depends on what side project you pick. So, there is some nuance for sure.
[edit removed link]
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.
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.
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
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.
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.
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.
I think thinking that people won't pay for it has more to do with self doubt and lack of confidence in myself.
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.
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.
> 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.
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.
Don't do it, keep it to yourself until there is something tangible to show.
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.
I wrote a related blog post last week on related thoughts, if you're interested: https://jakedahn.com/2020/06/23/its-not-a-side-project-its-a...
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.
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.
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?
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?
[1] https://keycombiner.com - a web application to learn and train keyboard shortcuts
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:
https://bettybeta.com/bouldering/projects
... 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.
Fun stuff.
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!
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.
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 tend to check in code that's broken on purpose with a message: "BROKEN... " and then roughly where the project was.
Also, I tend to check in code with links in the comments to anything I was using so that I can find the links again.
Any project but the simplest always keep finding more things I want to add to it.
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.
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)
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.
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.
Like they say at Nike: "Just do it."
One of the big reasons that I do them, is because they help me to develop the habit of ship.
Also, one of my side projects has actually become a worldwide standard, so I think that treating all of my projects as "ship" has turned out well.
I have a number of works in progress. Some, I will complete, some, I won't.
"We are what we repeatedly do. Excellence, then, is not an act, but a habit." -Attributed to some guy that wore a sheet.
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.
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.
Getting it done is just a (great) side effect.
Sending love to everyone building side projects, you're awesome.
