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.

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.

When working with a project that has already been built up to a certain point, one can find themselves lost in where to look first, how to accomplish their job within that project, how the program even works as a whole. I’ve had firsthand experience with this already working with the Thea’s Pantry system. Ultimately, the only way to really learn what is going on in the system is by looking at the code and trying to make sense of it.

This pattern is very important within the context of working in the Software Development field. The quote at the end is a synopsis of it: if a programmer can learn a codebase quickly after being hired, then they can more quickly be productive and add value to the project for the employer they are writing code for. Otherwise, you’re spending a lot of time just trying to get an understanding of things while you have deadlines coming soon.

The one thing is that obviously getting an understanding of a codebase is incredibly difficult depending on your level of knowledge in various languages and programming as a whole. Of course, this is one of the later patterns (chapter 5), but regardless if I don’t have much experience with JavaScript, trying to read a project that operates on JavaScript at a high level will be a bit more difficult than reading a project that uses C given that I have worked with C for a year, let’s say.

There’s also the consideration of documentation. Documentation can be very helpful, but there will always be cases where the code was changed and the documentation was forgotten about. This leads to additional confusion, and it only compounds when there are comments in the actual code that are misleading, or functions that weren’t written with clean code principles in mind. Everyone makes mistakes, and sometimes those mistakes lead to tech debt that has been compounded upon to the point where that bit of code that’s hard to understand cannot be changed without a whole refactor.

Of course, this is dependent on the project. I’m sure that projects like version control systems that were mentioned in the reading are fairly consistent because they need to be, and having the experience of learning a codebase like that is definitely useful and builds on adaptation skills that are somewhat of a necessity in the tech field. It’s an interesting thought, and I can see how it can lead to better code.

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.

“Confront Your Ignorance” urges us to face our lack of knowledge head-on. Instead of shying away from what we don’t know, this pattern encourages us to acknowledge our ignorance and embrace it as a stepping stone to growth.

Key points of the pattern include:

1. Recognizing Blind Spots: We all have blind spots – areas where our knowledge is lacking or incomplete. The first step is acknowledging these blind spots and accepting that there’s always more to learn.
2. Seeking Learning Opportunities: Actively seek out opportunities to expand your knowledge and skills. Whether it’s through reading books, attending workshops, or collaborating with peers, every experience is a chance to confront your ignorance.
3. Embracing Humility: Embrace humility and be open to learning from others. Recognize that expertise comes from a continuous process of confronting and overcoming ignorance, rather than pretending to know it all.
4. Asking Questions: Don’t be afraid to ask questions, even if they seem basic or obvious. Asking questions is a sign of curiosity and a willingness to learn.

My Reaction:

“Confront Your Ignorance” resonated deeply with me, especially as someone navigating the complex landscape of software development. It’s easy to feel overwhelmed by the vastness of the field, but this pattern reminded me that it’s okay not to have all the answers.

One aspect of the pattern that particularly struck me is the emphasis on humility. In a culture that often values expertise and confidence above all else, it can be daunting to admit when we don’t know something. However, this pattern taught me that true growth comes from embracing our ignorance and using it as fuel for learning.

I’ve also realized the importance of seeking out learning opportunities proactively. Instead of waiting for knowledge to come to me, I now actively seek out books, courses, and conversations that challenge my existing understanding.

One point of contention I have with the pattern is the suggestion to ask questions, even if they seem basic. While I agree with the sentiment, I sometimes struggle with feeling like I’m bothering others with my questions. However, I’m working on overcoming this hesitation and embracing the value of curiosity.

In conclusion, “Confront Your Ignorance” has shifted my perspective on learning and growth. By embracing the unknown and confronting my ignorance, I’m committed to embarking on a journey of continuous improvement and discovery.

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.

Summary: The “Find Mentors” pattern emphasizes the importance of seeking guidance and mentorship from experienced individuals in the field of software craftsmanship. It acknowledges the challenges faced by apprentices in navigating their professional journeys and advocates for actively seeking out mentors who can provide valuable insights and guidance. The pattern highlights the rarity of finding a master craftsman but encourages apprentices to engage with a series of mentors, recognizing that mentorship can come in various forms and may not always be face-to-face.

Reaction: This pattern resonates deeply with me as it underscores the significance of mentorship in personal and professional development. It acknowledges the inherent challenges in finding suitable mentors but emphasizes the transformative impact that mentorship can have on one’s journey towards mastery. I appreciate the practical advice offered in the pattern, such as lurking in online communities to identify potential mentors and taking the initiative to reach out to them for informal advice.

Interest: What I find particularly interesting and useful about this pattern is its emphasis on the reciprocal nature of mentorship. While apprentices seek guidance from experienced practitioners, they are also encouraged to pay it forward by mentoring others who are earlier in their journey. This aspect highlights the collaborative and communal nature of the software craftsmanship community, where knowledge sharing and mentorship play vital roles in fostering growth and development.

Reflection: The “Find Mentors” pattern has prompted me to reflect on my own approach to mentorship and how I can leverage it to enhance my professional growth. As I navigate my career in software development, I recognize the importance of seeking out mentors who can provide guidance, feedback, and support. Additionally, I am inspired to contribute to the community by offering mentorship to others who may benefit from my experiences and insights.

Disagreement: While I wholeheartedly agree with the principles outlined in the pattern, I believe that it could provide more nuanced guidance on navigating the complexities of mentorship relationships. For example, it could delve into strategies for building meaningful connections with mentors and managing expectations within the mentorship dynamic. Additionally, the pattern could explore potential challenges or pitfalls that apprentices may encounter in their quest to find suitable mentors.

Conclusion: In conclusion, the “Find Mentors” pattern serves as a valuable reminder of the importance of mentorship in the journey towards software craftsmanship. By actively seeking out mentors and engaging in reciprocal mentorship relationships, apprentices can accelerate their learning, navigate challenges more effectively, and contribute to the growth of the software craftsmanship community. As I continue on my own journey, I am committed to embracing mentorship as a cornerstone of my professional development and to paying it forward by supporting others along the way.

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

The Deep End pattern is about growing your skills and boosting your confidence. It’s also about challenging yourself with bigger things. Growth is significant, it’s about taking big risks and doing things you don’t usually reach out for. Taking risks may be scary but playing it safe doesn’t help you improve or leave you unsatisfied. The Deep End pattern means that people should take on big projects or high-profile roles even when they don’t feel ready to. The importance of finding mentors, building feedback loops, and seeking help when needed. People should want to take on challenges, even if there’s a chance of failure, can open up doors and opportunities that playing it safe never will.That pattern knows that there are risks involved but those risks can cause growth by being in a scary situation and getting passed your comfort zone.

I found the pattern useful because it’s supposed to not only build your skills but also build your confidence. Boosting your confidence is a skill that some people don’t think is necessary but it can open up so many opportunities. Just by being brave, taking risks, and learning from failures taking those experiences can help people shape a successful future. I would say that pattern has changed my way of working because usually, I want to take the safe side and not take any risks doing that would just keep me from fulfilling my full potential. Challenging my self will only better myself and the way I work. I don’t disagree with The Deep End pattern because it has the right idea of doing something risky so you can grow instead of being comfortable with where you are now. This pattern is about bettering yourself, learn from any failures you had in the past, and grow from them. Don’t let anything hold you back from shaping your future keep trying to succeed. This is a pattern I will use moving forward so it can not only help me become more successful by taking risks but also build my confidence so i’m not scared to take any opportunities ahead of 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.

link to blog at the end:

Have you ever heard a word or phrase that you feel like you should understand but you just don’t? It’s happened to many people, and I’m sure it is not uncommon in the software industry. Certain software terms are either confusing or unknown, which is perfectly understandable!

Chris Kenst’s blog post relates to what we studied in class this past week, as it correlates with and even mentions some of the terms we learned, such as black box testing. It will hopefully help the definitions we previously learned stick in my head as the weeks go by.

This blog post is all about lingo. It aims to better prepare students and software-testing newbies for the confusing jargon coming out of their coworkers’ mouths. It is in a simple glossary format, which is easy to understand and refer back to from time to time. There are 50 terms listed as well, so there may be some left out, but the ones listed are what you are most likely to hear in the workplace or in communication. Kenst also mentions at the end of the post that an increased mutual understanding of such terms can lead to increased productivity and collaboration.

I chose to cover this blog post because it is easy to get lost in all the mumbo jumbo tech buzzwords flying around the internet. It is like being a parent and learning what your kids’ slang means; except the kids are your coworkers and the slang is important keywords for your profession. I would not want to be the one guy at a meeting who does not understand “black-box testing” or what “domain testing” is. Jokes aside, this is a great resource for my fellow students to refer back to, especially as we are just beginning our software testing journey. These terms are important to know, because otherwise you might fall behind as new terms and testing variations are created. 

I personally believe this is a great starting point for those new to software testing (like me) and those who might need a refresher every now and then whenever their coworker says something unfamiliar. I learned how “high volume automated testing” involves auto generation, execution, and evaluation of multiple tests that may be weaker and not as thorough on their own, but together expose bugs and weaknesses. I will continue to learn more testing variations and other terms from this list to strengthen my confidence as a software tester and engineer. I hope to apply this knowledge in the future whether it be at a job interview or in a working environment, proving to my coworkers that I understand the language they are speaking and can keep up with their discussions.

Blog: 50 Software Testing Terms Defined – Chris Kenst

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

The blog I chose was “Will AI Replace Manual Testers?” by Thijs Kok. The blog post highlighted the importance of testing for software development and the role that AI plays. I chose this blog for two reasons, one due to the fact that we recently discussed the types of testing in software development. The other reason being the rise of artificial intelligence popularity in the software and technology field. I thought this blog was able to highlight one of the main fears that people who are studying computer science or people who are already in the field have when it comes to artificial intelligence. This fear being is artificial intelligence going to be able to take over our jobs. We have seen just what artificial intelligence is able to do through a multitude of examples showcasing just how advanced the AI is when it comes to solving programming problems. For those reasons, that is why I chose this blog because I thought it would be interesting if AI could take over this aspect of the jobs we want.

The blog post started off by acknowledging the power AI has right now throughout the world and how the tech field is no exception. The author described three ways how AI is already being utilized within the software testing scope. These ways being test case generation through, test case execution and test result analysis. The blog post ended with the overall question, will artificial intelligence replace testers? The conclusion that the author reached was, no, “While AI can automate specific testing aspects, it cannot entirely replace human testers. The cognitive skills, creativity, problem-solving abilities, and emotional intelligence that human testers bring to the table are irreplaceable”. The author stated that even though AI can be very powerful it can be seen more as an enhancement rather than a replacement.

My overall take from this blog post is the importance in understanding how AI works and how to integrate to use it as a tool for the future. While we can’t use the AI to just do the work for us it can be a helpful asset that will make the job easier allowing us to focus our efforts on more important matters, things that the AI otherwise could not handle. I believe that the blog post was a great piece that anyone could read and take away various insights from. For example, it was able to downplay people’s fears on AI taking over as well as teaching people how to use it to their benefit allowing integrations for the future.

https://www.testmonitor.com/blog/will-ai-replace-manual-testers

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.