Category Archives: CS-448

Teaching to Learn: Understanding Through Sharing

Hey Everyone! As apprentices in the making , we spend countless hours absorbing knowledge, honing our skills, and making our craft as efficient as possible. However, the “Share What You Learn” pattern reminds us that true growth lies not just in getting knowledge but also in generously sharing it with others.
The essence of this pattern is fairly captured in the quote from Twyla Tharp: “Look at the luckiest people around you, the ones you envy, the ones who seem to have destiny falling habitually into their laps… they involve their friends in their work, and they tend to make others feel lucky to be around them.” This resonates deeply, as it highlights the equal relationship between sharing knowledge and creating a fulfilling, comfortable community.
Personally, I find this pattern both thought-provoking and inspiring. It goes against the idea of knowledge is a finite resource to be put aside, instead advocating for its free exchange and somewhat of distribution. By sharing what we learn, we not only empower others but also solidify our own understanding. As the saying goes, “When one person teaches, two people learn.” I’ve never resonated with a quote as much as that one. Teaching forces us to organize our thoughts, anticipate questions, and articulate concepts in a clear manner – a process that always deepens our understanding.
Moreover, this pattern has influenced my thoughts on our field. I now recognize that true mastery extends beyond individual expertise; it follows the ability to communicate effectively and uplift others. The pattern explains how a skilled craftsman who fails to share their knowledge ultimately limits their impact, while one who embraces this pattern becomes a trigger for collective growth, leaving a lasting legacy that goes past their individual contributions.
One aspect of the pattern that I agree with a lot is the perspective of knowledge sharing. It serves as a reminder that not all lessons are ours to share, particularly those that may harm others or breach confidentiality. This way highlights the importance of wisdom and care when sharing knowledge, ensuring that our actions contribute to a positive, trustworthy environment.
Overall, the “Share What You Learn” pattern has inspired me to embrace the joy of knowledge sharing and to view it as an important part of my professional journey. By defining what I’ve learned, I can make stronger connections within my community, validate my own understanding, and help to the collective improvement of our craft as we say how we never stop learning. It’s a upright cycle that benefits all involved, to continue to make an environment of continuous growth and mutual support.

andicuni
May 15, 2024

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.

CS-448: Week 15

The Long Road

The pattern “The Long Road” is about how in today’s culture, we value overnight celebrities, rising stars, and quick results. This leads to the conditioning of assuming that the shortest path possible is also the best path. With this thinking, people say to take the highest paying job and the first promotion available; however, this takes away from developers being able to slowly build up their skills.

The first step to this pattern is to accept that this nontraditional way of thinking may be considered strange because the focus is set on learning and the long term rather than a high salary and traditional views of leadership. The pattern highlights the importance of planning for the long term, and to plan on being a software developer for decades. Planning for the long term will help to influence what jobs to take and future ambitions. The pattern emphasizes planning for the long term because it takes a long time to comprehend the deeper, more complex topics that come with software development.

The pattern states that this is not a pattern for people who’s main focus is monetary gain. This is not to say that those who follow this pattern will not be able to make money, but it is not their main focus. If monetary gain is the main motivator for someone, they may find themselves counting down the days to retirement as opposed to the craftsman who will joyfully work until the end of their career.

In order to plan for the long term future, the pattern suggests thinking about yourself a long time from now, 20 plus years ahead. With that in mind, imagine what you would want your professional history to look like, and the biggest influences. Using that as a baseline can help plan for future career choices.

Conclusion

I found this pattern to be interesting because it showed a perspective that most do not talk about. The idea that the journey of a craftsman is a long road, so should be treated as such changed the way how I view going about my own career. Rather than focusing solely on how high the salary is, focusing on learning and long term goals will lead to a more joyful and enjoyable career.

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

Retrospective – Sprint #3

During this sprint, I contributed to 3 issues:

  1. Determine what needs to be done on GuestInfoFrontend – GuestInfoFrontend/issues/88
    (As a whole team, we explored the GuestInfoFrontend for any improvements, and created tickets for teams next semester)
  2. Verifying that InventoryAPI has the correct extensions, linters, and pipeline stages – InventoryAPI/issues/25
    (As a whole team, we reviewed and made changes to files in the InventoryAPI to ensure extensions, linters, and pipeline were all set for next semester)
  3. Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – Inventory Backend – InventoryBackend/issues/101
    (3 of us reviewed and made changes to files in the InventoryBackend to ensure extensions, linters, and pipeline are all set for next semester)

Again, this sprint I also assisted in reviewing some issues for the team

This sprint was a breeze, all of us were comfortable working with most systems at this point and we were able to complete almost every one of the issues we set out to do. We did have a little hiccup with the GuestInfoFrontend as we were unsure of the process to start a backend and frontend hot reload instance after moving from Docker to Gitpod but after some direction from Professor Wurst, we were able to continue with our Determine what needs to be done on GuestInfoFrontend issue. Other than that we didn’t run into any problems over the duration of the sprint and we completed >75% very fast this time around too.

I don’t think that there is much or anything for us to improve on this sprint since most of the issues we worked on this sprint were team-collaborated issues we spent less time working on issues than in prior sprints since we were able to collaborate and fix any bugs with ease. Any of the issues that our team members did take on themselves, such were done without much if any assistance past peer reviewing, and overall the team worked like a “well-oiled machine” this sprint.

As a team, we killed it this sprint. We improved on our weak areas from our last two sprints and further solidified what we did well. I feel like communication can always be improved as we had made strides from our first sprint but I feel as if it had stagnated to an acceptable level for sprints #2 and #3. Other than that I can say there was anything that we should have done differently as we were on point this time around. Our in-person communication was a lot better than our discord communication but in the end, both weren’t bad at all, we just could have done better in some areas.

As an individual, I felt as if I could have worked more spreading the load of work since I feel that compared to our other sprints I had taken the least amount of burden of work this time around but if I look back to sprint #1 I feel that maybe it balanced out over the whole year since I felt as if I took on a large burden of work the first sprint so overall I think it evens out. I also could have been better at communicating when I will be on for calls as I had just joined when I could due to school and life just being busy so sometimes I joined Discord later than our usual time without explicitly communicating I would be doing so.

In the end, I feel as if this sprint had been our best yet since we had completed almost all issues (1 wasn’t completed), spread our burden of work, and communicated the best we had the entire semester. While there is always going to be room for some improvement, I feel that we had found our rhythm as a team this time around and we operated at our maximum efficacy.

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

Crafting Mastery: Deliberate Practice in Software Development

Summary:

The “Practice, Practice, Practice” pattern emphasizes the importance of deliberate practice and continuous improvement in mastering any skill, particularly in the realm of software development. Drawing from George Leonard’s concept of mastery and K. Anders Ericsson’s research on deliberate practice, the pattern highlights the necessity of carving out dedicated time for practice separate from daily professional responsibilities. While an ideal scenario involves structured exercises and mentorship, the reality often requires individuals to take initiative in their own skill development.

Reaction:

This pattern strikes a chord with me as it underscores the essence of lifelong learning and skill refinement. The notion that mastery is not merely a destination but a journey fueled by deliberate practice resonates deeply. It challenges the notion of perfection in favor of embracing imperfection as a catalyst for growth. Furthermore, the emphasis on creating a stress-free and playful environment for practice aligns with my belief in the importance of experimentation and exploration in learning.

Interest and Utility:

What I find intriguing about this pattern is its application of martial arts principles to software development. The concept of code katas, akin to choreographed movements in martial arts, offers a structured framework for practicing fundamental coding skills. Moreover, the emphasis on short feedback loops and the integration of public performance within a community of craftsmen underscores the collaborative nature of skill development in the tech industry.

Impact on Professional Outlook:

As someone aspiring to excel in software development, this pattern has prompted me to reconsider my approach to skill acquisition. Instead of viewing mistakes as setbacks, I now perceive them as invaluable learning opportunities. By committing to regular practice sessions and seeking feedback from peers, I aim to cultivate a growth mindset and continuously refine my coding abilities. Additionally, the suggestion to explore timeless resources like “Programming Pearls” for practice exercises has inspired me to delve deeper into the fundamentals of computer science.

Disagreement:

While I agree with the overarching principles of the “Practice, Practice, Practice” pattern, I believe there’s a need for acknowledgment of individual learning preferences and constraints. Not everyone thrives in a structured dojo environment, and some may prefer solitary practice or alternative forms of skill development. Therefore, while code katas and group sessions offer valuable avenues for improvement, they may not be universally applicable or accessible to all aspiring developers.

Conclusion:

In conclusion, the “Practice, Practice, Practice” pattern serves as a poignant reminder of the importance of intentional practice in achieving mastery in software development. By embracing the principles of deliberate practice, seeking feedback, and exploring diverse learning resources, individuals can embark on a journey of continuous growth and skill refinement. As I incorporate these insights into my own professional development, I’m excited to see how regular practice and reflection will shape my journey toward mastery in software engineering.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Introduction

  • In this sprint, our primary focus was on rigorously testing the frontend developed during sprint 2, applying the insights and frameworks we had discussed with team 2. This sprint appeared significantly shorter than the extensive sprint 2, partly due to the lighter workload with a target of only 16 points. This more manageable workload allowed us some capacity to address and rectify lingering issues from the previous sprint.
  • The brevity of this sprint highlighted the importance of continuous integration and testing, which enabled us to quickly identify and resolve issues. Our collaborative efforts with team 2 proved invaluable, as their feedback directly influenced our troubleshooting and refining processes. Moving forward, maintaining this synergy and applying these practices consistently will be crucial for smoothing out any future bumps in our development process and enhancing the overall quality of our project.

Links to Activity on GitLab

Reflections on the Sprint

What Worked Well:

Advertisements

https://c0.pubmine.com/sf/0.0.7/html/safeframe.html

REPORT THIS AD

The standout success of this sprint was our group communication. Facing challenges as a team, rather than individually, significantly eased our problem-solving process. Our review procedures were effective, facilitating a focused approach towards achieving our objectives.

Areas for Improvement:

The primary challenge we encountered was time management, particularly as progress on the front end depended on having a working template. This dependency delayed our efforts, resulting in a hectic sprint conclusion. Better planning or earlier template availability might mitigate similar issues in future sprints.

Improvements for Team Performance

The team’s collaborative communication and problem-solving were key strengths this sprint, continuing a positive trend from the previous sprint. It’s crucial to sustain this momentum into the next sprint, incorporating some strategic improvements:

Improvements for the Next Sprint:

  1. Consistent Scheduling: To avoid the congestion experienced towards the end of the last sprint, establishing a more consistent schedule for meetings could help in better time management and distribute tasks more evenly throughout the sprint.
  2. Balanced Division of Labor: We should continue to monitor and adjust the workload among team members to ensure tasks are evenly distributed, preventing any team member from being overwhelmed while others have less to do.
  3. Streamlined Communication Channels: Building on our previous success, maintaining all critical communications in a centralized, organized, and easily accessible system will enhance clarity and continuity, aiding in more effective decision-making and problem-solving.

Personal Improvements

Reflecting on my personal challenges during this sprint, specifically around managing merge requests correctly

  1. 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.
  2. Frequent Check-Ins: In realizing the significance of team alignment, I commit to checking in more frequently with my team members. By maintaining regular communication and seeking feedback, I aim to ensure that our efforts remain aligned towards our common objectives throughout each sprint.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

448 – Blog Post

“Rubbing Elbows” advocates for the power of hands-on collaboration with another software developer to overcome learning more and enhance craftsmanship. This pattern complements “Kindred Spirits” by emphasizing the benefits of direct, side-by-side interaction in skill development.

Dave’s experience with Roman shows the efficacy of this pattern. By working closely together, they not only learned about new technologies but also gained insights into micro-techniques that are often overlooked in traditional teaching settings. The narrative shows the significance of collaboration, even outside formal mentorship relationships, in fostering skill enhancement and professional growth.

Pair Programming emerges as a concrete ideaology of “Rubbing Elbows,” offering apprentices invaluable opportunities to learn from more experienced developers. While pair programming can be challenging, especially for apprentices, it provides a dynamic environment for skill acquisition. The pattern advises apprentices to communicate effectively with their pair programming partners, seek rotations if necessary, and explore alternative methods like Ping-Pong Programming to enhance participation.

Drawing from Richard Sennett’s concept of the ideal craft workshop, “Rubbing Elbows” advocates for exposure to diverse working habits and practices. This extends beyond coding to encompass all aspects of software development, such as academic collaborations or open-source projects. Ade’s experience illustrates how collaborating on unconventional projects can broaden perspectives and lead to unexpected insights.

Regardless of the outcome, apprentices are encouraged to record their experiences and reflections for future reference. This documentation serves as a valuable resource for personal growth and facilitates empathy towards future junior collaborators.

In action, the pattern suggests initiating collaborative projects, such as contributing to an open-source project, with someone interested in similar pursuits. By committing to regular sessions and adapting to challenges, apprentices can sustain motivation and continue their learning journey.

In summary, “Rubbing Elbows” underscores the importance of hands-on collaboration in overcoming learning plateaus, fostering skill development, and enhancing craftsmanship. Through direct interaction and shared experiences, apprentices can accelerate their growth and achieve mastery in software development.

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

448 Blog Post

The piece “Draw Your Own Map” encourages individuals to take control of their career paths rather than relying solely on their employers or societal expectations. It addresses the common notion that programming and career advancement in the field are limited, especially for those who may not fit the stereotype of fresh graduates. It emphasizes the importance of identifying one’s own career goals and taking proactive steps to achieve them.

The solution proposed involves identifying logical yet ambitious career steps and visualizing the incremental actions needed to reach those goals. It advocates for taking the first step, even if seemingly insignificant, as it generates momentum towards larger aspirations. Rather than setting only high-level goals, the article suggests defining small, achievable steps that provide feedback and aid in obtaining assistance from like-minded individuals.

The narrative includes personal stories illustrating individuals’ struggles to pursue programming despite organizational constraints. It highlights the importance of prioritizing personal aspirations over organizational expectations and seeking opportunities that align with one’s goals.

The actionable advice includes listing potential career paths, extending the list to explore additional options, and challenging preconceived constraints to open up new possibilities. It also encourages seeking mentors and kindred spirits who can provide guidance and support along the way.

Overall, the piece advocates for a proactive and flexible approach to career planning, empowering individuals to chart their own paths and overcome obstacles to achieve their desired destinations. What I thought was the most important of this piece is the career planning aspect of it especially since this semester I am finishing up my degree and starting on looking for a career, this also like points me in the write direction on a professional work future.

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

CS-448 Sprint 3 Retrospective

Files · jlee1999/check-documentation-and-39 · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / GenerateWCFBReportFrontend · GitLab

Since the last sprint my team was assigned to verify the pipeline tests and linters for this branch, I worked on looking over and adjusting the documentation in the repository to match any changes made. When I tried to run the frontend, however, it was not loading properly. After looking at the documentation, I worked on fixing the front-end functionality or at least making progress in it to set up the students next semester that will be working on it.

feat: merge branch ‘jlee1999/fix-documentation-in-guestinfobackend-126’ into ‘main’ (32d05a94) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoBackend · GitLab

Like GenerateWCFBReportFrontend, my team worked with GuestInfoBackend last sprint to implement nodemon into the repository so that developers can hot reload the servers whenever they adjust the code in the source folder. After making those changes, I worked on matching the documentation with the previous changes to make it easier for other people working in the repository to know how to run the backend in production mode versus development mode.

Files · implementing-nodemon · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

Over the course of the semester, my team has been working in the CheckInventoryFrontend repository to work on different issues. One thing we were struggling with was getting the front end to load properly to see the layout. In this branch, I was able to fix the front end to load properly so that we as developers can see what the layout will look like to the client. I also worked on implementing nodemon in this repository to hot reload the backend servers to put it in development mode.

Files · jlee1999/fix-documentation-in-the-39 · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

This issue dealt with fixing the documentation in the CheckInventoryFrontend repository to match all the changes my team has made throughout the semester. We worked on setting up the repository to look like GuestInfoFrontend which made the repository more organized and easier to navigate. With all those changes, however, the documentation that was previously there was now outdated. While it might not be as glamorous as other work, adjusting the documentation is important and will help future developers when they start working on this project.

This was the last sprint for the semester, and I believe that it went as well as the last sprint. Each team member was tasked to do specific issues that did not necessarily need work from multiple team members at once, which helped spread the issues throughout each of us. The one issue that required multiple team members at once was the overall updating of CheckInventoryFrontend but we were able to split up that big general issue into smaller problems that each member can focus on in their own time. I continue to feel confident in the gitlab setting and have had an easier time navigating through each repository and have improved in that aspect compared to the beginning of the semester.

I will say what changed from last sprint to this sprint was the decrease in communication throughout the team, but I do not think it hindered our progress as much as it would have previously. Since the issues could be worked on individually, we would still update each other through the stand-up meetings and were able to get enough progress through the sprint to reach our goal. There was sometimes confusion amongst us on what part of CheckInventoryFrontend to work on.

As previously mentioned, I think communication amongst the team could have improved which would have only increased our team’s production throughout the sprint. I am not sure why it dropped this sprint, but there were times where I would try to message the team to get something approved or ask for progress through their issue, the communication would be delayed. It did not completely hinder us since we still fixed enough issues to reach the weight requirement as a team. I started to get the hang of focusing more time and energy on one issue rather than multiple at once but also knew when it was time to stop before hitting a wall.

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 3 Retrospective

After finishing our last sprint I believe it went very well compared to our last two sprints. Our team did a great job of communicating, time management, and ensuring everyone’s ideas were heard. We also made sure that issues were assigned equally and that our issues weren’t sitting in needs review. I believe we didn’t have any issues for this sprint since the last two gave us a better idea of what we needed to do this time. As a group of 5, we needed a weight total of 25, we managed to complete over 75% of our issues. Since the last sprint, I believe we made a lot of progress as a team and managed to get through this sprint without any issues.

As a team, I believe we made a lot of progress in this sprint and didn’t have any issues to work on. We made sure to communicate with each other about how everyone’s progress was going on with their issue and if they needed any help with anything. The reason why we managed to get through this sprint is because of our communication and teamwork. Like I said earlier I believe that as a team for this sprint, we didn’t have anything that we needed to improve on. Our working agreement helped us get through these sprints by making sure we were straightforward with everyone and that we got to improve each time. Based on the last two sprints, we’ve grown improvement-wise. We made sure to stay on top of any work that needed to be reviewed, communicated with each other, assigned issues equally, and managed our time very well. I enjoyed working with my team members and was glad that we were able to complete this sprint without any issues.

As an Individual I believe I made a lot of improvements since the last sprint. I made sure that the work was even spread out between me and the team, I also made sure that we stayed on top of reviewing each other’s work. The issues I worked on were Update and Review Documentation GuestInfoSystem and a couple of group issues like Determining what needs to be done in GuestInfoFrontend. I made sure that the guestinfo system documentation had the right extensions, linters and that the pipelines were working. Then as a group, we worked on the GuestInfoFrontend and created a couple of issues that next year’s students can work on for their sprint. Some issues we created were moving “Other Assitance” attribute and moving receiving unemployment attribute to assistance. Those issues will help the GuestInfoFrontend look cleaner and see what is missing in the code that for some strange reason gave us a harder time to deal with. With this being our last sprint I can proudly say that our group did a great job in getting the work done and communicating with each other. By learning from our mistakes we were able to get through this sprint without any troubles and managed to get it done quickly.

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.

Sprint Retrospective Blog #3

Hi everyone, my name is Abdullah Farouk, for those who don’t know me by now, and this is going to be my first sprint retrospective of the semester. First, I will start out by saying, considering this whole thing is brand new to us, we did a great job working with this new style and adapted quickly to all the changes. Don’t get me wrong, there is still a lot of room for improvement from everyone in the team, but we successfully passed through this semester. This sprint consisted of us getting more familiar with libre food pantry more and to see how this scrum framework actually go and went more in depth into the actual system. The first thing we did in the beginning of the semester was weighing the different issues and breaking some epics into smaller issues and assigning it to our team. We then organized the issues on which one we wanted to do first and so on. I worked on most of the issues during class time, which worked out nicely because I had my team member there to help me with things just in case, I got stuck, which I did sometimes. I liked meeting in person instead of virtual meetings, as I think we do more work when we see each other instead of behind a computer screen.

One thing that I would say the we massively on was how we weighed the issues in the beginning. Compared to the first sprint, Some of the issues took less than what we had anticipated, and some took way longer, but this sprint we got it spot on and managed to finish all the issues on the board just in time. Another thing that we improved on was communicating outside of class time. I started privately messaging class mates for updates if they haven’t said anything in days. One thing we still didn’t do well was Some of the issues we had made, we didn’t add a description to it, so it was a little harder for me to figure out what they want me to do just from the title, so I had to ask classmate to double check.

Other than that one issues, I think me, and the team did a great job going through these issues and completing them on a timely basis. I worked on multiple issues for this sprint that I will list at the ends, but mostly I was trying to clean up code and made sure anything that I had left unfinished, was either finished or deleted so the next class is not having a headache trying to figure out why it’s there. I also checked a couple of my classmate’s issues that needed to be reviewed in order to merge to main. I also worked on. I also learned a lot about nodemon function and have a basic understanding of how it works and how to properly integrate it.

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

  • Update CheckInventoryFrontend

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/inventorysystem/checkinventoryfrontend/-/issues/27

  • Think and write down possible ways to further enhance the CheckInventoryFrontend

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

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