Why is completing a side project is way harder than completing a project for a client? Some problems that I face when working on a side project are:
- Changing project scope, coming up with a new feature before completing the previous features.
- Sacrificing on requirements, because at the end of the day, I'm in charge
- Self-sabotaging for not finishing the project
Among a few others, and to tackle this I had to find new ways, and tips to help me get my side-projects done, because I don't see myself good on a corporate job, and the path I chose with my career which is more of freelancing and entrepreneurship, so it is crucial to learn the skill of finishing side-projects
So tens of side projects later and half-completed repositories, I have learned a lot and in this post, I will share with you the lessons I learned, that I will help you with finishing your side project.
Side-projects are no different from normal projects, they just happen to be your secondary focus instead of the primary one, though in some scenarios you could just have a bunch of side-projects, so with that being said, as of any project, the most important thing is
There is a lot of variables that comes into play when talking about side projects, things like what tech stack will you be using? Where are you going to host it? Who is going to use it? Is it a website, CLI, or a GUI app? Are you going to learn a new stack to build it? Or are you going to just get it done with a technology you already know?
And to be honest with you that's a lot to take into consideration, but there are a few basics things you need to know before starting on your next side-project, so here is a set of easy questions so you can drastically improve your plan of creating your side-project and actually getting it done.
- Why do you need to finish this project? Then why is the most important thing, because if you knew why then you can identify if it's worth your time and effort in the first place. If you're going to dumb it than do it now instead of going half the way of finishing it before quitting, and instead spend that time and energy into a project that worth the time and effort.
- Is your goal to learn a tech or finish the project? In other words, will the project be used as a reliable tool? Or do you just want to learn more about a technology that you haven't used before?
- Are you the only one who is going to use this project? If yes, then you have more flexibility, as you should only make it work on your machine with your requirements.
- What is the targeted platform? Does it need to be available everywhere? If so, then your best bet would be web app. If It needs to be on mobiles and use native features, then you will need to go with native solutions like Java, Kotlin for Android or Swift for IOS or cross-platform SDK's like flutter and Xamarin or React Native to name a few. Or maybe it's a CLI that you will be using inside your CMD/BASH shell, whatever you chose make sure to be specific, and to start small, I know it could be tempting to "Dream big", but you don't want to dream, you want to get the project done, so chose one platform, or go with cross-platform solutions.
- What is the ONE most important feature of the app? Think of it as the sub-headline of your project, as of convert-kit "Audience building for creators" that's their main focus, your project should have one too, for my Twitter-Positivity-Meter project that features is in the name, which is a metric of the positivity of a twitter account, and in other project I'm currently working on which is a Syncing app for my android phone, which it's only and the main feature is to sync files and folders between my phone and my PC. This way it's easier to know what to focus on and to actually get the project done
Working in public
This is one of the most important things to do as you work on your side projects.
Basically you should be comfortable working on public, I'm still trying it, but I've already seen a good results, the other day I posted a picture of the code of the syncing app and someone asked me for the repo link, which I think is amazing! So this leads us to the next point
It's very beneficial to do so, for a lot of reasons, the most important one is that you are held accountable, even if no one is watching, though I would recommend that you use hashtags like #100daysofcode as you may find someone who is interested and you may become friends.
Also, you may get a second eye, you could get suggestions of how to improve the project, or if there is a better way of doing things.
Time vs the final product and the problem of procrastination
Don't focus on the final product, so instead of thinking I would need 10 hours to complete the product, and I will be waiting for the day that I will have 10 hours to do my project and get it to be a final product, I would instead focus on spending a certain block of time throughout the week, which would result in me spending the 10 hours throughout the week, instead of waiting for the day that I have 10 hours, which if I got, I will probably not spend it on this project.
That's on the bigger picture, but also it's easier to work on a project, if you're not intimated by the bigger picture of the product inside your head, that way you can leverage the power of the Pomodoro technique, and at any point during the day, you can just decide that you would spend i.e. 25 minutes of focused work on your side project, and that's it, that way it's easier to resume working, and it's easy to convince yourself to just work 25 minutes on your project in oppose to setting for 10 hours to complete it, and probably you will not stop because you would be already in the flow
Also, one more thing is. Time is the main asset you have, so it makes more sense to structure the day accordingly, and that's why I like this method.
But that doesn't give you permission to drag out things, but instead do your best to get them done as fast as possible
I might be the only one who does this, but basically, I used to always change project requirements, which causes me to not finish any of the projects, so now instead I would do all the planning on the beginning, and I'm not allowed to change the requirements until I finish the requirements, but of course, there might be some exceptions, and to be honest it's tempting, especially if you found a new tech or read an about a new methodology, and I would be excited to change the requirements to use this new tech/method instead.
It's all work in progress
All the projects you will build should adopt this way of thinking, in other words applying best practices like TDD and CI/CD can be really beneficial, because that way you can do what we mentioned on the previous point which is working on public, you would create an initial version, and share it, then if you think it's worth it then you can create the additional features, you can think of it as only create MVP's for your side projects, and I think that is much better than having half-done project because I would feel proud for getting a side-project to an MVP level, if it didn't have all the features, I can add them.
And don't worry about what anyone would think, even you because you really can change it at any point if it's worth the time and effort.
At the end of the day, this doesn't only apply to your side projects only, but to creating and projects in general, I believe that those tips really helped me with creating, as this is also my first post here on dev.to hope you enjoy it, and if you're interested in Software Development, Freelancing and Content creation than follow me on Twitter here @abod_ftw also I create videos about software and software development on Whilelab YouTube channel here
As I'm reviewing the article now, I think it's heavily influenced by the Agile method, but if it works then why not use it.
You can say Hi! On twitter
Thank you for reading!