The Value of Personal Projects
If i had to hire engineers on their answer to a single question, that question would be "tell me about your personal projects". That may sound silly, but i haven't found a question whose answer better correlates to ability of the interviewee. This shouldn't surprise people, the best developers are generally the most passionate ones. It would follow that the passionate developers work on more personal projects than their less passionate peers.
But while that simple explanation passes the sniff test, the reality is actually reversed. Personal projects make developers better. Better developers then want to work on more personal projects, so the improvement loops back and reinforces itself. The gateway to this growth is starting personal projects, not some latent genius.
Regardless of the interpretation you buy into, we can probably agree that personal projects make a developer better at their craft. Every bit of code is practice, after all. You find a problem, you code a solution. The cycle repeats and you grow as a coder.
This cycle also has another benefit. When you encounter problems in a personal project, you can use any technology you want. When we write programs for our job, we reach for techs we are familiar with. With experienced tools in hand we deliver more reliable code, faster. Personal projects offer us a lot more freedom. This freedom is a big deal for the teams we work with at our jobs.
Over time, mainstream development technologies shift. Without developers experimenting with personal projects, there are two ways a company can expand its team's expertise: bring on new engineers or pull in new languages for upcoming projects.
Hiring, i think we all know, is a slow and tiresome process. It is also not a sustainable way to keep a team up to speed on evolving technologies. Our other option is to adopt new languages/technologies on an upcoming project. This is almost always a bad idea. Your first foray with a language or tech will leave you with a number of "next time i would change" moments. While valuable, those lessons harm a company's codebase and should be avoided.
So, hiring is slow and expensive. Blindly adopting new techs is fast and quite possibly more expensive. Far cheaper than either is for developers to experiment with techs themselves, free of the codebase their team is married to.
What we are saying here is that working on person projects makes you a better coder. As an added bonus, these same projects expand your teams expertise by extension. It sounds like a win-win. The drawback is, of course, hours are a limited resource. We have jobs, families, friends and basic human needs. Is there balance to be had here?
There is. With all this value surrounding person projects, it surprises me more companies don't build in time for their teams to do them. No matter, I am going to do personal projects regardless of if a company is affording me part of 40 hours/week to do them. If a company wants me to work so many hours that i can't sustainably continue my own projects, i simply cannot work for that company.
That may sound harsh, but it is the reality of the matter. Work on personal projects. You're duty, should you want to own one, is to be excellent at what you love. Personal projects can be a big step toward that excellence.
