Breakable Toys
Curiosity killed the cat
As programmers, we like experimenting with various tools, technologies and platforms. The "bleeding-edge" of technology fascinates many in our tribe. We read about something, it catches our attention, we get curious and then we want to play around with it. Sometimes the bleeding-edge is overrated and curiosity kills the cat.
Teams I've have worked with in the past have adapted in different ways to save these cats.
Dedicated Platform Teams
Platform Teams focus on architecture, infrastructure, developer productivity, etc. A lot of time is dedicated to exploration and experimentation and these teams are not directly involved in product engineering. Things like Tech Radars and RFCs (Request For Comment) are used for discussions, evaluation and adoption.
Functional Teams
Functional teams manage both feature development and continuous improvement. These are self-organising teams designing their workflows and processes. The focus on exploration is a bit limited compared to dedicated platform teams.
If It Works, Don't Touch It
Some teams follow the "if it works, don't touch it" mantra religiously. Sometimes this may be a pragmatic approach but I've mostly experienced this in codebases that are rigid and not robust, fragile and not flexible. To top it all, the work environment does not allow for failure. Yet failure is often the best way to learn anything. Only by attempting to do bold things, failing, learning from that failure, and trying again can we succeed when faced with difficult problems. There's one thing everyone can do to grow in such environments.
Creating Toy Systems
Magicians would not attempt new tricks on an audience without practice. As experience is built upon failure as much as success, a private space needed to seek out failure. The same applies to software, we need a safe place to make mistakes. Design and build toy systems that are similar in tool set, but not in scope to the systems you build at work. This is the Breakable Toys Pattern.
When building Breakable Toys, make them relevant and useful to you to keep things fun. Here are some of my toy apps for example:
- MovieGuide: an Android app to track movies and try out some GUI design patterns.
- Mizu: a Mac app to remind me to stay hydrated and learn how to build for Mac OS.
Your solutions might be massively over-engineered for the problem they’re solving, and probably could easily be replaced by something off the shelf. However, these projects are where you are allowed to fail. They’re the projects where you can try ideas and techniques that might lead to catastrophic failure. But the only one who can be hurt by their failure is you.
The essential point is that building the toy involves learning new things, giving you an opportunity to gain a deeper understanding of your tools in an environment that is both safe (since you are the only or most important user) and where there is still room for you to better serve your own needs as a user than even the slickest of commercial alternatives.
These are your Breakable Toys. As you carry them with you from job to job, some of them will become living embodiments of your craftsmanship. Despite that, remember that they're toys and as such should be fun. If they’re not fun, then after the initial burst of enthusiasm they will gather dust while you focus your energies on the things you actually enjoy building.
So, if you can't find a team where you can explore, experiment and grow, build Breakable Toys. Deliberately create opportunities to learn by stepping beyond the edge of your skills and build fun software projects.
I've written about Communities of Practice previously, these can be another way of learning and building stuff together with like-minded people.
References
