Summary:

Retreat into competence is a pattern that involves taking a break from a challenging task to work on something you are more comfortable or confident in. This helps a developer reflect on how far they have come and can keep them motivated to move forward. Patterns may emerge that show how you got proficient in that task. These patterns can then be used to advance your current tasks. Motivation can also be a problem if someone is constantly getting stuck on a task, or just not being able to progress a project forward. Being able to step back and complete a more familiar task can help keep up the drive during the long road.

Reflection:

This pattern really popped out at me originally for the “Context” and “Problem” sections, as I have felt very overwhelmed many times finishing up my college degree. There have been countless times that I have questioned if I have learned enough for my degree. Each semester felt like it only introduced me to a whole new branch of computer science that I didn’t know. Even the classes that had focused on more advanced topics still felt like it was only just the tip of the iceberg.

There have been a few times this semester that I have been stuck on an issue and just could not figure out where to start looking for a solution. It can be really demotivating when you are unable to complete a task that other people are relying on you to complete. Taking the time to work on another issue helped me in both ways mentioned above. Solving an issue that I was confident I could do made me realize what steps I needed to follow to work on the other issue. Not only this, but being able to actually complete an issue kept my motivation up as I felt like I was contributing to the team.

When I first read through this pattern I originally thought mostly about the motivation and satisfaction aspects of being able to complete a task that is familiar to you. However, as I read through it and began to understand more about what you could learn from working on more approachable projects. Paying attention to and understanding the patterns and steps one takes to solve familiar problems can be used to solve new or challenging issues.

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

Retreat into Competence

This pattern is about how it is easy to get caught up in constantly learning new technologies due to the fast pace of software development, and how to manage the intense pace of learning. The pattern highlights the importance of taking a step back from the fast paced learning and to focus on honing existing skills. Trying to learn the latest tools, frameworks, and methodologies can be overwhelming. Along with the overwhelming feeling of trying to learn many skills at once, there is also a risk of never fully mastering the fundamentals. Therefore it is important to take a step back, and take time to practice fundamental skills.

According to the pattern, being an apprentice is a rollercoaster ride. This is because there is the thrill using newly learned skills to deliver value to the customer, but there is also the terror of realizing how little is known compared to more experienced craftsman and experts. However both are normal and inevitable experiences.

Although the pattern encourages developers to take a break from learning new skills, it also emphasizes how retreating back to competence is to not get stuck in the realm of competence. It is important to be intentional when retreating, as this pattern is only a short term fix. Spending too much time on this pattern can lead to halted learning. Being able to learn something new is a skill in itself; therefore, learning should be practiced unlike any other skill.

In order to prevent the pattern being used, setting a time limit for honing new skills is useful. This is so one does not focus too much on retreating, and helps them stay in the habit of learning new skills. A strategy the pattern suggests is to pick a well understood topic that is self contained, and to reimplement it. This can help regain confidence to propel learning.

Conclusion

I found this pattern to be interesting as constantly learning new technologies can be tiring, so having a strategy to regain confidence is helpful for the future. I particularly enjoyed the analogy of a catapult to represent this pattern. The analogy being that the skill of learning new topics can be launched forward by taking a step back. The pattern has changed the way I view learning new skills, and maintaining old ones.

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.

For my final Apprenticeship Patterns reflection, I want to talk about the “Confront Your Ignorance” pattern in the second chapter, “Emptying the Cup”. In the last sprint of our software development capstone course, I felt that I wasn’t able to deliver my best work – partly because of how undeveloped my unit testing design skills are, and partly because I caught a mild cold partway into the sprint that zapped my energy levels. If I want to be honest though, the former problem was the more severe of the two, and it will stick around far longer than the sniffles I had. I’ve realized how much more I need to study the technologies I’ve been working with. In combination with the “Reading List” and “Record What You Learn” patterns, I want to put this pattern into action over the summer break and establish a disciplined reading and studying habit for software development topics.

In addition to the unit test design, there were other parts of the work I took part in over the semester that I didn’t completely understand before it came time to implement them. Docker is one subject I want to take the time to research in further detail, since it was an essential component of our work. I first encountered Docker last semester, but it wasn’t until this semester that I’ve understood what the purpose and benefits of virtualized containers are. I know now that Docker allows development teams to create applications within a common virtual operating system. What I want to learn more about is how to write docker-compose files to initialize a functional HTTP backend server. One of my tasks this sprint was to do just that for one of the backend microservices in Thea’s Pantry, and I wouldn’t have been able to do that if there wasn’t a complete docker-compose file in another backend that I could adapt for the repository I was working in.

The largest gap that in my knowledge that I’ve been wanting to address is my technical skill with Java. Java has been the language that I’ve accomplished the most with, next to Python, but I haven’t taken the time to write any Java this semester besides the foundations of my MonsterFactory project, which I realize now could qualify as an example of the “Breakable Toys” pattern from the textbook. Over the summer I think I would like to implement my studying of unit test design into the MonsterFactory and create some tests for the abstract factory classes.

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

Throughout the long road of lifes, we always strive to find success, but sometimes we may hit roadblocks and fail. Some of us choose to accept those failures and learn from them, but others may neglect those failures and choose to take an alternative route. The Learn How You Fail pattern, emphasizes the importance of embracing failure. Embracing failure is a crucial aspect of not only personal growth but also professional growth. This pattern encourages us to look for our weaknesses and patterns of failure, and instead of avoiding them, accepting and learning from them. If we can gain knowledge on how, why, and what led to our previous failures, we can learn from them, make adjustments, and pave a path to success in the future.

When we think of the word failure, we often think that it carries a negative connotation, referencing setbacks or disappointments. Yet, in our journey as aspiring craftsmen, failure is not just part of our professional learning, it is possibly one of our greatest teachers. We’ve all experienced some sort of failure at some point in our lives. But the most important part of dealing with failure is pinpointing why we failed, fixing it, and taking those issues head on.

I found this pattern to be extremely interesting considering many people give up after they fail. Failure isn’t something that should be feared or avoided. Instead it should be embraced as a catalyst for learning and self development. It underscores the idea that true growth comes from a willingness to confront our failures and adapt. What I find particularly interesting about this pattern though, is its emphasis on self-awareness and introspection. By actively seeking to understand our patterns of failure, we can empower ourselves to make better decisions about our personal and professional development.

After reading more, I was able to connect the pattern to the software development field. In the field, we cannot just expect to find success. Through lots of learning, practice, and trial and error, we can eventually find success. Instead of viewing failure as a setback or embarrassment, I view it more as an opportunity for reflection and growth. I now realize the importance of acknowledging my successes but also embracing my failures as learning experiences. In the future, I plan on having a more proactive approach towards identifying and addressing any of my weaknesses, rather than just ignoring them.

With this being said, the Learn How You Fail pattern, offers valuable insights into the importance of embracing failure as a means of personal and professional development. By learning from our failures, we can ultimately find success in our chosen fields.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Summary of the Pattern:

In the pursuit of professional growth, stagnation can often be a hindrance. The pattern, “Be the Worst,” advocates for seeking out environments where one is the weakest member of the team. By intentionally placing oneself in a position where there’s ample room for learning and improvement, individuals can continue to progress in their careers.

Reaction to the Pattern:

“Be the Worst” challenges conventional wisdom by advocating for humility and a willingness to learn from those more skilled. Initially unreasonable, this approach fosters an environment conducive to continuous learning and development. The personal narrative of David H. Hoover underscores the transformative power of embracing this pattern, highlighting the significant gains that can be achieved by putting oneself in a team of exceptional developers.

Interesting Insights:

The notion of deliberately positioning oneself as the weakest member of a team prompts reflection on personal growth and professional aspirations. It underscores the importance of humility and the recognition that true progress often stems from embracing challenges rather than seeking comfort in familiarity.

Impact on Professional Perspective:

For individuals navigating the dynamic landscape of their profession, “Be the Worst” prompts a re-evaluation of traditional career trajectories. It encourages a shift from a mindset focused solely on achieving positions of authority to one centered on continuous improvement and skill acquisition. This pattern has the potential to redefine how individuals approach their careers, emphasizing the value of learning and adaptability in an ever-evolving industry.

Disagreements and Considerations:

While “Be the Worst” advocates for joining teams where one is the least skilled, it’s essential to acknowledge potential challenges. The risk of feeling overwhelmed or inadequate may deter some individuals from fully embracing this pattern. Moreover, the pattern’s emphasis on humility and learning from others may not align with certain cultural norms that prioritize individual achievement over collaborative growth.

In conclusion:

“Be the Worst” serves as a reminder of the transformative power of humility and the value of surrounding oneself with mentors and peers who inspire growth. By embracing the discomfort of being the least skilled team member, individuals can unlock unparalleled opportunities for learning and advancement in their professional journey.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

The “Breakable Toys” pattern offers a solution to a common problem faced by software developers, which is the lack of opportunities to learn from failure in a professional setting. The purpose of this pattern is to create a safe environment where developers can experiment, make mistakes, and learn without fear of repercussions. By building toy systems that mimic real-world settings but with reduced scope and complexity, developers can gain valuable experience and develop their skills more effectively.

The intriguing thing about this pattern is its emphasis on the importance of failure in the learning process. In many industries, including software development, there’s often a stigma attached to failure, which leads to a culture where taking risks is discouraged. However, this pattern changes that mindset by suggesting that failure is not only acceptable but also a necessary step toward growth and improvement.

As someone whose goal is to become a software developer, this pattern has certainly changed my perspective on my approach toward learning and skill development. It highlights the value of creating a learning environment that prioritizes experimentation and iteration over perfection. This helps get rid of the fear of failing and being afraid to make mistakes, and now I see them more as opportunities to grow and learn.

One of the aspects of the pattern that resonates with me is the idea of “budgeting for failure”. By allocating time and resources to build and experiment with breakable toys, developers can proactively invest in their own professional development. This proactive approach to learning is essential in this industry due to the continued growth and evolution, where adaptability and continuous improvement are key to success.

While I do like this style of thinking, I can also see potential challenges in implementing this pattern in a corporate environment that may prioritize productivity and efficiency over learning and experimentation. Convincing management or team leaders of the benefits of breakable toys may require a shift in mindset and a willingness to embrace a culture of learning and innovation.

Overall, the Breakable Toys pattern offers a refreshing perspective on how to approach learning and skill development in software development. By creating a safe space for experimentation and failure, developers can cultivate a growth mindset and become more resilient and adaptable in the face of challenges.

5. Perpetual Learning | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Expose Your Ignorance” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to show that you don’t know everything and can have confidence in learning is essential to growth, both professionally and personally.

This section of the chapter discusses that learning is an essential part of the development process. “Show the people who are depending on you that the learning process is part of delivering software. Let them see you grow. According to research by the social psychologist Carol Dweck, the need to appear competent is ingrained into people of most industrialized societies. These societies are increasingly dependent on your competence as a developer, as software creeps ever-deeper into our everyday lives. Yet because of your inexperience, you have many zones of ignorance. You are in a bind. The people around you—your manager, your client, your colleagues, not to mention yourself—are all under tremendous pressure to deliver software. You can see the need for confidence in people’s eyes when they ask you how long feature X will take you to finish. There can be tremendous pressure to pacify them, to reassure them that you know precisely what they want, how you’re going to give it to them, and when.” The need to appear completely in control and competent when you are new is a very difficult instinct to let go of, but it is essential to free yourself of it if you want to progress.

You must be honest with your colleagues and clients, don’ just tell them what they want to hear because what they want to happen might be impossible. “Software craftsmen build their reputations through strong relationships with their clients and colleagues. Conceding to unspoken pressures and telling people what they want to hear is not a good way to build strong relationships. Tell people the truth. Let them know that you’re starting to understand what they want and you’re in the process of learning how to give it to them. If you reassure them, reassure them with your ability to learn, not by pretending to know something you don’t. In this way, your reputation will be built upon your learning ability rather than what you already know.”

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Concrete Skills” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to supplement your knowledge with practical abilities will show to future development teams that you can be a helpful addition to the teams.

The first part of this section talks about how some of the first concrete skills that you will learn will mostly entail navigating HR and team assignments, and being able to assure your team mates that you won’t need constant supervision. “Acquire and maintain concrete skills. Even though one of the things that an apprentice brings to a team is an ability to learn quickly, the possession of discrete and demonstrable ability with specific tools and technologies increases the likelihood that you will be trusted to contribute indirectly until you start to gain stature. Some of the concrete skills you should acquire will be little more than mechanisms to get you past crude HR filters and managers who construct teams by playing buzzword bingo. Others will reassure your prospective team members that you can be put to good use and will not require “day care” (Organizational Patterns of Agile Software Development, p. 88). Examples of concrete skills include writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice.” Being able to show your fellow developers that you can stand on your own with development is a very important aspect of joining new development teams, but you must be able and willing to ask for help when you need it. The next section mentions something briefly that I think is incredible important, being able to quickly and effectively show an interviewer your concrete skills.

Being able to quickly and succinctly describe your concrete skills in a technical interview is essential. “The point is that you will often require hiring managers to take a leap of faith in choosing you. Concrete skills (which are ideally discrete enough that you can bring toy implementations to an interview) allow you to meet them halfway. The concrete skills you possess are your answer to the question: “If we hire you today, what can you do on Monday morning that will benefit us?” A deep understanding of Your First Language will help establish your credibility and should prove to be extremely useful to your team.”

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Unleash Your Enthusiasm” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to properly and effectively hone your energy to be the most productive is an important skill.

The article first discusses how a new hire’s enthusiasm can be unintentionally forced down by the new hire in order to try to fit in with the development team. “Despite (and because of!) your inexperience, you bring some unique attributes to your team, including an infectious enthusiasm. Do not allow anyone to dampen your excitement for the craft—it is a precious commodity and will accelerate your learning. As a software developer, you will inevitably work as part of a team. In any group setting, there is a tendency to conform to the norm, particularly for newcomers. Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar. They either repress their enthusiasm altogether, or allow it to manifest only outside of their day jobs.” While this is a natural reaction, it is important to be able to know when to show some of this passion to your team because, your passion is infectuous and may be able to help with team morale.

You must be careful however, depending on the team showing too much passion may work against you. “There are certainly risks involved in unleashing your enthusiasm on an established team. If morale is low or if the team is not welcoming of newcomers, you will likely get some eye-rolling behind your back. You could certainly make a poor impression on people who value competence more than learning ability, particularly when you expose your ignorance. Like any pattern, this one should not be applied blindly. Team dynamics should always be considered. If you find yourself on a team that does not accept your excitement, you will need to find ways to nurture your passion. “

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.