Summary of the Pattern: The “Breakable Toys” pattern addresses the challenge of growing in a professional environment where failure can have significant consequences. This pattern encourages individuals to create a safe space for learning by developing projects or systems on their own time, which they can afford to break or mess up without risking their professional standing. The essence of this approach is to allow for experimentation, learning from mistakes, and thereby gaining confidence and skill in a low-stakes setting.

My Reaction: Initially, the concept of “Breakable Toys” struck me as a simple, yet profoundly effective way to cultivate new skills and deepen existing knowledge. It’s the permission to fail – but on my own terms – that I found incredibly liberating. This pattern resonates with me deeply, as it underscores the importance of self-directed learning and the intrinsic value of failure as a stepping stone to mastery.

Insights and Changes in Perspective: The pattern illuminated the stark contrast between the safety nets often present in educational settings and the high-pressure environments of the professional world. It made me reflect on my approach to learning and professional growth, emphasizing that the path to expertise is paved with mistakes and learning opportunities. Adopting this pattern has encouraged me to shift my mindset from fear of failure to embracing it as a crucial component of my development process. It’s a paradigm shift that I believe will not only make me a more resilient professional but also a more inventive and adaptive problem-solver.

Disagreements and Critiques: While I wholeheartedly embrace the concept of “Breakable Toys,” I recognize that not everyone may have the luxury of time or resources to invest in side projects. For some, the pressures of life or work may make it challenging to find space for such endeavors. However, I believe the underlying principle of seeking out low-risk opportunities to learn and grow can be adapted in various ways, such as through virtual labs, open-source contributions, or even thought experiments.

Conclusion: The “Breakable Toys” pattern has not only broadened my understanding of learning in a professional context but also invigorated my approach to personal and professional development. It serves as a reminder that the journey towards mastery is personal, non-linear, and fraught with setbacks, all of which are invaluable learning opportunities. As I move forward in my career, I intend to keep this pattern close to my heart, ensuring that I never lose sight of the importance of playful experimentation and the lessons learned from each “breakable toy” I encounter.

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.

The White Belt pattern is about adopting a beginner’s mindset when approaching new challenges, even if you’re an expert in a particular field. It encourages setting aside previous knowledge to embrace learning opportunities fully. This mindset shift is crucial for personal and professional growth, allowing people to discover new perspectives, solutions, and approaches. The White Belt pattern offers insights into the process of continuous learning and personal development. It talks about the importance of humility, curiosity, and openness to new experiences, which are important qualities for success in any job. Encourage people to step out of their comfort zones and embrace the unknown.

Something I thought was interesting is the aspect of the pattern and its application beyond programming languages. It has many examples from the field of software development, the principles can be applied to any job or profession. The idea of challenging misconceptions and learning from diverse perspectives is interesting. Also, the emphasis on adopting new skills and approaches to problem-solving is relevant in today’s world since it’s rapidly changing. 

This pattern has caused me to reflect on my approach to learning and problem-solving in my job. It has strengthened the importance of staying adaptable and continuously seeking new knowledge and experiences. Also, it has challenged me to be more open-minded and willing to embrace anything I’m uncertain about and discomfort as part of the learning process. While the White Belt pattern is about adopting a beginner’s mindset, it may overlook the existing expertise in certain situations. While it’s important to go for new challenges with modesty, it’s also important to recognize the strengths and knowledge that come from previous experiences. Keeping a balance of openness to new ideas with confidence in one’s skills is essential for effective learning and growth. In conclusion, the White Belt pattern offers great insights into the process of continuous learning and personal development. By embracing a beginner’s mindset, people can unlock new opportunities for growth and change in their personal and professional lives. However, it’s important to strike a balance between modesty and confidence, recognizing the value of both new perspectives and existing expertise.

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.

For this week’s blog post, I chose the article “Behavior Testing | What it is, Why & How to Automate?” from testsigma.com. I selected this article because it fits within the Behavioral testing section in the course topics section of the syllabus. This article goes into great detail about behavioral testing, from discussing what it is to explain how AI could be used in its implementation. For this blog post, however, I will discuss the sections on what behavioral testing is and a couple of methods that can be used to catch errors with behavioral testing.

The article describes behavioral testing as a form of functional testing designed to test the external functionality of a system. “Behavior testing or behavioral testing is a type of testing that focuses on testing the external behavior of a software application. It is a type of functional testing. It helps ensure that software systems meet the expectations and requirements of end-users, making it a valuable part of the software development and testing process. Behavior testing is also known as black-box testing.” As described by the article, behavioral testing is essential to ensure that the systems or products you are designing work well enough so your customers can use them efficiently. There are many different methods when using behavioral testing to find errors, such as equivalence partitioning.

According to the article, one method that can be used with behavioral testing that is good at finding errors is Equivalence Partitioning. “The equivalence partitioning testing technique involves dividing the input data into different classes or partitions, such as valid and invalid data, assuming the system will behave the same for both inputs. Example – For a login form, if the password requires at least eight characters, you might test one case with a 6-character password (invalid) and another with a 10-character password (valid).” When using equivalence partitioning, because you are dividing inputs into separate groups, in a way, you can do two things at once. One is that the system functions as it should with valid inputs, and the other can catch invalid inputs. Another way behavioral testing can be implemented is through boundary value analysis.

According to the article, boundary value analysis is a form of behavioral testing focusing on the possible range of inputs, specifically numerical inputs. “It focuses on testing the boundaries of input ranges, as errors often occur at the edges of these ranges. Test cases are designed for values at the lower and upper boundaries and just above and below. Example – If an input field accepts values from 1 to 100, the test data can be 0, 1, 2, 99, 100, and 101.” This kind of testing can be very helpful in making sure that you have accounted for the possible range of inputs that a user may enter, both valid and invalid.

Article: https://testsigma.com/guides/behavior-testing/

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.

For this week’s blog post, I covered the design pattern “Sustainable Motivations” from chapter three of “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. I chose “Sustainable Motivations” for this week’s pattern because I think that maintaining your motivations for your career is one of the most important things you can do for your mental health regarding software development. This chapter discusses why sustainable motivations are essential.

A section of this chapter that stuck with me was when the author says that there will be days when you are surprised that you are paid to write software and how happy you are with what you are working on. The author then mentions that those days are few and far between. “There will be days, weeks, and months when you love your job. You’ll chuckle to yourself, in awe that you actually get paid to develop software. The software you write will flow effortlessly from your mind through your fingertips, beautiful to behold in function and design. These are good and extraordinary days. In other words, they are not your ordinary days.” This was not a massive revelation for me, and I am well aware that most of my time working will be just that, working. I am not necessarily working somewhere because I love what I am developing, though I hope I do love what I am working on. That is the goal, after all.

The authors also go into some detail about what challenges a developer would face in the field. “As Paul Graham so rightly says, the typical programming job will put you face-to-face with tedious, vaguely defined, and needlessly complex problems. Nasty, wicked problems. What’s more, you may also be faced with bureaucracy, difficult personalities, and spotty leadership. There will be days, weeks, and months when you question your commitment to the craft. When you are confronted with such problems, it is crucial that your motivations to program are aligned with walking The Long Road.” Thankfully, with my experiences so far through my education, I feel prepared for the challenges that come from the work itself. From living life, I think that I can navigate bureaucratic and interpersonal issues reasonably well.

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.

The pattern I chose to write about from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye is in chapter 3: Sustainable Motivations. I chose this as my first pattern to touch on because I find that motivation is something that I struggle with constantly. I already face days where I question my commitment. I did it today. Imposter syndrome got to me and I questioned whether I was cut out for this field. 

I agree with the argument that “it is crucial that your motivations to program are aligned with walking The Long Road”. Two of the examples of unsustainable motivations were money and thinking of programming as fun. Initially, my primary motivation for getting into this field was money; I did think it was somewhat fun to write code and think of solutions but I was thinking about a career path that would pay decently well. My line of thinking was impacted by how expensive it is to live and enjoy life. I figured that it’s best to just become a software developer because “It’s not like I hate it and it pays well”. After reading, I want to try figuring out what motivates me to stay in this field. I’m motivated by something that isn’t money or how fun it is because I’m still studying software development despite my struggles. 

I couldn’t find something in this pattern that I disagreed with but I don’t exactly understand the task from the action part. It instructed to “Write down at least 15 things that motivate you. Wait a little while, then write down another five. How many of your motivations are about what other people think rather than what you feel? Are the percentages different between your first 15 and the final 5? How many of the motivating factors can you do without? Now write down a list of the five most important things that motivate you”. I don’t understand the practice of writing down an initial 15 and then another 5 when you can keep the questions in mind as you write the last important 5. Maybe I’ll try it and figure it out.

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.

  The ‘Unleash your enthusiasm’ apprenticeship pattern is one which I would consider very important. The basis of this pattern is that you should not feel the need to suppress your own excitement over crafting software when you are part of a team but you should be mindful of the team’s dynamic and attitude before blindly acting on your own enthusiasm. Essentially it is completely normal for a newcomer in software development to be excited to learn or even to be working within a professional team but the newcomer should always keep in mind that their enthusiasm may be warranted but depending on your colleagues you may want to keep your enthusiasm to yourself in order to not make any negative impression which is important in many different fields not only software development. But even if you judge that your enthusiasm should be kept to yourself based on a team or individual’s dynamic you can still ask questions in order to better yourself.

  I found this pattern particularly useful as I myself along with some fellow computer science majors I know are hesitant to show excitement over software development at times as I do not know if it would be considered as unprofessional. This pattern explained to me that while you do not want to overly express your excitement throughout the learning process it can be helpful to question things and give your ideas even as a beginner when working in a team as the perspective you offer the team is fresh and can lead to helpful solutions or enhance your own learning process and the more you know about what you are developing with your team the more useful you will be when trying to work together on productive and time effective solutions. Being aware that it is for the most part encouraged to share your thoughts, question or ideas when you can at the very least so that you can get an explanation on why an idea would or would not work is something that will help me to be more open to sharing my thoughts with others whether it be colleagues, other students professors etc.

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.

Summary: 

The white belt pattern focuses on the idea that new situations should be approached with all previous knowledge set aside. The white belt signifies an entry level of knowledge and understanding of a subject, and is only achievable if all preconceptions and past experiences are removed during the learning process. This mental clean slate prevents old habits or patterns from getting in the way of exploring new possibilities when it comes to solving problems.

Reflection:

The more I reflect on this pattern the more I agree with it. However, my opinion felt like it went from agreeing to disagreeing back to agreeing. When in reality, it went from agreeing with some parts, and disagreeing with parts I didn’t fully understand. To eventually gaining an understanding of the pattern that I fully agree with.

Originally agreeing with the overall idea that you should have the mentality of a white belt when learning something new, I disagreed with the notion that all previous knowledge was bad. I, as do many others, learn by being able to take previous knowledge and experiences and relating them to the new situations. This however is the trap that this pattern is actually trying to avoid. The interesting part in this section that made me realize my mistake in my in initial interpretation was the “problem of ‘writing Fortran in any language.’” Not knowing what FORTRAN was, I researched it and found out that I was in fact making this same mistake. Learning a new language doesn’t mean just being able to recreate a simple program. It involves learning all the small nuances and limitations each language has. The only way to explore those is to approach each situation independently and with a clean slate.

My first language was java, and when it comes to learning a new language it is helpful for me to be able to relate things in the new language to elements in java. This turns out to be a trap if you are only looking for 1 to 1 relationships, or you let your old knowledge prevent you from learning something specific to the new language. The more I think back to all my older projects that involved learning in a language that was not java, all I actually learned was the syntax of how to rewrite my code in another language. My understanding of the language or coding in general did not get deeper. Having my previous knowledge acted more as blinders than guidelines, showing me the one way I already knew, but preventing me from seeing other possibilities I didn’t know even existed.

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