This post is an adaptation from a post by Dave Hooper on Breakable Toys. Dave’s original project referred to breakable toys. I hate the metaphor but the underlying concepts were still valid. This post is an attempt to convey the concepts while changing the metaphor.
Experience is built upon failure as much as (if not more than) success.
You work in an environment that does not allow for failure. Yet failure is one of the best ways to learn things. Since only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems.
Budget for failure by designing and building systems that are similar to the systems you build at work in toolset but not in scope and that allow for you to experiment with.
“We can all benefit by doing occasional programs, when artificial restrictions are set up, so that we are forced to push our abilities to the limit.” - Donald Knuth, Computer Programming as an Art, 1974 ACM Turing Award Lecture
If experience is built upon failure as much as success then there needs to be a more or less private space where you can seek out failure. In juggling, the three-ball juggler who never attempts five balls never makes the step up. Yet the one who gets back-aches from having to pick up dropped balls for hours on end will one day get it right. The same lesson applies to software. Just as the three-ball juggler would not attempt to juggle five balls during a performance, software developers need a safe place to make mistakes.
As a teenager working in Nova Scotia, Steve Baker was looked upon as a leader and an expert within his small development organization. Steve described how these expectations impacted him: “Everyone expected me to already know the right way to do it. Since I couldn’t use those projects as a learning experience, I had to stop learning.” This reasonated with Ade’s consulting experiences where he couldn’t afford to be wrong and he couldn’t just walk away from people who were depending on him to be right…all the time! Ade knew that in order learn, he needed the freedom to drop the ball. Like countless software developers before him, Ade used learning projects to help him learn.
Make these systems relevant and useful to your life as an apprentice. For example, build your own wiki, calendar, or address book. Your solutions might be massively over-engineered for the problem they’re solving and could easily be replaced by something off the shelf. However, these projects are where you can fail safely. 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 yourself.
A classic example of this pattern is the multitude of people who have built their own wikis. A personal wiki is a great tool for the apprentice because you can use it to Record What You Learn. Wikis make good Learning Projects because they can be simple, and there are countless examples to look at if you Use The Source. Other examples of Learning Projects include games (one of our colleagues is in the habit of writing a game in every new language he learns) like Tetris and Tic-Tac-Toe, blogging software and IRC clients. 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 Learning Projects. As you carry them with you from job to job, some of them will become living embodiments of your craftsmanship. Despite that you must not forget 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 whilst you focus your energies on the things you actually enjoy building.
Often these learning projects are simple re-implementations of industry-standard tools that give you a deeper understanding of the forces that lead to the current design of that tool. At other times one of your learning projects will take on a life of its own and acquire other users. In those cases you may find yourself having to seek out a new learning project.
