It's been a while since I've done a blog post. A lot has changed since then: I've graduated from a university, moved, and started a job. A coworker asked me to type up my thoughts on working on things that aren't exactly work related to enhance your skills, the assertion being that any new skills could benefit the company in the long run. My first thought was "Hey, blog post!" and such this post was born/forged/hastily thrown together.
I've always been a fairly laid back developer in some regards and very much not in others. That's not a very descriptive way of putting it, so let me explain. I will take my shoes off, try to relax and write some code. I'll walk around and talk to other developers, maybe even playing a game of Go or helping with a jigsaw puzzle or two. I feel that environment helps foster creativity which is good for developers. Creating software is as much an art as it is a science. I like to compare it to writing an essay, in that an essay can be beautiful if it's well written. The problem comes when the most beautiful or "elegant" solution isn't the easiest to read. It may be the most concise which many developers have made the mistake of assuming is always the best. When we read a well worded essay, we skip over the part of deciding if it makes sense and immediately are able to see its effectiveness. The same happens when we design software. If code is well written, we can discuss high level concepts without looking at the gritty details. This is where I'm not laid back. I believe in continued refactoring and improvement. If a feature you're trying to implement doesn't fit perfectly, make room for it by first refactoring enough to create a nice place for it. If you're not sure exactly how the feature will work, you can always start with pure TDD, creating tests for it until it exists by itself or you understand exactly how you want to interface with this new object/feature.
I start with that long intro because I feel the background is necessary to show exactly why I feel the way I do. I believe that working on things that aren't strictly work related can be detrimental or beneficial,but it depends on both scope and attitude. Scope is referring to how closely related to your job it is. Writing doom to work on some piece of hardware may be beneficial if this piece of hardware is something your company makes that you need to support. You might learn a lot about the system that you would have never known beforehand that could be beneficial later. It would be like if you had been using a while(True) loop with a break statement based on some variable, but later found out there was this magical thing called a for loop. Your code would be cleaner because you decided to dig a little deeper into an area you were unfamiliar.
The same thing can happen if you want to learn a new language. You might learn a new language or framework (I'm currently loving the Haskell language and the Laravel php framework) which is beneficial to your way of thinking. Haskell has been useful for me because it allows me to see things as small modular and composable functions that can each be verified individually before being verified as a whole. Laravel has given me a new perspective on IOC and Dependency Injection that I would not have seen before. (Shout out to Laracasts for posting videos about testing and SOLID)
It's fairly easy to see if your scope matches with your company and your own objectives. Try and measure it from a scale of 1 to 10. If it's a 10, then it's highly cohesive and is a very good quick side project for you to experiment with. A 1 would be a project that's going to take way too long for it to be useful and has very little to do with what you're working with or plan to be working with.
Also, I am not responsible for you getting fired. Always talk to your boss first.