Lessons learnt from side projects

Over the last few years i've worked on 4 side projects. One was a personal trainer website for matching you with personal trainers in Dublin (not released). The second one was a website/image archive for my old school https://benildus-college.firebaseapp.com/ with React and Firebase. The third was a web app for organizing secondary schools online study resources (never released). The fourth was a joint venture building a car buy and sell app with a tinder like interface. I worked on that for about a year and I left the project during summer 2019 on good terms. The guys kept working on the project and have done a great job releasing it recently with a great response from users. You can check that out here https://www.sweep.ie/.

I'm currently working on a project called devkeep that helps developers organise their online research/learning.

Here are some lessons I've learnt about working on side projects over the last few years.

Build something you feel is worthwhile

It will take a lot of time and effort to build something great. Because of this your motivation for your project will likely be volatile. In order to actually follow through with your idea you will need to feel like theres worthwhile challenge to tackle. A good question to ask is "Can I see my self working on this 5-10 years", this way you can view the project as a life decision, rather than just a cool thing to build and really gauge whether its something your willing to commit to in the long term.

A good starting point for thinking about things to build that you feel are worthwhile, is to try and think of software that you personally want. If you really want it then it's likely you feel that it's worthwhile thing to build over the coming years.

Involve people you have a shared history with

If you want to involve other people in the project you need to be able trust them both professionally and personally. Ideally you could involve someone you have worked with before and are good friends with. That way you know if they're good at what they do and you have experience solving problems with them and over coming conflict. Remember when your building a start up you're not just building the product you're building the team that builds the product so involve people you trust fully and work well with.

Solve simple problems really well

When developing a new product (not prototype) its often tempting to do whats quickest to implement so you can see more progress. If you are serious about your project then this is just impatience. Do the simple things really well and watch a quality product emerge over the weeks and months ahead. If you keep building on top of sub standard code you'll eventually create a nasty codebase that sickens you to even think of. Take your time and take pride in doing the simple things well.

Refactor early and often

Theres a famous saying that I think is sometimes misinterpreted "Move fast and break things". This does not mean write shite code! You can write good code really quickly if you make the extra effort to refactor often. If you write something just to get it working thats grand, but once it's working don't just leave that there tidy it up! This will make your project feel like a sturdy ship moving forward rather than a stack of dinner dishes you're struggling to keep stable. This will also make developers you hire in future enjoy working in your codebase, and will speed up any new features they look to implement.

No Zero Days

It's really tough to juggle a full time job with a side project. When you come home from a long day at work the last thing you want to do is hop straight back into programming, you just want to switch off and watch Rick and Morty with all of its nihilistic undertones. Don't beat yourself up over that. You can either decide to do just that and switch off completely, or you can open your laptop and pick one small thing to work. Rather than a few weeks going by with no progress on your project, you'll find you've got a load of work done out of nowhere. Remember you don't get time back so treat it like a precious resource and get into a habit of doing a bit when you're nakered.

Use Postman for API docs

Use postman to test your API as you build it, this way you build the backend and documentation at the same time. Also when your ready you can use Newman on top of Postman for regression testing.

If you've ever worked as a FE dev somewhere where there is little to no documentation for the API you'll realise how important it is. You can waste a lot of time trying to figure out how to interact with an API. Sometimes you just have to read the backend code to figure out what to send and why. In the early days when its just you working on your project this is fine because you know whats going on front to backend in your own head.

Imagine you are a FE dev just off the street and you've been roped into working on your project, the aim is for them to be able to start implementing new features straight away without having to ask the old wizard in the corner about that dodgy controller!

Use Trello to organise work

Trello is great! It helps you organise future features down to small bugs and prioritise your work. The column layout I use is Backlog, Todo, This week, In Progress, Done. The 'This week' column I think is really important for side projects because it helps you focus on incremental progress.

Thanks for reading hopefully this helps you with your side projects.