Category Archives: CS-448

Craft Over Art: A Journey of Mastery

Summary of Craft Over Art:

The “Craft over Art” pattern delves into the distinction between craftsmanship and artistic expression within the realm of software development. It emphasizes the importance of prioritizing craftsmanship, which entails mastering the fundamental skills and techniques required to create high-quality software, over the pursuit of artistic flair.

My reaction:

Upon encountering the “Craft over Art” pattern, I found myself reflecting deeply on the essence of software development as a craft. What struck me most was the notion that craftsmanship transcends mere creativity or innovation—it embodies a dedication to continuous learning, refinement, and adherence to best practices. This perspective has profoundly influenced my perception of my intended profession as a software developer.

Initially, I was drawn to software development by the allure of innovation and the opportunity to unleash my creativity through code. However, this pattern prompted me to reconsider the significance of honing my technical skills and adopting disciplined practices. It made me realize that while creativity has its place in software development, it is craftsmanship that truly underpins the creation of reliable, maintainable, and scalable software solutions.

Moreover, the pattern’s emphasis on mastery resonated with me on a personal level. It sparked a realization that becoming a proficient software developer requires more than just technical prowess—it demands a commitment to continuous improvement and a willingness to embrace challenges as opportunities for growth.

While I wholeheartedly agree with the premise of prioritizing craftsmanship over artistry in software development, I acknowledge that striking a balance between the two is essential. Creativity and innovation undoubtedly drive progress in our field, but without a solid foundation of craftsmanship, they risk being mere flashes in the pan. Therefore, I believe that the key lies in integrating artistic expression with the principles of craftsmanship, leveraging creativity to enhance the quality and elegance of our code.

“Craft over Art” pattern has been instrumental in shaping my understanding of software development as a craft. It has inspired me to prioritize mastery, discipline, and continuous learning in my journey as a software developer, ultimately guiding me towards the path of excellence in my 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.

The White Belt

In this week’s blog post, I will be discussing the “The White Belt” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to set aside what you have learned in order to learn more is a difficult but important skill.

A quote early into this section that I can personally relate to discusses how your confidence in what you have already learned can cause you to have a harder time learning more. “You are struggling to learn new things, and it seems somehow harder than it was before to acquire new skills. The pace of your self-education seems to be slowing down despite your best efforts. You fear that your personal development may have stalled.” I have been in this position myself more than once. One approach the chapter mentions is called the not knowing stance.

The not-knowing stance, as mentioned in the chapter, is an approach to understanding that you do not and can not currently understand the entirety of what you are trying to accomplish. “Part of the approach Dave took as a family therapist included maintaining a not-knowing stance. Families in difficult circumstances were experiencing a unique reality that, despite his training, Dave knew he could not fully appreciate. While he acknowledged his skills at facilitating constructive questions and conversations, Dave was taught to refrain from believing that he had any expert knowledge into the realities that these families experienced. While this may seem counterintuitive, in reality, it fosters an attitude of respect and curiosity that opens up unforeseen possibilities and solutions. Rather than pushing solutions down on the family, Dave’s not knowing stance helped him to collaborate with the family to find solutions as a team.” As shown in this quote, embracing the not-knowing stance, can help you have a more open mind in trying to solve problems, or learn new things in different ways. Embracing the not-knowing stance is not only incredibly helpful in being able to learn new things, but can also help interpersonally, as shown by the quote.

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.

Sprint Retrospective March 3, 2024

During this sprint, I worked on four issues that were assigned to me. As a group, we all did well in our first sprint and felt we had much to improve on. There were areas where I could improve. During this sprint, I worked on four different issues; one of them was “Investigate GenerateWCFBReport frontend for better understanding of what tests need to be created”(1). This issue involved looking into the .vue files in the GenerateWCFBReport to determine the tests required. Keith and I had looked through the files separately to see what would be done. While I wrote down what needed to be done in a Word document, I remembered that I needed to add a comment to the issue page, which Keith already did.

Another issue I worked on was “Add AlexJS linter to pipelines for AddInventoryFrontend”(2). I had a lot of trouble with this issue, and it took around three hours to finally finish. Thankfully, I was able to work with my team to correct the issues I was having in getting this issue completed, even though, as I wrote in my notes while working on this issue, I was not and am not sure how I was able to get the pipeline to pass. However, Keith later noticed we may need to correctly complete this issue and other issues related to adding AlexJS. We plan on correcting these issues in sprint two.

A third issue I worked on during the sprint was “Move commands from ‘GuestInfoAPI/commands’ to ‘GuestInfoAPI/bin’”(3). This issue went smoothly for me, but I recall Tommy was having trouble completing a similar issue in a different section of the project, we tried to help him as best as we could, but for some reason specific files were being picked up by linters that should not have been. I am still unsure as to how the rest of the group did not have similar issues with their issues regarding moving their commands code.

The fourth issue I worked on this week was “Gitpod Dev Environments GuestInfoApi Team 2″(4). I had a lot of trouble with this issue as well, as mentioned in the issue page comments, I had to skip these issues “stoplight.spectral”, “hashhar.gitattributes”, “tlahmann.alex-linter” because of this error “[extension] extension is not found in Open VSXgitpod”. This was the first one I worked on during the sprint, so I had several issues merging the commits. “I also had difficulty merging commits, but Keith found a workaround to correct the issue. This took around 45 minutes to find and correct. In addition to this, I spent another 45 minutes trying to correct some linting errors being caused by “/t” markers.”

As a group we agreed that our communication was fantastic, we reached out to one another when we needed help, and were all able to communicate our ideas politely and efficiently and were all on the same page. However, we all agreed that we needed help with efficiently scheduling meetings between the four of us. We also needed help with weighing our issues appropriately. These issues can be easily corrected, with the scheduling we have determined to dedicate at least one class meeting to be in person and the other online. Regarding the weighing issues, that was primarily due to our inexperience.

I could improve by working on my assignments more on my own rather than just during our meetings. I also could improve by putting more comments on my issues in GitLab.

Issue 1: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/36

Issue 2: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/30

Issue 3: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/146

Issue 4: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/149

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.

The Importance of Finding Mentors

Beginning a journey in the Software Development field is like walking through a maze. Every turn presents different challenges, different opportunities, and different outcomes. Having a mentor can be the guiding light that we need through our journeys. The Finding Mentors pattern underscores the importance of seeking out help and assistance from experienced individuals who can provide both support and guidance while navigating the complexities of the field.

Reflecting on my own experiences, having a mentor can have quite a profound impact on shaping skills, gaining knowledge, and viewing things from different perspectives. I’m yet to experience this within my software development journey, but experienced it on numerous occasions with my athletic career where I was coached by a number of professional athletes. This in turn enhanced my skills and knowledge and resulted in me becoming a better overall player and athlete. I would assume the same would happen within the development field. Having a mentor would overall increase our knowledge and skillset, allowing us to further walk down our professional journeys.

What I found particularly interesting about this pattern was the emphasis on the give and take nature of mentorship. While apprentices seek guidance from experienced individuals, they then also have the opportunity to mentor others. This creates a culture of continuous learning and collaboration within the software development community as a whole. Additionally, the pattern has reinforced the notion that mastery can be achieved through the guidance and mentorship of individuals who have already walked the path we are trying to take. This allows us to take a step further in our learning journey. Therefore, this has prompted me to actively seek out mentors and engage more proactively within the development community to accelerate my personal learning and growth.

Additionally, while having a mentor can be an extreme plus in our own personal development, we should acknowledge that finding mentors can be challenging. This is due to the fact that some individuals may lack access to established networks or communities. In this case, we can look into alternative approaches to finding a mentor through online platforms or peer-to-peer mentorship programs.

Therefore, the Finding Mentors pattern can serve as a guiding light for us as aspiring craftsman, utilizing the power of mentorship in our professional development. By embracing the core message outlined within the pattern and seeking out mentorship opportunities, apprentices can then navigate through the complexities of software development with purpose and confidence, while also growing and learning for their 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.

Sprint 1 Retrospective

With this being our first sprint of the semester it went well but we had our fair share of issues that we had to work through as a team which will help us make better decisions on our workflow and our team dynamic in the future. I personally worked on five issues throughout the sprint, one of these issues being a team issue and three of the issues being assigned to myself while we still worked as a team while going through our individual issues. These issues included adding the alex js linter to a pipeline and resolving alex js issues, adding a git pod dev environment setup to a repo in the project and moving from commands to bin for a specific repo within the project. Our group issue that we completed included researching frontend development and using our research to create issues for our second sprint regarding the wireframe for the add inventory frontend.

Overall I did not have much trouble with my individual issues within this sprint. My first issue I worked on with the alex js linter was straightforward and I was able to complete it without much delay as there were not a lot of terms flagged by the linter after its implementation to the pipeline. My second issue regarding git pod dev environments took a bit more time which was simply just due to the time it took to fully test the pipeline after a commit but I did not have trouble with implementing the git pod dev environment within the repository. My last individual issue involved moving from commands to bin, this was my most simple individual issue as it mainly consisted of renaming a folder and checking for commands which used the commands folder and changing it to use the bin folder. Our team wide issue of researching frontend and making issues also went well as we all attended the meeting and went over frontend basics together. Links to my individual issues are listed below.

Although we did not have a large amount of problems within this sprint I still feel as though there are things we could work on to improve as a team. One thing we can improve on is our timeline when it comes to reviewing, during the sprint we didn’t review our code until near the end of the sprint which just ended up being inefficient and experiencing this has led to us deciding to review code as soon as possible during this sprint instead of waiting until the end of the sprint in order to notify each other of any issues with our work with ample time to fix mistakes. Another thing I feel as though we all need to work on during sprint two is our use of gitlab as there were points where we got lost in gitlab when making merge requests, branches etc so being more careful when using gitlab will help us all remain more organized in order to ensure we get our code properly reviewed and merged within a timely manner. In my opinion we worked well together given it was our first time working in a team like this and hopefully we can continue to develop our abilities to work as a team throughout the next two sprints.

Alex JS Linter issue: 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/33

Gitpod Dev Environments Issue: 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/32

Move from commands to bin issue: 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/31

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.

Sprint 1

During this sprint it was very much of a learning process there was a lot of things that we had to do to first get used to working with teamsters and also with figuring out the scrum since it was the officially first time we were working on it as a “professional “ setting. As we worked together, we learned what we could do better in the next sprint. One of the things that we changed how we reviewed and worked on things. During some of the issues, we would assign a review and then have the review, review it, mark it as done and then have the original person that worked on it merge. That we learned took more time and there was more margins for error, therefore we decided that the reviewer would review and then they would just merge it and mark the issue as done. Another thing that we talked about improving on the team is communication, over all we had good communication but here and there we would forgot to say something about what we did and we had someone work on it doubled. Another thing we decided to do during this spring is when issues arise about during something we are working on to send it in the group or keep it in writing so that when it is time to come up with issues we have those to go back too. Since this time around when we were done with the sprint and it was time to write new issues we spent a lot of time going back and refreshing especially for the things that were in the initial part of the sprint. As an individual, I am trying to work on your review the issues as soon as it gets tagged. Sometimes it is hard because of my work schedule but I am trying my best so that if something does need to get fixed, that can be done as soon as possible so that we do not get behind. I think that this sprint even though we have more issues it will run more smoothly since we now know how the structure is and how it is supposed to go. A lot of last spring was figuring if the structure was right and if what we were doing was right. But now I feel more comfortable.

This was the issue that was used to plan out the test to make sure that the front end is compatible with and user friendly for this I had to do some research.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/28

Like the one above this was our non program ones, where we researched and came up with ways to enchance the checkInverotryfrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/27

This issue was to move commands and make it bins, we had a few of these and we separated it to team mates, mine was the ReportingAPI

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/21

This issue was set up to work with VSCode in Gitpod, since before we used devContainers, this was to switch it to gitpod

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/32

This was one we worked as in a group and thought that it was going be easier ended up being harder than we thought there for it carried on to the second sprint

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/26

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Going into our first sprint, not only as a team together but as each of our first sprints individually, we were all on the same page with similar expectations. Those being that we would equally know just as little as each other. This mentality was good to have when we ran into issues that we knew ahead of time would take working as a team to solve. We had no idea what those issues would be, just that there were going to be plenty as this was a learning opportunity for each one of us.

Our team was tasked with setting up AlexJS linter and Gitpod extensions in select repositories in Thea’s Pantry. We tackled these tasks by dividing the work between us so that we would work primarily in one repository, with mine being the GuestInfoSytems/GuestInfoFrontend. This only worked for 3 of our members with the 4th having to work in a different repository for each issue. Looking back on this, only working in one repository makes working individually more organized but, as we found out later, would lead to less cross referencing and things being missed.

Other issues our team tackled during the sprint involved frontend testing. First we worked together to do research on open source frontend testing software that could be used in our project. This led us to understand how frontend testing works and what tests should be expected. With this knowledge, we investigated the frontends that were available to design the test that would need to be built in a later sprint.

What Worked Well:

Our team collaboration was by far our strongest feature. With all of us willing to work together and communicate, we were able to make sure that we all stayed on the same page throughout the sprint. Our team stayed in constant communication throughout, even in between meetings. This meant we could communicate times for meetings well ahead of when we wanted to have them, while still being flexible if something came up. When we were working together in a meeting it was either in person or over a discord call. These calls sometimes went on for hours. However, no one let that bother them when it came to getting the work done and sticking around to make sure we all understood what was going on.

What Didn’t Work Well:

The most notable issue we ran into was the weights of our issues. While on paper the issues seemed trivial, what we didn’t account for was the complexities of learning Gitpod and Gitlab. Navigating gitlab and handling pipeline commit message issues lead to the majority of the long nights and ultimately meant that none of our weights should have been a 0.

Team Improvements:

We were all working on the same or similar issues in different repositories meant we could do them together simultaneously. This led to all of our work this sprint being done during the calls with only minor issues being handled individually. While this made the work way more digestible at the start, it is important that we are able to handle issues individually in the future when we have to work on issues that don’t all align with each other’s. 

Person Improvements:

I noticed that a lot of, if not all, of my questions were answered in the documentation provided in the repository I was working in. Moving forward I am going to do better at fully looking through the documentation and files to get a better understanding of the project and how to approach issues.

Gitpod Issues:

Setup Gitpod environment and settings for GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/85

Issue to change commands to bin in GuestInfoFrontend was fixed prior to the sprint:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/82 

Worked on adding the AlexJS linter to the pipeline for GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/81 

Researched open source frontend testing software:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/86

Designed tests for GuestInfoSytems/GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/87

Designed tests for InventorySystem/CheckOutGuestFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/36 

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

Sprint 1 Retrospective Blog

As the first sprint EVER, it went very well, and it provided significant learning opportunities.

Our team exhibited strong collaboration throughout this initial phase. Effective communication was a cornerstone of our approach, enabling us to schedule both online and face-to-face meetings efficiently. A testament to our collaborative spirit was achieving our target of completing more than 75% of the tasks by the sprint’s end. This success largely stemmed from our commitment to weekly in-person meetings, fostering a united team environment crucial for addressing new challenges and workflows.

Despite these positive aspects, our journey was not devoid of hurdles. We encountered several setbacks, primarily due to our collective inexperience with GitLab and its workflow processes. Initially, we struggled with navigation, issue postings, and branch creations, leading to confusion and delays. Our approach to merge requests and the subsequent review process also proved problematic, culminating in merge conflicts and pipeline failures due to our wait-until-the-end strategy.

In light of these challenges, we aim to refine our approach in the upcoming sprint. We plan to create a “Workflow tips” document, compiling our experiences and solutions from this sprint to circumvent similar obstacles in the future. We intend to adopt a more proactive review process for issues and streamline our approach to merge requests, ensuring they align with workflow requirements.

Reflecting on the obstacles I encountered this sprint, there are several areas for personal improvement:

Enhancing GitLab Skills: I recognize the importance of becoming more proficient with GitLab. I intend to invest effort into understanding its intricacies, especially concerning branch management, handling merge requests, and connecting issues. I plan to utilize online resources, seek guidance from tutorials, and lean on my peers for support to enhance my competency.

Strengthening Communication: Acknowledging the need for improvement, I aim to enhance my approach to communication. I will take initiative to seek out feedback more actively and clarify doubts promptly with team members and mentors, aiming to resolve issues before they escalate.

Boosting Organizational Capabilities: I understand that better organization is key to avoiding past mistakes. Therefore, I am committed to honing my organizational skills, particularly in keeping track of my tasks, associated merge requests, and issues. Employing project management tools or maintaining a personal task tracker will be instrumental in keeping me in sync with the team’s goals and deadlines.

Links to the issues covered in this sprint:

Create Integration and Pipeline

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/integration/-/issues/1

Settings and extensions previously located in the dev container should now be transferred to .vscode/settings.json and .vscode/extensions.json within the Gitpod environment, as outlined in the .gitpod.yml documentation. Furthermore, developer commands should be moved from the commands directory to bin to align with standard Linux conventions, necessitating updates in script paths and .gitlab-ci.yaml environment variables. Additionally, integrate the AlexJS linter into each project’s pipeline and the bin/lint.sh script, ensuring all documentation is checked and updated accordingly.

Familiarize ourselves with guestInfoFrontend to understand what goes into CheckoutGuestFrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37

This activity served as an introduction to the primary objectives of sprint 2. During this phase, we collectively reviewed the current wireframe for the checkout guest front end to familiarize ourselves with the anticipated design layout.

Refactor commands folder to bin

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/gitlab-profile/-/issues/69

This process entailed establishing a bin directory within the project and transferring three scripts from the template project into this new folder. Following this, I conducted tests on each of the three scripts to verify their functionality.

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.

Building Skills with “Breakable Toys” Week-6

Cultivating Skills in a Safe Space:

“Breakable Toys,” a pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, advocates for the creation of personal projects or ‘toys’ that can endure failures. These projects offer a sandbox for experimentation, where learning and mistakes occur without the high stakes of a professional environment. This pattern underlines the significance of having a personal space to apply and test new skills and knowledge in a tangible, yet forgiving, setting.

A Concept That Inspires:

While I am yet to embark on a professional career in software development, the idea of “Breakable Toys” strikes a chord with me. It appeals to the part of me that believes in the power of hands-on experience and learning through doing. The notion of constructing a personal project where the risk of failure is not only permissible but encouraged, is both liberating and exciting, especially for someone preparing to enter the tech industry.

The Freedom to Experiment:

What I find most intriguing about this pattern is the emphasis on the freedom to experiment, innovate, and yes, even fail. In the realm of these personal projects, the usual barriers and fears associated with failure are reduced, paving the way for creativity and exploration. This approach makes “Breakable Toys” not just a learning exercise, but a crucible for innovation and self-discovery.

Anticipating Its Impact on Learning:

The concept of “Breakable Toys” has already begun to shape how I envisage my approach to learning and development in software engineering. It reinforces my belief in the importance of engaging in personal projects as a fundamental part of my learning journey. This hands-on practice will be key to transforming theoretical knowledge into practical expertise.

A Balance Between Play and Purpose:

While I am enthusiastic about the potential of “Breakable Toys,” I also recognize the importance of balancing these personal explorations with goal-oriented learning. It’s essential that these projects are not just about exploration but also about advancing specific learning objectives or developing particular skills.

In conclusion, the “Breakable Toys” pattern presents a compelling approach for anyone aspiring to grow in software development. It highlights that mastering this field involves not just structured learning but also unstructured, creative experimentation. By building and experimenting with personal projects, one can cultivate a deeper understanding and a more versatile skill set, all within a context where failure becomes a stepping stone to innovation and mastery. This pattern celebrates the idea that sometimes, the most valuable learning experiences come from the freedom to break things and learn in the process.

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 Retrospective

Sprint 1 Retrospective

Introduction

  • In the first sprint we were mostly focused on learning the ropes of gitlab and getting familiarized with the sprint structure.
  • This sprint lasted for 5 stand ups which is equivalent to 2 and ½ weeks. This ended up feeling a bit cramped considering the amount of learning that was necessary for this process.

Links to Activity on GitLab

Reflections on the Sprint

What Worked Well?
  • In this sprint I found that communication as a group was key to our success. Any problems that we faced were made much easier when we tackled them as a group instead of alone. I think that our review process was good and we just need to make sure we keep logs of these reviews in the appropriate discord channel.
What Didn’t Work Well?
  • I think that the main thing that we struggled with was learning how to use this new environment and process. I think that this caused lots of issued especially with multiple people working in the same projects and all being confused about what to do, This lead to issues with people creating branches in the wrong issues as well as people accidentally doing issues for other teams. I personally struggled with making sure the right merge request was linked to the issue and will try to improve this for the next sprint.

Given the detailed account of your Sprint 1 Retrospective, let’s complete the remaining sections with reflective insights and forward-looking statements based on your experiences and observations.

Improvements for Team Performance

The team’s ability to communicate and tackle problems collectively was a strong point during this sprint. However, the transition to using new tools and processes highlighted several areas for improvement. To enhance our team performance in future sprints, we propose the following changes:

  1. Enhanced Onboarding for New Tools: Given the difficulties encountered with GitLab and related tools, a focused session or resource compilation on these tools at the sprint’s start could mitigate confusion. This could include tutorial links, common troubleshooting tips, and a Q&A session.
  2. Clarification of Roles and Tasks: To prevent overlap and confusion, especially in a multi-person project environment, clearly defining roles and tasks at the sprint planning meeting could ensure smoother operation. This might involve assigning specific issues to individuals or small groups and establishing clear ownership of tasks.
  3. Streamlined Communication Channels: While communication was strong, ensuring that all discussions, especially those related to problem-solving and decision-making, are logged in an accessible and organized manner (e.g., categorized Discord channels or a dedicated project management tool) would help maintain clarity and continuity.

Personal Improvements

Reflecting on my personal challenges during this sprint, specifically around managing merge requests correctly, I see valuable opportunities for growth:

  1. GitLab Proficiency: I will dedicate time to deepen my understanding of GitLab’s workflow, focusing on branch management, merge requests, and issue linking. Online resources, tutorials, and peer assistance will be valuable in this learning process.
  2. Proactive Communication: To prevent and swiftly address any uncertainties or errors in my work, I commit to being more proactive in seeking feedback and clarifications from team members and mentors.

Organizational Skills: I will improve my organizational skills, particularly in tracking my tasks and their related merge requests and issues. Using project management tools or personal task trackers could help ensure that I am always aligned with the team’s objectives and timelines.

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.