Do you remember how many side projects have you think of? How many did you start? And finally, how many did you finish? If the number that came to your mind is not decreasing question after question, then you might not need to read this post. If you want to go direct to the list, skip the next section which is intended as context (and a bit of "feel you bro")
The Context
Since I first became a Software Developer, a lot of different cool ideas came to my mind, things that I thought would change the world, would end poverty and violence in my country or things that would make me rich! All of them were things that I was capable of build with my new software developer skills. I believed in those ideas so I started working on them, but in the meantime I got a job as Software Engineer just to pay the bills, because you know my side project is going to make me rich!
I ended up working 8 hours from Monday to Friday, after that I worked on my side projects. It all went well the first couple of days, I was a bit tired after work but excited about working on my cool idea, unfortunately that feeling did not last too long. I found myself trying to create the best application I could possible found, I was doing TDD, localizing the texts, following design patterns, integrating CI, working hard on design, etc. All of those cool things you learn and (try to use) at work.
The days passed and when I looked at my project I could barely see an MVP, I did not even want to work on it anymore because I had to do all those complex things before adding that amazing feature I thought of during lunch time, so I ended up losing interest and the project died.
The same thing happened to my next side project, and the one that followed it, and so on. A ton of abandoned Github repositories and Git directories in my computer started to pilled up. One day while I was doing some space cleanup I found some of my old projects and I wonder what went wrong with them, and so I ended up with this list of things you need to do (or don't) when working on side projects if you actually want to finished them.
The Guide
Forget about best practices
Clean code? Nah! Design patterns? No!
Side projects usually have different purposes, if the purpose of your side project is to get a product out and make money or fame (or whatever) then apply this rule. Best practices like Clean Code, applying Design Patterns, or even writing tests are going to slow you down.
You need that piece of logic in the view? Go for it. Your model is getting fat? No problem! Are you hardcoding those values? It's ok! Do whatever makes you go fast, do what is best FOR YOU, not for the code.
And before I get punished by my old mentor, I have to say that this should only be applied for your personal projects, please don't take them to your work. When I said that best practices are going to slow you down I mean in the short term, and only some of them. Most of your side projects (unfortunately) might not live enough to enjoy the benefits of design patterns or clean code.
YAGNI
You Aren't Gonna Need It!
Maybe I should localize this text just in case my app is so successful that I need to translate it to French, maybe I should split this logic to make it easier to change once my app goes public and investors wanted to do some changes, I should definitely learn and use React for this side project to make it easy for Facebook developers to work on it once I'm acquired.
YAGNI: You aren't gonna need it!
I noticed that lifetime of side projects is very short, we lost interest in them pretty fast and planning for the future might not be the best idea. Try to find the minimal setup that can get you hands-on delivering features as quickly as possible. Don't do the CI setup just yet, don't translate your app to Chinese today, we know that your app's success is almost secured but it's only you right now, leave it in the TO-DO list for the moment.
No PMs allowed
No Project Management is the new Project Management
I once tried to write tickets and put them in a board for one of my side projects in an effort to keep myself organized and motivated after looking at all those tickets closed and... I ended up spending more time tracking and creating tasks than writing code.
Don't feel bad if you are already working on the frontend view even though the controller isn't fully finished. Did you start one task and then suddenly changed to another? That's fine, this is your project not your work, you set the rules.
YDD
YOLO Driven Development
Your project is probably only going to live once, so let it live a life of adventures and risk by not writing tests.
Tests are a strong part of applications that you can rely on when changing code, specially unstable code, they allow applications to be modified without too much fear for them to die in production and affect thousands of users. But your application is not in production, does not have users and does not have too much code (yet).
You might be tempted to add a couple of tests just to make that the feature you added works but in this scenario, anything that explicitly prevents you from continue adding features to your app is bad. Sometimes, depending on the complexity of the feature you are working on tests are enhancers of development speed so they are welcome, but try to think before if it really is going to help you move faster.
Testing that the homepage still renders can definitely wait.
Every Line Matters
Rome wasn't built in a day
Make sure that you are aware and appreciate every line of code you write. Get in your mind that every change is adding value to your project and is getting you closer to deliver time, this is necessary for you to keep the energy, illusion, and excitement of working on this side project like on day one.
Don't feel bad if you only wrote a couple of lines of code today or that you did not even work on it because you were tired. This is your project and you should work on it as you please.
If you are not good at working without someone pushing you for a goal, making yourself aware of the progress you are doing with every line of code you write, is going to help you keep motivated, which is the purpose of most of the tips in this guide.
MVP
My Victory Pot
Think in terms of getting a Minimum Viable Product as fast as possible. We all know that your idea is amazing and has a ton of features that would change people's lives for ever, but try to identify the most important and amazing ones and isolate them in a version 1 of your product. Which will be your victory pot when completed.
Again, our interest span is quite short and the excitement you feel about this project today (as big as it might be) could be gone in a week. Let's try to at least validate that the idea works and hopefully that will give us more things to be excited about and thus continue working on the project.
This is not your job...
...yet
If you work as a Software Developer and your side projects is about software too, you might be unconsciously applying the rules and practices you have at workplace.
- Don't push to master
- Write tests
- Create Pull requests
- QA
If you do this you might feel like working 12 hours a day and you are going to quit very soon. Make yourself comfortable while working on your side project, try things like: Work on a different machine, use a different setup that the one from work both in hardware and software, feel the "switch" to the side project.
Push to Main Master FTW
It's ok to push to main
master
During my first side projects I was trying to follow the workflow we had at my job so I created a branch, made the change, create the PR (with description), setup review apps and then merge it almost immediately (because there was no one to review).
This was time consuming and repetitive and I got tired of it, so I pushed to main master once in my next side project and it felt so good I could not stop. It increased the speed at which I was developing features and I was more comfortable with it, it helped me keep motivated by doing things that I am usually not allowed to do at work.
It then becomes also like a playground to experiment new things.
Experiment
Break the rules
A very important tip to keep yourself motivated through out the development process of your side project is to allow yourself to experiment with different approaches to solve things.
For example, I usually order my CSS properties alphabetically at work, I don't like that but it's something I have to do. I was doing the same thing on my side projects and I was feeling that discomfort. Until one day when I realized that I can order CSS classes the way I want and no one can stop me! (Insert tyrant laugh here)
I think it's better to order CSS properties by context, and split them by a blank space when needed for example:
.my-css-class {
display: flex;
height: 350px;
width: 100%;
font-size: 2rem;
font-weight: bold;
}
It might create a big class but it's easier for me to identify the property or property group I want to (or need to) change, it can also create very large CSS files but if you use a preprocessor like SCSS you can split them easily. I have a post on my TO-DO list explaining why I like this approach, stay tuned!
Anyway, I tried the above approach on my side project and it felt so good, to actually be able to do what I think it's best rather than what other people think is best.
Keep Yourself Motivated
KEEP YOURSELF MOTIVATED
KEEP YOURSELF MOTIVATED! Find new and innovative ways to keep yourself motivated while working on side projects, this is mostly special and specific to each human but here's something you can try:
- Tell your friends about your project and show your progress to them, don't worry they won't still your idea.
- Try new approaches of developing software, not just the conventional ones. I'm pretty sure you have challenged those "best practices" before. This is your opportunity to find a better way!
- Work at your pace, set your own work rhythm: Don't set yourself deadlines or too many objectives. You might thing that without deadlines or a work calendar you are going to fail at making progress or work at all on your project, but all of that is replaced by the motivation you will have of working on it!
- Create a playlist with the songs you like the most and don't listen to them only until you are working on your side project.
- Reward yourself with a prize when doing progress: The candy you like the most, a day free of working even in your side project, etc.
- Invite some of your friends to work on the same project!
Finally...
This guide might help you getting your project to a quick MVP level to validate the idea. You might end up with a bunch of mediocre features with poor quality code but a bunch of others that are innovative and creative. By "finishing" many side projects you will be refining the process and you are going to get better at delivering products with higher quality.
The purpose of this guide is to enable you to validate your side projects quickly and to hopefully help you get one of those to a successful end.
Top comments (0)