Let’s talk about pet projects
In many years reviewing job applications from software developers, one topic has come up as surprisingly controversial time and again: pet projects, i.e. projects that developers work on on their own time. So let’s have a look and see what the fuzz is all about.
From the employers perspective
First, let’s look at it from the employers perspective. A colleague of mine once succinctly put it like this: “You wouldn’t expect a slater to tile a roof in their free time, would you?”. And there’s a lot of truth to that.
As an employer selecting potential candidates there are two main reasons why you would want to scan for pet projects and they aren’t too positive:
Employer reason 1: you want the best
If you’re looking to hire the best developers, you might be tempted to use the presence of a pet project as an indicator of engangement and passion. However, at the same time you’ll also narrow down your candidates to those who have ample time to maintain these projects by neglecting other hobbies like families and non-development-related activities which might broaden their horizons when solving problems.
As such, with a steady supply of studies showing that diversity is good for performance, you’ll be doing your team a disservice by applying this selection criterion.
Employer reason 2: no time to train & educate on the job
Another issue might be that employers don’t want to allocate time for their employees to further their skills on the job. Time might be notoriously short and developers are supposed to crank out code as quickly as possible.
There are many reasons why this is bad practice but let’s focus on the fact that in such a climate, mistakes are bound to happen and the code base will be a hot steaming mess after just a few months.
This might not be a problem in the context of service companies that are supposed to deliver small projects with many similarities over and over but whatever the context might be: any developer who is driven enough to maintain a pet project in their free time will probably want to leave this environment as soon as they realise what’s going on.
From the developers perspective
Nonetheless, even if your employer gives you room to experiment and learn on the job, there are good reasons to start a pet project.
Developer reason 1: you’ll have to do non-coding tasks, too
When working on a pet project, you’ll also have to think about all the things that happen around coding.
- what are the most important features for your app and what can be left out? (MVP)
- how is the UI supposed to work so that it is intuitive and shows relevant information in the right places?
- how to interact with users and prioritise feature requests?
- how to communicate problems to users?
- …
Having to do all these things helps you to see the bigger picture which ultimately will make you a better developer, too.
Developer reason 2: more space for experimentation
While an employers training program will usually try to focus on the technology and frameworks that are already being used on the job, a pet project gives you more freedom for technological choice.
You might want to look into other programming languages or even experiment with other programming paradigms like functional programming - something I heartily recommend, btw ;) Or you can try out another front-end framework that you have heard about but which isn’t being used yet at your place of work.
Also you’ll come in touch with other aspects, like setting up a CI/CD pipeline that aren’t usually in scope for your regular work.
TL;DR
Yes, I’m a big fan of trying out other programming languages in my free time and love the insight this gives me into what I knew before.
But while I’d recommend every developer to experiment with pet projects, I’d strongly advise employers against using them as a criterion for employee selection.