Category Archives: Week-15

Apprenticeship Patters Chapter 2 (Emptying the Cup)

For this week, I read the Apprenticeship pattern “Emptying the Cup”, the second chapter of the Apprenticeship Patterns. I found this pattern to be very interesting since this chapter teaches you how to effectively become a better apprentice, as well as how to use your experience of problem-solving to become a better member of a programming community later on. While the beginning of this Pattern explains the pouring of the tea cup, it is actually a metaphor that pertains to “clearing your mind of bad habits”, meaning that you should remove all distractions or de-motivators so that you can think more openly about the subject in mind.

I find it very interesting that the rest of the sections describing the “tools” to start your apprenticeship are sorted in a specific manner so that you yourself are familiar with all the experiences and different skills needed to learn a programming language. For instance, there is a problem and solution section in the “Concrete Skills” Section of “Emptying the Cup” that caught my attention. The problem state that a team believes that you cannot write a program, but that is where the solution tells you to learn about building concrete skills in order to convince the team to trust in you to be able to do the work. While the rest of the sections does not touch upon anything specific to programming, they all help you in showing your capability to help with coding.

What I found useful in this chapter was the “Your First Language” section that talked about the effective ways of becoming a better programmer. In the “Solution” section, there’s a specific segment where programmer Ralph Johnson explains in an interview on learning a programming language. When asked about which programming language to start with, he say “…the best way to learn a language is to work with an expert in it. You should pick a language based on people who you know. One expert is all it takes, but you need one.” Like the rest of the “Solution” section describes, I have learned that it is better to learn a programming language when you have an person or a group who can help guide you to writing better programs.

While the rest of the sections start to describe the many different problems and solutions to specific problems, the main takeaway I have from reading this apprenticeship pattern is to openly express your problems and work with your team on showing your commitment to programming in your career. I did not have any specific disagreements with this pattern, but I am still am curious about what the other sections have to show for learning the other patterns.

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

The Long Road

Summary

The long road pattern emphasizes the lifelong journey towards mastering software craftsmanship. In a culture that values quick success, it prioritizes long-term growth and continuous learning over immediate financial rewards and traditional career advancements. This path is more for those who are dedicated to mastering the craft than those seeking quick riches or executive rolls.

Reflection

With graduation behind me, it’s fitting to focus on the long road ahead. One of the lines from this pattern that stood out to me immediately was “For every step you take toward mastery, your destination moves two steps further away.” The ongoing theme through my computer sciences degree was that every time I would gain knowledge in a topic I would also gain even more knowledge about now much I don’t know. This really opened my eyes to how much it is going to take to master the craft. This started to feel daunting as it continued to happen, feeling like the destination is always getting further away. However, another key point in this pattern was that the journey is just as important as the destination.

When I think of what I know now compared to what I knew even just 2 years ago, it’s such a drastic difference. Even with the feeling of the destination getting further away, each step I took was still forward in my journey. With each step I grow and gain skills that I can continue to use. 

As I look to begin my career as a software developer, I understand that quick wealth is not feasible with my current lack of experience and knowledge in the field. This however is not something that will change overnight, which is something I am already aware of. As I look for a job, I really am looking for an opportunity to gain experience and learn while getting paid. This mindset values the knowledge and experience just as much as the monetary value gained from the position. As long as I keep this mentality moving forward I see the experience and knowledge paying for itself down the long road ahead. 

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

‘Breakable Toys’ Pattern

The “breakable toys” pattern from chapter 5 is one of if not the most important pattern contained in this book in my opinion. This pattern specifically talks about the necessity of learning from failure even if your work environment does not allow you to do so. A situation like this is common within industries such as software engineering and the example the book gives of a juggler and how someone who can juggle three balls would not attempt to juggle five while actually performing which relates to software engineering as this pattern encourages you to make mistake and learn from your failures on your own time if your workplace does not allow it. “Breakable Toys” also suggests constructing a similar system to the one you may work on at work in order to be able to experiment on your own time and learn from your mistakes in an environment that directly resembles the one you are in at work. You should push yourself to find learning opportunities for yourself through the use of this pattern as if you do not have those opportunities at work then you must make your own in order to continue learning and get better at your craft. It is also stated that your “breakable toys” should be things that you find fun or have interest in so that even though they are meant to provide learning experiences for you, you are still engaged enough to where you look forward to working with them.

I think that this pattern is very important especially to a software engineer. No matter what company you work at there will eventually be a job where you are expected to make nearly no mistakes and you will not be able to try different solutions due to this expectation. But if you are able to experiment with different solutions on your own and see why they may not work or why they do work you can not only learn for yourself but you can also help the team you are working on evolve from using one standardized solution to using one that could be more efficient or faster.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Capitilzing on your Title

This week, I chose to read the “Use Your Title” apprenticeship pattern under the “Walking the Long Road” chapter. I found “Use Your Title” interesting as it points out that titles like “senior,” “architect,” or “lead” aren’t accurate reflections of one’s personal skill level. Titles like these won’t alone mean an apprentice has become a journeyman, and due to the lack of craftsmen, apprentices still receive these titles, which can potentially cause feelings of inadequacy or overconfidence. This pattern emphasizes maintaining focus on continual learning and self-assessment, viewing titles as indications of company workflow patterns rather than reflecting a craftsman’s advancement along their journey.

This pattern spins a new perspective on the traditional view of titles, suggesting that titles can provide insight into a company’s structure and values. For example, if a title feels inflated or undeserved, it might indicate a lack of rigorous standards within an organization. On the other hand, a lack of recognition might point to an environment where contributions are undervalued.

It’s interesting how the pattern also brings up formal titles such as “senior” while also acknowledging the existence of informal titles. Informal titles are team- or company-wide accepted roles being fulfilled by certain employees without having a title to reflect such. It seems that both have sway in the perception of the validity of one’s work, but informal titles, in my opinion, seem more applicable to one’s skills rather than workflow.

Looking at Dave Hoover’s testimony solidifies things my mentors have told me in the past as well. If you move up the totem pole, it doesn’t always correlate with your development and is more a reflection of a company’s need for more craftsmen. I’ve been told that as a rule of thumb, gauge your progress at your current position every three years. If you feel like your work is underappreciated or your title is inflated or undeserved, then it might be time to move on to better fulfill your personal development. A position at a company may work at first, but over time it is important to also take an objective look and figure out if that position still suits your development or hinders it.

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

Learning How We Fail Until We Hit Growth

Hey Everyone! In the nonstop pursuit of excellence, the “Learn How You Fail” pattern reminds us of a old forsaken truth: failure is not a curse but a catalyst for growth. It challenges us to confront our weaknesses head-on, to seek out the patterns and behaviors that lead to our missteps, and to use that self-knowledge as a powerful tool for transformation.

The whole point of this pattern means a lot to me deeply, as it recognizes that true creativity and work ethic are not born from a quest for perfection but actually a willingness to form somewhat of a imperfection. As Atul Gawande states, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.”

Personally, I find this pattern both humbling and it gave me a sense of confidence. After reading it a couple of times, it forces us to confront the uncomfortable reality that our successes are often counterbalanced by our failures and weaknesses. I’ve always related to the fact that you have to get out of the comfort zone otherwise you’ll stay there forever. Reason is, in that discomfort is the seed of growth – by consciously acknowledging our limitations, we open ourselves to the possibility of going past them.

This pattern has profoundly influenced my perspective on the intended profession. It has reinforced the idea that your craft is not a destination but a continuous journey of self-discovery and self-improvement. By embracing the idea of “learning how we fail,” we create a mindset of resilience and adaptability, qualities that are essential in the ever-evolving landscape of software development, especially after reading about these patterns.

One aspect of the pattern that resonates particularly is the hard point on making conscious choices. By gaining self-knowledge about our patterns of failure, we empower ourselves to make informed decisions, sort of how some work better under pressure– whether to work on fixing those weaknesses or to acknowledge our limitations and focus our efforts elsewhere.

Lastly, the “Learn How You Fail” pattern is a powerful reminder that failure is not an enemy to be feared but a guide to be embraced. It is a call to take in vulnerability, to find the illusion of perfection, and to strive as more self-aware, adaptable, and the best version of ourselves we can be in and out of software development.

andicuni
May 15, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Embracing the Cycle of Growth

Hey Everyone! The “Create Feedback Loops” pattern shines a light on this predicament, reminding us of the fundamental importance of going outside the box, objective feedback to fuel our growth and development.

At its core, this pattern challenges the idea that self-assessment alone is enough for recognizing our strengths and weaknesses. It acknowledges the built in biases and limitations of our own perspectives, which can be hooked by the very teams we work with or the environments we are around. The solution is in actively creating methods that provide us with a mirror, reflecting our true selves through the eyes of others.

What resonates with me about this pattern is its emphasis on the nature of growth. I’ve always been one to say how we never stop learning in this field and by requesting feedback early, often, and effectively, we can create a clean cycle – one where we become conscious of times where we lack understanding, take action to improve, and then seek further feedback to validate our progress. We need to understand there is nothing wrong with taking criticism. This continuous loop not only fuels our personal development but also helps search for a mindset of success and openness to learning.

Personally, I find the pattern’s recognition of the difference between useful and ineffective feedback is definitely a new way I would’ve originally thought about it. It highlights the importance of constructive criticism from distractions, separating obtainable data from well-meaning but misguided advice. This judgment supports us to focus our efforts on the feedback that truly matters, giving us a new way to make targeted improvements and avoid the mindset of false confidence or unnecessary self-doubt.

So to speak on how this impacted me, I like when the patterns give me a different influence on my perspective on the intended field in a positive way. It has strengthened the concept that true mastery is not a isolated push but rather a collaborative journey, where we actively seek out and embrace the perspectives of others. By creating feedback loops, we not only improve our own skills but also contribute to the growth of those around us, fostering a culture of mutual support and shared learning.

In conclusion, the “Create Feedback Loops” pattern is a powerful reminder of the importance of seeking objective, actionable feedback in our quest for growth and mastery. It challenges us to be open to the idea of okay to listen, okay to fail, and okay to continue trying. By cultivating this cycle, we encourage our own development but also add to the supportive growth of our peers and technical community.

andicuni
May 15, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Teaching to Learn: Understanding Through Sharing

Hey Everyone! As apprentices in the making , we spend countless hours absorbing knowledge, honing our skills, and making our craft as efficient as possible. However, the “Share What You Learn” pattern reminds us that true growth lies not just in getting knowledge but also in generously sharing it with others.
The essence of this pattern is fairly captured in the quote from Twyla Tharp: “Look at the luckiest people around you, the ones you envy, the ones who seem to have destiny falling habitually into their laps… they involve their friends in their work, and they tend to make others feel lucky to be around them.” This resonates deeply, as it highlights the equal relationship between sharing knowledge and creating a fulfilling, comfortable community.
Personally, I find this pattern both thought-provoking and inspiring. It goes against the idea of knowledge is a finite resource to be put aside, instead advocating for its free exchange and somewhat of distribution. By sharing what we learn, we not only empower others but also solidify our own understanding. As the saying goes, “When one person teaches, two people learn.” I’ve never resonated with a quote as much as that one. Teaching forces us to organize our thoughts, anticipate questions, and articulate concepts in a clear manner – a process that always deepens our understanding.
Moreover, this pattern has influenced my thoughts on our field. I now recognize that true mastery extends beyond individual expertise; it follows the ability to communicate effectively and uplift others. The pattern explains how a skilled craftsman who fails to share their knowledge ultimately limits their impact, while one who embraces this pattern becomes a trigger for collective growth, leaving a lasting legacy that goes past their individual contributions.
One aspect of the pattern that I agree with a lot is the perspective of knowledge sharing. It serves as a reminder that not all lessons are ours to share, particularly those that may harm others or breach confidentiality. This way highlights the importance of wisdom and care when sharing knowledge, ensuring that our actions contribute to a positive, trustworthy environment.
Overall, the “Share What You Learn” pattern has inspired me to embrace the joy of knowledge sharing and to view it as an important part of my professional journey. By defining what I’ve learned, I can make stronger connections within my community, validate my own understanding, and help to the collective improvement of our craft as we say how we never stop learning. It’s a upright cycle that benefits all involved, to continue to make an environment of continuous growth and mutual support.

andicuni
May 15, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

CS-448: Week 15

The Long Road

The pattern “The Long Road” is about how in today’s culture, we value overnight celebrities, rising stars, and quick results. This leads to the conditioning of assuming that the shortest path possible is also the best path. With this thinking, people say to take the highest paying job and the first promotion available; however, this takes away from developers being able to slowly build up their skills.

The first step to this pattern is to accept that this nontraditional way of thinking may be considered strange because the focus is set on learning and the long term rather than a high salary and traditional views of leadership. The pattern highlights the importance of planning for the long term, and to plan on being a software developer for decades. Planning for the long term will help to influence what jobs to take and future ambitions. The pattern emphasizes planning for the long term because it takes a long time to comprehend the deeper, more complex topics that come with software development.

The pattern states that this is not a pattern for people who’s main focus is monetary gain. This is not to say that those who follow this pattern will not be able to make money, but it is not their main focus. If monetary gain is the main motivator for someone, they may find themselves counting down the days to retirement as opposed to the craftsman who will joyfully work until the end of their career.

In order to plan for the long term future, the pattern suggests thinking about yourself a long time from now, 20 plus years ahead. With that in mind, imagine what you would want your professional history to look like, and the biggest influences. Using that as a baseline can help plan for future career choices.

Conclusion

I found this pattern to be interesting because it showed a perspective that most do not talk about. The idea that the journey of a craftsman is a long road, so should be treated as such changed the way how I view going about my own career. Rather than focusing solely on how high the salary is, focusing on learning and long term goals will lead to a more joyful and enjoyable career.

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.

Crafting Mastery: Deliberate Practice in Software Development

Summary:

The “Practice, Practice, Practice” pattern emphasizes the importance of deliberate practice and continuous improvement in mastering any skill, particularly in the realm of software development. Drawing from George Leonard’s concept of mastery and K. Anders Ericsson’s research on deliberate practice, the pattern highlights the necessity of carving out dedicated time for practice separate from daily professional responsibilities. While an ideal scenario involves structured exercises and mentorship, the reality often requires individuals to take initiative in their own skill development.

Reaction:

This pattern strikes a chord with me as it underscores the essence of lifelong learning and skill refinement. The notion that mastery is not merely a destination but a journey fueled by deliberate practice resonates deeply. It challenges the notion of perfection in favor of embracing imperfection as a catalyst for growth. Furthermore, the emphasis on creating a stress-free and playful environment for practice aligns with my belief in the importance of experimentation and exploration in learning.

Interest and Utility:

What I find intriguing about this pattern is its application of martial arts principles to software development. The concept of code katas, akin to choreographed movements in martial arts, offers a structured framework for practicing fundamental coding skills. Moreover, the emphasis on short feedback loops and the integration of public performance within a community of craftsmen underscores the collaborative nature of skill development in the tech industry.

Impact on Professional Outlook:

As someone aspiring to excel in software development, this pattern has prompted me to reconsider my approach to skill acquisition. Instead of viewing mistakes as setbacks, I now perceive them as invaluable learning opportunities. By committing to regular practice sessions and seeking feedback from peers, I aim to cultivate a growth mindset and continuously refine my coding abilities. Additionally, the suggestion to explore timeless resources like “Programming Pearls” for practice exercises has inspired me to delve deeper into the fundamentals of computer science.

Disagreement:

While I agree with the overarching principles of the “Practice, Practice, Practice” pattern, I believe there’s a need for acknowledgment of individual learning preferences and constraints. Not everyone thrives in a structured dojo environment, and some may prefer solitary practice or alternative forms of skill development. Therefore, while code katas and group sessions offer valuable avenues for improvement, they may not be universally applicable or accessible to all aspiring developers.

Conclusion:

In conclusion, the “Practice, Practice, Practice” pattern serves as a poignant reminder of the importance of intentional practice in achieving mastery in software development. By embracing the principles of deliberate practice, seeking feedback, and exploring diverse learning resources, individuals can embark on a journey of continuous growth and skill refinement. As I incorporate these insights into my own professional development, I’m excited to see how regular practice and reflection will shape my journey toward mastery in software engineering.

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

Pytest

As a student of computer science, encountering different tools that streamline coding processes is a cornerstone of my educational journey. One such tool that has caught my attention this semester is pytest, a testing framework for Python that allows for simple unit tests as well as complex functional testing. After a thorough exploration, here’s why I believe every budding software developer should dive into pytest’s documentation.

Why I Chose This Resource

The reason I chose to delve into the pytest documentation is twofold. Firstly, our course has increasingly emphasized the importance of test-driven development (TDD), a method pytest excels at supporting. Secondly, several industry professionals I look up to have recommended pytest for its simplicity and efficacy, making it an essential skill in a developer’s toolkit.

Summary of the Resource

The pytest documentation provides a comprehensive guide to getting started with pytest, from installation to writing your first test. It covers key features like fixtures for a scalable and modular setup, markers for categorizing tests, and plugins to extend pytest’s capabilities. The documentation is well-organized and rich with examples, making it accessible to newcomers and a valuable reference for experienced developers.

Personal Reflection and Application

Reading through the pytest documentation was an enlightening experience. It not only clarified the mechanics of pytest but also underscored the benefits of using such a tool in real-world programming. One of the standout sections was on ‘parametrized testing’, which illustrated how to execute multiple permutations of a test with different input sets, ensuring broader coverage with fewer lines of code.

This resource has profoundly affected my approach to programming. It has instilled a more disciplined mindset towards testing, making me appreciate how early detection of issues can save time and resources in the development cycle. I now plan to integrate pytest into my upcoming projects, confident that it will enhance the quality and reliability of my code.

Future Practice

The knowledge gained from the pytest documentation is something I intend to apply in all my future software development endeavors. I see it as a step towards adopting best practices in testing, which is vital for any aspiring software engineer dedicated to producing robust and fault-tolerant software.

Conclusion

For any student of computer science, understanding the tools at your disposal is as crucial as mastering programming concepts. The pytest documentation is a goldmine of information that promises to elevate your testing skills. I highly recommend it to anyone looking to embrace test-driven development fully.

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