Monthly Archives: January 2024

Apprenticeship Patterns Intro

Dave’s Story

The narrative of Dave’s journey serves as an illustrative example of how apprenticeship patterns can contribute to personal growth in software development. It emphasizes the importance of mentors, the willingness to expose ignorance, and the value of continuous learning and experimentation. Dave’s story underlines the idea that apprenticeship is a dynamic and evolving process, shaped by experiences, challenges, and the pursuit of improvement.

What Is Software Craftsmanship?

It critiques existing definitions of software craftsmanship, drawing inspiration from medieval craft models. While it rejects a rigid hierarchical structure but advocates for a modern craft studio where practitioners are free to innovate. The author also emphasizes the need for a community united by shared values, such as a growth mindset, adaptability, pragmatism, openness to sharing knowledge, and dedication to self-improvement.

Roles in Software Craftsmanship

The passage outlines three key roles in software craftsmanship: apprentice, journeyman, and master. Apprentices focus on personal growth, learning, and building foundational skills. Journeymen expand their responsibilities to include communication, mentoring, and portfolio building. Masters not only excel in their craft but also contribute to the industry’s advancement, mentoring others and creating tools or techniques that elevate the entire community.

What Is Apprenticeship?

The concept of apprenticeship is explored as a way for individuals to learn about professional software development. It is portrayed as a mindset, acknowledging that not everyone has the luxury of a formal apprenticeship and that many must create their own learning opportunities in less-than-ideal situations. The text encourages individuals to recognize their position at the beginning of their career and actively seek opportunities for learning and growth.

What Is an Apprenticeship Pattern?

The authors introduce apprenticeship patterns as guidance for career progression in software development. These patterns, extracted from personal experiences and practitioner interviews, offer flexible solutions to common challenges. The book is structured as a pattern language, allowing readers to choose, combine, and adapt patterns based on their unique circumstances.

Reflection

Through the reading felt very connected to Chapater 6 which focused on the
Idea that there is so much to learn but only one of you. I often find myself overwhelmed trying to learn as much as possible just to be versatile. Whether that be multiple languages, IDEs, frameworks, or anything in between. I finally was able to take some time to create a roadmap that I could follow that would better help me achieve my end goal of becoming a full-stack developer. This map focuses more on understanding over forcing content down someone’s throat and allowing the user time to properly learn and experience the tools needed to reach my goal.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Hi, my name is Abdullah Farouk and this will be my first blog of the semester and it is based on the readings from chapter 1 and the introductions of chapters two through six.

I did not know what apprenticeship actually means until after reading these chapters. From what I understand, It is basically learning from more “experienced” coders on how to be a better developer. Dave’s story was pretty cool and awesome to read as it gives me more motivation and I can see how good it is to get some help sometimes. From the three stages he provided for us in a developer’s career, I think most people are stuck between an apprentice and a journeyman with very few people in the masters category. An apprentice is someone who still has a lot to learn and wants to improve their way of doing things. I believe I am at this level right now because I still have some areas in my field that I need to upgrade or work on with my team or the professor. This gave me extra motivation because I want to be in the journeyman stage, at the very least by the end of this semester. Our professor would be in the “masters” category because he is very advanced in his area, performs the roles of a journeyman and is focused on moving the industry forward by teaching us and advancing the Worcester state pantry website. I do agree with these roles but I do think that there should be another category because there is a lot of difference between a journeyman and a master and that gap should be filled and made its own category. I like the idea of always wanting to improve and adapting based on the feedback people give you. The author talked about “a belief that it is better to share what we know than to create scarcity by hoarding it.” I found this quote very interesting and I 100% agree with him but I feel like this only is true in the computer world since people go off each other’s ideas and make changes to improve it. After reading the introduction for chapters two through six, I think I have found what my next blog is going to be about so it is giving me something to look toward and forward too. I will see you on the next blog, hopefully. 

Website: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch01.html?_gl=1*2xjvhe*_ga*MjYwNDQ1ODc5LjE3MDY1NTY4MTg.*_ga_092EL089CH*MTcwNjU1NjgxNy4xLjAuMTcwNjU1NjgyMy41NC4wLjA.#introduction

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

Apprenticeship Patters Chapter Introductions

In this week’s blog post, I will be discussing my opinions and what I learned from the introduction to chapter 2 of “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. The introduction to chapter two was the most impactful of the reading.

The introduction to chapter 2 starts with a Zen master who is being visited by a young philosopher who has traveled a long way to learn from the master. Once they met, they soon began to discuss what the young philosopher could learn from the old master, but each time the old master tried to teach the young philosopher something new, he would be cut off by the young philosopher’s eagerness to learn. Each time, he mentioned how he had learned to do the same thing differently from someone else. After having this happen several times, each with the master patiently waiting with a warm smile, the master mentioned how it is important to see the humor in every situation. Of course, he was once again cut off by the young philosopher, who was eager to mention some of his favorite jokes. The irony of the situation was wholly lost upon the young philosopher.

Not long after, the master invited the young philosopher to a tea ceremony, which the young philosopher eagerly accepted, having heard of the master’s unique style regarding tea ceremonies. Once the master got to the part of the ceremony where he was filling the teacup, he overpoured the tea. This led the young philosopher to exclaim, “Stop pouring! Can’t you see the cup is already full and overflowing?” to which the master replied, “If you come to me with a cup that is already full, how can you expect me to give you something to drink?” The master was saying, if you come to me with all of the answers, what can you expect me to teach you? Meaning that in order to learn more, you must understand that you don’t know what you are learning and accept that you are ignorant of some things.

The lesson that the master taught the young philosopher is one that I often find difficult. When learning new things, I tend to rush into them mindlessly, thinking that I know enough to skip the beginning, much like the young philosopher, only to find later myself having to go back to the beginning to understand what I am doing and what I did wrong.

While this lesson benefited me, it is also helpful to most people, especially those who work in computer science. Being able and willing to start from the beginning to learn something new is not easy and can make learning seem very difficult. What I find to help make this easier is to think of it as a change in perspective rather than a change in ability or knowledge.

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.

Strategies of Behavior Testing

There are many kinds of software testing, behavior testing is one of the more common types. Behavior testing involves a thorough evaluation of a code’s behavior through a controlled testing of inputs. By evaluating the outputs, the developer is able to verify that software is working as intended, to fix the bugs if not, and by doing so ensure that the program meets user requirements.

Because of the numerous scenarios in which a program may be used, it is important specifically in behavior testing to evaluate the code a thoroughly as possible. There are multiple ways to do this. In the blog “What is Behavior Testing in Software Testing?” from codiumAI, five main types of behavior testing strategies are covered. I will share the top three that I found the most useful and interesting.

  1. Functional Testing

    This is a foundational testing type and used in practically every type of testing not just behavior testing. In the context of behavior testing however, the goal of functional testing is to verify that the software performs the specified functions and actions as needed.

    Specifically, functional testing aims to guarantee that the program complies with functional requirements, and when given certain inputs, that it generates the expected outputs. This can be done at the unit or system level to ensure that not only the software as a whole works, but also each individual component of code.

  2. End-to-End Testing

    After all the parts of a program are thoroughly individually tested, the next important step is to test how well all the parts work together to run the entire program. This is the purpose of end-to-end testing. The developers examine the flow of the entire program to make sure that all data and information are passed down through each module correctly and that there is seamless connection between each system.

  3. Usability Testing

    This type of testing is focused more the user experience. Usability testing, as the name suggests, focuses on the software’s user interface and overall user satisfaction. So, instead of checking for code bugs or input/output requirements, developers doing this type of testing are on the lookout for usability issues, poor layout, confusing navigation, or unclear instructions.

    Usability testing ensures that the application not only runs correctly but is also intuitive and pleasant to use at the business/consumer level.

Out of the three strategies of behavior testing, I found usability testing the most interesting because it reminded me that the best applications are the ones that not only do their job, but also do it in an intuitive, user-friendly way. So as someone who is looking to so into software development, it is important to remember to look at the code from a user’s perspective, especially when doing software testing.

Blog: https://www.codium.ai/blog/what-is-behavior-testing-in-software-testing/

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapters 2-6 Introductions

After reading the introductions to Chapter 1 and Chapters 2-6 of Apprenticeship Patterns, my desire to be in the software development field drastically increased. It is more than a field of just constant repetition. Instead it is an ever changing field where there is always something new to learn, questions to ask, individuals to interact with, and skills to eventually master. The introduction of chapter one instills the fact that when first starting in the field, we may be nervous or not really know what we should do and question software development as a career. It encourages us to reflect on our career journey, what we have accomplished, what we still need to learn, and how we can overcome different challenges we may face to eventually reach a mastery level.

What interested me most was learning about the differences between an apprentice, a journeyman, and a master. An apprentice is typically an individual who is trying to find a way to complete tasks in a more efficient, faster, smarter way, and in a role with few responsibilities and continuous learning. The journeyman retains the attributes learned as an apprentice to continue to grow in the field. In this case, the journeyman’s next focus is to create connections between practitioners, different communication channels, and masters. After adding this, the journeyman begins building a portfolio to demonstrate their understanding in the field. Lastly, the master encompasses all the roles of both the apprentice and the journeyman as well as focuses on moving the industry forward. I found this interesting because no matter what we all start as an apprentice. Some skills may be easier to learn and understand than others, but overtime with constant training and learning, we can become masters in any aspect of the growing field.

In regards to Chapters 2-6, the book covers topics revolving around being committed to your work, continuous learning, mentoring, and constant practice. I am personally interested in reading Chapter 3, Walking The Long Road. The introduction of this chapter refers to viewing software development as more of a journey rather than just a field or destination and that there is always something new to learn, challenges to face, and things to master. Additionally, this chapter drives into setting meaningful goals and how to overcome challenges in your learning journey.

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

Software Testing Terms – Can you list them all?

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.

Object-oriented Testing

Object-oriented testing revolves around the examination of individual classes within an object oriented program. Objects are instances of these classes. In the article ” Object Oriented Testing in Software Testing” , the author talks about the evolution between old testing methods to object-oriented testing. The author also talks about the advantages of object oriented testing, which include reliability, extendibility, and reusability.

Navigating Object-Oriented Testing

Strategies and techniques for developing test cases in Object Oriented Testing could include Fault-based testing, scenario-based testing, and class testing based on method testing,. These different test cases / techniques play a pivotal role when it comes to trying to find all defects, improper interactions among classes, or being less time consuming. Object-oriented testing can however present some challenges such as testing inheritance in larger systems or the inability to dynamically test classes.

Why did I pick this Article?

I chose this article because it offers a great understanding of Object-oriented testing and highlights the many techniques that can be used, also the many different advantages of Object oriented testing. Moreover, the article does a good job explaining the evolution of testing methods, to object-oriented testing and some challenges you may face in testing Object-oriented programs.

Personal Reflection

This article has broadened my understanding of object-oriented testing, specifically detailing the transition from old traditional methods to object-oriented. I was also able to grasp the many advantages and challenges that object oriented presents, allowing me to know why we should and should not use it in certain scenarios. The knowledge gained from reading this article will play a pivotal role when approached to testing in object-oriented environments. The knowledge for developing test cases and the advantages and challenges will guide me in future projects.

The full Article is here: https://www.scaler.com/topics/software-testing/object-oriented-testing-in-software-testing/

From the blog CS@Worcester – In's and Out's of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

AI In Software Testing

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.

Apprenticeship Patterns by David H. Hoover and Adewale Oshineye: Ch. 1 and Introductions for Chs. 2-6

I’d like to talk about my thoughts after reading the portions of Apprenticeship Patterns by David H. Hoover and Adewale Oshineye assigned to our Software Development Capstone class. My first impression on reading the title was that this textbook would present different outlines of careers in software and information technology. After reading the introduction, however, I realized that the purpose of this book was to share different patterns and habits that would lend themselves to a successful apprenticeship in software craftsmanship.

The promotion of a growth mindset is one of the first themes established in the book. The authors talk about the growth mindset’s emergence from the research of Carol Dweck, the author of “Mindset: The New Psychology for Success”. The core belief of a healthy growth mindset is that a person’s intelligence is not fixed, and that a person can always grow their knowledge and ability through effort and learning. Through the growth mindset, people are encouraged to perceive failure as an opportunity for learning and reflection instead of as an indicator of inadequacy.

Maintaining an optimistic growth mindset is especially important for people working in software development and computer science. The volume of knowledge it seems to require to contribute anything of substance seems so overwhelming, it can be easy to tell yourself that you’re incapable of learning it all, or that you don’t even know anything as you are now. This emotional state of feeling incompetent or like a fraud despite your accumulated experience and talent is popularly referred to as imposter syndrome, and a survey conducted by Blind in 2018 found that more than half of tech workers report feeling like an imposter in their place of work. These responses came from people working with tech industry leaders like Google and Amazon, which shows that these feelings of self-doubt can exist in anyone, no matter how hard-working, efficient, or naturally talented. In a profession like software development, where the majority of a developer’s work is built on top of the sum of the work of many other people over many years, it’s essential to adopt a growth mindset to bolster your mental and emotional health despite the temptation to doubt yourself and invalidate your own accomplishments.  

In addition to the maintenance of a growth mindset, the authors propose other uniting values of a software craftsmanship community. Among them are constant adaptation, a desire for pragmatism over dogmatism, and the open sharing of knowledge. This software craftsmanship community would also value individual responsibility for one’s apprenticeship journey, and a willingness to experiment and be proven wrong.

The concept that interested me the most from the introductions of later chapters was The Long Road. I understood The Long Road as a metaphor for the lifelong journey of learning, and I recognized the necessity of the growth mindset the authors described earlier as a way to steadily propel yourself along that road. Without that mindset, the discouragement and confusion that naturally accompany learning can be too difficult to overcome.

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.

Reflecting on the Initial Chapters of “Apprenticeship Patterns”

As I delved into the first two chapters of “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, I found myself engaged not just with a book, but with a conversation about the journey of a software developer. This isn’t a typical textbook; it’s a guide for navigating the intricate path of professional growth in software development.

Chapter 1: A Revelation in Learning

The initial chapter immediately struck a chord with me. The concept of ‘breaking the mold’ resonated deeply, challenging the conventional approach to learning. It advocates for a mindset of continuous improvement and learning from every experience, a philosophy I find both daunting and exhilarating. I was particularly intrigued by the idea of being a ‘perpetual apprentice,’ which suggests that there is always more to learn, and every encounter is an opportunity to grow.

Provocations and Insights from Chapters 2-6

As I browsed through the introductions of chapters 2 to 6, I found myself rethinking my approach to my career. The book doesn’t just offer advice; it provokes thought. It made me question: Am I too comfortable in my current knowledge? Am I challenging myself enough? The concept of ‘constructive discomfort’ as a growth mechanism is something I plan to embrace more actively.

A Grain of Disagreement

While I found most of the book enlightening, I did have my reservations. The emphasis on self-reliance, for instance, seems to downplay the importance of structured learning environments. In my experience, a blend of self-driven learning and formal education often yields the best results.

Personal Relevance and Perspective Shift

As a junior developer, the chapters discussing ‘concrete skills’ and ‘nurturing your passion’ seemed particularly relevant. They made me reflect on my current skill set and my long-term career aspirations. This reading has subtly shifted my perspective, making me more open to exploring unfamiliar territories in technology and more conscious of my learning journey.

Conclusion: A Journey, Not a Destination

In summary, “Apprenticeship Patterns” is more than just a read; it’s a reflection on the continuous journey of learning and growing as a software developer. I’m excited to apply some of these patterns in my career, embracing the role of a perpetual apprentice, ever-curious and ever-evolving.

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.