Recently I completed another pet project of mine, and now after completing a handful of projects of substance I’m at a place where I can give my insight into the value and importance of making time for a code project on the side. Hopefully this will help highlight some gains (and caveats) to consider when allocating time to write a pet project.

First off we need to define what a pet project can/should be. It should be something that gives you interest, it could be a new technology (new to you or new in general), something you’ve come across your day-to-day, an idea of your own or something completely new you can bring back to a community. Either way it needs to be something meaty, something you’re willing to give a bit of your time to for a few weeks/months and pay dividends in the long run.

Now comes the reasons why you should be turning that idea/concept into a tangible reality…

It's your project

Simple first reason. Despite whatever you’re doing 9–5, this project is your baby. Just like an artist works on their sculpture, or a petrolhead tinkers with their car, you as a coder get to work on something for you.

It’s your chance to go ‘off-script’.

It’s natural as a developer to be locked-in to specific tech choices in our jobs. It can be something as generic as the language itself (Java, .net etc) or something as specific as a framework (angular, react etc). Either way this is your chance to go ‘what-if’. You can explore a technology to whatever degree you want.

The value is in the knowledge.

So you’ve written something completely off-script from your usual day-to-day. The result? You may produce a busted bit of code, but at least you’ve learned a completely new technology in the process! You may like it, you may loathe it. Either way it’s some experience you’ve got for the future.

WARNING — just because you’ve done a pet project doesn’t make you a subject matter expert. The dangers of exploring something new independently are that you can establish anti-patterns and code smells unknowingly. It’s very easy to fall into a trap of being the go-to person on a tech topic just because you fiddled with it for an hour on a Thursday night. Don’t panic, this is all part of the process!

---

You offer something new to your job.

Regardless of your level of expertise, you’re offering something to you and your team. It could be something as simple as a brownbag talk, or something much more valuable. Either way, you’re informing others of something new from a faraway land!

Furthermore there may be someone else on your team who can help further your learning or idea. That anti-pattern you were unknowingly writing? Someone with more experience could point you in the right direction! The important fact to take from this is you’re becoming more of a subject matter expert than you were before trying your pet project.

---

You (might) have something useful at the end of it.

As well as learning something new, there’s also the chance you have a tool at the end of it. Maybe you tried prototyping a build server, maybe you wrote a gulp script, maybe it’s a reusable module. Either way it’s a tool you (and maybe others) didn’t have before starting on your crazy idea! Maybe it’s something you can share further (maybe it’s lucrative!)

---

You get to be naughty.

Unlike your day-to-day job, this probably isn’t the time to be playing by the rulebook. You don’t need to sprint, you don’t need to test to the nth degree, you don’t need to over-engineer. It’s your chance to break the rules.

I’m sure every engineer gets bogged down at some point in their job, they want to get something written but there’s a billion other tasks that go with it (they’re there for a reason but that’s another discussion). Nothing like a pet project to help let off steam and throw code out the door unchecked! Sure it’s throwaway code, but it gives a sense of momentum when writing stuff. As long as you’re aware you’re ‘breaking the rules’ and don’t make a habit of it when it really matters then it’s okay.

Of course you could go one further and start enforcing yourself to start testing, sprinting, creating dev/prod builds etc but don’t lose sight of your pet project’s intent and purpose (you could always have a standalone pet project to explore testing for instance).

---

A chance to fail.

I think this is goes hand in hand with my earlier warning, voyaging into the unknown you are going to screw up. With a pet project you can at least isolate your screw up on throwaway code. One scenario which still boggles my mind is when a company wants the newest of the new but aren’t willing or able to give their engineers the time or facilities to become acquainted with the newest of the new.

Usually PoCs or hackathons can help do this exploratory work but I’ve seen and heard of times this hasn’t been the case (as if we’re supposed to be able to plug knowledge into our brain and learn it like kung-fu in the matrix).

Worst case scenario is you use brand new tech on your production product with about 5% knowledge on the subject matter. You can’t complete the project (or write something riddled with bugs) and end up in a bad, bad place. One of the biggest risks? It’s essentially blind leading the blind.

With a pet project you can at least embark on that voyage in advance. You’re investing your own time for work (which is up to you) but at the same time you’re aware of the traps and pitfalls you and your team may come across. If you screw up or start getting stuck you can at least address these problems before these problems become risks to your project.

Personally I like to digest new ideas on my own time on my own terms and let my professional work excel because of the time I’ve put in. I’m not saying try and write your project before writing your project for reals. My suggestion is at least use a pet project as an exercise in writing an end-to-end of something you know it’s going to rear it’s ugly head (and possibly make your 9–5 miserable). Identify all moving parts and issues when it’s not critical, you’ll thank yourself in the long run and will help solidify your confidence in a new tech area (less blind leading the blind, more someone with bad glasses leading the blind…)

---

A chance to improve and upgrade.

We all have that scenario where our tech choice becomes out of date quickly. If only we had a chance to upgrade and try the latest and greatest? With a pet project you can do that.

In the past one of my projects has been very much an evolutionary one. It’s seen three iterations over the past four years and is now entering it’s fourth iteration. What are these iterations?

• Migrating from a webforms CMS to ASP.net MVC
• ASP.net MVC with API
• react with API
• react to full server-rendering with node and an orchestration api.

Each iteration brings something new. I learn the migration process whilst also embracing new tech choices and architectural patterns. Basically whatever you write now, you get to revisit/refactor/rewrite later. With something like github it makes it even easier to fork and try something new. You may move between jobs or professions, but your pet project code will stay with you for future use.

---

Considerations

So I think I’ve addressed the benefits and advantages of allocating time for a pet project. But there are some important considerations to be made when embarking on your own project.

Check your stature

This is a more serious consideration, companies can be strict around policy when it comes to writing your own code. You may be contractually obligated to forfeit any code you write whilst under employment as the code may be owned by the company. Most companies are lenient and promote your own independent learning so long as it doesn’t affect business, but you need to know where you stand.

My advice is to be aware of what you’re writing, if it’s of value to your employer or competitor then you should address it. Usually I base my pet projects around something existing open source, or something that’s going to serve no practical purpose to anyone other than myself. And keep pet project work on your own time at home and on your devices at home, it helps keep that work/life balance.

Conversely you should always ask if external forces are impeding your independent learning and professional development (red tape shouldn’t be a reason you can’t keep up with the industry, it’s your future).

---

Keep your pet project time in check

It’s all too easy to let a pet project die, it’s also all too easy to donate too much of your time to a project. You may be able to finish work and then start writing your pet project for 3 hours an evening, but just remember you’re basically adding 15 hours to your working week.

---

Remember the intent and purpose of your project

Basically don’t go overboard. It’s all too easy to get carried away with a pet project and allow it to explode into something new. If you want to extend a project into a new idea (or ideas), think how to do it strategically. You may be signing yourself up to something impossible and wasting code originally intended for something more practical.

---

Keep checking your work is of value

Always ask if your project is still useful as time goes on. Don’t beat a dead horse for the sake of completing a project (you wouldn’t be asked to do it at work, don’t do it at home). There’s no shame in abandoning a pet project if the knowledge gain or final product is useless. If you end up in that unfortunate situation then take it on board (if a overnight redundant framework has come from a specific company, you know not to trust them so much going forward). Certainly don’t delete your work as eventually you may find use for that code it in a future pet project.

---

Now go pick a pet and write some code!

I think I’ve offered as much insight and advice as I can for pet projects. In the future I’m going to discuss how to effectively allocate time for your project but for now I hope I’ve given you good reason to start investing some personal time for your professional development!