When I was reading each of the introductions of the “Apprenticeship Patterns” book, the term “breakable toys” came up a couple of times. I wasn’t sure what the authors were trying to describe, so the Breakable Toys pattern was the next that I read. As it turns out, this pattern resonates deeply with me and my workstyle.
Breakable toys are essentially more private projects or spaces where practice is encouraged, without being concerned about the potential consequences of failing. For an apprentice who works in a high-stakes environment with no room for failure, this pattern is key to better understanding and learning about the tools used in their workplace. It removes the pressure of having to consistently be correct when developing software, which would be daunting not just for apprentices, but also for those with more experience. Breakable toys are great for anybody who simply wants a safe spot to work on projects away from their work environment.
Whenever I am writing code, or really doing anything in general, I am always nervous about failure. In conjunction with my previous post (which touches upon the apprenticeship pattern called Be the Worst), I also get intimidated when working with those with more experience, which in turn causes me to get worried about causing any failures when working with such individuals. For me, implementing a Breakable Toy would be great so that I could comfortably learn at my own pace, without fear of messing up in front of the development team and further affecting my ever-present impostor syndrome. I already have started various personal projects and courses, which I can now view as Breakable Toys of sorts.
Reading about this pattern didn’t really change the way I’m thinking about development and my apprenticeship process. Rather, it helped me realize that the kinds of activities that I’m already taking part in (like coding projects on my own or working my way through courses/textbooks outside of my schoolwork) are great steps that I should be taking in order to fine-tune my skills while also embracing any failures that may arise. By encountering these failures now, I can also better prepare for being a part of a development environment with less room for error.
Thanks for reading!