After reading Apprenticeship Patterns, I was left perplexed over some of the topics this book covered. To preface, I think that the authors, Dave Hoover and Adewale Oshineye, did a great job addressing how Software Development demands that individuals retain a ‘growth mindset’ throughout their studies and practice. My largest gripe is with how they frame individual progression. Hoover and Oshineye use an apprenticeship model to describe one’s progression. For starters, I believe that mastery does not exist and conflicts with the content covered in Chapter 2. The authors define mastery as “performing all the roles of an apprentice or a journeyman as well as focusing on moving the industry forward.”. Fundamentally this would be a fitting definition, as apprentices focus on learning, and journeymen focus on applying their knowledge. In practice, it can be difficult to find a balance between these two roles. Furthermore, masters are ‘pillars of knowledge’ as apprentices and journeymen refer to them for their experience. In this scenario, if the master has not found a balance between learning and practicing, then they may give ineffective or incorrect information. My solution to this dilemma is the erasure of mastery. In a field such as Software Development that is ever-changing mastery is nigh impossible to achieve. Hence, we must all dedicate ourselves to improving and finding balance between apprentice and journeyman responsibilities.
Despite having personal issues with their framework, as the content they covered in later chapters resonated with me. Chapters 3 and 4, Walking the Long Road and Accurate Self-Assessment respectively, shared ideas I agreed with the most. Chapter 3’s driving point is that we are all on the same path and that skills you see in others can be eventually learned by you. A year ago I found myself in a group of students learning Software Development. We were learning how to write tests in Java, which I had experience with from another course. In this group, we all knew the fundamentals of testing, but each of us had different skills outside of testing that we indirectly taught each other over the semester. Naturally, I was intimidated by the amount of knowledge my group members had that at the time I lacked. As the semester came to a close, that knowledge gap slowly closed as I found myself learning from seeing how they approached these problems. Chapter 4’s driving point is to not settle with your inadequacies, but to grow because of it. In this chapter, the authors suggest surrounding yourself with people who understand the material you’re trying to learn. Linux commands and Docker are some of my least knowledgeable subjects, but I chose them as my focus for this project to further develop my knowledge. Fortunately, I have been placed in a team where we all have varying degrees of skill with these subjects. I have been taking tasks involving team organization and documentation, as through writing these instructions and understanding our workflow have slowly begun to fill gaps in my knowledge.
-AG
From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.