I thought being open-minded when you’re learning something new was useful from the reading. I thought it was interesting because a lot of people don’t like change and would prefer to stick with what they already know but when it comes to being an apprentice you need to have an open mind when learning new things so you can broaden your experiences and learn not to get too comfortable with certain skills. I know some people would disagree about not getting comfortable with one skill because they probably believe that one skill is more important than any skill but those other skills could not only improve the skill that they mastered but also teach them something new. Chapter 4 is a great example of being really good at something and then realizing that there’s always more to discover. This reading has caused me to change the way I learn things. I don’t need to learn and master one skill set I should expand my horizons and not get comfortable with one skill. The reading also talks about overcoming challenges and learning from them, that’s how you improve your skills instead of just getting upset and giving up. If you are too comfortable with what you’re working on you won’t have any motivation to push yourself to learn more. 

I don’t disagree with anything from the reading because it’s only telling people to stay curious, don’t be afraid of any challenges, and keep trying to improve their skills. Those things are important when being a new apprentice, they help you become more successful and not limit yourself. The chapters that stood out to me were chapters 2 and 3 because it was very detailed about learning new skills and being confused as part of the journey as well as being good at one skill doesn’t mean you shouldn’t stop learning new things. Those chapters are about pushing yourself and not staying in just one lane, I think that is why I like those two chapters so much because I’m used to just learning one thing and sticking with it but being open-minded can do so much more for me.

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

Today, let’s chat about a riveting adventure I recently embarked on within the pages of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye, Chapter 1 sets the stage for a profound exploration into the world of software craftsmanship. The chapter introduces the concept of being a Software Craftsman and outlines the three pivotal stages of becoming one: The Breakthrough, The Apprenticeship, and The Mastery.

What struck me most in Chapter 1 was the authors’ emphasis on the continuous learning aspect of software development. It’s not merely a job but a craft that demands dedication, deliberate practice, and a commitment to constant improvement. The concept of transitioning from a novice to a master craftsman resonated with me, reinforcing the idea that the journey is ongoing, and mastery is a perpetual pursuit.

Moving forward into the introductions of Chapters 2-6, each chapter offers a glimpse into the patterns that follow, providing insights into various aspects of software craftsmanship. Chapter 2 shares a thought-provoking story about a Zen master and a young philosopher, emphasizing the importance of approaching learning with humility and an open mind. This resonated deeply with me, challenging my tendency to rush into learning without acknowledging my own ignorance. It prompted a change in my perspective, encouraging me to embrace the learning journey with a more receptive mindset.

The subsequent chapters further delve into the multifaceted nature of software development. Chapters 3 to 6 touch on topics like constructing a personalized curriculum, practicing deliberately, recording what you learn, and sharing knowledge with the community. Chapter 3, “Walking The Long Road,” caught my attention, advocating for viewing software development as a journey rather than a destination. It prompted reflection on setting meaningful goals and overcoming challenges in the ongoing learning process.

The reading has reinforced my belief in the importance of humility in learning and the dynamic, ever-evolving nature of the software development field. It has encouraged me to adopt a more deliberate and open-minded approach to my learning journey. While I don’t necessarily disagree with any aspects of the reading, it has sparked a shift in how I perceive the learning process, urging me to appreciate the journey as much as the destination.

As I progress in this course, the chapters on constructing a curriculum, deliberate practice, and sharing knowledge with the community seem particularly relevant to my growth as a software developer. They align with my aspirations to continuously improve, contribute meaningfully to the community, and approach learning with an open and humble mindset. The insights gained from these readings will undoubtedly shape my approach to software development, guiding me on the path to becoming a Software Craftsman.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

A Dive into Mastery:

“Your First Language,” a pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, champions the concept of mastering one programming language thoroughly at the start of a software development career. This pattern isn’t just about learning to code; it’s about immersing oneself deeply in the language’s syntax, idioms, and, importantly, its community and culture. Mastery of one language is posited as a stepping stone to understanding broader programming concepts, making it easier to adapt to other languages in the future.

Personal Resonance:

When I first encountered this pattern, it felt like a lightbulb moment. The tech world often feels like a race to learn as many languages as possible. “Your First Language” counters this, advocating depth over breadth. This approach aligns with my belief in building a strong foundation before branching out. It’s like learning to play one musical instrument well before learning another; the skills and disciplines you acquire often translate seamlessly.

The Intriguing Depth:

What captivated me most was the pattern’s emphasis on engaging with the language’s community. Programming is often seen as a solitary activity, but this pattern reminds us of the collaborative and communal aspects of coding. Participating in forums, contributing to open-source projects, or attending language-specific meetups can offer insights that go beyond syntax and function.

Redefining My Professional Approach:

This pattern has subtly shifted how I view my career development. Instead of being a jack-of-all-trades, I now aspire to be a master of one (at least initially). This doesn’t mean I’ll shun other languages, but it does mean I’ll commit myself fully to one language before moving to the next. This depth-first approach, I believe, will make me a more competent and confident developer in the long run.

A Balanced Perspective:

While I align with the core message of the pattern, I also recognize the importance of having a basic understanding of multiple languages, especially in a field as diverse as software development. Thus, while I advocate for depth, I also see the value in breadth. Being well-versed in one language shouldn’t mean being oblivious to others.

In conclusion, “Your First Language” is more than just a learning strategy; it’s a philosophy of growth and mastery. By embedding myself deeply in one language, I’m not just learning to code; I’m learning to think and solve problems like a seasoned developer. This pattern, I believe, is essential for anyone beginning their journey in software development.

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

I enjoyed how the reading introduced the values of software craftsmanship. The bullet point that caught my interest was from Atul Gawande. It mentioned how you always need to adapt and change based on the feedback you get. I thought that the fact that Gawande refers to this as a willingness to “recognize the inadequacies in what you do and to seek out solutions” (Better, p. 257) was interesting. I think I tend to get caught up in my inadequacies and don’t think about finding solutions right away. I think that quote encapsulates what it means to be an apprentice, as described in the text. I think having bullet points like these in the beginning was very useful in aiding in understanding.

One of the chapters that I found to be more relevant is the second chapter. It not only discussed the beginning of your journey and why you should start out learning one language very well but it also touched on patterns that happen later in your journey. I enjoyed reading the section that mentioned why you should find a master in your target language to help you learn because the nuances of different languages are best taught through oral tradition. I also found the part about why you should find an opportunity to unlearn something. The example of taking a program you have written in one programming paradigm and then implementing it in a different language that uses a different one was great. However, I don’t agree with phrasing it as “unlearning” what you know. It just seems like learning another language to me.  While learning Java and C I had to do research to find solutions to problems at times. I ended up finding solutions to the problems in languages I didn’t know and worked to translate them. It gave me exposure to a new language and opened my eyes to how the same issue could be solved in a different way. 

Another chapter that I found to be relevant is the fourth chapter. I think you have to constantly be honest with yourself about your own capabilities and surround yourself with people who you can learn from in order to progress toward your goal. There is always room to grow especially when you’re in an industry that is changing frequently. Chapter four touches on striving to surround yourself with people whom you can learn from and touches on what to do if you can’t find a mentor. These are very real issues that many software engineers will face. I never thought about trying to be the weakest person on my team to help myself learn but after reading this chapter I would like to put it into practice when I can.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

this is my blog post for CS 443 where all my blogs will be posted.

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Reading these few chapters was very interesting. It brought some useful topics and contexts to different problems that you might face with some solutions like in chapter two there was a part that was talked about concrete skills and how it gave examples about the problems you can face like if a team has no incentive to risk hiring someone. I liked how they showed and described a problem and a solution. I feel like that was interesting to understand different concepts that they brought up, it almost painted a clear picture. One thing I liked doing while reading these chapters was reading the problem and then without reading the solution just thing about what could be that and then compare that with my answer. Another thing I really thought was interesting was all the real-world examples. The chapters that where most relevant to me or that most I took interest was chapter 3 especially when it was talked about sustainable motivations, this was most relevant to me since I feel like it is something that I always need to work is keeping my motivations up. So, that section was nice to read to learn different illustrations on how to bring the motivation back. The mentor section was another really good one for me just as a reminder to ask for help and find some one that is a “master Craftsman” and not only a master craftsman but a person that will accept you as an a apprentice. I did not disagree with anything in this reading, if anything I found that all the chapters and context was really helpful even if there was things that I already knew, it was good to just refresh and remember different tools and solutions to different concepts. In general, I really thought this reading was very beneficial especially since ill be entering the computer science work force soon defiantly freshened up some context of things I had not heard in a while and it even brought me to thought process of things I never really thought of like when it was states that take advantage of being the weakest in a group to grow stronger that was definitely very motivational for times that you might feel insecure in being a new engineer.

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Intro to Apprenticeship Patterns

Apprenticeship Patterns is for software apprentices who are beginning their career in software development because it provides strategies to guide apprentices how to progress their career.

One of the most useful themes in the text was that a career in software development is a long road and it takes time to reach the end destination of being a “master craftsman.” I found this to be most interesting because it shows that becoming a master craftsman takes time and deliberate practice.

The history of the model in which the text draws inspiration from is what I found to be interesting. This model was prevalent in medieval Europe up until the Industrial Revolution. I enjoyed learning where the name journeyman comes from. This is because they were nomadic and had to travel city to city in order to learn new skills, further enforcing the long road analogy.

One of the most relevant chapters to me is chapter 2: Emptying the Cup. Chapter 2 gives the analogy, “if you already have a cup that’s full, how do you expect someone to fill it?” This analogy refers to going to learn from someone, but assuming you already understand what they are trying to teach. I found this to be relevant because when going to someone for mentorship; recognizing that they are more experienced, so going to them with an open mind is important.

Briefly looking at the apprenticeship patterns in chapter 2, one of the most relevant patterns is Concrete Skills. This pattern provides a strategy on how to know which concrete skills to learn. It states that an apprentice can collect CVs of people whose skills they respect. The apprentice can then use these as a list of skills that are useful to have. Another pattern that I found to be useful is Confront Your Ignorance. The context of this pattern is that there are gaps in your skillset, but are not sure how to begin to fill in those gaps. The text suggests the strategy of writing down a list of skills that may be gaps in a skillset. Then being deliberate about learning about those skills individually. Doing this may also lead to additional gaps in a skillset. This pattern is relevant to me because it gives a strategy of how to identify gaps in your skillset, by breaking down the gaps into small manageable tasks.

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

My initial gut feeling about this was honestly that I can’t really see myself being so entrenched with something that equates to labor that I need to perform in order to get money to survive. I certainly want to be good at what I do, but the reading came off as though you are supposed to absolutely hone in on software development in order to be a craftsman, in a sense. I’m sure that wasn’t necessarily the intention, but honestly there are things that I overall value more in terms of learning than the things that I have to learn for my work. That being said, I do understand that learning to learn is an important part of learning to be a software engineer, and that this book does seem to want to establish good practices so we can better our skills, even if we don’t commit ourselves completely to being defined as software developers through and through. This is touched upon in chapter 5.

With regards to chapter 4, I do find that many people in virtually any occupation find themselves, at some point, in a place of stagnation and unwilingness to adapt to advancements in the field or technology over time. As much as I don’t want to be defined by my labor, I don’t ever want to find myself in a position where I am actively choosing not to learn, as this is not only disrespectful to myself but also disrespectful to those I am working with.

I found chapter 3 the most relevant to me personally, as I tend to experience a sort of imposter syndrome a lot when looking at others’ capabilities compared to mine, mostly in terms of intuition. There are things that, at my current understanding of a given skill, I cannot inuit as quickly as those who are more practiced in that skill or have more of a natural inclination to that skill, maybe because they have had early experiences with the skill or because they’ve spent more time with it. Either way, I do think it’s something you have to kind of overcome. I’ve been informed of a statistic that over 70% of tech professionals have reported experiencing imposter syndrome in their careers, and it’s no joke. It truly is something you have to sort of overcome and learn to focus on yourself and your growth.

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