Breakable toys

Up until relatively recently, Facebook’s mantra was “Move fast and break things.” As a smaller startup, that seemed like a cool or trendy catchphrase, suggesting that they were an agile company that could adapt and afford to leave older functionality in the dust in favor of new hotness. But you and I, most likely, don’t work at facebook. And we all know that breaking things isn’t sexy to our employers, and definitely not to our clients. With that in mind, I think it’s important to have “breakable toys”. Little applications that are created that demonstrate proofs of concept but aren’t integral to business processes. Programs you’re okay with completely destroying, because you’re learning an important concept that could revolutionize your bigger idea. Such applications are ways to “move fast and break things” without actually doing so. They allow you to embrace failure as a learning process instead of as a sticking point with a client. I’ve been embracing this concept of breakable toys for the past year—my GitHub serving as the cutting-room floor for concepts, failed experiments and new technology ventures. It’s helped me push forward as a developer, learning important concepts such as polymorphism, join tables, nested forms and lower-level SQL queries—important concepts that older / more “classically-trained” developers might take for granted. At their hearts, breakable toys force you as a person to step beyond your boundaries. But I think the most important part of this idea is the word “toy”. These projects should be fun! They should remind you of why you started creating in the first place. Discovery should be an exciting prospect, not a word that fills you with dread at the beginning of a project sprint.