- October 18, 2012
Expanding The Box
- @markhuot
- Development Director
I always hear stories of managers pushing employees to “think outside the box”—to go beyond their day-to-day and find that idea that is unlike anything else. This is a tall order and maybe even a bit unrealistic. If our comfort zone is A, B, and C, how can we expect to find X without first understanding D–W? Because of this, I like to think in terms of “expanding the box” instead of jumping entirely outside of it.
Working primarily on back-end development, front-end development and CSS aren’t always part of my day-to-day workload. Nonetheless, as an overly-nerdy back-end developer, I like to keep current and explore the aspects of CSS I find interesting. One way I recently did this was by modeling the Brooklyn Bridge in CSS for
WebKit-based browsers. It’s a silly exercise with no clear real-world application, but man was it fun. Most importantly, I didn’t start outside the box (even though I may have ended up there). I began by simply wondering if I could use Sass to create a 3D rendering engine. I’m very comfortable with Sass. 3D modeling, on the other hand, is a bit foreign to me. Beyond some Maya work I did in college, 3D modeling lies well outside the box. By combining Sass and 3D modeling, I was able to expand my understanding of Sass by learning a bit more about viewports and rendering engines. This project allowed me to experiment with Sass mixins to create 3D primitives, such as cubes. It also gave me a chance to play with CSS animation beyond common hover changes. Animating a car in a 3D space to drive across the bridge required me to understand and integrate my knowledge of animation, 3D space, transforms, and z-index stacking.
Expanding your box of knowledge can be as simple as trying a new technique or as complex as learning a new programming language. I like to keep up with other languages, because doing so helps me in my primary language every day. For example, while I work in PHP most days, I absolutely love Django’s template inheritance; and Ruby’s Tilt template library seems like the smartest implementation of disparate engines yet. If I were to dive into creating either of those from scratch, I’d be hopelessly lost, because my understanding is still just A, B, and C. So, to help move me along to the X that is a Ruby Template engine, I try to keep knowledgeable about the Ruby syntax. Recently, I took my love of Handlebars.js and applied the library to a fun Ruby project building a Guard watcher to precompile handlebars templates. On the surface, I’m comfortable with Guard and use it often to compile Sass projects. But, I never had written my own Guard library. Writing a Guard library allowed me to write Ruby without worrying about library or gem specifics. I was simply building on past work to extend it to function as I needed. I learned a bit about Ruby modules and expanded my understanding of Ruby exception handling.
In the end, both of these examples started well within my comfort zone and pushed me into areas in which I don’t typically work. They built on a solid foundation of knowledge and took something fun to bring that foundation to new areas. So, next time you’re asked to “think outside the box,” try expanding it instead. You may land even further if you do.