In Sprint 3, I did not have a specific personal task. Instead, the sprint was primarily spent working together to fix issues that were generated in Sprint 1 and completing outstanding tasks from Sprint 2. As a recap, in Sprint 1, my task was to add a new date field to the backend API to indicate when a new account was created. In Sprint 2, my task was to modify all endpoints to accept access tokens so that the system could verify whether the request was being made by an authorized user or not.
What was best for me in Sprint 3 was being able to fix bugs that were present, which gave me better insight into the general structure and functionality of the system. Better understanding of backend behavior, especially in how to apply access tokens and authorization, I gained a lot of experience in backend development. What did not work best for me was when we did a merge request, the pipeline failed because of lint comments and tests. My teammate Sean and I were so confused about why the test failed in the pipeline. The error was in an endpoint that we did not even touch when working on our tasks. This is not ideally how I wanted to end the Sprint, however, we did not have enough time to fix this issue.
In general, I believe we worked quite well together as a team. My team was effective at sprint planning and working on each team member’s task well. All members of the team were good at reporting what they had accomplished every week of the sprint. I liked that my team members were always there to provide feedback every week and also helped me when I was not sure how to go about doing my assignment. As we have come to the end of the semester, I honestly do not have much to say about my team improving. In the future, I hope that each team member continues to improve in their personal tasks in their future workplaces where they need to work in a group.
Since Sprint 3 involved less outright ownership and more integration and collaboration work, I found my experience closely relating to the “Be the Worst” pattern in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The “Be the Worst” approach tells programmers to specifically put themselves in situations where they are the least experienced or the least able member of the group. The idea is that this positioning optimizes for growth by allowing you to learn from more experienced colleagues, be challenged by high expectations, and learn good habits by watching and collaborating with others.
I chose this pattern because my experience in Sprint 3 repeated its underlying message. Rather than concentrating on completing work on new tasks, I was deeply involved in teamwork, reviewing and debugging code that I did not write, learning unfamiliar parts of the system, and completing work that demanded a broader view of the backend infrastructure. This made me consider how valuable it is to be in situations where you’re pushed to learn by being around more experienced or otherwise capable coworkers.
From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.