Category Archives: Week 4

CS-448 Apprenticeship Patterns Chapter 2-6 Introduction

Chapters 2-6 in the Apprenticeship Patterns textbooks goes over the specific different practices and patterns that software developers use in order to grow in their field.

Chapter 2 talks about the values of “emptying the cup” as an apprentice. Embrace the beginner’s mindset with The White Belt. Overcome roadblocks with Unleashed Enthusiasm. Acquire concrete skills in specific technologies to explore advanced patterns. Avoid complacency by systematically broadening your tech skills. Expose your ignorance to focus on learning needs. Confront and flex your knowledge muscles. Take audacious tasks to learn and grow. Retreat into competence when overwhelmed, then gather yourself to ascend further.

Chapter 3 explains how many people are walking the same path even when they seem to be on a different path. In other words, the experts that know more than you in the work field went through the same struggles (walked the same path) as you are to get to where they are now. It explains the story of Dave as he continues his journey in software development with a sense of assurance. However, his interactions with highly skilled hackers in online communities and face-to-face collaborations with high level developers humbled him and fueled his desire to learn. As he delved deeper into side projects and consuming learning material, Dave realized the vastness of knowledge available and the continuous learning process inherent in software development. While there is a considerable gap between his skills and those of seasoned developers, Dave found solace in the shared journey towards mastery that all developers embark on.

Chapter 4 introduces the concept of letting go of perceived competence and allow yourself to recognize that there is way more to learn and more to travel down the Long Road. The rapid learner faces the risk of becoming complacent in their success within their current environment which could stagnate their growth. It is crucial for such individuals to acknowledge the broader landscape of opportunities beyond their immediate sphere and to remain humble in the face of their accomplishments. The focus should not be on surpassing others but on personal growth and improvement, recognizing that the journey towards mastery is ongoing and that collaboration and mutual support are integral to this process.

Chapter 5 emphasizes the concept of learning and, especially for apprentices, how it is critical these patterns be applied early on in their journey. The essence of apprenticeship in software development revolves around perpetual learning and effective communication. Apprentices must constantly seek opportunities to replace ignorance with skill, not only acquiring concrete technical abilities but also in developing the ability to learn itself. These concrete learning activities such as “Expanding your bandwidth” and “Breakable Toys” pave the way for deeper self-discovery, leading to the importance of reflecting on work. sharing knowledge, creating feedback loops, and understanding personal weaknesses to transition successfully from apprentice to journeyman and eventually master craftsman.

Chapter 6 talks about the constant time and effort that should be put into studying to further develop your learning curriculum. In today’s age digital age, access to vast amounts of information is easy, thanks to the Internet and handheld devices. While blogs and online resources offer valuable content, the wisdom found in traditional books by experts like Jerry Weinberg and Kent Back is irreplaceable. Incorporating reading into an apprenticeship is crucial for success, allowing individuals to construct their own learning curriculum.

2. Emptying the Cup | Apprenticeship Patterns (

3. Walking the Long Road | Apprenticeship Patterns (

4. Accurate Self-Assessment | Apprenticeship Patterns (

5. Perpetual Learning | Apprenticeship Patterns (

6. Construct Your Curriculum | Apprenticeship Patterns (

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

CS448 Software Development Capstone -Apprenticeship Patterns: “Practice, Practice, Practice”

The first pattern from “Apprenticeship Patterns” by David H. Hoover and Adewale Oshineye that I would like to write about is “Practice, Practice, Practice”, from chapter 5 of the textbook. I’ve been learning how to code since shortly before I started my first semester at community college, in the fall after I graduated from high school. I’ve been able to complete the lessons that I’ve been assigned at school and through online resources, but even still today, whenever I’m working, I feel like I’m calling on every last bit of knowledge that I’ve got, and that once I’m on my own in the real world I’m going to end up drowning. This anxious feeling can get especially distracting when I imagine how much more progress and work there is to do in building myself into a competent software developer, let alone an exceptional one. Consequently, reading this textbook has been something of an exposure therapy exercise for me.

Developing some kind of practice regimen to reinforce my fundamental skills would go a long way toward constructing a sense of basic competence that I can eventually build on to enhance my skillset. Here I am about to graduate with a degree in computer science, and I honestly can’t say I know how to practice programming outside of school without starting a project and “just doing it”. This approach results in me feeling a lot of pressure to learn many new concepts and produce something useful before I get up from the chair again, and because my emotions quickly become too strong and distracting, I don’t end up doing either of those things. I need to develop a new way to practice my computer programming skills.

The phrasing of the problem presented in this pattern caught my attention because of how much I related to the sentiment: “It’s as if you’re always on stage.” I feel like every time I open my text editor to complete my daily tasks, or whenever I need to research a new subject, it’s the ultimate test of my ability and merit as a programmer. It’s going to be incredibly difficult to test my limits over the course of my career if my everyday experience feels so drastic. The solution offered through this pattern is the technique of practicing through “code katas”. The author explains that the term “kata” is borrowed from martial arts, and that it as a term which refers to a sequence of movements provided by a teacher to their students, performed without an opponent. The purpose of executing the kata is to reinforce the student’s fundamentals and build their physical control, fluidity, and power.

The benefits of applying the same practice of repeating fundamental movements to build overall competence towards the craft of software development are that it enables a practice environment without deadlines or expectations and that this method of practice allows learners to build their self-confidence without introducing the stress that comes with delivering complex software projects. About practicing with code katas, software developer Dave Thomas says “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.”

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.

Don’t Trade Programming for Promotions

Even though it may seem counterintuitive, it makes perfect sense. If you take yourself away from the code you will slowly lose your way with your craft. It’s important to continue learning and practicing even as a master craftsman. Higher positions in a company won’t always equate to “better” positions for a craftsman.

It’s a part of “walking the long road” and staying on the path is crucial to one day finishing that path. As it goes for anything in life, you can never truly fail at something until the day you give up and cease trying. If one were to take a position that pulls them away from programming it allows for their long journey to appear shortened, but in reality, they just took one of the many exits along the way onto the intended destination of becoming a journeyman then master craftsman. Along this road, journeyman status can be achieved and one may choose to stop there but personally, I’m striving to eventually arrive at master status in the future.

I also agreed with the pragmatic response offered in how to react if faced with promotions that pull away from programming. If working for a flexible company, ask for better pay or non-traditional technical management roles instead of accepting such a promotion. If working for an inflexible company, it’s better to seek other opportunities elsewhere than to let yourself become lost along the long road.

I also found myself agreeing with the notion that if the rewards offered by employers aren’t appealing, one should counter with some rewards that are better suited for their interests and professional growth. It could be helpful if one were to prepare alternative incentives and rewards before refusing a promotion (if possible) to allow for transparency and understanding of the professional goals of the individual.

I think that overall, to “stay in the trenches” is a great mindset to have. It’s equipped my mind with the knowledge that shines importance on staying within a position that allows me to continue to practice and grow as a craftsman. If I were presented with such an opportunity in the future, I’d remember that it’s more important to continue on my long journey than to let some small miscellaneous gains to pull me away from my end goal of eventually becoming a master craftsman.

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.

Embracing The White Belt Mentality

As software developers, we are on a quest for both personal and professional growth, but there comes a time where we reach a plateau. We’ve mastered some skills and embraced pride in our knowledge, but despite what we’ve accomplished, there’s a fear that our development is at a standstill. The White Belt Pattern involves taking a new approach to this challenge. This involves possessing a beginners mindset and setting aside previous knowledge in order to learn and understand new knowledge.

I found the concept of the White Belt mentality to be extremely intriguing. In our modern world where new techniques and technologies evolve daily, we would figure that expertise and mastery would be most important and the idea of embracing a beginners mindset may feel counterintuitive. However, there’s always something new to learn and we should approach these situations with an open mindset.

Learning more about this pattern allowed me to reevaluate my approach to the software development field. In a field where continuous learning and adaptation are essential, I now understand the importance of just taking a step back to avoid becoming complacent with my knowledge and open to new perspectives and ideas. I love programming in Java and Python, but if I focus on mastering those two languages, then I wouldn’t be able to learn other languages like C or JavaScript.

One part that resonated with me was the emphasis on collaboration. By acknowledging that we don’t have all the answers and can’t solve every problem, creates a space for collaboration and problem solving. Therefore by having the White Belt mentality, we can create a deeper connection with individuals in our workspace, while also possessing a genuine desire to learn new things.

A challenging aspect regarding this pattern is the idea of stepping back for growth. I understand we should challenge our knowledge, but believe there’s also value in building upon our existing knowledge. Instead of disregarding what we’ve mastered, we should find a midpoint where we can learn new things and see different perspectives while still utilizing our previous successes.

Overall, the White Belt mentality allowed me to reevaluate my approach to personal learning and growth. Instead of viewing mastery as a destination, I now see it as a continuous lifelong journey with plenty of opportunities for learning and discovery along the way.

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

Embracing “Breakable Toys”: A Pathway to Mastery

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.

Understanding Test Driven Development in Software Engineering

Test Driven Development is a method in software development in which tests are created before the actual code. By writing test before hand, developers have a clear understanding of what will need to implemented, which can help avoid unnecessary errors. This approach will help to have the software behave as expected. This method is a structured and systematic approach. This test method is doesn’t just focus on testing, however it also focuses on quality and behavior. The main goal of this test method is to ensure that the code meets the specified requirements and behaves as expected. Test Driven Development helps with clarifying requirements, reducing defects, and improving the code maintainability.

How does it work?

Test Driven Development operates on a cycle like, first write a test, second make it run, third change the code to make it pass, and then repeat. Developers should first write a test that will analyze the behavior that they want implement. After running the test and writing and rewriting the code to make the test pass, developers will then need to continue reframing the code to improve it’s design and maintainability without changing it’s behavior. This process will make sure that that each piece of code is throughly tested and validate before moving on to the next.

Test Driven Development vs Traditional Testing

The difference between Test Drive Development and Traditional testing is that test driven development method has a different approach and objective. Traditional testing methods usually aim to find bugs or even defects in code, test driven development mainly focuses on making sure that the code meets the specific requirements. A failed test in test driven development method tells the developers to write new code to fulfill the requirement’s, and it also tends to make sure that the code will be lead to higher quality, with fewer defects.

There are also two levels of test driven development that focuses on different aspects of software development. Those two levels being Acceptance TDD and Developer TDD. Acceptance involves writing acceptance test that verify the overall behavior of the systems based on the users requirements. Development TDD, focuses on writing unit tests for individual components or modules of the system.

Why Did I pick this Article?

I chose this article because Test Driven Development is a very important concept in software engineering. This article has taught me a lot about test driven development , which include numerous benefits like improved quality of code, reduced bugs and fewer defects, and faster development cycle. These many advantages are valuable for any software development project.


After reading this article, i have learned a lot about Test Driven Development and it’s many advantages. One key take away for me was how in this method developers are to write test before actually writing the code, which can help in clarifying and ensuring that the code is correct and meets the required specifications. I also found how the article talks about the difference between test driven development and traditional testing methods. Learning about the Acceptance TDD framework helped me with my understanding of how test drive development can be scaled for larger projects and integrated into Acceptance methods.

Now that my understanding has been enlighten with this new found valuable knowledge and insights into test driven development methods, I can apply this in my future software development projects. I will also be able to writer better, cleaner, and more maintainable code when using this method.

Article link is Here:

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.

Specification Based Testing

  Specification based testing is a type of software testing that directly uses a systems specification in order to design tests. WHile considered a type of black box testing specification based testing can be used on any type of system but works particularly well when testing web applications. When practicing specification based testing you would first look at the code and its documentation in order to see what must be tested based on its functionality and uses. The objectives of specification based testing are functional accuracy, conduct based compliance, error detection, reliability/robustness, full coverage and compliance with the standards.

  There are 7 types of specification based testing listed which are “state transition” which is used to uncover errors in a system when switching states, “decision table” testing which can test functional and non functional system requirements, “equivalence partitioning” which is similar to decision table testing except it is best used when testing different inputs while decision table testing is best used on different combinations of inputs. Then there is “boundary value analysis” which consists of creating a test case for each boundary value, “all pair testing” which makes a test case for every possible input, “classification tree” is based on deriving test cases from a decision tree and “use case” testing which focuses on the functionality of the entire system rather than any individual component.

  I selected this topic/source as we have been practicing specification based testing in class recently and I was interested in researching more into the topic and the different types of testing that are classified as specification based and this article from “geeksforgeeks” went in depth not only into what the definition of specification based testing is but also the different types and the objectives of this type of testing. 

  This article was very helpful in my opinion as is gave me a perspective on specification based testing as a whole and after practicing some of the different types of specification based testing in class and reading this article I have a greater understanding or not only what this type of testing is but also how to go about testing in this fashion and writing test cases which pertain to the specifications of a system. I would consider this type of testing to be one which is more self explanatory than others but being able to understand its importance and its limitations is something that will help me when testing in the future.

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.

Black-Box, White-Box, and Grey-Box Testing

This week I decided to find a blog that discusses the differences between Black-Box, White-Box, and Grey-Box Testing because even I didn’t grasp it during the class activity. The article “Difference Between Black-Box, White-Box, and Grey-Box Testing” by TestFort Expert explains each way of testing in depth by using bullet points to outline the techniques of each type of testing and reviews the pros and cons of each.

The blog summarizes that the black-box testing method involves testing the software without knowledge of the internal structure and source code. You use this method to test the interface against the specifications that the client gives. The techniques that are involved are decision table testing, error guessing, all-pairs testing, and equivalence partitioning. The first technique tests with if-then-else and switch-case statements to find errors related to conditions. The second technique describes testing based on intuition, the third tests combinations of each pair of input parameters to find bugs from interacting parameters and the last technique involves splitting up parts to reduce testing time. The method tests for functionality but can only be applied to small segments of code.

White-box testing tests the internal structure of software and the logic behind it. One needs full knowledge of the code and the software for this method. It uses these techniques: control flow testing, data flow testing, and branch testing. The first technique logic of the code by executing input values and comparing for expected results. The second detects improper use of data values and data flow by coding errors. The last technique focuses on validating branches in the code. The blog mentioned that technical debt is reduced  by maintaining the code quality which is something I dint think about. Another thing I didn’t think about is that it can result in false positives because test results are strictly tied to the way the code was written. 

Grey-box testing is a combination of the previous methods. It tests for the interface, functionality, and internal structure. It requires some knowledge of the source code but takes more of a straightforward approach. The technique of this approach is matrix testing. regression testing and pattern testing. The first method involves tracing user requirements to identify missing functionality. The second technique involves testing the software after modifications, and the last technique involves analyzing the design and architecture of the software to find the root cause of a defect. This method isn’t suitable for algorithm testing. 

I think this blog is a good resource to learn about each testing method in depth. I think the lists of techniques were helpful in understanding what each method involves. I left class without truly understanding each method. I think the pros for the methods were straightforward but I didn’t think about the cons so I found that section helpful. Now that I know the techniques of each method I am better equipped to think about how to test software.

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.

‘Unleash Your Enthusiasm’ Pattern

  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.

Boundary Software Testing

This past week we began understanding and practicing boundary value testing using simple programs and, of course, simple tests. This blog post discusses that same topic, and gives multiple real life-scenarios and dives deep into the subject. Although it is not a super difficult subject to grasp (in my opinion), I feel this is a good way to reinforce those ideas we learned in class.

This blog by testbytes gives all the information one would need to give them a solid starting ground for boundary value testing. It first explains the concept of the testing model and why it would be done, such as explaining how testers hope to identify errors more proficiently. An example is given, using discount percentages that apply ONLY when purchase totals reach a certain threshold. The lower boundary of the first discount is given, testing if the total is less than $10 (which should mean a 0% discount). Then, the upper boundary of the first discount is checked, with a $10 order receiving an expected 5% discount, so on and so forth. 

Later the blog discusses the different types of boundary value testing as well as their distinctions and the disadvantages and advantages of this type of testing. 

I selected this resource because it gives a quick definition of boundary value testing but then goes into further detail on the subject with good examples and explanations. It is a well thought out post that gave me a more concrete understanding of boundary value testing and edge cases. 

Testbytes on its own is a reliable source for this specific information since it is an entire company dedicated to software testing and quality assurance. Through checking out their other posts, I see they have a variety of testing area blogs including mobile apps, web apps, games, automation, security, and more. 

Overall, this resource is great to refer back to due to its consistent information and easy to understand descriptions. 

As previously mentioned, the content in this blog post by Testbytes is a really solid basis for a good understanding of boundary value testing. I can’t say that it is the highest quality and in-depth education on the subject one can receive, but it’s useful for someone like me who is just getting started. 

Personally, I really enjoyed the material, especially the example given at the start. Although I wasn’t struggling with what we were learning in class, there were times where I had a moment of confusion. This is a quick bit of information that instilled some more confidence in me about this topic. One main thing I learned through this blog is a big disadvantage of BVA is truly how many test cases it may require to check all boundaries/edges, which can lead to a lot of effort on the system and more power/time consumption. I expect to use such advantages and disadvantages when creating test cases for my future individual and work projects.

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.