Not everything you do has to be for a purpose.
Sometimes, it's ok to play around. It can even be helpful in the long run. You might not know why it's going to be helpful, or when, but it will come back to you - I promise.
Your life is built on past experience. What you do each day shapes your brain into what it will be tomorrow. As an engineer, you have inspiration all around you. If you read Hacker News or other blogs, it's almost a guarantee you find inspiration on a daily basis. If you walk around your apartment or clear your mind in the shower, you experience moments where your mind is free from distraction and the weight of your ever-present todo list.
That's why playing around is so powerful. Try it sometime. It's a trick to get you inspired or get you in the zone. Here are a few examples where playing around has helped our team:
Bruno, one of our developers, has been playing around with Chef.
Bruno wanted to dive into DevOps and learn Chef. EngineYard uses Chef, so we need to learn it as we go to make tweaks and setup deployment tasks. However, our team lacks quite a bit of knowledge in the Chef department (you know, setting up your own Rails application servers on AWS or Digital Ocean).
Bruno has been playing around with Chef for the last few weeks. In our weekly engineering meetings (I'll have to write a blog post about these), Bruno has been showing us what he's done. The first week he showed us how he spins up a Digital Ocean server via the command line. The next week he showed us the tools he was using to provision the server and setup all the necessary components (nginx, uwf, ssh, etc.). And just last week, he showed us how he setup Capistrano to complete the create, provision, deployment path.
We've also been wanting to build a pair programming gem (a one command pair-programming setup in vim and tmux for two people in different countries). As we were talking through his Chef experiments, we realized that Bruno had already built half of the gem. Part of the gem would provision a $5 Digital Ocean server to serve as a "meeting point" between the two remote developers.
Without somewhat playing around with Chef, we would still be without much progress on our gem.
In my free time, I've been researching Rails 4 and upgrading Tula at the same time.
We set an engineering goal for the year to move Tula to Rails 4. We'd like to take advantage of the Live Controller instead of using web sockets among other things. However, we haven't really set time aside to do it - we've had an overload of client work as of late and we've had higher priority items for Tula.
Instead of waiting until we were able to dedicate the time, I started playing around. I didn't really have a goal in mind nor a timeline of when I needed to get it done. I just wanted to see if I could get things working (at least a little bit).
So, I bumped the version of Rails to 4.0.3 to see what would happen. Of course, things started blowing up. I started reading through the Rails 4 upgrade guides and looking through the logs for deprecation warnings. We had quite a few scopes and queries causing problems due to changes in Rails 4. Since we weren't really on a timeline, that was ok - I slowly started fixing major problems.
Within a day or two, I was able to get things somewhat stable. We aren't done with the upgrade yet (I'm still spending just an hour or two at night), but we have a much better idea of where we're at and how much effort it will take. We're actually almost done.
If I hadn't started playing around, we still wouldn't know much about the Rails 4 situation with Tula.
Project Idealism