Category Archives: CS-448

Week 7: CS-448

Concrete Skills

For this post, I read about the Concrete Skills pattern. This pattern is about when seeking a new role on a development team, the team may not want to risk the possibility that one may you be able to contribute to the team. They may think this because you may not have much concrete work to show your skillset and prove to teams you are able to contribute. The solution to this problem according to the text, is to acquire and maintain concrete skills. In order to do this, the text suggests collecting CVs of people whose skills you respect. Collecting CVs helps give an idea to what skills are useful and looked for when joining these teams. After learning these skills, then build a project using them to demonstrate that you can apply those newly learned skills.

I found this pattern to be useful because I am currently in the process of applying to jobs, so this pattern is very prevalent to me. Collecting CVs of those already in the industry, or those with more experience is something I had not thought of. However I believe it is a good way to find skills that you may be missing. Collecting a list of skills is also useful in the sense that common buzzwords used among CVs can be noted to help get past HR filters and managers who construct teams based off of those buzzwords.

I found the statement that describes hiring managers requiring to take a leap of faith on choosing who they hire, and having concrete work allows you to meet them halfway to be interesting. I found this to be interesting because it changes my perspective on the hiring process.

This pattern has changed the way I go about looking for new skills to learn. When learning new skills, I sometimes plateau and get overwhelmed with what I should be looking into. Now after reading this pattern, going into the future I will start collecting CVs because having a list of skills will be useful to direct my focus in the skills I should be learning.

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.

CS-448 Week 7 Learn How you Fail

The pattern being examined is “Learn How to Fail” and it emphasizes the inevitability of failure in everyone’s life. It also suggests that failure is not a sign of incompetence but rather an opportunity for growth and self-awareness. This encourages individuals to analyze their failures, understand the underlying patterns, and address them effectively without dwelling on past mistakes or striving for perfection.

This pattern resonates deeply with me due to the universal nature of failure and brings light to the fact it is a natural part of the learning process. I am one that values continuous self-improvement and find the idea of embracing failure as a catalyst for personal growth both empowering and liberating. Instead of viewing failure as inadequate, it is seen as an invaluable source of feedback that can inform my future decisions and actions.

One of the more interesting and useful aspects of this pattern is its emphasis on self-reflection and self-awareness. The pattern provides a practical framework for introspection and self-discovery by encouraging individuals to identify recurring patterns, habits, and behaviors that contribute to their failures. This will help individuals to make more informed choices and develop strategies to lessen their weaknesses effectively.

This pattern has certainly influenced the way I think about my intended profession and how I approach my work. Failure is now viewed as an opportunity for learning and development rather than a setback or source of shame. I intend to face challenges and setbacks during my career path and handle them with resilience, knowing that they will contribute to my overall growth and success.

While I do not disagree with the general message of this pattern, there can be cause for concern given how you might handle failure. It is important to acknowledge and learn from failure, it is just as important to celebrate successes and achievements. Failure can provide valuable lessons but can also overshadow or diminish one’s accomplishments in the search of self-improvement. Balancing both self-reflection and self-affirmation is crucial for maintaining a healthy mindset and sustained motivation.

In conclusion, the pattern underscores the importance of embracing failure as a steppingstone to personal and professional growth. By cultivating self-awareness, learning from mistakes, and approaching challenges with resilience, individuals can navigate their professional journeys with confidence and adaptability.

5. Perpetual Learning | Apprenticeship Patterns (oreilly.com)

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.

sustainable motivations

I hear this a lot: getting into tech, and specifically software engineering, because of money. It certainly seems to be the case that many people since maybe the 2010s have worked on Computer Science degrees solely because of the income and luxury of it, rather than an actual enjoyment of it.

I always found myself good with technology. When I took my first Computer Science course in high school, I always ended up completing assignments in 10-15 minutes when the allotted time was around two class periods. This is what I’m good at, as far as I can tell, but that’s not necessarily enough for me to make a career off of. If I don’t care about it, then I’m stagnating. If my motivation is simply that I’m good at it, it doesn’t necessarily inspire growth.

These are two examples of unsustainable motivations. The idea is that we can get trapped in the motivations we set up for what we do, and they lock us into a (most of the time, negative) mindset. Instead of enjoying my day to day work, I’ll see it as just work, and want the day to be over as soon as it starts, without actually growing as a person or in my skill level.

While the solution given tries to offer a practical approach (writing down your motivations and how much they factor in to your decision to stay a software developer), I don’t necessarily think this is a strong solution. I’m inclined to say that you have to have a more inquisitive investigation to why you care about this career, and what is really motivating you. Ultimately, you yourself create this motivation, it’s not out there waiting to be found. You can either construct for yourself an enjoyment of the journey, or you can only care about the outcomes.

From this, I would say solely caring about outcomes is unhealthy, and that mindset lends itself to motivations like reputation and money. As such, you have to ultimately figure out how to care about the journey if you actually want to have some level of enjoyment in your career. Otherwise every day genuinely will be a soulless repetition of the last.

There’s a reason why Camus wrote that one must imagine Sisyphus happy. If Sisyphus were to redefine the pushing of that boulder as a journey, and the rolling down of that boulder as a satisfying conclusion and new beginning, then this punishment is not as severe. Of course, this requires a lot of mental effort, but I think it’s necessary to live a life that you can actually be happy with.

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.

Exposing Your Ignorance

This week the pattern I decided to write about is from chapter 2. The pattern titled “Expose Your Ignorance” discusses something I’ve had to experience recently: letting those you’re working with fill the gaps in your knowledge. This section opens up with this quote by Jake Scruggs in “My Apprenticeship at Object Mentor”. The quote is “Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.” Opening this topic with that quote is impactful because I think a lot of people feel shame and would call themselves stupid for simple gaps in their knowledge when others have high expectations for them. It’s important to acknowledge that it’s okay to not know everything and be transparent about it instead of struggling alone while deadlines approach.

When I was working on a website with a group of other developers, we were all transparent with each other about our knowledge gaps for the tech stack we had to work with. This allowed us to play off of each other’s strengths and weaknesses. Some of us were more knowledgeable about the front end while others were more knowledgeable about what was required for the backend. I was more unfamiliar with what the front end required so I worked on the backend team. When we started working on the project, I was transparent about my lack of knowledge about JavaScript, routes, controllers, and HTTP requests. My team leader spent some time going over the material with me and provided some resources to research on my own. I then looked for more resources to learn. We also made an effort for everyone to learn a bit more about both the front end and the back end.

 In the text, it said, “Conceding to unspoken pressures and telling people what they want to hear is not a good way to build strong relationships.” I agree with this because our transparency made sure we were able to help each other grow and in turn strengthen our relationships with each other. Your reputation will be built off of your willingness to learn. There wasn’t any part that I could disagree with. When you’re honest about your ignorance you will end up picking up knowledge about a variety of technologies which will make it easier for you to adapt down the road.

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.

CS448 Software Development Capstone – Apprenticeship Patterns: “Concrete Skills”

I would like to continue my reflection on my fundamental software development skills and how to reinforce them in this week’s blog post. The “Concrete Skills” pattern in the “Emptying The Cup” chapter of “Apprenticeship Patterns” by David H. Hoover and Adewale Oshineye describes the practice of building and maintaining your concrete skill set to make yourself a better choice for a professional role. Knowledge on how to write build files, familiarity with the standard libraries for your chosen programming language, basic web design, and JavaScript are some examples of concrete skills given by the authors. Possession of these concrete skills are what allow you to stand out as a candidate for a developer position. The authors recommend constructing “toy implementations” to demonstrate your understanding of these concrete skills in an interview.

I wanted to read and reflect on this pattern because recently I was challenged with a programming problem where I needed to iterate through the nodes of a linked list. I remember learning about the linked list as a data structure in a previous course, and now in the elective course that I’m taking, we’ve been tasked with implementing a linked list as well as performing operations on it. The implementation of each linked list node as an object with a ‘head’ containing data, and a ‘tail’ that functioned as a pointer to the next node in the list was familiar to me. Despite my previous experience learning about the linked list, I still spent a long time implementing a function that would do something and then iterate through the linked list. I knew I had to repeatedly set the head of the list to its tail within a while loop until the data ‘head’ of the list was empty. It was only with the help of my classmates that I rediscovered how to express that implementation in code and properly operate on each element in a linked list, and then exit the while loop once the ‘head’ member variable of the node was empty. I realized that while I believed that I understood basic data structures like linked lists, trees, and queues conceptually, I struggled with implementing those design concepts when put to the test.

The pattern’s recommendation to demonstrate your concrete skills through small-scale projects has me reflecting on my goals for a project I started a few weeks ago and have only spent a few collective hours on since. I’ve been wanting to practice my design patterns, so I started a Java project called “MonsterFactory” as an exercise. I have a collection of Java classes like Zombie, Werewolf, or Vampire that all inherit from a Monster superclass and share some member variables and methods. I want to implement a MonsterFactory class that follows the Factory software design pattern that could instantiate whichever Monster subclass we could want in any given situation. This project could serve as a functional example of my understanding of software design patterns, and I could also expand upon it to take advantage of the libraries offered in Java. I’m primarily working with strings and integers as data types in this project but learning how to work with images as a data type to accompany each Monster could be an entirely achievable goal for me to add to this project.

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

Craft Over Art: A Journey of Mastery

Summary of Craft Over Art:

The “Craft over Art” pattern delves into the distinction between craftsmanship and artistic expression within the realm of software development. It emphasizes the importance of prioritizing craftsmanship, which entails mastering the fundamental skills and techniques required to create high-quality software, over the pursuit of artistic flair.

My reaction:

Upon encountering the “Craft over Art” pattern, I found myself reflecting deeply on the essence of software development as a craft. What struck me most was the notion that craftsmanship transcends mere creativity or innovation—it embodies a dedication to continuous learning, refinement, and adherence to best practices. This perspective has profoundly influenced my perception of my intended profession as a software developer.

Initially, I was drawn to software development by the allure of innovation and the opportunity to unleash my creativity through code. However, this pattern prompted me to reconsider the significance of honing my technical skills and adopting disciplined practices. It made me realize that while creativity has its place in software development, it is craftsmanship that truly underpins the creation of reliable, maintainable, and scalable software solutions.

Moreover, the pattern’s emphasis on mastery resonated with me on a personal level. It sparked a realization that becoming a proficient software developer requires more than just technical prowess—it demands a commitment to continuous improvement and a willingness to embrace challenges as opportunities for growth.

While I wholeheartedly agree with the premise of prioritizing craftsmanship over artistry in software development, I acknowledge that striking a balance between the two is essential. Creativity and innovation undoubtedly drive progress in our field, but without a solid foundation of craftsmanship, they risk being mere flashes in the pan. Therefore, I believe that the key lies in integrating artistic expression with the principles of craftsmanship, leveraging creativity to enhance the quality and elegance of our code.

“Craft over Art” pattern has been instrumental in shaping my understanding of software development as a craft. It has inspired me to prioritize mastery, discipline, and continuous learning in my journey as a software developer, ultimately guiding me towards the path of excellence in my profession.

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.

The White Belt

In this week’s blog post, I will be discussing the “The White Belt” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to set aside what you have learned in order to learn more is a difficult but important skill.

A quote early into this section that I can personally relate to discusses how your confidence in what you have already learned can cause you to have a harder time learning more. “You are struggling to learn new things, and it seems somehow harder than it was before to acquire new skills. The pace of your self-education seems to be slowing down despite your best efforts. You fear that your personal development may have stalled.” I have been in this position myself more than once. One approach the chapter mentions is called the not knowing stance.

The not-knowing stance, as mentioned in the chapter, is an approach to understanding that you do not and can not currently understand the entirety of what you are trying to accomplish. “Part of the approach Dave took as a family therapist included maintaining a not-knowing stance. Families in difficult circumstances were experiencing a unique reality that, despite his training, Dave knew he could not fully appreciate. While he acknowledged his skills at facilitating constructive questions and conversations, Dave was taught to refrain from believing that he had any expert knowledge into the realities that these families experienced. While this may seem counterintuitive, in reality, it fosters an attitude of respect and curiosity that opens up unforeseen possibilities and solutions. Rather than pushing solutions down on the family, Dave’s not knowing stance helped him to collaborate with the family to find solutions as a team.” As shown in this quote, embracing the not-knowing stance, can help you have a more open mind in trying to solve problems, or learn new things in different ways. Embracing the not-knowing stance is not only incredibly helpful in being able to learn new things, but can also help interpersonally, as shown by the quote.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective March 3, 2024

During this sprint, I worked on four issues that were assigned to me. As a group, we all did well in our first sprint and felt we had much to improve on. There were areas where I could improve. During this sprint, I worked on four different issues; one of them was “Investigate GenerateWCFBReport frontend for better understanding of what tests need to be created”(1). This issue involved looking into the .vue files in the GenerateWCFBReport to determine the tests required. Keith and I had looked through the files separately to see what would be done. While I wrote down what needed to be done in a Word document, I remembered that I needed to add a comment to the issue page, which Keith already did.

Another issue I worked on was “Add AlexJS linter to pipelines for AddInventoryFrontend”(2). I had a lot of trouble with this issue, and it took around three hours to finally finish. Thankfully, I was able to work with my team to correct the issues I was having in getting this issue completed, even though, as I wrote in my notes while working on this issue, I was not and am not sure how I was able to get the pipeline to pass. However, Keith later noticed we may need to correctly complete this issue and other issues related to adding AlexJS. We plan on correcting these issues in sprint two.

A third issue I worked on during the sprint was “Move commands from ‘GuestInfoAPI/commands’ to ‘GuestInfoAPI/bin’”(3). This issue went smoothly for me, but I recall Tommy was having trouble completing a similar issue in a different section of the project, we tried to help him as best as we could, but for some reason specific files were being picked up by linters that should not have been. I am still unsure as to how the rest of the group did not have similar issues with their issues regarding moving their commands code.

The fourth issue I worked on this week was “Gitpod Dev Environments GuestInfoApi Team 2″(4). I had a lot of trouble with this issue as well, as mentioned in the issue page comments, I had to skip these issues “stoplight.spectral”, “hashhar.gitattributes”, “tlahmann.alex-linter” because of this error “[extension] extension is not found in Open VSXgitpod”. This was the first one I worked on during the sprint, so I had several issues merging the commits. “I also had difficulty merging commits, but Keith found a workaround to correct the issue. This took around 45 minutes to find and correct. In addition to this, I spent another 45 minutes trying to correct some linting errors being caused by “/t” markers.”

As a group we agreed that our communication was fantastic, we reached out to one another when we needed help, and were all able to communicate our ideas politely and efficiently and were all on the same page. However, we all agreed that we needed help with efficiently scheduling meetings between the four of us. We also needed help with weighing our issues appropriately. These issues can be easily corrected, with the scheduling we have determined to dedicate at least one class meeting to be in person and the other online. Regarding the weighing issues, that was primarily due to our inexperience.

I could improve by working on my assignments more on my own rather than just during our meetings. I also could improve by putting more comments on my issues in GitLab.

Issue 1: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/36

Issue 2: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/30

Issue 3: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/146

Issue 4: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/149

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The Importance of Finding Mentors

Beginning a journey in the Software Development field is like walking through a maze. Every turn presents different challenges, different opportunities, and different outcomes. Having a mentor can be the guiding light that we need through our journeys. The Finding Mentors pattern underscores the importance of seeking out help and assistance from experienced individuals who can provide both support and guidance while navigating the complexities of the field.

Reflecting on my own experiences, having a mentor can have quite a profound impact on shaping skills, gaining knowledge, and viewing things from different perspectives. I’m yet to experience this within my software development journey, but experienced it on numerous occasions with my athletic career where I was coached by a number of professional athletes. This in turn enhanced my skills and knowledge and resulted in me becoming a better overall player and athlete. I would assume the same would happen within the development field. Having a mentor would overall increase our knowledge and skillset, allowing us to further walk down our professional journeys.

What I found particularly interesting about this pattern was the emphasis on the give and take nature of mentorship. While apprentices seek guidance from experienced individuals, they then also have the opportunity to mentor others. This creates a culture of continuous learning and collaboration within the software development community as a whole. Additionally, the pattern has reinforced the notion that mastery can be achieved through the guidance and mentorship of individuals who have already walked the path we are trying to take. This allows us to take a step further in our learning journey. Therefore, this has prompted me to actively seek out mentors and engage more proactively within the development community to accelerate my personal learning and growth.

Additionally, while having a mentor can be an extreme plus in our own personal development, we should acknowledge that finding mentors can be challenging. This is due to the fact that some individuals may lack access to established networks or communities. In this case, we can look into alternative approaches to finding a mentor through online platforms or peer-to-peer mentorship programs.

Therefore, the Finding Mentors pattern can serve as a guiding light for us as aspiring craftsman, utilizing the power of mentorship in our professional development. By embracing the core message outlined within the pattern and seeking out mentorship opportunities, apprentices can then navigate through the complexities of software development with purpose and confidence, while also growing and learning for their professional career.

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

Sprint 1 Retrospective

With this being our first sprint of the semester it went well but we had our fair share of issues that we had to work through as a team which will help us make better decisions on our workflow and our team dynamic in the future. I personally worked on five issues throughout the sprint, one of these issues being a team issue and three of the issues being assigned to myself while we still worked as a team while going through our individual issues. These issues included adding the alex js linter to a pipeline and resolving alex js issues, adding a git pod dev environment setup to a repo in the project and moving from commands to bin for a specific repo within the project. Our group issue that we completed included researching frontend development and using our research to create issues for our second sprint regarding the wireframe for the add inventory frontend.

Overall I did not have much trouble with my individual issues within this sprint. My first issue I worked on with the alex js linter was straightforward and I was able to complete it without much delay as there were not a lot of terms flagged by the linter after its implementation to the pipeline. My second issue regarding git pod dev environments took a bit more time which was simply just due to the time it took to fully test the pipeline after a commit but I did not have trouble with implementing the git pod dev environment within the repository. My last individual issue involved moving from commands to bin, this was my most simple individual issue as it mainly consisted of renaming a folder and checking for commands which used the commands folder and changing it to use the bin folder. Our team wide issue of researching frontend and making issues also went well as we all attended the meeting and went over frontend basics together. Links to my individual issues are listed below.

Although we did not have a large amount of problems within this sprint I still feel as though there are things we could work on to improve as a team. One thing we can improve on is our timeline when it comes to reviewing, during the sprint we didn’t review our code until near the end of the sprint which just ended up being inefficient and experiencing this has led to us deciding to review code as soon as possible during this sprint instead of waiting until the end of the sprint in order to notify each other of any issues with our work with ample time to fix mistakes. Another thing I feel as though we all need to work on during sprint two is our use of gitlab as there were points where we got lost in gitlab when making merge requests, branches etc so being more careful when using gitlab will help us all remain more organized in order to ensure we get our code properly reviewed and merged within a timely manner. In my opinion we worked well together given it was our first time working in a team like this and hopefully we can continue to develop our abilities to work as a team throughout the next two sprints.

Alex JS Linter issue: 

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

Gitpod Dev Environments Issue: 

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

Move from commands to bin issue: 

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

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.