As a web developer, I have this almost magical ability to think of a weird thing I wish was on the internet and then make it so.
Facebook for dogs? I can try making that. A ToDo management system? You bet I can throw another one of those onto the pile of ToDo applications that feed the hamster powering the wheel that runs the entire World Wide Web.
Or at least, we as developers have the skills to make some version of those things. What usually happens, though, is that we start a personal project and then it lives on as a half finished ghost town repository in a Github account.
Side Projects are Awesome but they Sure are Hard to ‘Finish’
Most of the time, we work on our side projects in the tiny chunks of time between our other obligations. Maybe you find you have 30 minutes before dinner, or an hour in the morning before work. It’s easy to just spend that small window of time trying to remember what you were working on last. It’s even easier to put off spending time on your project when you have a million ideas and feel like you don’t have enough time to do them all.
This blog post is going to outline some tips and tricks for success working on a side project. Spoiler Alert: it’s a lot of the things we already have to know and do for work.
Let’s imagine you want to make a website that prepares people for coding interviews by providing sample programming exercises and look at some tricks you could use to finish your Interview Code Challenge Website.
1. Use a Project Management Tool and Write Stories
I know this is a side project and after work is just for fun times – but be as rigid about writing stories/tickets as you would be at work.
Sit down and write user tickets. A feature story for your Interview Code Challenge app might be: ‘As a user, on the home page, I want to see a list of programming languages and links to exercises ordered by language’.
As you work, create tickets for defects and chores. This will help keep you from getting caught in the weeds while you’re focusing on features.
Check out software, like sprint.ly, for managing the stories.
If you work like this, you’ll spend way less time trying to remember where you left off last time and more time committing code. You can also avoid the natural tendency to procrastinate on hard things by telling yourself ‘Okay, I’m just going to open Sprint.ly and look at the next thing in the pipeline and maybe write a line or two’. You’d be surprised how much you can trick yourself into getting done.
2. Plan Out Iterations and Releases
One of the hardest things to figure out with any project is ‘What is My Definition of Done?’.
When you were day dreaming about your programming exercise app, you imagined that users would be able to review other users’ solutions. You figured they’d also want to be able to search for exercises that specific companies used – which would mean building a way to crowdsource users submitting code challenges from interviews they’ve been on. You even had an idea where the user would have a profile with their completed challenges that they could send to employers.
Some ideas are good, some ideas are bad – but either way, they’re not all getting done.
When you’re planning, start to group stories and epics into iterations. Force yourself to plan an MVP (Minimum Viable Product). For your code challenge application, you’d love to have users submit their solutions, but really, the main thing is that you want them to be able to find the challenges. So your MVP here is ‘users see static challenges, sorted by programming language’. Start moving all other great ideas into different iterations beyond the MVP.
Releases don’t have to start at the MVP. Many people will consider their first release just setting up a shiny splash page with a call to action for people who access the page to sign up for an email list for the beta release.
You side project may never be ‘done’ – but you can consider an iteration or release as being done – and celebrate each one!
3. Work in Branches
Things come up. Never leave your master branch a mess, assuming you’ll pick it back up tomorrow. You might get halfway through development on the feature where a user can submit their own code challenges and you suddenly realize you’re going to need to refactor your entire user model to make this feature work. Now you really want to take a step back and plan this feature out a little bit better.
Only one problem… you’ve been committing and pushing up things to master as you go. Now what do you do? Revert all the work so you can work on something else? Leave things half done?
In the words of my co-worker Michael: ‘If you set your project down while it’s in a broken state, it’s extraordinarily hard to pick it up again’.
Even if you’re the only one working on a project, do yourself a favor and split new work into its own branch.
4. Make Your Project Easy to Work On For People Who Aren’t You
If your project is open source, making it easy to work on will allow you to un-ironically say things like ‘Pull Request Accepted’. Harness the amazing force of random contributors by adding a README document that walks a user through pulling down the application, downloading the dependencies and running the tests. If you’re working in Github, create some Github issues for tickets that people could pick up and work on.
Good things to turn into Github issues would be things you could tag as ‘Easy Pickins’ – which are non-critical bugs or small improvements that don’t require a developer to know everything about the domain. I also suggest adding issues tagged as ‘Nice to Haves’. These are features or improvements that are outside of your interests or skill sets.
If your project isn’t Open Source, then you’re probably planning to make money off of it. And if you make money, you’re going to want to make more money, and that’ll involve bringing on another developer or 20. Your project might suddenly get tons of press and you need to scale it up quickly.
Make your code your documentation and refactor as you go. Keep your README up-to-date. You’ll thank yourself when you hire someone and don’t need to spend days walking them through every page of code in the application.
5. Balance Learning New Things and Accomplishing Goals
A side project should always be the kind of work that pushes you to learn new things and grow as a developer, but balance your desire to learn against your desire to have a working product.
Let me explain.
Let’s say you want to learn React.js. Learning a new framework is hard. You can build your new Code Challenge application with a React.js front-end but don’t also decide that this is a good chance to start using MongoDB and to roll your own version of Bootstrap.
If you’re working on a project that you feel passionate about, then choose your new tech challenges wisely. If your heart is in delivering features, you might spend more time getting frustrated with new tech than learning from it.
If you really want to learn React.js, MongoDB and CSS grids all at the same time, maybe make a silly ToDo app or Facebook for Cats with that tech stack – not your passion project.
6. Look at your Employee Contract and Do Not Work on your Side Projects at Work*
I’m adding an asterisk to this for the times when you’re doing a ‘side project’ as a part of your job – but generally speaking, it’s a bad idea to commit code on your personal projects during working hours.
I am not a lawyer and this doesn’t represent legal counsel, but I typically follow these rules:
1. Don’t commit or store any personal code on a work device.
2. Don’t commit any code on personal projects during work hours.
I do sometimes spend my lunch hour reading blog posts, or play around with techniques that I think I might want to use in a side project.
Some employer contracts allow you to own your own work – but you may be surprised to find out that you may have a contract with your employer that has some gray area where that’s concerned. You might even find that your company owns anything you write, regardless of when where and how you write it. You’re taking a risk if you have a contract like that and you decide to do first and ask permission later.
If you are at all worried about legal issues around the ownership of your side project, consult with a lawyer who specializes in the field. It’s worth the expense to build the relationship and to educate yourself.
Side Projects Really are Awesome
You learn a ton from them, and sometimes you even make something totally amazing. Ultimately though, the you that exists outside of working hours is probably the worst employee you could ever hire. PersonalLifeYou is often easily distracted, flighty, unavailable most of the time and a huge procrastinator.
If you want your side projects to go well, be as formal with yourself as you would with a new employee.
And never forget, you’re a wizard, Harry. Go forth and make magical things.