In breakable toys of Apprenticeship Patterns, the authors clarify that developers should have room for failure, and failure makes greatness. Good experience is built upon failure as much as success like in the saying “Rome was not built in a day” which means there is no overnight success. Mistakes are made, but learning from mistakes is a way to help us gather deeper knowledge and also aid us in collecting further experiences.
What was interesting in Breakable Toys was the close bridge between learning and failing. Failure is part of a software developer and without failure, there would not be a great developer as well as great software. What I agree is developers should be given space where they can seek out failure to train their mindset and to develop their practical involvement. The example was Steve Baker (a teenager working in Nova Scotia), people looked upon him as a leader and an expert within his small development organization. Thus, he could not afford to be wrong and obviously could not walk away from his people who were depending on him. The solution that he later found out was using a breakable toy. Breakable toys were the tools that he used to help him learn by failing.
What I have learned is that when implementing the breakable toys pattern, I should make the system relevant and useful to my life as an apprentice. The examples were building my projects such as a to-do list or expense tracker. At first, the solution would somehow be overengineered and failed. Yet, these are the type of projects that were designed to be backslid without any bothersome. They are used to develop my ideas and techniques and could be a disaster but that is a part of learning. By building these projects, they give me a deeper understanding of designs, data structure, and language. Furthermore, not giving up on problems would help me eventually get them right. Beyond constructing things myself, consider team efforts as one of the alternative ways of learning.
The point that the authors try to make in this chapter is by building things will help developers learn better than listening to plain lectures. Allowing space for failures is a way of improving and expanding knowledge as well as experimenting to learn deeper and to understand thoroughly.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

The most significant part of the learning process as a software developer is putting the knowledge that I have acquired over time into actual, practical use and create something tangible that is a good representation of what I have learned. While it is important to have a good grasp in the theoretical aspect of my craft, it will do me absolutely no good if I do not actually exercise the skills I have acquired, especially when I need to use them in a professional environment. However, it is not just the act of simply practicing any acquired skills that is important. What is also important is to know how to properly apply the skills in real situations. For example, simply knowing how to code in theory is simply not enough on its own, it is also important to experiment with the acquired skills as part of their learning process. In this case, the pattern of “Breakable Toys” is introduced.

When a developer chooses to utilize “breakable toys” as part of their learning process, it means that they are working on personal projects that, although they are detached enough from a professional environment so as to minimize the risk of failure, they have enough functionality so as to maintain the realism of working on an actual project that needs to be delivered. Essentially, a developer creates a functional project on which they can experiment on and use any potential mistakes that may occur along the way as valuable ways of reflecting on or enhancing their learning process. The developer gets to reap the benefits of hands-on experience with none of the risks of  that would come up if their inexperience were to result in failure while working in a professional space. However, it is important to note that “breakable toys” in programming does not mean that the practice that you put on is discarded immediately after a developer has a better understanding of the problem they practiced on. Rather, “breakable toys” that are broken should also be recorded with the same importance as spike solutions that work flawlessly.

This particular pattern is a favourite of mine as it combines the pattern of “Practice, Practice, Practice”, which I always enforce in my own working career ad-nauseum, as well as the pattern of “Record What You Learn” since even small projects that were made on a whim may still be valuable enough to return to later. However, a significant aspect of this post’s pattern that aligns with me is the focus that it puts on actual hands-on experience, which is more valuable to me than endlessly reading documentations that I may never utilize.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

The pattern I decided to read is titled “Expose Your Ignorance” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts with throwing out a hypothetical problem where the reader is working for an employer that is expecting the reader to deliver a product but the reader is unfamiliar with the required technologies. The solution to this problem is in giving an honest response and building a reputation on your ability to learn rather building a reputation on what you know. This pattern also mentions how asking questions is a great way to expose your ignorance because you show what you are learning to your teammates. The pattern ends by discussing how exposing your ignorance is a trait of walking the long road because it means you are open to learning unfamiliar technologies and new domains. Whereas, experts tend to narrow their scope of learning, practice, and projects by specializing in specific things.

There were two instantly helpful pieces of information I gathered from reading this pattern. The first useful piece of information was how as I work on becoming a software craftsman, it is more useful to be known for my ability to learn things instead of being known for the specific technologies I am already familiar with. This piece of advice immediately affects how I think and how I will speak about future projects.

The second thought-provoking piece I read was how becoming an expert is a by-product of the long road I am on. This absolutely blew my mind but also humbled me because I should have known this already since I use a similar perspective for exercising in the gym. My goal of living a long and healthy life means that as a result I will have strong muscles if I am regularly going to the gym. I think one of the reasons this was so striking to me is because I feel like I have such a long way to go before I feel confident enough to call myself an expert in something. Therefore, hearing that becoming an expert is a by-product of the long road showed me how long this long road really is for me.

Lastly, there isn’t anything significant in this pattern that I disagree with. It was an enjoyable pattern to read and one where I learned some valuable information.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Malcolm Gladwell published a book about him analyzing how the practice has helped successful people succeed with the 10,000 hours rule. One of the sections in Apprenticeship Pattern Guide for Aspiring Software Craftsman ensures the similar point that practicing is an essential key in making a software engineer become better.
What I found interesting about this is the connection between some of the points in this section and Malcolm Gladwell’s in the “Outliers” are Malcolm shows that practicing was among the factors that led to the Beatle’s success and Bill Gates himself. These people had been able to manage practicing days and nights to the point that they were quite comfortable with the materials similar tools no matter what or where.
Taking the time to practice your craft without interruptions which means to the point where the mistakes are what we are comfortable with as it is mentioned in the Apprenticeship Pattern Guidance . I found it very interesting of how these two authors have the same perspective of spending more time practicing and confronting the problems. Ultimately at a critical time, we might run into those problems again, and being able to solve them would save us time and sources.
To be honest, I’m not a fan of lectures therefore sitting over a lecture in college is somewhat an achievement to me and I’m more like a hands-on person. Fortunately, that is one of the good ways to learn as a Software Engineer.As it was referred to in the book, a beginner should learn by doing rather than reading and sitting through lectures. Besides that, doing and repeating exercises helps us sharpen our skills, our minds, and our bodies to react to the disciplines. Another excellent point in this section that I found helpful is writing a lot and writing code often would help us develop neurons reactions in a good way.
Open to feedback is introduced in this section as well which I completely agree with. Being able to get feedback helps us determine whether we are on the right track. But part of me finds this odd because not everyone could get a good mentor and not everyone can give you good feedback. This also often is hard for people with small circle of relationships and connections. Relying on someone else feedback without knowing ours own issues is not a wise choice.
What I learned from this is finding an exercise and sticking with it until I could solve the problem on my own and then observing the solution that I have made over time as a programmer would have a measurable impact on my abilities to solve any problem later in my career.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern discusses how software developers need to chart their own paths. It talks about how a software developer’s career is their responsibility, and they must take an active role in shaping it. The pattern notes that it’s not up to your employer, your career counselor, or your professors to decide what the next step is for you career. You should also not let company culture or expectations prevent you from achieving your goals. Only you can decide what is the right step and what is not.

To make progress in your career as a software developer, first you need to identify an ambitious but logical next step. Then once you have identified your next step, you need to come with up with smaller intermediate steps that will help you reach that next step. The pattern really emphasizes breaking things down. This is because the pattern notes that difference between doing things in a daydream and doing things in reality is the willingness to take that very important first step. The pattern recognizes that this could be a terrifying thing to do, and so breaking your goal into small bite sized, realistic, and achievable steps would help make taking this first step less daunting.

The pattern also highlights that there is no such thing as a single path or a perfect path to take. Everybody’s career map is different because everybody has different circumstances and values. Your own career path should be based on your own circumstances and values. You should be continuously reassessing your career map as your values and circumstances change. Sometimes this results in your career map aligning with those around you and sometimes it does not, and you must chart a new path.

I think this apprenticeship pattern can be summarized into three simple steps. First, search for and pick a logical but ambitious goal that advances you in your career, break down those goals into small and achievable tasks so you can turn it into reality, and finally make sure that you’re following your own path that’s based on your own values and circumstances. By following these steps, you will have a much easier time analyzing and identifying the next destinations on your career map as well as being able to do what’s necessary to turn your goals into reality.

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.

Summary:

This apprenticeship pattern is concerned with a lack of familiar tools that a programmer has on his belt. It’s recommended that the apprentice become very skilled at five tools such that he does not need to read the documentation while also understanding the nooks and crannies of them. As time goes on, and he moves from job to job or project to project, become sufficiently familiar with the tools he learned. This does not mean that an apprentice that is good with these tools means it will be good for others or for the team.

This pattern is similar to the “Your first language” apprenticeship pattern, which states that it’s good to master your first language before moving on to a second language. I like this apprenticeship pattern because of its ideal of mastering and recording the tools that one learns. I also like the idea of trying to find better and more powerful tools available whilst the apprentice writes down the tools he is already familiar with. 

The pattern has somewhat changed my view on my intended profession. However, I don’t have a hardline goal about what my intended profession looks like, I’m completely fine with bending my skills and attitudes based on what my employer wants me to do, and what is required of me. If my team at a future company requires me to learn a new system that I’ve never used before, then that’s what I’ll do. Likewise, if they require me to use what I already know, then I’m also completely fine doing that as well. 

I’m not entirely sure if I fully agree with the fact that all of the tools that an apprentice will learn and be familiar with will become obsolete by the time he becomes a journeyman. What if a student / apprentice becomes very familiar with Java and eventually becomes employed as a software developer who utilizes Java? I know as time goes on, tools change and languages become favored or disfavored as the development landscape changes, but I am having a hard time agreeing with this statement. I know that a lot of different apprentices can have many different skills, many of which can me more useful than others, especially when taking into account what type of work they’ll likely be employed in.

From the blog CS@Worcester – Chris's CS Blog by Chris and used with permission of the author. All other rights reserved by the author.

The apprenticeship pattern I have chosen this week is the “breakable toys’ pattern which was very interesting to me. The pattern was about failure and how it is usually the best way to learn. There is a problem however when the place we are working in does not tolerate any failure and any such occurrence will have dire consequences. Here with the breakable toys pattern, we are allowed to make our own systems that are still relevant to our work. This way when we work with them and make mistakes, can can apply what we have learned to our workplaces without it hurting other people in the process.

This here is an interesting pattern to think about as so far, most students have been in a environment where mistakes are common and tolerated but later down the line, they will most likely face a much harsher environment than what they are used to including me. This means that later down the line, I will have to invest my time into these side projects in order to obtain failure and stimulate learning. There could even be one used in some of our current projects in which we could make some side projects in order to boost our learning. This also makes me wonder on the tolerance of different places on how much do they tolerate failure which is most likely very little which makes these breakable toys all the more important for one to use. Although that does make me think on whether or not the person would actually have the time to develop these programs. There is the chance that the work this person is working on is already very time consuming and that if their life was a bit too hectic with outside responsibility’s to actually make of any use of these toys in which this pattern might not be for them.

This pattern overall is a good one to learn on failure without it negatively affecting other people, especially if I were to go into professions that were high profile or had any basis in security in which failure is not an option.

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.

In this apprenticeship pattern, it talks about the importance of practicing our coding skills and how we should practice. The section starts off by talking about how the reason why people make coding mistakes on the job is because they are practicing and learning the skill while they are doing it. A lot of programmers do not have the time to practice and learn the skill before they have to put the skill to use at their job and with the looming project deadlines that is why there are often so many mistakes made on the job. So, the first thing that the chapter talks about is the importance of finding time to practice coding skills on our own without any deadlines. Without deadlines, it removes the pressure of having to learn a skill before a certain date and we can learn at our own pace. In addition to making time to practice our coding skills, the section also talks about how we should allow time for criticism. This is because if we don’t, we may or may not pick up bad habits without knowing it. The last topic that the section talks about is the importance of not practicing so much that it becomes a permanent habit and that instead we should be careful on what we choose to practice.

I agree with this section and think that practicing is very important. I think this is something that I personally need to work on. Often after I learn a skill in class, I don’t touch that skill again until it is brought up again in another class and usually by then, I had let that skill become stale. Another thing that I agree with from this section is the importance of not practicing too much and that we should be careful of what we practice. I agree with this because I was guilty of letting this happen before. A while back when I was practicing coding with my cousin, we were both working on the same problem, and I coded it how I normally would. My cousin asked me why I was coding it that way and I told him that it was how I always coded it. Then he showed how he did it and his way was very different from how I did it. So, he showed that I was letting practice become permanent and that I was coding the same way whenever I see a similar problem. So, my cousin reminded me that there may be more than one way to solve a problem and that we should consider the best way.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.