In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Gitlab Descriptions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend : created addBarcodeFrontend under our teams project to work on the scanner page.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/64bc3d4f720e6e8a69bafa709276beff820f719b : I added the scanner onto the frontend page, using a vue library to make it look good.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/200cac8ad4de849c3647b1223d9bc6f7075b8da2: I fixed the layout to how it ended up looking by the end of the sprint, as well as working on some other issues like fixing camera mirroring, and also added logos to the page.

Team Reflection

As this project is the first time I have worked in a team adopting the scrum methodology, I was a little hesitant at first as to how well we would work together, with possible conflicting problems that would only lead to decreased productivity, but the way that it has turned out isn’t like that at all. An important part of the lack of disagreements comes from our collective trust in each other to produce the outcome that we envisioned from the issue that they were assigned. Our issue allowed us to split our team into smaller teams, focusing on separate issues which would eventually connect to fulfill our team’s original project goal. This delegation of tasks to each subteam has allowed us to focus on our own tasks, while also checking in with each other to see how the rest are doing. This frees us of the burden of trying to work over each other to accomplish one thing which I believe would lead to inefficiencies and conflicting ideas. This subteam workflow allows us to dedicate our time and effort to one topic while checking in on the other topics to stay updated and give feedback. 

Although I just mentioned that the subteam system allows us to check in on each other and give feedback, this is somewhat untrue or at the very least an idealized version of what we are practicing. I do feel that I am working well in my subteam, and with my partner we are efficiently approaching our goal, however when it comes time to check in on the other teams, I feel as though I don’t get enough of an idea of the inner workings of what they’re doing to give good, constructive feedback. The same goes for my teammates giving me feedback. I think that is the tradeoff with this system though because it entrusts you with knowing what you’re doing, and I don’t think it’s as detrimental as it could be because each subteam at least has a partner that does give detailed feedback, sacrificing quantity for quality.

Apprenticeship Pattern

The perpetual learning pattern assumes there is always more knowledge to be known and your journey as a learner is never truly over. I selected this pattern because I think the pursuit of knowledge is important to sustain a continued expansion of knowledge and innovation, as well as satisfying a person’s internal sense of accomplishment and fulfillment. The point that this book tries to make about being a software apprentice is that you can become a master within your lifetime, but that doesn’t mean you stop learning. This pattern fits into the sprint because there was never a time I really felt like I fully understood a concept to a point where there wasn’t anything else I could learn by further investigating it or digging deeper. Even in established technologies or languages like HTML or CSS, there are a lot of things that many people may not know and working with it so much means I am more comfortable with it, but it doesn’t mean I am anywhere near mastering it, following this pattern of perpetual learning.

If I had thought of this pattern before the sprint started I would have gone into it more open-minded, knowing that anything I encountered would be surface level and that if I really wanted to I could go down a rabbit hole for each new thing I learned. There’s so much information out there that is almost impossible to get to, especially for me in the time of one sprint. I think to improve as an individual in future sprints, I could go out of my way to learn as much as I can so I can understand what I’m working on as best I can.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

My task for Sprint 1 was to add a new date field that shows when the guest was created into the backend API. In this sprint, I worked closely with my teammate Sean Kirwin as he was working on the backend as well. I had to create a reference to the schema for the date of the first entry in the OpenAPI field. Below is the link to the merge request.

What worked well for me in Sprint 1 was being able to work on a task that I had experience with. I was confident to get what I needed to get done in a timely manner. I also appreciated the fact that I was able to work with one of my team members. 

As a team, I believe we worked well together. My team did a good job with the sprint planning and dividing the roles for each task effectively. Each team member was good at communicating what they had done each week of the sprint. I appreciated that my team members were always there to give constructive feedback each week and also helped me out when I had a question about how to navigate working on my task. A way my team could improve is show the work we did for the week instead of just explaining it. It would help visually. 

This task took me more time than it needed to. As an individual, I could improve my time management when it comes to working on my assigned tasks. Although I had improved my communication with the team throughout the sprint, I think I could do. I did not necessarily have issues with making the changes to the files, however, my partner and I had issues with the merge request. The pipeline kept failing because of the lint-commit-messages, but my partner and I were able to resolve this issue with research. 

The pattern I related to from the Apprenticeship Patterns book was “Learn How You Fail”.In this chapter, it highlights the significance of being aware of your weaknesses and areas of failure. It implies that although learning improves performance, shortcomings and failures endure unless they are actively addressed. The most important lesson is to seek self-awareness about the actions, circumstances, and habits that contribute to failure. Making deliberate choices either to accept and overcome limits or to do better in particular areas is made possible by this self-awareness. The pattern promotes a balanced approach to growth and discourages self-pity or perfectionism.

I chose this pattern because it is closely related to my experience during the sprint. I ran into issues with time management, working with others on code reviews, and managing merge request issues during the sprint. I became aware that I was frequently making the same errors, such as failing to consider edge scenarios or misinterpreting project specifications. I could have dealt with these failure patterns proactively rather than reactively when issues emerged if I had been more deliberate about identifying them early. The “Learn How You Fail” pattern would have helped me take a step back, identify recurring problems, and strategize ways to improve.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/107

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

Evidence of Activity on GitLab

1. Meeting with Customer to Identify Categories
   • A .js file named categories.js was built to help my peers start testing different category structures.
2. Data Extraction for TeaSparty Project
   • The USDA FoodData Central downloadable data was extracted to build a comprehensive database.
3. Database Optimization
   • The original database file was over 3.2GB and contained multiple unnecessary fields.
   • A Java file was developed to remove unnecessary fields such as foodNutrients, nutrients, rank, protein, and their respective IDs.
   • Successfully reduced the database from 3.2GB to 0.7GB, making it more manageable for our project.

Reflection on What Worked Well

1. Customer Collaboration
   • Meeting with the customer to identify category requirements ensured that the project met their needs effectively.
   • The creation of categories.js provided a starting point for peer testing, helping streamline future work.
2. Database Optimization
   • By removing unnecessary fields, the database was significantly reduced in size, improving efficiency.
   • The pre-cleaning process helped identify redundant fields early on, making subsequent steps more manageable.

Reflection on What Didn’t Work Well

1. API Call Extraction Issue
   • Initially, I attempted to extract the database via API calls but encountered a limitation: API calls only supported retrieving 100 items at a time, whereas there were over 100 pages to extract.
   • Researching solutions, I found that automation was the best approach, but due to my lack of expertise in automation, I couldn’t implement it effectively.
2. Challenges in Categorizing Products
   • A Java file was created to categorize all products, but it was crashing due to issues with object field descriptions containing multiple nested quotes.
   • Example issue: "description":"ORIGINAL SWEET & SMOKY BAR \"\"B\"\" \"\"Q\"\" SAUCE, ORIGINAL".
   • As a workaround, I manually cleaned some of the problematic entries but am still looking for a better solution.

Reflection on What Changes Could Be Made to Improve as a Team

• Better Communication
  • Ensuring consistent updates within the team would help synchronize our work and avoid redundant efforts.
  • More frequent check-ins to discuss roadblocks and potential solutions could improve efficiency.

Reflection on What Changes Could Be Made to Improve as an Individual

• Increase Work Hours on the Project
  • Spending more time on the project will allow my peers to see my progress and provide feedback earlier.
• Dependency on Others’ Progress
  • I am currently waiting for Alex to finish the dev container. In the meantime, I am focusing on cleaning the db.json file so I can upload it as soon as possible.

Apprenticeship Pattern: “Expose Your Ignorance”

Summary of the Pattern

The “Expose Your Ignorance” pattern from the Apprenticeship Patterns book emphasizes acknowledging one’s knowledge gaps and actively seeking to learn. It encourages transparency about what you don’t know while making efforts to bridge those gaps.

Why This Pattern Was Selected

During this sprint, I faced challenges with API automation and data cleaning that slowed my progress. If I had openly acknowledged my lack of expertise in automation sooner, I could have sought help from peers or external resources earlier in the sprint. This pattern aligns with my experience because it highlights the importance of being upfront about knowledge gaps and taking proactive steps to fill them.

How This Pattern Would Have Changed My Behavior

Had I followed this pattern earlier in the sprint:

• I would have sought advice from team members or forums on API automation instead of spending excessive time trying to figure it out alone.
• I would have explored existing libraries or tools for handling JSON parsing issues more efficiently instead of resorting to manual cleaning.

Conclusion

This sprint provided valuable lessons in data handling, API limitations, and the importance of seeking help when needed. Moving forward, I plan to improve communication within the team, allocate more time to the project, and be more proactive in addressing technical challenges. Applying the “Expose Your Ignorance” pattern will help me become a more effective contributor in future sprints.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

GitLab Activity

During this sprint, I contributed to multiple aspects of the project, focusing on both collaborative research and frontend development. Below are the key tasks I worked on, with links to the related issues:

1. Issue #26: Created a fake frontend – Designed and developed a simulated frontend to represent the user interface for testing and demonstration purposes.
2. Issue #20: Researched Docker architecture – Collaboratively explored and documented Docker architecture with the team to establish a strong foundation for the project’s infrastructure.
3. Issue #31: Created dummy pages for frontend login redirect – Built placeholder pages to simulate the login redirection process, enabling smoother navigation during development.

Reflection on Performance

What Worked Well

This sprint highlighted some clear wins for both myself and the team. Collaborating on Docker architecture research proved to be an invaluable learning experience. By pooling our knowledge and resources, we quickly gained a better understanding of Docker’s potential for our project. On the frontend, creating the fake frontend and dummy login redirect pages allowed me to apply and refine my skills in UI development. These tasks were particularly fulfilling because they provided tangible progress toward a functional interface.

What Didn’t Work Well

While the sprint had its successes, there were also challenges. Managing time effectively across multiple tasks was one of my personal struggles. For instance, balancing the research on Docker architecture with the development of the frontend required careful prioritization, and I occasionally found myself spending too much time on one task at the expense of another. Additionally, the lack of established workflows for testing the fake frontend made it harder to identify and fix issues early on.

Changes to Improve as a Team

As a team, we could benefit from setting aside dedicated time for pair programming or collaborative problem-solving sessions. This could enhance our understanding of challenging topics, like Docker architecture, and ensure that everyone feels confident in applying what we’ve learned. Regular check-ins or daily stand-ups could also help us address blockers more quickly and align our efforts more effectively.

Changes to Improve as an Individual

Individually, I want to work on improving my time management and task prioritization. Establishing a clear plan at the start of each sprint, with time allocated to specific tasks, could help me maintain better focus. I also aim to proactively seek feedback on my work, particularly when tackling new challenges like Docker architecture, so I can learn more efficiently and avoid unnecessary delays.

Apprenticeship Pattern Reflection

Selected Pattern: “Expose Your Ignorance”

For this sprint, I chose the Apprenticeship Pattern “Expose Your Ignorance” from Chapter 2. This pattern emphasizes the importance of acknowledging knowledge gaps and actively working to address them by seeking help, asking questions, and being open about what you don’t know.

Summary

The pattern advocates for embracing ignorance as a normal part of the learning process. It challenges the notion that developers should appear to have all the answers, encouraging honesty and curiosity instead. By exposing ignorance, individuals can learn more effectively and foster a collaborative environment where everyone feels empowered to grow.

Relevance to My Experience

This pattern resonated deeply with my experience during the sprint, particularly in the context of Docker architecture research. Initially, I felt hesitant to admit my lack of familiarity with some Docker concepts, but collaborating with the team and sharing our findings made the learning process much smoother. Similarly, while working on the fake frontend, I encountered unfamiliar scenarios where seeking guidance earlier would have saved time.

How It Would Have Changed My Behavior

If I had fully embraced this pattern from the beginning of the sprint, I would have been more proactive in asking questions and seeking clarification during our Docker research sessions. I might also have reached out to teammates or mentors for advice on frontend best practices when creating the fake frontend and dummy pages. In future sprints, I plan to actively apply this principle by fostering a culture of openness and curiosity, both for myself and within the team.

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