Category Archives: CS-448

Apprenticeship Pattern: White Belt

Summary of the Pattern:

The “White Belt” pattern emphasizes the importance of approaching new learning experiences with a beginner’s mind, regardless of your level of expertise. It suggests setting aside previous knowledge and preconceptions to fully absorb new information. Drawing analogies from various fields like family therapy and programming, the pattern illustrates the benefits of adopting a mindset of not knowing. By embracing ignorance and being open to making mistakes, individuals can accelerate their learning and gain deeper insights.

Reaction:

As someone who takes pride in my skills, it’s easy to fall into the trap of believing I already know the best way to approach a problem. However, the “White Belt” pattern reminds me that there’s always more to learn and different perspectives to consider.

What to Do:

The pattern suggests practical steps to implement its principles. For example, it recommends trying to implement a program in a language with a different paradigm, or learning from someone in a different technological community to understand their perspectives. These actions challenge one’s comfort zone and encourage embracing new ways of thinking.

What I Found Thought-Provoking:

The analogy of wearing a white belt, signifying a beginner’s level, is powerful. It reminds me that true mastery comes from a willingness to continuously learn and adapt. Additionally, the idea of consciously unlearning and relearning is intriguing. It requires humility and courage but promises significant growth.

Changes in Thinking:

This pattern has reminded me in the importance of continuous learning and humility in any area of life. I aim to approach new challenges with a more open mind, ready to embrace the discomfort of being a beginner again. Instead of seeing setbacks as failures, I now view them as opportunities for growth.

Disagreements:

While I don’t disagree with the core principles of the pattern, I recognize that fully embracing a beginner’s mindset can be challenging, especially in environments that value expertise and efficiency. However, I do see a view of balance on where it can be useful to listen to new ideas/appreaches while incoperating past ideas. As I do not think the White Belt pattern suggest to blondly accept any and all new information without any rebuttals or input.

In conclusion, the “White Belt” pattern serves as a powerful reminder to approach learning with humility and openness. By unlearning and relearning, we can break through plateaus and continue our journey toward mastery.

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.

The Long Road

For this week’s blog, I decided to write about the pattern called “The Long Road” from Chapter 3. My previous blogs touched a bit on the contents of this pattern so I decided to discuss what the authors suggest for this pattern. In this pattern, the situation that is presented relates to how your aspirations to become a master software developer conflict with the expectations of others and how “Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills”. 

The solution that is presented is to first accept the judgments you may receive from others to go against the status quo and then to stay focused on the long term. During the journey you will gain quite a bit of skills and knowledge; it is a long one so you need to prepare for it by drawing your own map. The text mentions “ you should keep in mind the expectation that you will be a working software developer even when you are middle-aged. Let this influence the jobs you take and the scope of your ambitions. If you’re still going to be working in 20 years’ time, then you can do anything”. You will be able to catch up to anyone in terms of skills in the decades that you will work and you may just pass them. Before reading this pattern I never really thought about just how long I will be working in the field. As I have discussed in many of my blogs for this class, I have been working on developing myself professionally and learning from other developers; as I have progressed, I have thought about the possibility of not being the weakest on the team so I agree that it is realistic to surpass people during your long journey.

The pattern really stresses the idea that instead of counting the days to retirement, a craftsman will willingly work until their final decades. You should thoughtfully work on developing your craft over many years. The idea of taking the long road is the foundation for a successful apprenticeship along with self-assessment. I couldn’t find anything in this section that I could disagree with. It definitely made me think of what I want to get out of this long journey because I didn’t take the time to think about it in-depth before.

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.

CS-448: Week 11

Confront Your Ignorance

This pattern is about confronting your ignorance. After going through the “Expose your ignorance” pattern, where you identify gaps in your skillset, the next step is to confront those gaps. The main problem that comes from this pattern is that there are techniques and tools that need to be learned, but the process of actually learning these techniques in unclear. Some of these may be techniques that everyone already knows, so there is an expectation that everyone be competent in that area.

The solution to this pattern, with the list generated from “Expose your ignorance”, is to pick an item from that list and actively fill the gaps for that item. How this can be done is a matter of preference. Some prefer to research everything they can about a topic, such as introductory articles and forums. Others prefer a more hands on approach by going straight into the topic by building a simple project. Although confronting your ignorance is mostly an individual task, asking mentors and experienced people is important to learn what information they can share with you. Asking mentors can also be beneficial as they may have learned tricks that they found themselves that may not be discoverable through documentation.

As mentioned before, this pattern is do be done after exposing your ignorance. Exposing your ignorance is a critical step because it makes the gaps in your knowledge public, which makes your team aware of those gaps and your learning ability. Having your gaps be on display for your team encourages an environment where failure and learning are acceptable as they both play a large role in an apprentice transitioning to become a journeyman and so on.

Conclusion

This pattern is helpful to me because confronting my ignorance is something I struggle with at times. The pattern states that exposing your ignorance without confronting can lead to excessive humility and helplessness which are feelings I have had in the past, so this pattern helps to give some encouragement to start confronting that gaps in my knowledge. After reading the patterns “Expose your ignorance” and “Confront your ignorance”, I feel much more confident in the future on how I can improve my skills in a methodical manner.

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.

CS448 Software Development Capstone – Apprenticeship Patterns – “Record What You Learn”

In this blog post, I want to talk about the “Record What You Learn” pattern from the “Apprenticeship Patterns” textbook by David H. Hoover and Adewale Oshineye. The premise presented in the pattern’s introduction,

“You learn the same lessons again and again. They never seem to stick… You remember doing very similar things in the past, but the exact details escape you.”

, captures some of the feelings that I’ve been having as our development group continues our work on Thea’s Pantry. I remember doing so much backend HTTP server work last semester, but I haven’t retained the lessons as well as I wanted to, and I feel like I’m repeatedly reviewing old material.

Lately, I’ve been reflecting on how well I’ve been nourishing my writing abilities – I stopped keeping a daily journal some time ago, and I’ve noticed that I haven’t been taking as many handwritten notes in my classes as I used to. The first reason I can think of for not wanting to stick to the habit is that I haven’t been exactly clicking with the record-keeping tools that I’ve been using. At first, I wanted to keep digital personal journals with tools like Microsoft Word or a journaling app on my Android device because I liked the idea of having as much space to write as much I wanted, without having to think about reaching a physical “end of the book”. However, I’ve realized over time that there are parts of the electronic writing process, like the glow of the monitor and the distractions of other applications, that can make it harder to concentrate on personal writing as opposed to pen and paper.

I’ve also been reflecting on my writing practices in addition to the tools I’ve been using. I’ve known for some time that I would be helped by keeping records of the things I’ve learned about computers, networking, and software development in my own writing, but I just haven’t known how to start or structure a collection of notes that I want to return to and reference in the future. One solution offered by the “Record What You Learn” pattern is to utilize a personal wiki to organize and store your notes. While I’ve been thinking I want to return to pen and paper for more personal writing, I think that a digital tool like a wiki would be a great choice to organize knowledge-based writing and references to further learning resources. The review process is also an essential part of using the “Record What You Learn” pattern. The authors emphasize the importance of rereading your material: “Your notebook, blog, or wiki should be a nursery, not a graveyard—lessons should be born from this record, rather than going there to die.”

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.

The Deep End

This pattern describes growing your skills by challenging yourself with any opportunity that is given to you. Whether it’s done through taking on bigger or more complex problems or working with larger teams, there is always something to learn by trying something new. This also means seeking out projects to work on to build a portfolio and expand your skills.

For someone who started programming java in 2007, my portfolio is pretty barren. This comes down to two factors. Lost old files, and failing to start new projects. This pattern is one that I can definitely relate to the problem of feeling like I have plateaued. My eyes are opened to the truth as I get more exposure to the world of software development. If I am going to gain new skills I need to actively seek projects that push the boundaries of what I already know. I have always wanted to develop an application, but without any clear idea of what kind of application I wanted to make. This has always paralyzed me from actually learning how to develop an application. There are two clear solutions I can think of right now based off of two other patterns I have written about in the past. Following the pattern of “Find Mentors,” I could have sought out the guidance of a mentor and asked for ideas for projects that would develop my skills. The second pattern of “Breakable Toys,” gives me the option of just making an application for the sake of having a tool I can use. Making a breakable toy for an application would be a great way for me to jump into the deep end as far as pushing my knowledge of software development.

The other part of challenging myself is working with larger teams. Up until last year all of the projects I have worked on have been solo. Last semester, where I was partnered with another classmate, was one of my first exposures to developing large projects with someone else, and the challenges that come with it. Teamwork is crucial as anywhere I go in my career I will be working on a team, so being able to work together and communicate are important skills to develop. And just like learning from actually developing code, these skills will be built by actually working in larger teams.

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

Sprint 2 Retrospective

After finishing our second sprint I believe it went very well. Our team did a great job of communicating, time management and ensuring everyone’s ideas were heard. We also made sure to ask each other questions if we were stuck on an issue as well as ask anyone if they needed any help with their issue if they were having any problems. I believe the only problem we had was reviewing the issues, we either got a little sidetracked or were waiting on a response to a question we had about the issue so it kind of prevented the reviewer from checking on it. As a group of 5, we needed a weight total of 30, we managed to complete all of our issues. Since the last sprint, I believe we made a lot of progress as a team and managed to get through this sprint without a lot of issues.

As a team, I believe we made a lot of progress in this sprint and didn’t have a lot of issues to work on. We made sure to communicate with each other about how everyone’s progress was going on with their issue and if they needed any help with anything. The reason why we managed to get through this sprint is because of our communication and teamwork. As a team an improvement that we can make is our reviewing, we did have a couple of issues left in the needs review column that just needed to be checked but we kind of delayed that. I believe that was our only problem this sprint since for most of the issues we worked as a group and managed to get it done in one meeting. If we just made sure to stay on top of any work that needs review I feel like our sprint would’ve been done sooner than later.

As an Individual I believe I made a lot of improvements since the last sprint. I made sure that the work was even spread out between me and the team. The issues I worked on were Get the InventorySystem General test and build working and Verifying GuestInfosystem/Documentation. I made sure that the guestinfo system documentation had the right extensions, linters and that the pipelines were working. The only problem I ended up having was with the inventory system general test and build working. I just ended up asking Professor Wurst what I should do with them since by looking at other repos the general didn’t have a test or build so I just ended up disabling those pipelines and everything ran smoothly. Next sprint I plan on working on my issues and making sure that nothing sits in needs review so my team members don’t have to do more work than they need to and make sure that I’m contributing as well. I also plan on making sure to get any questions I have asked as soon as possible so that the issue can be solved sooner rather than later. 

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.

Sprint 2 Retrospective

Introduction

As we conclude Sprint 2, it’s essential to take stock of our journey, examining both our successes and the challenges we’ve encountered along the way. This sprint, our primary focus was on scaling up productivity and initiating the UI development process. Despite its longer duration compared to the previous sprint, Sprint 2 felt back-heavy due to delays in commencing frontend work until we obtained access to the new template.

Challenges Faced and Lessons Learned

Both sprints presented us with unique challenges, contributing to our team’s growth and development. One significant challenge in Sprint 2 was the unexpected complexity encountered while coding a UI component. Initially deemed a simple task, unforeseen changes in the source code necessitated extensive adjustments, resulting in delays and frustration. However, this challenge provided valuable lessons in flexibility and adaptability. By grappling with the intricacies of the component and adapting to evolving requirements, we honed our problem-solving skills and gained a deeper understanding of UI development.

Another challenge stemmed from the weight of certain child issues, which had a more substantial impact on our workflow than initially anticipated. This highlighted the importance of thorough planning and assessment when breaking down tasks and allocating resources. Moving forward, we recognize the need for a more nuanced approach to issue prioritization to ensure each task receives the appropriate attention and resources.

Team Dynamics and Communication

Effective communication emerged as a cornerstone of our approach throughout both sprints. We found that tackling problems collectively as a group significantly eased the resolution process. Whether through online discussions or face-to-face meetings, open dialogue and transparent communication channels were maintained, ensuring alignment and informed decision-making. We intend to prioritize effective communication, proactive problem-solving, and meticulous planning in future endeavors.

Strategies for Improvement

Team Improvement

  1. Keep a consistent schedule: In hopes of avoiding a repeat of the last sprint where everything was stacked at the back of the sprint, it would be beneficial to manage our time better as a group with a more consistent meeting time.
  2. Division of Labor: We continue to ensure that one person does not get stacked with too much to do while others get left with little to work on.

Personal Improvement

  1. Frequent Check-Ins: In realizing the significance of team alignment, I commit to checking in more frequently with my team members. By maintaining regular communication and seeking feedback, I aim to ensure that our efforts remain aligned towards our common objectives throughout each sprint.

Moving Forward

As we look ahead, we are committed to leveraging the lessons learned from Sprint 2 to inform our approach in subsequent iterations. Documenting challenges, solutions, and key takeaways in a “lessons learned” repository will serve as a valuable resource for future sprints, enabling us to anticipate and mitigate potential obstacles more effectively. With a shared commitment to continuous improvement and a supportive team environment, we are confident in our ability to overcome challenges and achieve our goals collectively.

Links to Activity on GitLab

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.

share your knowledge

As my final Apprenticeship Pattern blog post for my capstone course, I found it fitting to write about the “Share What You Learn” pattern. The idea is fairly simple, if you are gaining knowledge on a topic, you should be able to share that knowledge with others effectively to foster mutual growth, which results in everyone building on their ‘craftsmanship,’ which further results in better products from everyone involved.

We don’t work in a vacuum by ourselves, and so communication is incredibly important. We will always be working on teams of software developers, and even in our personal projects, we are working with information that we are informed about from the entirety of the software development ‘community.’ As such, learning to communicate your ideas and share your knowledge is always great for your team.

Different people have different specializations, and in software development, we have our own specializations and interests within this field, and it is beneficial to not only contribute your expertise to the project you are working on with your team, but also share things about that expertise to get everyone on the same board with what you are doing, and perhaps foster growth in them as people and the project as a whole.

The intersting thing is that you can also learn from others’ specializations and expertise when you are sharing your own, and you can also build on your knowledge from ideas and suggestions that others may make when hearing your ideas. It’s a bounce back and forth.

I think everyone has probably experienced this to some extent, even in small circumstances. As the authors mention, simply knowing one small thing more than another person allows you the opportunity to inform that person about your piece of knowledge, and that fosters growth, no matter how small. I know that, for me, I’ve had multiple people ask me about how to do things when they need reminders or help with assignments or issues that they run into at work, and in that situation, it is beneficial to know how to communicate solutions, suggestions and feedback in a way where everyone stands to gain.

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.

Sprint 2 Retrospective Blog

As we wrap up our second sprint, it’s time to pause, reflect, and glean insights from the journey we’ve undertaken together. Sprint 2 has been a period of significant learning, characterized by both triumphs and obstacles that have shaped our team dynamics and individual growth. In this retrospective, we’ll delve into the challenges we faced, the lessons we learned, and the strategies we’ll implement moving forward.

One of the pivotal challenges we encountered during this sprint was the coding of a UI component. Initially perceived as a straightforward task, it quickly evolved into a complex endeavor due to unforeseen changes in the source. These alterations necessitated extensive adjustments to our initial plans, leading to delays and frustration. However, amidst the challenges, we discovered an opportunity for growth. By grappling with the intricacies of the component and adapting to evolving requirements, we honed our problem-solving skills and gained a deeper understanding of UI development. This experience underscored the importance of flexibility and adaptability in the face of unforeseen circumstances, emphasizing the need to approach tasks with an open mind and a willingness to iterate and refine our approach.

Another significant aspect that influenced our sprint was the weight of certain child issues. What initially appeared as minor tasks turned out to have a more substantial impact on our workflow than anticipated. This discrepancy highlighted the importance of thorough planning and assessment when breaking down tasks and allocating resources. Moving forward, we recognize the need for a more nuanced approach to issue prioritization, ensuring that each task receives the appropriate level of attention and resources commensurate with its importance. By fostering a culture of careful planning and strategic resource allocation, we aim to mitigate the risk of unexpected bottlenecks and delays in future sprints.

Despite the challenges encountered, sprint 2 has been instrumental in fostering our team’s growth and development. We’ve had the opportunity to enhance our problem-solving skills, adapt to changing circumstances, and refine our communication and collaboration strategies. Effective communication emerged as a cornerstone of our approach, enabling us to navigate challenges and coordinate efforts seamlessly. Whether through online discussions or face-to-face meetings, we remained committed to fostering open dialogue and transparent communication channels, ensuring that everyone remained aligned and informed throughout the sprint.

Looking ahead, we recognize the importance of carrying forward the lessons learned from sprint 2. We are committed to prioritizing effective communication, proactive problem-solving, and meticulous planning to ensure the success of future endeavors. Additionally, we plan to leverage our experiences from this sprint to inform our approach in subsequent iterations. By documenting our challenges, solutions, and key takeaways in a “lessons learned” repository, we aim to create a knowledge base that will serve as a valuable resource for future sprints, enabling us to anticipate and mitigate potential obstacles more effectively.

In conclusion, sprint 2 has been a journey of growth, resilience, and collaboration. While we encountered our fair share of challenges along the way, each obstacle served as an opportunity for learning and development. Armed with newfound insights and a renewed sense of determination, we look forward to tackling the challenges that lie ahead and achieving our goals as a team. With a shared commitment to continuous improvement and a supportive team environment, we are confident in our ability to overcome any obstacle and emerge stronger than before.

Links to issues covered:

Review GUI mockup
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/45

Coding new UI and fixing gitpod implementation
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/43

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.

Sprint #2 Retrospective

What Worked Well:

Sprint #2 was another productive learning experience for our team. We were able to continue building upon the momentum gained from Sprint #1 and were able to achieve commendable progress. In this sprint, we were tasked with completing eight different issues to reach a total issue weight of 30. We crushed this number, completing all eight of our issues on our issue board before the end of the sprint. Something worth noting was our familiarity with the project, what tools we needed, and the process. When comparing last sprint to this one, we found ourselves navigating through GitLab and GitPod more efficiently without any major issues. This resulted in a much smoother workflow. Additionally, I thought that our communication throughout the Sprint remained a cornerstone of our success. We stood up to date with scheduled meetings through Discord and in-person, allowing us to touch on some points, any updates, problems, discussions, and allowed for collaborative problem-solving. This consistent communication fostered a sense of cohesion within the team and ensured that every team member stayed aligned towards completing our tasks. I also found our workflow to be great. We completed some issues together and some individually, but as we finished one thing no one was hesitant to pick up another issue, help someone out, or review work. In regards to what didn’t work well, I don’t have much. Sprint #1 was a learning process for the entire team and once we understood everything, how to time manage our work, and how everything functions in the system, we brought what we learned into Sprint #2. We were able to complete tasks in a very timely manner while also knowing exactly what’s happening in the system and how to correct any issues.

Improvements As A Team:

We made some drastic improvements from the previous sprint in regards to how we took on work, the time we worked on it, our review process, and much more. Although I really liked the progress our team made throughout this sprint I believe one possible area for improvement could potentially be commenting or adding notes for work being completed. As stated, some tasks we completed individually. With this being said, when having other individuals of the team review work, it can be a little challenging to actually see what was changed, added, or the thought process behind someone’s work. By adding some comments directly to issues or connected to merge requests, it allows for both reviewers and anyone going through the work to easily understand what was completed, added, or needs to still be done. A simple message such as, fixed linter errors or solved merge conflicts can go a long way.

Improvements As An Individual:

During Sprint #2, I was able to complete one issue individually and two issues with my team. My first issue was Get Inventory Backend Test Working in InventoryBackend. In Sprint #1, we had some issues with the Inventory System test pipeline. I wanted to really get that testing pipeline to work to continue progressing the project forward. This issue involved me creating a test-runner file, along with an automated_testing_docker-compose.yaml file to integrate into the project. I also communicated with other groups for what they were completing to then integrate our work together and have the testing pipeline run and pass. My second and third issues were completed with my team. This being Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the GuestInfoBackend, and Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the GuestInfoAPI. These issues involved adding and enabling the different linters in our system and testing their respective pipelines to ensure they passed. If they didn’t pass, we needed to go into their specific files to make changes and correct the issues. In regards to improvements as an individual, I’d like to see myself become more of a team player for our last sprint. Sometimes I tend to get so focused on fixing and completing one issue that I forget to check in with the needs of the rest of the team. For me, this could be jumping in to help someone that’s stuck on a specific issue, reviewing the team’s work and providing feedback, and even voicing my thoughts, interests, or opinions more to my team. By doing so, I believe it’ll help me grow as an individual and a teammate, and help me tremendously with my professional career.

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