Category Archives: CS-448

CS 448-01 Team 3 Sprint 3 Retrospective (5/7)

Following the very close end to our 3rd and last sprint, I feel like we really put in the effort to finish AddInventoryFrontend. As a team, we completed all of the issues that we were assigned as a team and meet up together for many in-person meetings in order to finally finish up some loose-ends.

One of the biggest things that we finished from last sprint was that we were to got AddInventoryFrontend working. Last sprint was very difficult because the code that we were working on was messy and we had to change a few different approaches to the Frontend since our original approach to create a wireframe which would eventually become the UI did not come together. For this sprint, we had updated our code to be able to finally string together the Frontend with the Backend, like changing around our directory, adding in key files to run the Frontend, and then test through trial and error our Frontend. We used our current wireframe in order to build our Frontend to what we ended up with.

For AddInventoryFrontend, I had worked on updating the Documentation of AddInventoryFrontend since I wanted to be able to contribute more in this sprint. When I looked at the documentation in its original state, I was dumbfounded to find that there were almost nothing there to begin with. It must have looked liked a template since it specified that the linter being used was called test.sh instead of lint.sh. Because everyone on my team was doing so much work on the Frontend and its functionality, I wanted to be able to contribute more as a member of the team, so I decided to modify the documentation so that it would reflect the changes that we made as as a team.

Unfortunately, we were unable to completely fix some issue that we had with our Frontend before the end of the sprint. Our Frontend works great and loads properly now that we have fixed it. If we had another sprint left before the end of the semester, we would have worked on optimizing our Frontend so that the button could work so that you can add and remove units of food from the inventory, and also keep track of how much food is in the inventory through a viewable parameter that would check in the database for the inventory amount. With that being said, any issues that we had with AddInventoryFrontend will have to be resolved next year.

As a member of our team, I definitely could work on trying to practicing some code so that I would be able to make changes that they made with the Frontend. The Frontend was not impossible for me to read since I have played around with HTML before, but I was still trying to figure out all the formatting for our Frontend so I took a good look at our code. I could tell that at the very least that we did our best with creating the Frontend with the little time that we had following our previous sprint, but I would like to not forget about the things we did as a team to create our Frontend. I think that I better understand how AddInventoryFrontend works because I did run the environment on my own. For our presentation, I really hope that we can talk more about how we got our Frontend to work rather than just listing out the issues that we did in our sprint.

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

CS 448-01 Team 3: Sprint 2 Retrospective (4/4)

With the second sprint, we had so much trouble with our sprint until near the end of the sprint. To elaborate on what went wrong, I would like to start out with what we were planning from the very start, as this will be very important for what we will be doing for the next sprint.

While our last sprint, we split between meeting remotely and meeting in-person, we finally decided that it would be better for us to meet in-person. We also came up with a wireframe that we decided to use as our template to create our framework for AddInventoryFrontend (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/blob/main/Developer/Wireframes.md). Since we already had AddInventoryBackend working as intended with the proper testing IDs being used as a way to test our code for the Backend, we only just needed to create AddInventoryFrontend so that we can try to put a frame over all the work that was done with the Backend from last year. At the very least, we knew exactly how we wanted to build our front-end.

On the contrary to how we finally have a plan for our Frontend, I was having lots of trouble with trying to build the Frontend. Since I had lots of trouble with some of the issues that we did, I instead decided to focus on redoing some of the issues we had from last sprint (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/36). At the very least, I could at least contribute a little bit to our sprint, knowing the tasks that we were unable to completely finish.

What we as a team learned from sprint 2 was that we learned about using Vue, a Javascript framework that we would use to help build our Frontend. While we were not able to get the entire page running, we added a functionality to be able to add a button to our Frontend, just as we intended when we were following our wireframe example from earlier. Once we had explored our options to how we would build our Frontend, we decided to use a new wireframe that my teammate would create for our team to follow along with.

The things I could do improve on as an individual is that I need to speak out more with my team about the issues that may have, let it be related to work or anything other. I had trouble with this sprint because I was not great with programming with HTML and Javascript, and I felt like that was really hindering my performance as a team member. I did my best with trying to get help with working on the sprint, and when that was not working out well for me, I consulted my search engines instead. As someone who was much better with AddInventoryBackend, working with the Frontend was not my strength as shown in this sprint. I was confused with what wireframe we were using for the sprint until the end of the sprint when we had a semi-functioning Frontend that we were going to tweak in our next sprint. For the next sprint, I am hoping that I can get to do anything that is not too technical like directly running the Frontend, and I hope that then next sprint will be where our team will be able to get a working Frontend by the end of next sprint.

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

CS 448-01 Team 3: Sprint 1 Retrospective (2/22)

This beginning of the sprint was a very weird sprint, but me and my team managed to make it through without much trouble.

Seeing how the directory for AddInventoryBackend works, it was easy enough to move the files from their VSCode locations to the directory paths that GitPod uses to be able to use the important files. For this sprint in general, we just needed to move the Linters to the correct directories and then try to run them as best as possible. For the Linters that did not work, we either replaced them with other Linters that were accessible through GitPod, or we just removed them. Since we only needed specific Linters to use for our project, our team were able to confirm that we had a sufficient amount of Linters needed thanks in part to consulting our product owner. Also since I used GitLab, creating issues and labeling them were not too difficult either as we were familiar with managing our issue boards, especially since we learned about workflows in a previous class about Software Process Management.

What did not work well was that I was having a very hard time with trying to use GitLab and GitPod, because I had never directly worked on issues before, making it more difficult for me to fully understand how to utilize my environment until near the end of the sprint. I had made myself a note for the next sprint to remember what I have done for this sprint and what else I had to do for next sprint, because I am very mistake-prone when working on a new IDE. GitPod’s changes are new and more convenient, but as someone who has used other IDEs such as Visual Studio Code and Eclipse to name a few, this was a completely new environment that was very unfamiliar to me. While I did make a few notable mistakes like not understanding how to create merge requests or which tags to use, my team guided me to learn how to be able to make those changes by myself after lots of practice.

As a team, we were really prioritizing meeting up together as necessary as possible. We considered using Discord as a means of having our virtual calls since that is where we were going to communicate and do our stand-ups anyways. However, we found that meeting up in-person was much better for us as working on a sprint by call is not consistent with us since joining a Discord call is too inconvenient and takes up too much time. Like I said before, managing GitLab was not too difficult since we all have experience with Scrum from our previous class. I think the best part about our team is that we are very open to helping each other whenever we were stuck on any issues relating to tasks like with the Linters.

For my individual work in the sprint I had done a couple issues to start out with the sprint. I moved the shell script commands from the /Commands bin to /Bin since that is how we were going to organize our shell-scripts like our lint.sh script (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/32). Another task I did was very similar to the first one, except I am instead moving the Docker files to specific directories in GitPod (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/33). The Linter task that I did was to add AlexJS to GitPod so then we can utilize a new Linter to help with checking our code for our project (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/gitlab-profile/-/issues/83). I did all of those tasks before I would verify to make sure that our entire repository was in the correct state (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/35). Overall, I think that I am doing good so far individually with the sprints. The one thing I need to work on as a team member is speaking out whenever I need help or so I can find something in particular to do in the sprint since it is not just my team who has to contribute to our work. I am hoping for this next sprint, I can get a specific issue that I can work on to contribute using my skills that I have learned from my previous classes.

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

Apprenticeship Patters Chapter 2 (Emptying the Cup)

For this week, I read the Apprenticeship pattern “Emptying the Cup”, the second chapter of the Apprenticeship Patterns. I found this pattern to be very interesting since this chapter teaches you how to effectively become a better apprentice, as well as how to use your experience of problem-solving to become a better member of a programming community later on. While the beginning of this Pattern explains the pouring of the tea cup, it is actually a metaphor that pertains to “clearing your mind of bad habits”, meaning that you should remove all distractions or de-motivators so that you can think more openly about the subject in mind.

I find it very interesting that the rest of the sections describing the “tools” to start your apprenticeship are sorted in a specific manner so that you yourself are familiar with all the experiences and different skills needed to learn a programming language. For instance, there is a problem and solution section in the “Concrete Skills” Section of “Emptying the Cup” that caught my attention. The problem state that a team believes that you cannot write a program, but that is where the solution tells you to learn about building concrete skills in order to convince the team to trust in you to be able to do the work. While the rest of the sections does not touch upon anything specific to programming, they all help you in showing your capability to help with coding.

What I found useful in this chapter was the “Your First Language” section that talked about the effective ways of becoming a better programmer. In the “Solution” section, there’s a specific segment where programmer Ralph Johnson explains in an interview on learning a programming language. When asked about which programming language to start with, he say “…the best way to learn a language is to work with an expert in it. You should pick a language based on people who you know. One expert is all it takes, but you need one.” Like the rest of the “Solution” section describes, I have learned that it is better to learn a programming language when you have an person or a group who can help guide you to writing better programs.

While the rest of the sections start to describe the many different problems and solutions to specific problems, the main takeaway I have from reading this apprenticeship pattern is to openly express your problems and work with your team on showing your commitment to programming in your career. I did not have any specific disagreements with this pattern, but I am still am curious about what the other sections have to show for learning the other patterns.

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

The Long Road

Summary

The long road pattern emphasizes the lifelong journey towards mastering software craftsmanship. In a culture that values quick success, it prioritizes long-term growth and continuous learning over immediate financial rewards and traditional career advancements. This path is more for those who are dedicated to mastering the craft than those seeking quick riches or executive rolls.

Reflection

With graduation behind me, it’s fitting to focus on the long road ahead. One of the lines from this pattern that stood out to me immediately was “For every step you take toward mastery, your destination moves two steps further away.” The ongoing theme through my computer sciences degree was that every time I would gain knowledge in a topic I would also gain even more knowledge about now much I don’t know. This really opened my eyes to how much it is going to take to master the craft. This started to feel daunting as it continued to happen, feeling like the destination is always getting further away. However, another key point in this pattern was that the journey is just as important as the destination.

When I think of what I know now compared to what I knew even just 2 years ago, it’s such a drastic difference. Even with the feeling of the destination getting further away, each step I took was still forward in my journey. With each step I grow and gain skills that I can continue to use. 

As I look to begin my career as a software developer, I understand that quick wealth is not feasible with my current lack of experience and knowledge in the field. This however is not something that will change overnight, which is something I am already aware of. As I look for a job, I really am looking for an opportunity to gain experience and learn while getting paid. This mindset values the knowledge and experience just as much as the monetary value gained from the position. As long as I keep this mentality moving forward I see the experience and knowledge paying for itself down the long road ahead. 

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

Sprint 3 Retrospective

Activity on Gitlab (from oldest to youngest)

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend

  • Worked on verifying correct linters are present/used, pushed branch and was merged later

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend

  • Helped team by commenting details in regards to issue worked on as a group

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend

  • Deleted branch to do some clean up at the end of the sprint

In the dynamic realm of sprint cycles, our team of five individuals embarked on a journey of collaboration, growth, and shared accomplishments throughout Sprint Three. As the semester progressed, we evolved into a more cohesive and efficient unit, leveraging our collective strengths to overcome challenges and achieve our objectives with confidence.

From the beginning of this sprint, our experience was characterized by seamless workflow, effective time management, and a strong emphasis on teamwork dynamics. Through a combination of collaborative efforts, individual contributions, and paired work, we navigated our sprint objectives with precision and determination, exceeding expectations within the designated timeframe.

Reflecting on our previous sprints, we collectively identified areas for improvement and implemented strategies to enhance our performance. One notable shift in our approach for Sprint Three was the refinement of our task allocation process and the adoption of a more strategic approach to problem-solving. Recognizing the importance of leveraging diverse perspectives and skill sets, we allocated tasks based on complexity and urgency, ensuring optimal resource utilization and productivity.

Furthermore, we continued to prioritize inclusive code reviews, fostering a culture of knowledge sharing and continuous improvement within the team. By conducting comprehensive reviews as a team, we not only enhanced the quality of our work but also reinforced our commitment to collective success. Paired work remained instrumental in our strategy, facilitating better communication, collaboration, and task completion efficiency.

Despite the inherent challenges of a five-person team, we maintained a cohesive and supportive environment throughout Sprint Three. Each team member actively contributed to discussions, shared insights, and collaborated with others to overcome obstacles. Our shared dedication to excellence and mutual respect for one another’s contributions fostered a positive team dynamic, elevating our overall productivity and morale.

Moreover, we remained focused on maximizing our time and resources by prioritizing tasks based on importance and feasibility. Setting ambitious yet attainable goals, we remained committed to completing at least 75 percent of our sprint backlog, ensuring progress towards our objectives while allowing flexibility for unforeseen challenges or revisions.

As we look towards future sprints, we are confident in our ability to build upon the successes of Sprint Three while addressing any identified areas for improvement. By continuing to prioritize collaboration, effective communication, and adaptive problem-solving, we are poised to further enhance our team’s performance and achieve even greater success in the upcoming iterations.

In conclusion, Sprint Three was a testament to our team’s resilience, growth, and unwavering commitment to excellence. Through strategic task allocation, inclusive code reviews, and increased paired work, we navigated our sprint backlog with confidence and cohesion, emerging stronger and more united than ever before. As we continue to iterate and refine our processes, we remain dedicated to driving innovation, fostering teamwork, and delivering exceptional results in all our endeavors.

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

‘Breakable Toys’ Pattern

The “breakable toys” pattern from chapter 5 is one of if not the most important pattern contained in this book in my opinion. This pattern specifically talks about the necessity of learning from failure even if your work environment does not allow you to do so. A situation like this is common within industries such as software engineering and the example the book gives of a juggler and how someone who can juggle three balls would not attempt to juggle five while actually performing which relates to software engineering as this pattern encourages you to make mistake and learn from your failures on your own time if your workplace does not allow it. “Breakable Toys” also suggests constructing a similar system to the one you may work on at work in order to be able to experiment on your own time and learn from your mistakes in an environment that directly resembles the one you are in at work. You should push yourself to find learning opportunities for yourself through the use of this pattern as if you do not have those opportunities at work then you must make your own in order to continue learning and get better at your craft. It is also stated that your “breakable toys” should be things that you find fun or have interest in so that even though they are meant to provide learning experiences for you, you are still engaged enough to where you look forward to working with them.

I think that this pattern is very important especially to a software engineer. No matter what company you work at there will eventually be a job where you are expected to make nearly no mistakes and you will not be able to try different solutions due to this expectation. But if you are able to experiment with different solutions on your own and see why they may not work or why they do work you can not only learn for yourself but you can also help the team you are working on evolve from using one standardized solution to using one that could be more efficient or faster.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Capitilzing on your Title

This week, I chose to read the “Use Your Title” apprenticeship pattern under the “Walking the Long Road” chapter. I found “Use Your Title” interesting as it points out that titles like “senior,” “architect,” or “lead” aren’t accurate reflections of one’s personal skill level. Titles like these won’t alone mean an apprentice has become a journeyman, and due to the lack of craftsmen, apprentices still receive these titles, which can potentially cause feelings of inadequacy or overconfidence. This pattern emphasizes maintaining focus on continual learning and self-assessment, viewing titles as indications of company workflow patterns rather than reflecting a craftsman’s advancement along their journey.

This pattern spins a new perspective on the traditional view of titles, suggesting that titles can provide insight into a company’s structure and values. For example, if a title feels inflated or undeserved, it might indicate a lack of rigorous standards within an organization. On the other hand, a lack of recognition might point to an environment where contributions are undervalued.

It’s interesting how the pattern also brings up formal titles such as “senior” while also acknowledging the existence of informal titles. Informal titles are team- or company-wide accepted roles being fulfilled by certain employees without having a title to reflect such. It seems that both have sway in the perception of the validity of one’s work, but informal titles, in my opinion, seem more applicable to one’s skills rather than workflow.

Looking at Dave Hoover’s testimony solidifies things my mentors have told me in the past as well. If you move up the totem pole, it doesn’t always correlate with your development and is more a reflection of a company’s need for more craftsmen. I’ve been told that as a rule of thumb, gauge your progress at your current position every three years. If you feel like your work is underappreciated or your title is inflated or undeserved, then it might be time to move on to better fulfill your personal development. A position at a company may work at first, but over time it is important to also take an objective look and figure out if that position still suits your development or hinders it.

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.

Learning How We Fail Until We Hit Growth

Hey Everyone! In the nonstop pursuit of excellence, the “Learn How You Fail” pattern reminds us of a old forsaken truth: failure is not a curse but a catalyst for growth. It challenges us to confront our weaknesses head-on, to seek out the patterns and behaviors that lead to our missteps, and to use that self-knowledge as a powerful tool for transformation.

The whole point of this pattern means a lot to me deeply, as it recognizes that true creativity and work ethic are not born from a quest for perfection but actually a willingness to form somewhat of a imperfection. As Atul Gawande states, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.”

Personally, I find this pattern both humbling and it gave me a sense of confidence. After reading it a couple of times, it forces us to confront the uncomfortable reality that our successes are often counterbalanced by our failures and weaknesses. I’ve always related to the fact that you have to get out of the comfort zone otherwise you’ll stay there forever. Reason is, in that discomfort is the seed of growth – by consciously acknowledging our limitations, we open ourselves to the possibility of going past them.

This pattern has profoundly influenced my perspective on the intended profession. It has reinforced the idea that your craft is not a destination but a continuous journey of self-discovery and self-improvement. By embracing the idea of “learning how we fail,” we create a mindset of resilience and adaptability, qualities that are essential in the ever-evolving landscape of software development, especially after reading about these patterns.

One aspect of the pattern that resonates particularly is the hard point on making conscious choices. By gaining self-knowledge about our patterns of failure, we empower ourselves to make informed decisions, sort of how some work better under pressure– whether to work on fixing those weaknesses or to acknowledge our limitations and focus our efforts elsewhere.

Lastly, the “Learn How You Fail” pattern is a powerful reminder that failure is not an enemy to be feared but a guide to be embraced. It is a call to take in vulnerability, to find the illusion of perfection, and to strive as more self-aware, adaptable, and the best version of ourselves we can be in and out of software development.

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.

Embracing the Cycle of Growth

Hey Everyone! The “Create Feedback Loops” pattern shines a light on this predicament, reminding us of the fundamental importance of going outside the box, objective feedback to fuel our growth and development.

At its core, this pattern challenges the idea that self-assessment alone is enough for recognizing our strengths and weaknesses. It acknowledges the built in biases and limitations of our own perspectives, which can be hooked by the very teams we work with or the environments we are around. The solution is in actively creating methods that provide us with a mirror, reflecting our true selves through the eyes of others.

What resonates with me about this pattern is its emphasis on the nature of growth. I’ve always been one to say how we never stop learning in this field and by requesting feedback early, often, and effectively, we can create a clean cycle – one where we become conscious of times where we lack understanding, take action to improve, and then seek further feedback to validate our progress. We need to understand there is nothing wrong with taking criticism. This continuous loop not only fuels our personal development but also helps search for a mindset of success and openness to learning.

Personally, I find the pattern’s recognition of the difference between useful and ineffective feedback is definitely a new way I would’ve originally thought about it. It highlights the importance of constructive criticism from distractions, separating obtainable data from well-meaning but misguided advice. This judgment supports us to focus our efforts on the feedback that truly matters, giving us a new way to make targeted improvements and avoid the mindset of false confidence or unnecessary self-doubt.

So to speak on how this impacted me, I like when the patterns give me a different influence on my perspective on the intended field in a positive way. It has strengthened the concept that true mastery is not a isolated push but rather a collaborative journey, where we actively seek out and embrace the perspectives of others. By creating feedback loops, we not only improve our own skills but also contribute to the growth of those around us, fostering a culture of mutual support and shared learning.

In conclusion, the “Create Feedback Loops” pattern is a powerful reminder of the importance of seeking objective, actionable feedback in our quest for growth and mastery. It challenges us to be open to the idea of okay to listen, okay to fail, and okay to continue trying. By cultivating this cycle, we encourage our own development but also add to the supportive growth of our peers and technical community.

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.