Category Archives: CS-448

Sprint 2 Retrospective

In our second sprint, the team made important progress on a variety of tasks related to the reporting backend, integration, and documentation. The specific work items we addressed included updating npm packages, improving documentation in the reporting backend, setting up Gitpod permissions, implementing hot-reload functionality with Nodemon, composing Docker files, verifying the testing suite, configuring linters and the pipeline, and fixing a build script. Overall, I feel our team had better communication and a more fair approach to splitting the work this sprint.

Reflection on What Worked Well
One of the key strengths of this sprint was the increased level of communication within the team. We made a better effort to stay in sync, share updates regularly, and support each other when needed. This led to a more collaborative and efficient workflow, as we were able to identify blockers early and provide assistance to unblock each other’s progress. I’d say that a fair distribution of work was also a positive aspect, as we made a combined effort to split the tasks more evenly and ensure that everyone had a manageable workload. This allowed us to make steady progress throughout the sprint, rather than having a last-minute crunch.

Reflection on What Didn’t Work Well
While we did see improvements in our progress flow compared to the previous sprint, there were still periods where a significant amount of work was left until the final week. It gave a bit of pressure and gave an increase in the risk of missing deadlines or compromising on quality. Additionally, the team decided not to go forward the Kubernetes with Docker Compose YAML approach, as we don’t currently have Kubernetes set up. Instead, we focused on consolidating all the API Docker files into a single root deployment. The linter and extension setup was also split across multiple issues, which could have been better organized.

Reflection on Changes to Improve as a Team
Moving forward, we should aim to distribute the work more evenly across the entire sprint duration to maintain a more consistent flow of progress. This may involve better planning and task estimation at the start of the sprint, as well as more frequent check-ins and adjustments throughout. Additionally, we should continue to keep our commit messages as clear as possible, especially for merge commits, to ensure the project history remains easy to follow.

Reflection on Changes to Improve as an Individual
As an individual, I could have been more proactive in checking in with my teammates and offering assistance, even if it’s not directly related to my assigned tasks. I want to make sure I’m staying aware of the overall progress and roadblocks faced by the team, and I can provide support where needed. Additionally, I will learn and do what it takes to be better to complete my individual tasks as early as possible to avoid last-minute stress and make sure we meet our sprint goals.

Work and Work Products
One of the key work products I contributed to this sprint was the update to the npm packages in the reporting backend, as well as the improvements to the documentation for recent changes. I also collaborated with Issac on writing documentation for the reporting backend and composing the Docker files. While I was involved in the initial stages of configuring the linters and pipeline in the reporting integration, Victor and Hieu took the lead on those tasks as they were more closely related to their other assigned issues.

To speak upon the work and work products we are producing, we faced an issue with the guest info frontend not working due to a local host problem, and we worked to set up a solution where the application can check if it’s running in Gitpod and query the URL accordingly. We also identified the need to have a more stronger approach to setting up environment variables, rather than hardcoding them.

Overall, this sprint saw improvements in team communication and task distribution, but there is still room for us to refine our process and ensure a more consistent flow of progress. As we move forward, I am committed to playing an active role in supporting my teammates, completing my work efficiently, and contributing to the improvement of our team goals.

April 9, 2024

andicuni

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/70#note_1840354434

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Sprint-2 Retrospective Blog – Team OL-2

As we conclude Sprint-2 and gather for our retrospective meeting, it’s crucial to delve into what went well and identify areas where we can enhance our performance moving forward. Here’s a detailed reflection on our observations and insights:

Reflection on what worked well:

During Sprint-2, our team made notable progress in several areas compared to the previous sprint, demonstrating our ability to adapt and improve:

  1. Enhanced Communication: Communication within the team showed significant improvement, with members actively engaging in discussions, sharing progress updates, and addressing challenges effectively. Our meetings were more focused, productive, and purposeful, leading to better collaboration and decision-making.
  2. Productive Meetings: Our meetings were more structured and goal-oriented, providing valuable opportunities for planning tasks, discussing issues, and aligning on project goals. This contributed to a clearer understanding of individual responsibilities and project progress.
  3. Improved Task Weighting: Adjusting task weights based on our learnings from Sprint-1 resulted in a more accurate reflection of task complexity. This led to a better-balanced workload distribution among team members, ensuring that tasks were appropriately scoped and assigned.
  4. Enhanced Understanding of Project Management Tools: Our team gained a better understanding of using GitLab, particularly the issues and epic boards. This improvement allowed for smoother task management, clearer progress tracking, and better coordination among team members.

Reflection on what didn’t work well:

Despite our progress, Sprint-2 also presented us with challenges and areas for improvement:

  1. Persistent Docker-compose Issues: We continued to face challenges with Docker-compose issues and documentation, impacting task completion and overall efficiency. Addressing these technical hurdles remains a priority for future sprints.
  2. Individual Workload: While collaboration improved, some team members still worked on tasks independently without seeking or receiving sufficient support from others. This hindered overall productivity and efficiency in task execution.
  3. Task Dependencies: Certain tasks were blocked due to dependencies on issues assigned to other teams. This led to delays in task completion and affected our overall task completion rate.

Reflection on changes to improve as a team:

To enhance our team’s performance and effectiveness, we have identified several key areas for improvement:

  1. Promoting Better Collaboration: We aim to foster even better teamwork by encouraging more collaboration, knowledge sharing, and mutual support among team members.
  2. Improving Code Cleanliness and Documentation: Clearer documentation, standardized coding practices, and a focus on code cleanliness will contribute to smoother development processes, easier collaboration, and improved project comprehension.
  3. Effective Task Prioritization and Dependency Management: We plan to prioritize tasks effectively, address dependencies proactively, and communicate any blockers or challenges promptly.
  4. Enhancing Communication Channels: We aim to enhance communication channels within the team, ensuring that information is shared transparently, decisions are communicated clearly, and feedback is provided constructively.

Reflection on changes to improve as an individual:

During Sprint-2, I successfully completed two assigned tasks. The first task involved checking linters and configuring them if necessary for the reporting integration with Victor. This task required running all linters and ensuring that the project passed all tests. I encountered errors related to disallowed words and had to decide whether to reword, add exceptions, or disable certain rules before the relevant code lines to pass the linter tests. Despite these challenges, we completed the task smoothly without any major issues.

The second task was updating documentation to reflect recent changes for reportingAPI and reportingbackend. This included addressing references to the “commands” folder instead of “bin,” adding information about GitPod to Development-environment.md, and updating the outdated Cheat-sheet.md. I successfully completed this task as well, ensuring that the documentation accurately reflected the project’s current state without encountering any obstacles.

As an individual team member, I have identified areas for personal improvement and growth:

  1. Attention to Detail: I recognize the importance of meticulous attention to detail in my work to avoid oversights and ensure thoroughness in task execution.
  2. Proactive Collaboration: I aim to offer more assistance to fellow team members, proactively collaborate on tasks, and share knowledge and expertise.
  3. Effective Time Management: Prioritizing tasks effectively, managing time efficiently, and communicating any challenges or delays promptly will contribute to smoother task execution and improved productivity.

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.

Sprint Retrospective Blog #1

Hello everyone, I’m Abdullah Farouk, for those who may not be familiar with me yet, and I’m here to document my second sprint retrospective blog for this semester. Let me begin by saying how impressed I am with our collective efforts in adapting to these issues; we’ve managed to go  through various changes very nicely. While there’s certainly room for improvement across the board, I want to say we have successfully navigated through this long sprint. This sprint went deeper into our project which is the libre food pantry. The first thing we did in the beginning of the sprint was weighing the different issues and breaking some epics into smaller issues and assigning it to our team, just like we did in the last sprint.  Then, we prioritized these tasks and started working on them. Personally, I found class time to be particularly productive, allowing me to get most of the issues done, with the support of my teammates. Obviously, there were moments when there were challenges, but having my teammates by my side proved to be helpful. Additionally, I want to say I prefer in-person meetings over virtual ones; the presence of one another helps me be  more productive, as opposed to interacting only through computer screens. I would definitely say that this sprint went better than sprint-1, everyone was more involved because we knew what we had to do in order to finish the semester. Our work was more evenly spread and we did not have any major hiccups or challenges that we couldn’t figure out as a group.

I feel like we fixed our issue of not knowing how to weigh the issues properly, compared to the first sprint. I downloaded discord on my phone so I was responding more to my classmates outside of class time, which is a BIG improvement from last semester. One thing we still need to put some more work and effort into is adding a description to some of the issues that we created. It was still a little difficult for me to figure out what they wanted me to do just from the title, so I had to ask a classmate to double check. I hate asking people for help on things that should be more clear, so that’s one thing we need to be better at in the next sprint.

Other than those minor issues, I think me, and the team did a great job going through these issues and completing them on a timely basis. To improve as an individual, work on these issues gradually. I took spring break for granted, when I should have finished at least the issue that I was working on so I don’t hold my team back. To improve as a team, I think we should start adding a description of the issue under the title just so we don’t get confused and be more organized I would say.

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

  • Verifying that ReportingAPI has correct extensions and linters

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/68

  • Verifying that ReportingBackend has correct extensions, linters, and pipeline stages

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

  • Examine GuestInfoFrontend with its wireframe to see if there is any helpful code that can be shared

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/122

  • Research functionality of “nodemon” and how to properly integrate it

From the blog CS@Worcester – Farouk's blog by afarouk1 and used with permission of the author. All other rights reserved by the author.

The Apprentice’s Superpower!

Hey Everyone ! As a computer science student embarking on my journey towards becoming a software development professional, the pattern “Unleash Your Enthusiasm” from the Apprenticeship Patterns book has matched deeply with me. This pattern emphasizes the importance of embracing and expressing the excitement and curiosity that often characterize the early stages of one’s career.
The pattern highlights the interesting attributes that apprentices bring to their teams, such as a fresh perspective, diverse ideas, and an exciting drive for learning. It acknowledges that while this level of enthusiasm may be seen as rare or even risky by more experienced team members.
What I found particularly thought-provoking about this pattern is the way it challenges the common tendency to conform to the norms of a team or organization. The pattern encourages apprentices to resist the urge to suppress their enthusiasm and instead to embrace it as a valuable contribution to the collective intelligence of the group.
Moreover, the pattern’s weight on the diversity of thought that enthusiastic apprentices can bring to a team resonates with my understanding of the importance of diverse perspectives in problem-solving and innovation. As I progress in my studies and eventually enter the workforce, I am eager to leverage my background and mindset to offer new upcoming solutions and challenge the current state.
In my own context, as a computer science student, I can see the value of this pattern in the classroom, where I can actively engage with my peers and professors, offering new ideas and questioning established practices. I am also excited to bring this mindset to any internships or entry-level positions I may pursue, with the goal of not only accelerating my own learning but also contributing to the growth and success of the teams I work with.
Overall, the “Unleash Your Enthusiasm” pattern has inspired me to embrace my natural curiosity and excitement for the field of software development, while also modifying that enthusiasm with an understanding of the importance of navigating team dynamics and building strong relationships with my colleagues. As I continue on my apprenticeship journey, I am committed to maintaining this balance, using my enthusiasm as a catalyst for learning and growth, and ultimately, becoming a valued contributor to the software development community.

April 7, 2024

andicuni

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

For this week’s blog, I decided to discuss the pattern from Chapter 2 called “Unleash Your Enthusiasm”. This pattern discusses the enthusiasm for learning that many software engineering apprentices experience and how you should show it because, at this point in your career, you can provide unique qualities. This section discusses the situation where you may find yourself holding back because you may find that you have more enthusiasm than your colleagues. This is because there may be pressure to conform to the norm whenever you work on a team. In addition to this, many teams mainly focus on delivering the next product or improving on the aspects of the development life cycle. It also explains the risk of exposing your enthusiasm to an established team. In this situation, the text explains if the morale of the team is low or if they are not very welcoming to newcomers, you might make a poor impression. In this case, the text mentions that the advice in the section should not be applied blindly because you need to consider team dynamics.

The reason that I decided to pick this pattern is that I have never thought of concealing or holding back my enthusiasm for my craft. Every team that I have gotten the pleasure of joining in some way really valued my enthusiasm and the skills that they could learn from me. I have always been on a team where we all encouraged each other to learn from someone else on the team. Needless to say, I have never thought about the possibility of making a bad impression because of my enthusiasm for the task. In hindsight, I can see how exposing your ignorance of a topic can upset a team that values competence over enthusiasm for learning. I do think this quote from the text holds truth to it because of my own experience: “it is actually healthier for a team to consist of people with varying levels of experience”. Tech is a fast-paced industry so everyone is forced to keep up with new trends. A team that has a diverse set of skills at different levels is bound to create a healthy environment. With that being said, I can’t say that I disagree with anything from this section but I will be more aware of unleashing my enthusiasm on certain teams.

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.

Reading List

As the title of this section suggests, it is solely focused on creating a reading list. On the surface, this section has to be the most straightforward in the book, and yet the one I practice/experience the least. With the ever-growing importance of broadening my learning through reading, I wanted to focus on this section as it feels like the obvious place to start.

Section Summary:

The idea of creating a reading list seems simple, yet so open-ended that it may also feel impossible. The section focuses on ways you can expand your reading list without feeling so overwhelmed with the endless knowledge that is available. When it comes to learning what books are important and useful enough to add to your list, it makes sense to ask mentors. Other online sources can offer reading lists from other people which may give a good insight of which books should be added to your list. The third way of finding useful sources was to pay attention to which sources are commonly referenced and cited in other readings. Seeing the same book cited multiple times can be a great indicator that it is an important book to add to your list. 

Reflection:

Having a list of which books to read next is a great way to stay organized however, having a reading list will also keep track of what books you have read. One of the points the reading made was that this list is also a reflection of your past reading habits. My list right now would reflect awful reading habits, and I must change that. When I first started to read through the patterns at the start of the semester I saw the entire chapter dedicated to reading and how important it was to broaden my education and craft with the use of reading. Starting a reading list from scratch felt like it was going to be an impossible task, with zero clue where to start or what books would be worth my time. With simple solutions provided by the reading, such as looking for likeminded lists from other people, asking mentors, and paying attention to the cited sources, I now feel way more comfortable with being able to develop my reading list.

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

CS-448 Sprint 2 Retrospective

Merge branch ‘verify-pipeline-tests’ into ‘main’ (490e4d29) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / General · GitLab

Last sprint teams were focused on changing the pipeline tests and extensions for certain repositories and so this sprint teams were assigned to verify the correct linters and extensions were added as well as running the correct tests when committing the changes to Gitlab. ReportingSystem General does not build a Docker image nor does it have release number. For this repository, we only need to run the linter pipeline tests and ensure that they all passed with no errors.

Merge branch ‘verifying-that-reportingsystem-10’ into ‘main’ (e7755051) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / Documentation · GitLab

Like ReportingSystem General, the Documentation repository did not need to run through all the pipeline tests in Gitlab such as the build, test, or release stages. This means that we only had the linter tests run through the pipeline when committing any changes to this repository.

Merge branch ‘jlee1999/verifying-that-generatewcfbreportfrontend-38’ into ‘main’ (6e5d198e) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / GenerateWCFBReportFrontend · GitLab

GenerateWCFBReportFrontend is different than the other two repositories that I worked on as it does require pipeline tests such as build, test, and release. Originally, the tests were passed with a warning, which was okay at the time, but our goal was to ensure all the tests passed with no warnings.

Files · jlee1999/research-functionality-122 · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoBackend · GitLab

Once I completed the verification related issues in our sprint backlog, I shifted focus on the first steps of hot reloading GuestInfoBackend servers for development mode. First, I researched what the command “nodemon” is and how I can properly integrate it into the code. This command allows for the server to restart after any changes are made in the folders specified prior. I created a separate folder in this branch called “express-example” with a simple JavaScript file as well as the package.json file and any other required files needed. This allowed me to mess around with the functionality of the command without completely rearranging the main branch.

feat: merge branch ‘jlee1999/edit-scripts-to-allow-123’ into ‘main’ (f145cdc1) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoBackend · GitLab

After messing around with nodemon in the sample branch, I was ready to implement it to the main branch of GuestInfoBackend. I was having trouble making sure the nodemon command works while also ensuring the pipeline tests passed. If I was able to get the pipeline tests to pass then the functionality of nodemon was not working, and if nodemon was working then the pipeline tests would fail. I was struggling trying to figure out why this issue kept occurring, but after a while I was able to get both the functionality to work along with the pipeline tests to pass simultaneously. The cause of this problem was because the repository was using both npm and yarn when building the pipeline tests which caused problems. I decided to stick with strictly npm for the repository which then fixed the issue.

Files · update-checkinventory-29 · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

I did not get to work too much on CheckInventoryFrontend this sprint but was able to get a general idea of some issues that could be arising. I noticed that this repository also has both npm and yarn together which has caused some issues with the pipeline tests. Hopefully the next sprint my team and I can solve this issue and provide a simple and working frontend for the InventorySystem.

This was the second sprint for the team, and I believe that it went better this time around compared to the first sprint. I felt more comfortable with the whole set-up of our sprints and the team was able to get the work done we needed to. Around half of the issues this sprint revolved around verifying pipeline tests and extensions in repositories that will help in the future to allow people to focus on bigger parts of the project with more ease. While I worked on 3 of the issues around verifying pipeline tests, our team had 5 overall which made it easy for us to communicate what worked for the other issues. The continued work in Gitpod/Gitlab has gotten me even more comfortable committing changes along with merging branches. There was only one issue that I messed up the commit message when squashing the commits for GuestInfoBackend, but it did not affect the overall functionality of the repository and the pipeline tests were still able to pass.

While I would like to say everything worked out perfectly during this sprint, it would be a lie. There were some small hiccups in progression through this sprint, but I would say it was less severe than the issues holding us back last sprint. I believe the higher level of comfort in the progress helped allow the team to get passed any hiccups. The biggest issue I was running into was during the GuestInfoBackend issue about hot reloading the servers. I touched on it earlier, but the combination of npm and yarn in the repository was causing me the most issues during this sprint, but I was able to solve it before the end of the sprint which was the goal.

Overall, I believe the team can still improve on communications in some respects, but I would say we were all on the same page more often this sprint compared to last. I would make sure I would notify the team in Discord about any issues I was running into or if I needed a review on a merge request, and the team would be able to see it and help continue the progress of the sprint. I did a better job this sprint focusing on one issue at a time rather than trying to work on multiple issues at once.

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

sprint 2 retrospective

During the course of this sprint, I spent most of my time looking at the ReportingBackend repository to figure out what was going wrong with the testing suite. I also had assigned myself to configuring the pipeline specifically in ReportingAPI with the linters, but unfortunately was unable to complete this issue because the team responsible for actually adding the linters to the repository was not able to push their changes before the sprint ended. I continued to act as the scrum master for the team, taking an active approach to making sure everyone is doing work, getting credit for their work, and setting up meetings when necessary. I had to help out a bit with other team member’s issues as well, providing some guidance.

Verify the Testing Suite works: Investigate the testing suite and see if I can get it to work, or at least figure out the magnitude of the problem. I applied a couple of fixes (one of which was in the build.sh script that I had a separate 0 weight issue created for, as I had already found the bug and fix prior to the sprint starting.), but it seems like the issue transcends the testing suite and is moreso an issue with the build process with the server.

This sprint was pretty rough, if I’m being honest. For what we did well, our communication overall improved, and the team was better able to utilize GitLab for their work. I think that everything on GitLab was better organized and most of the issues had better descriptions on them than what we had last sprint, and the weight assigned to issues seemed fairly accurate all things considered, aside from the testing issue (which I did spend a lot of time on). We also did work with each other more than we did on the last sprint.

Most of the issues that were assigned to our team were rushed together during the last week of the sprint (from my perspective at least, there may have been some confusion with pushing to GitLab). As such, we weren’t able to get to all of the issues, and only got 14 weight out of the 24 weight assigned to our team fully merged in. I was offering support during the whole sprint, but it seemed like team members were not able to coordinate into a meeting at the same time for most of the sprint. I don’t really have a great reasoning for this, it seems like things weren’t being done until the time was very short to were we couldn’t get everything done, taking all of our other schoolwork into account.

Ultimately, I think for next sprint our team really just needs to work on spreading work out during the entire sprint rather than getting things done last minute. We should also work on coordination and being more present, as when anyone asked if we wanted to do a meeting, the team would all say they were available and no one would take the initiative to actually begin the meeting. Part of that is on me as scrum master, but ultimately we should be willing to meet without having everyone on board if we are working on specific issues.

I was able to spread out my work fairly well as an individual, but I can’t say the same for other team members, and so as scrum master I should be more active in making sure everyone is doing their work not just so the project moves forward, but so everyone gets the credit they need for the course.

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.

Draw Your Own Map

The draw-your-own-map pattern talks about how people should take control of their career paths and not rely on others to define their path. This pattern talks about identifying the next logical steps, visualizing how to achieve those steps, and continuing to evaluate their goals and values. Draw-your-own-map pattern suggests that getting help from like-minded people and being open to adjusting one’s map to any changes that came up. This pattern shows stories about people who go into programming despite challenges from employers and orginizational limits. Draw-your-own-map encourages people to set a specific goal rather than setting a goal that isnt reachable. That step not only helps provide feedback but it also makes you seek guidance from like-minded people, those people can give you resources and support when trying to achieve your goals. One of the key ideas of this pattern is flexibility, it supports the idea of one’s mind to keep reassuring themselves that it’s okay to make changes. This pattern promotes an approach to career development and make sure to empower people to find their way through there careers with a purpose.

I thought this pattern was interesting because it encourages people to be creative and not rely on other people to define our paths, it should be our decision. I also thought the steps that the pattern talks about was very helpful, it’s important to set realistic goals so that you don’t overwork yourself to reach that goal. Visualizing the steps to achieving those goals also help make sure you don’t rush through the process and able to have a set plan. Evaluating your goal and values are also important as you go on to make sure that you can still reach your goal and be okay with any changes that come. This pattern has changed the way I think about achieving my goals, I know now to set a more realistic goal for myself and not be scared to get help from people who think like me. I don’t disagree with this pattern because I feel like this will help a lot of people with reaching their goals and make them think more realistically while getting support from others.

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.

Expand Your Bandwidth, Expand Your Mind

In the fast paced Software Development field, staying ahead is not just advantageous but essential. Yet, many of us tend to find ourselves stuck in a rut, focused solely on the task at hand and neglecting the broader landscape of knowledge and innovation. The Expand Your Bandwidth pattern emphasizes the importance of continually expanding our knowledge and skills beyond just the day to day tasks we complete. Additionally, the importance of actively seeking out new information and participating in various learning opportunities to help accelerate our professional growth.

What I found particularly interesting regarding the pattern is the notion that we all want to achieve mastery following the long road, but achieving that mastery level is more than just mastering a specific technique or technology, but rather about cultivating a broad and adaptable skill set. The pattern also presents an analogy for learning through a straw and a fire hose. By immersing ourselves in a fire hose of information, while it may be overwhelming, is incredibly empowering. Therefore challenging the notion of compliance and encouraging us to continually learn, explore, and experiment.

After reading more about this pattern, it has changed the way I think about my approach to learning and professional growth. Previously, I tended to focus solely on completing immediate tasks, projects, and work, ignoring the broader landscape of knowledge and innovation. However, this pattern has inspired me to adopt a more expansive mindset and go out of the box to seek different opportunities for learning and growth. 

While I embrace the message from this pattern, I do think it is important to limit how much information we try taking in all at once. If we don’t manage all the information properly or carefully, it could lead to an information overload and overwhelm or stress us out.

With this being said, the Expand Your Bandwidth pattern helps serve as a powerful reminder of the always changing and evolving field and the importance of continually trying to learn more and more to increase our skillset. By embracing this pattern, I am confident that I will not only enhance my skills as a developer but also create a mindset of lifelong learning and adaptation, which is essential for success in our dynamic field.

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