Tag: @CS-448

• Sprint 2 Retrospective

  During Sprint 2, our team focused on improving both our workflow and communication while continuing to develop our project. Compared to Sprint 1, this sprint felt more organized, and we were able to complete all assigned tasks on time. This retrospective reflects on what went well, what could be improved, and how I can grow both as a team member and as an individual.

  What Worked Well

  What worked well during this sprint is that everyone completed their assigned tasks on time. Compared to the first sprint, our communication improved significantly. We were more consistent with updates and clearer about responsibilities, which helped avoid confusion. Even when we had to work remotely or adjust schedules, the team stayed accountable and ensured that all deliverables were completed. Additionally, we received good feedback from the professor, which confirmed that we are moving in the right direction.

  What Didn’t Work Well

  One of the main challenges during this sprint was coordinating schedules. Since everyone had different availability, we had to rely more on remote meetings, which were not always as efficient as meeting in person. While we were still able to complete everything on time, communication could sometimes feel delayed. However, despite these challenges, the team remained responsible, and everyone fulfilled their role, which ultimately allowed the sprint to succeed.

  Improvements as a Team

  To improve as a team, we could focus on better scheduling and planning meetings in advance. Setting a fixed weekly meeting time could help ensure that everyone is available and reduce the need for last-minute coordination. Additionally, using clearer communication tools or setting expectations for response times could help us stay even more aligned. Improving documentation of our work could also make it easier to track progress and support collaboration.

  Improvements as an Individual

  As an individual, I can improve by being more proactive in communication. Even though I completed my tasks on time, I could provide more frequent updates to keep the team informed. I can also work on better time management to avoid any last-minute pressure and contribute more actively during team discussions. Being more engaged in planning and helping others when possible would also strengthen my role within the team.

  Apprenticeship Pattern: “Breakable Toys”

  The pattern I selected is “Breakable Toys” from the Apprenticeship Patterns book. This pattern encourages developers to build small, experimental projects where they can freely explore ideas, make mistakes, and learn without fear of failure.

  This pattern is relevant to my experience during the sprint because there were moments when I hesitated to try new approaches, especially when working on features that affected the main project. I focused more on completing tasks correctly rather than experimenting or exploring alternative solutions. If I had applied this pattern, I might have created smaller test versions of my work to better understand different approaches before implementing them in the main project.

  Having read this pattern earlier, I would have been more confident in experimenting and learning through trial and error. Instead of worrying about making mistakes, I would have used them as opportunities to improve my understanding. This approach could have helped me develop stronger problem-solving skills and contribute more innovative ideas to the team.

  Final Thoughts

  Overall, Sprint 2 was a success. We improved our communication, completed all tasks on time, and received positive feedback. While there are still areas to improve, especially in scheduling and communication, the team is progressing well. I look forward to applying these lessons in the next sprint and continuing to grow both technically and professionally.

  GitLab Link #1 : I implemented my assigned feature and pushed the completed code to the repository, updated the issue tracker with progress and marked tasks as completed once finished.

  https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/-/boards?show=eyJpaWQiOiI4IiwiZnVsbF9wYXRoIjoiTGlicmVGb29kUGFudHJ5L2NsaWVudC1zb2x1dGlvbnMvdGhlYXMtcGFudHJ5L2lhbXN5c3RlbS9pYW1hZG1pbnBhbmVsIiwiaWQiOjE4NTkwMTUzMH0%3D

  April 9, 2026

  @CS-448, @Sprint-2, CS@Worcester

  ---

• Sprint 1 Retrospective

  Hi everybody! Welcome to my first Sprint review blog post.

  Ever since the start of the semester my team and I got along well with each other. We started with some ice breakers and getting to know one another, and then moved into discussing our team agreements. What I liked about our team is that everybody felt comfortable sharing their opinions and thoughts during our discussions, and it felt like a very inclusive environment. I asked many questions during this sprint and learned a lot from my teammates, even small things like different ways of thinking, terminology, and new tools. I also liked the small discussions with the professor to make sure our questions were answered and that we were on the right track.

  After the first week of the sprint, I felt like we didn’t have many new tasks to add and we started taking things a bit slowly. That might not have been a problem if it wasn’t for the snow days when we didn’t meet, which slowed things down even more. However, we still managed to finish our jobs on time and received really good feedback for our first sprint.

  One thing we can improve in the next sprint is communication. Even though the atmosphere felt comfortable for me to speak up when I felt lost or didn’t fully understand something, not everyone felt the same way. This made me realize that making people feel included is not just about being talkative during meetings, but also about answering questions that haven’t been asked yet and being aware of where others might feel lost or shy to speak up.

  Personally, I want to improve by being faster with the tasks I am assigned. I sometimes tend to leave things until the last minute. I also had the impression that we had more time left in the sprint, but the sprint review came sooner than I expected. Improving my time management will also allow us to review each other’s work more thoroughly as a team.

  I also appreciated how my teammates contributed during the sprint. Elizabeth was always taking notes during meetings with the professor so we didn’t miss anything important. Ben took over the Keycloak task and explained it to the rest of us so we understood how our work connected. Daniel worked on the UML diagram after finishing his task early, and Jonson offered to help me with Vue.js after finishing his first job.

  Apprenticeship Pattern Reflection: Expose Your Ignorance
  The apprenticeship pattern I selected from Apprenticeship Patterns is “Expose Your Ignorance.” This pattern encourages developers, especially those early in their careers, to openly admit when they do not understand something and use those moments as opportunities for learning rather than hiding their lack of knowledge. The idea behind this pattern is that learning happens faster when people are willing to ask questions and make their knowledge gaps visible instead of pretending to understand everything.

  I chose this pattern because it relates strongly to my experience during this sprint. During many of our meetings I asked questions about things I did not fully understand, whether it was terminology, tools, or how different components of the project worked together. At first I worried that asking too many questions might make me seem inexperienced, but I realized that those questions helped me understand the work better and also opened useful discussions within the team. For example, when we were trying to understand how Keycloak connected with the frontend pages, our team initially overcomplicated the solution. By discussing it openly with each other and with the professor, we were able to simplify our approach and move forward with a clearer plan.

  If I had read and reflected on this pattern before the sprint started, I think it would have influenced my behavior in two ways. First, I would have been even more intentional about asking questions earlier instead of trying to figure everything out alone. Second, I would have made a stronger effort to encourage my teammates to ask questions as well.

  Overall, this pattern reinforces the idea that learning in software development is a continuous process and that admitting what we do not know is actually a strength.

  Here is a link to my Sprint1 commit about the two admin frontend pages, the first allows admin to enter the email of whom the role is being changed, and the second shows the email entered with the role options to select from.

  https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/iamsystem/iamadminpanel/-/commit/4ff48ae29681abaf9cbc961942370800c38426e8

  March 10, 2026

  @CS-448, @Sprint-1, CS@Worcester

  ---

• Apprenticeship Patterns: Rethinking What It Means to Be a Developer

  After reading Apprenticeship Patterns, I see being a software engineer in a different lens. I did get into Computer Science initially because I was really good in science and the salaries were looking great, but I think it is really important for people that are looking to go into the tech industry and create new software, to really understand who you need to become. I believe the book really explains the hardships, importance of focus, humility, being intentional with your learning as you go into the career.

  Before this reading, I viewed growth mostly in terms of learning new technologies or building impressive projects. However, the authors explain apprenticeship as a mindset. The difference between apprentice, journeyman, and master is not about job titles, but about responsibility and focus. The explanation on this progression made me realize that technical ability alone is not the goal but growing in responsibility and having an impact in the community matters just as much.

  The introduction of Chapter 2, Emptying the Cup, I particularly liked. The Zen story about the overflowing teacup illustrates how ego and prior knowledge can block real learning. The reason why I liked it is because it gave me a completely different point of view when it comes to how people perceive themselves in the field when it comes to the skills you build  in the journey. I always saw myself as never knowing enough, being overly humble because of how much there is to know. It was interesting to see that there are also those who have learned multiple languages and frameworks might have it easy to assume competence transfers automatically. But the idea of “wearing the white belt” suggests that real progress requires humility. I guess the imposter syndrome in me serves for something good too.

  Chapter 3’s theme of Walking the Long Road also felt deeply relevant. The authors put a great importance on sustainable motivation and choosing growth over shortcuts. In a field where quick success and high salaries are often highlighted and attracted so many in this field, this chapter reframes success as long-term mastery rather than rapid advancement. It made me question whether I sometimes prioritize outcomes (grades, internships, resume lines) over the depth of understanding.

  The introductions to Chapters 4–6 suggest that accurate self-assessment, perpetual learning, and constructing your own curriculum are essential habits. That idea is both motivating and intimidating. I think that the CS major itself should be teaching the ‘behind the scenes’ part for us to understand the reasoning behind why things are done and the effect they have. It is our responsibility to learn the coding languages on our own. I understand that it could be harder for some people to self-study, but on the other hand you get to pick what you want to be a master in.

  Overall, this reading made me reflect on the fact that becoming a great developer is less about reaching a destination and more about committing to the process of mastery.

  February 22, 2026

  @CS-448, CS@Worcester

  ---