Category Archives: Week 12

CS 448-01 Team 3: Sprint 2 Retrospective (4/4)

With the second sprint, we had so much trouble with our sprint until near the end of the sprint. To elaborate on what went wrong, I would like to start out with what we were planning from the very start, as this will be very important for what we will be doing for the next sprint.

While our last sprint, we split between meeting remotely and meeting in-person, we finally decided that it would be better for us to meet in-person. We also came up with a wireframe that we decided to use as our template to create our framework for AddInventoryFrontend ( Since we already had AddInventoryBackend working as intended with the proper testing IDs being used as a way to test our code for the Backend, we only just needed to create AddInventoryFrontend so that we can try to put a frame over all the work that was done with the Backend from last year. At the very least, we knew exactly how we wanted to build our front-end.

On the contrary to how we finally have a plan for our Frontend, I was having lots of trouble with trying to build the Frontend. Since I had lots of trouble with some of the issues that we did, I instead decided to focus on redoing some of the issues we had from last sprint ( At the very least, I could at least contribute a little bit to our sprint, knowing the tasks that we were unable to completely finish.

What we as a team learned from sprint 2 was that we learned about using Vue, a Javascript framework that we would use to help build our Frontend. While we were not able to get the entire page running, we added a functionality to be able to add a button to our Frontend, just as we intended when we were following our wireframe example from earlier. Once we had explored our options to how we would build our Frontend, we decided to use a new wireframe that my teammate would create for our team to follow along with.

The things I could do improve on as an individual is that I need to speak out more with my team about the issues that may have, let it be related to work or anything other. I had trouble with this sprint because I was not great with programming with HTML and Javascript, and I felt like that was really hindering my performance as a team member. I did my best with trying to get help with working on the sprint, and when that was not working out well for me, I consulted my search engines instead. As someone who was much better with AddInventoryBackend, working with the Frontend was not my strength as shown in this sprint. I was confused with what wireframe we were using for the sprint until the end of the sprint when we had a semi-functioning Frontend that we were going to tweak in our next sprint. For the next sprint, I am hoping that I can get to do anything that is not too technical like directly running the Frontend, and I hope that then next sprint will be where our team will be able to get a working Frontend by the end of next sprint.

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

Rubbing Elbows: Shortcutting the Path to Software Mastery

The “Rubbing Elbows” pattern advocates for software developers to actively seek out opportunities to work hands-on, side-by-side with other skilled programmers. The core premise is that certain techniques and micro-habits can only be absorbed through close collaboration on shared coding tasks. Practices like pair programming try this kind of knowledge transfer, but the pattern applies to any endeavor that allows you to observe the workflow and decision-making of an experienced developer.
I found this pattern incredibly insightful and motivating. As a software engineering student, I’ve already experienced how much more I can learn by watching lecturers code and explain their thought process in real-time, versus just reading examples. The “Rubbing Elbows” pattern highlights how that same example of accelerated learning through consistency well beyond the classroom.
The authors make an good point that there are “thousand little everyday moves” that skilled developers have pressed through years of experience. These small refinements may seem minor on their own, but include into real improvements in productivity, code quality, and problem-solving prowess. However, these micro-habits are nearly impossible to fully carry through written documentation or formal teaching. Rubbing elbows allows an apprentice to organically absorb them through repeated, intimate observation.
I’m reminded of when I pair-programmed on a school project with a talented classmate. While daunting at first to have my code exposed, I soon realized I was gaining insight into his mental models, techniques for juggling complexity, and little shortcuts that markedly lifted his coding flow. Rubbing physical and mental elbows enabled knowledge transfer that couldn’t have occurred through solo learning.
This pattern has inspired me to be a go getter about joining open source projects, participating in local meetups, and seeking out internships that enable close collaboration with experienced mentors. Identifying and creating these “rubbing elbows” opportunities will be important for go beyond my current peak and speeding my progression as a capable, well-rounded software crafter.
While the unusual feeling of being the “newbie” amongst experts is unavoidable, I’m excited by the authors’ advice: embrace feeling lost at times, ask questions, rotate pair partners if stuck, and record learnings to cement them. Absorbing the tacit knowledge of those further along the path is key to rapidly elevating my own skills.

April 28, 2024

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

CS-448: Week 12

The Deep End

“The Deep End” pattern is about feeling unsatisfied with the path taken when learning new skills. The path taken has been small, safe steps that has made the learning process plateau. A way to jump start the learning process is by challenging yourself with bigger things such as bigger projects, working with larger teams, more complex projects, etc.

A solution to this pattern is to jump into the deep end, rather than waiting until you are ready. This is because the latter can lead to never starting anything, or challenging yourself to learn new skills. When a difficult problem occurs, rather than shying away, diving into the deep end and facing the problem head on is what will help in the long run. However there are some risks that are involved with going straight into the deep end. A risk is that you may get overwhelmed and fail. Although you may fail, failing is not necessarily a bad thing. Being prepared to fail, and recovering is what drives growth and provides opportunities that would be lost if the risk was never taken in the first place.

As mentioned before, in order to grow, bigger projects need to be made as a way to challenge yourself. Previous project’s size can be quantified by looking into those previous projects and marking down how many lines of code was written with how many developers. After reviewing all previous work, a chart can be made to see where how the next project compares.


I enjoyed reading about this pattern. I found the action to the pattern to be interesting because creating a chart, representing the size of your previous work, is something I would not have thought to do. However that process can be useful when determining if a project is at a large enough scale that can challenge previous projects. The pattern has changed the way I think about failure and taking risk. I like how the pattern paints the potential of failure as something that should be invited because I feel that failure is something that is not normally deemed acceptable. The pattern has ultimately changed the way I think about taking risks because risks and recovering from failures are what key to growth.

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

The Strength in In-Depth Exploration

Pattern Summary:

The “Dig Deeper” pattern from “Apprenticeship Patterns” advises aspiring software craftsmen to explore their craft beyond surface-level understanding. It emphasizes the importance of curiosity, continuous learning, and seeking deeper insights into software development concepts, tools, and techniques.

Reaction to the Pattern:

Upon reading about the “Dig Deeper” pattern, I was immediately struck by its relevance and applicability to my journey as a software enthusiast. What stood out to me as particularly intriguing and valuable was the idea of embracing curiosity as a driving force for growth. This pattern encourages us to go beyond mere familiarity with programming languages or frameworks and delve into the underlying principles, design patterns, and best practices that shape our craft. It has sparked a renewed sense of curiosity and passion for exploring the depths of software development.

Impact on Professional Perspective:

The “Dig Deeper” pattern has had a profound impact on how I view my intended profession and approach learning. It has shifted my focus from superficial knowledge acquisition to a more profound understanding of core concepts and foundational principles. By digging deeper into software development topics, I’ve gained a deeper appreciation for the intricacies and complexities of the craft. This pattern has reshaped my learning strategies, prompting me to prioritize depth over breadth and invest time in mastering fundamental concepts.

Disagreements and Critiques:

While I wholeheartedly embrace the essence of “Dig Deeper,” one potential challenge I’ve encountered is the overwhelming volume of information available in the software development realm. It can be daunting to decide which areas to delve deeper into and how to manage the depth of exploration effectively. However, I’ve found that setting specific learning goals, leveraging resources like documentation, tutorials, and mentorship, and focusing on practical application have helped overcome this challenge.

Overall Reflection:

Embracing the “Dig Deeper” pattern has been a transformative experience in my professional development journey. It has fueled my curiosity, expanded my knowledge horizon, and enriched my problem-solving capabilities. By diving deeper into software development concepts, I’ve gained confidence, resilience, and a deeper sense of fulfillment in my craft. This pattern has instilled in me a lifelong commitment to continuous learning and mastery, shaping the way I approach challenges, collaborate with peers, and contribute meaningfully to the software development community.

“Dig Deeper” serves as a guiding principle for aspiring software craftsmen, urging us to move beyond surface-level understanding and embrace the depths of our craft. By cultivating curiosity, seeking deeper insights, and mastering fundamental concepts, we pave the way for growth, innovation, and excellence in our profession.

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.

CS-448 Week 12 Study the Classics

The pattern “Study the Classics” highlights the importance of remembering and familiarizing yourself with foundational topics and the timeless concepts in software development. This is especially true for individuals with practical or self-taught backgrounds. It suggests that rather than feeling overwhelmed by the vast array of literature available, one should focus on reading books that have stood the test of time and continue to offer very valuable insights into the field.

What I find compelling about this pattern is the emphasis on the enduring relevance of classic texts in a rapidly evolving industry. It underscores the notion that while technologies may change, fundamental principles and concepts often remain consistent. Studying these fundamental texts will allow individuals to gain a deeper understanding of underlying principles that drive software development, which enables them to make more informed decisions and adapt to new technologies more effectively.

This pattern influenced my perspective on professional development and has reinforced the importance of continuous learning and reflection in my intended profession. Rather than focusing solely on the latest trends or technologies, I now see the value in investing time to study classic texts that offer timeless wisdom and insights.

While I agree with the overall premise of the pattern, I also recognize the possible limitations to solely relying on classic texts for learning and development. The field of software development is dynamic and multifaceted, and it’s essential to stay abreast of emerging trends and technologies. Therefore, studying the classics is valuable, but it should be complemented by ongoing learning and experimentation to ensure relevance and adaptability in today’s fast-paced industry.

In summary, “Study the Classics” underscores the importance of studying foundational texts in software development to gain a deeper understanding of timeless principles and concepts. While this pattern has reinforced the value of classic texts in my professional development, I also recognize the need for a balanced approach that incorporates both classic wisdom and ongoing learning to navigate the complexities of modern software development effectively.

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.

Valuing ‘HARD’ Skills: A Key to Professional Success

This week, I decided to read the “Concrete Skills” section of the “Emptying the Cup” chapter. This section discusses and highlights the importance of having strong technical skills, as well as good team skills, in order to be a promising and invaluable candidate for any prospective employers. I recognize that others who have been in the workforce longer, regardless of past profession, will have a head start on my soft or team skills by having more work and life experience than I possibly can at this exact moment. With this knowledge, I must understand that having soft skills alone won’t get me a position anywhere, since even though I do have some experience, it is very limited. By focusing on my hard or technical skills, I will be able to show any employer the types of direct contributions I can make to the team without needing to be taught or walked through.

I haven’t had the opportunity to gain software-related work experience, but I have been able to acquire some experience from a position working with data for around a year now. Even with that being said, I know I am still a risk to any employer since I still have yet to get my first position on a software team. By ensuring I have a strong foundation of technical skills, I can show to any future employer of mine that I can and will contribute to the team in a mutually beneficial way. In exchange for giving me a chance to learn and improve upon my craft, I will bring the pre-existing technological skills I possess to contribute to the optimization of any team’s efficacy.

Of course, as time goes on, I will become less focused on my technical skills and find the balance between displaying my “hard” skills as well as my “soft” skills complemented by any experience or achievements I will gain in the future. But at this current moment, I understand I don’t have that luxury, and any employment in the near future will be solely focused on my skills and what I could bring to the table.

Overall, this section reinforces the necessity of strength in the technical abilities of an entry-level prospective employee to ensure that their ability and understanding of programming will help jumpstart their journey into becoming a master craftsman. Over time, however, building a balance between technical and team skills, complemented by my future achievements, will be key to progressing from apprentice to journeyman and, one day, to a master.

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.

Learn How You Fail: Embracing Failure to Forge Success

Understanding the Pattern of Failure

The insightful pattern discussed in Atul Gawande’s “Better” emphasizes a profound truth: recognizing and reflecting on our failures is crucial for personal and professional growth. This notion is encapsulated in the phrase “Learn How You Fail,” which posits that true ingenuity stems not from sheer intellect but from character—specifically, the courage to face our shortcomings and adapt.

Personal Reaction

I found this pattern both challenging and refreshing. Initially, it’s discomforting to focus on failures rather than celebrate successes. However, Gawande’s approach—focusing on identifying and understanding the causes of our failures—provides a constructive framework for turning apparent setbacks into stepping stones.

This perspective is not just about acknowledging weaknesses but actively choosing which battles are worth fighting. The notion that not all failures need to be addressed equally, and some might even be embraced as limitations, is liberating. It helps in setting realistic goals and focusing efforts where they can truly make a difference.

Changes in Professional Perspective

As someone aspiring to thrive in a fast-evolving sector, this pattern has shifted my thinking towards a more adaptive and resilience-oriented professional mindset. The emphasis on continuous self-assessment and setting realistic boundaries resonates deeply. It underlines the importance of focusing on areas where I can excel and accepting areas where I may never be the best. This realization takes away the useless pursuit of perfection in every domain, instead encouraging a strategic approach to skill development and goal setting.

Points of Disagreement

While I appreciate the core message of the pattern, I hold reservations about the practicality of some suggested exercises, such as writing and debugging code without initial testing. While this can reveal unforeseen errors and personal blind spots, it may not be the most efficient learning method for everyone. This approach could lead to frustration or demotivation, particularly for novices who might benefit more from immediate feedback and iterative learning.


“Learn How You Fail” is not just about understanding how to handle failure—it’s about strategically leveraging these insights to refine our skills, set achievable goals, and foster a mindset that views challenges as opportunities for growth. This pattern has encouraged me to embrace my limitations, prioritize my efforts, and continue pushing the boundaries of my capabilities with a clear and realistic vision.

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

“Draw Your Own Map” Individual Apprenticeship Pattern

This week, I decided to focus on the “Draw Your Own Map” Individual Apprenticeship Pattern for CS448-Software Capstone. This is my final required apprenticeship pattern analysis post, and I chose this pattern because it feels applicable to me as I am about to graduate and enter the working environment, mapping out my intended career path from its starting point. 

The “Draw Your Own Map” individual apprenticeship pattern emphasizes the importance of taking control of one’s career development and learning journey. It encourages individuals to proactively chart their own course rather than relying solely on predefined paths or external guidance.

At its core, this pattern advocates for self-directed learning. It urges individuals to actively seek out opportunities to acquire new skills, knowledge, and experiences that align with their career aspirations. Setting personal goals is essential in this process, providing a roadmap for growth and development.

Identifying various learning opportunities, both formal and informal, is crucial for professional advancement. This could include attending workshops, pursuing certifications, participating in projects, or seeking mentorship. Adaptability and flexibility are also key, as career paths may require adaptation and adjustment over time.

Regular reflection on progress is encouraged to refine goals and adjust course as needed. By reflecting on past experiences and learning outcomes, individuals can iterate and improve their development strategies. Additionally, building a personal brand and reputation within the industry is essential for showcasing skills, expertise, and achievements.

In essence, the “Draw Your Own Map” pattern empowers individuals to navigate their professional journey with autonomy, self-reflection, and continuous learning. By embracing ownership of their career trajectories, individuals can pursue their long-term goals with purpose and resilience.

With such a competitive entry-level environment, it is possible that I may find myself (or at a later point in my career) choosing to take a position that may not fully align with my interests and career goals. Additionally, with all of the ongoing changes in the tech industry and world as a whole, what may have been a traditional and common career path is impractical today. So, it’s crucial that I can draw my own map to success and redraw it as necessary throughout my career. By following the strategies outlined in this apprenticeship pattern, it seems a lot more realistic to be able to take a starting position that may be less-than-ideal while still progressing toward my intended goal.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Writing Testable Code

For this week’s blog I decided to dive a bit deeper into writing testable code because I think it is a valuable skill. While searching for blogs that discuss this topic I found “TDD: Writing Testable Code” by Eric Elliott. In this blog, Elliott explains the importance of writing testable code barriers to writing testable code, and different tips to keep in mind to write testable code. 

The first thing he touches on is how a good quality process is essential to continuous delivery. One of the most important principles, he mentions, is the separation of concerns because “simplifies complexity and enhances the overall quality of your work”.

In the overview about testable code, he explains that achieving testable “allows for more efficient and effective identification of defects, ensuring higher quality and reliability”. The key characteristics of testable code are modularity (when code is organized into discrete units), clarity (code that is easily comprehensible), and independence (when code can be tested in isolation).One of the barriers of writing testable code that Elliott describes is tight coupling in code. The coupling in code is the instance where changing one part of the code can heavily impact or even break the functionality of another part in the code. If one part is changed there can be a chain reaction of bugs in various other parts of the code. Right coupling can be caused by parent class dependencies, shared mutable states, concrete class dependencies, event chains, state shape dependencies, control dependencies or temporal coupling. He explains that to write testable code you must reduce the forms of tight coupling mentioned because it makes testing easier and promotes a “more sustainable and scalable codebase”. This is why testable code and maintainable code are the same thing. 

Later he explains the test first vs test after approaches. The test first approach is the test driven development approach where tests are written before the code. The benefits include better developer experience and clearer requirements and design. The test after approach is where the tests are written after the implementation which leads to a probability of biased tests and reduced code coverage.

One of the last sections provided is about the separation of concerns which a  design principle for programs into distinct sections that  addresses separate concerns”. This principle is important because it allows independent testing and allows developers to isolate problems more effectively in addition to allowing the ability to make changes without unintended consequences. He describes that he likes to isolate into 3 distinct sections business and state logic (the core logic of the application), user interface, and I/O and effects (the part of the application that interacts with the database).

I think this source was well organized and easy to follow. It made the text easy to understand and provided great advice for writing testable code. I think the last section about how he likes to isolate the sections was especially helpful and I will keep it in mind for the future.

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.

Week 12 – Comparing Tips

For this week, I wanted to look at what some websites consider helpful tips when it comes to testing software in Java and compare that to what we have learned in class. By looking at each tip one by one and comparing it to the things Professor Wurst has taught us during our lectures.

For this, I will be looking at this website:

Tip Number 1 is to “Compose Tests before Writing Code”, which is actually what we have been focusing upon for the last few weeks, so it’s good to see that this is being reaffirmed

Number 2: Keep tests small and concentrated. This is another subject that we’ve been looking at as well, as we’ve been looking at strategies on how to concatenate code for test.

Number 3: Defining your Code Coverage. This isn’t actually something I believe we’ve spoken about in this class, however, we have discussed similar things in my previous classes with Process Management.

Number 4: Isolating Tests from External Sources. This one Im not sure if we have discussed it, but it also seems like a given, considering we have been taught to always only use tests in test classes and to pull from testing packages when importing.

Number 5: Automate wherever possible. I don’t actually think we’ve done this yet in Testing, however, this is something we have discussed previously in another class, I believe in Software Design. If you can automate something, always try to.

Number 6: Creating Mock Dependencies. This isn’t something in specific we’ve touched upon yet I feel, however it makes sense. I feel as though when I did our first homework, I kind of did something similar to this.

Number 7: Use Assertions. Yes. Absolutely we have done this in class. All if not most classes we have written use assert.equals(), assert.true(), or assert.false(), amongst others.

Number 8: Using proper names to test methods. This is something we learned way back in CS101. Always name your methods something understandable for you and your team to instantly know what it does. Never write gobbledygook names for methods, be concise.

Number 9: Keep Unit Tests Up to Date. I don’t believe this has been taught yet as most code we have worked with has been static and unchanging. However, Im sure we will have assignments where we focus on this harder. It definitely seems like something that is extremely important, as code changes so too should the tests, or else they wont work properly or even give false positives.

Number 10: Don’t Focus on Implementation. This one is interesting to me. We haven’t really spoken about implementation of code when it comes to testing. It’s very interesting to me because I have never really thought about this before, but it definitely makes a lot of sense to me. Something good to keep in mind for the future.

And lastly number 11: Create independent test cases. I actually unfortunately learned this myself the hard way with the first homework, as each class was accidentally dependent of one another if ran back to back. It’s something I definitely need to keep in mind going forwards.

And thats it! It’s definitely a lot of overlap which is great to see. Until next week!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.