Category Archives: CS@Worcester Blog

Nurturing Software Craftsmanship

Hey everyone! In “Apprenticeship Patterns,” the authors present the pattern “Nurture Your Passion.” This defines preserving and growing one’s passion for software craftsmanship, even in unique work environments.
The authors acknowledge that as a software developer, your true passion lies in the craft itself. Unfortunately, the daily grind can decrease this passion, with factors like crushing hierarchies, “death marches,” abusive managers, and colleagues ruining your enthusiasm. The pattern suggests strategies to protect and add on to your passion. One is to focus on aspects you genuinely enjoy and dedicate time, even outside work, to pursuing these interests. The authors cite Paul Graham’s advice to “work on what you like.”
Another strategy is to seek out “kindred spirits” – joining user groups, participating in forums, and starting a blog to connect with others who share your passion. These interactions can renovate your thought process and provide a supportive community. The pattern also encourages studying the “classics” of software development literature, as you involve yourself in the great works can open your eyes to a more inspiring world.
Finally, the authors emphasize the importance of drawing your own map – being willing to move to an organization that better aligns with your goals, even if it means leaving a comfortable job. They warn about going against the “hero mentality” that leads to “death marches.”
As an aspiring software developer, I found this pattern insightful. The idea of caring one’s passion, even among adversity, resonates deeply. I appreciate the authors’ acknowledgment of the challenges and their suggestions for proactively addressing them. The priority on seeking kindred spirits and studying the classics is crucial. These activities can help renew my enthusiasm and provide a sense of purpose, even for future career challenges.
Additionally, the authors’ caution against the “hero mentality” and the importance of setting boundaries to protect one’s passion is a valuable lesson. I will be thinking of maintaining a sustainable pace and refusing to compromise my standards.
Overall, the “Nurture Your Passion” pattern provides a compelling framework for approaching my future career as a software developer. By actively protecting and growing my love for the craft, I believe I can navigate the profession’s ups and downs and maintain a granting, fulfilling, and consistent career. Thanks for tuning in!

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.

Sharing Strategies for Effective Exploration!

As a student studying computer science and software testing, I found the blog post “Mushroom Picking and Testing” to be a fascinating and insightful exploration of the parallels between the art of mushroom foraging and the practice of software testing. The author, a seasoned mushroom picker from Estonia, skillfully draws connections between the two various activities, highlighting the similarities in the decision-making processes, risk assessment, and the development of observational skills.
The blog post begins by describing the author’s love for mushroom picking, a tradition rooted in their Estonian heritage. Interestingly, the author finds this activity to be a meditative and reflective experience, where one part of the mind focuses on the task at hand while the other have multiple thoughts and ideas. It is within this state that the author discovers the similarities between mushroom picking and software testing.
One of the key parallels drawn is the concept of “choice of location vs. product coverage.” Just as the author visits familiar forests to efficiently collect a good amount of mushrooms, software testers may focus on keep on testing the same areas of a product, limiting their vision and potentially missing new or exciting discoveries. The blog post encourages readers to pinpoint a balance between depth and breadth, considering the mission and objectives when deciding how to grant their time and resources.
Another comparison I found is the importance of making preparations before starting on either attempt. The author discusses the need to gather the necessary tools and equipment, as well as staying informed about environmental factors and recent changes that could impact the success of the task. Similarly, in software testing, it is crucial to have the right tools and knowledge about the product and its recent updates to make informed decisions and effectively approach the testing process.
I would say the most eye opening aspect of the blog post is the discussion around “knowing your oracles.” The author explains the importance of recognizing poisonous mushrooms, a skill passed down through generations. This concept directly translates to software testing, where testers must develop a deep understanding of the product’s characteristics and potential issues, rather than relying on a more questioning or searching.
As a software testing student, I found this blog post to be a refreshing and wise point of view on the craft of testing. The author’s ability to draw parallels between these two seemingly unrelated activities has provided me with a new lens through which to approach my studies and future practice. The emphasis on searching for more, risk-taking, and the development of observational skills are all elements that I will strive to plug into my testing methodology. This blog post has not only expanded my understanding of software testing but has also inspired me to continue the unexpected connections between the physical world and the digital realm.

April 14, 2024
andicuni

https://thepainandgainofedwardbear.wordpress.com/2017/09

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

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 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.

A Software QA Student’s Guide to Impactful Code Documentation

Hey everyone! I found the article “Elevating Your Test Automation Projects With Meaningful Code Documentation” to be a valuable resource that directly relates to the course material. The article begins by highlighting the common challenges faced when trying to understand existing automated test code, such as unclear naming conventions and a lack of explanatory comments or documentation. Dickson emphasizes the importance of documenting code to ensure that both new and experienced team members can easily comprehend the purpose and functionality of the automated tests.
One of the key points discussed in the article is the effective use of comments. Dickson outlines two simple rules for writing meaningful comments: avoiding redundancy and being informative and concise. She provides an example of a Cypress test where the description of the test case made the additional comments unnecessary, as the test was already self-explanatory. On the other hand, Dickson suggests adding comments to explain the purpose and implementation of more complex code.
Another valuable documentation technique covered in the article is the use of docstrings. Dickson explains how docstrings, which are associated with specific code blocks, can greatly improve the reusability of the code. She demonstrates the power of docstrings by showing how they can provide information about function parameters, return values, and usage examples, making it easier for collaborators to understand and effectively utilize the code.
Dickson outlines several popular naming conventions and explains the benefits of using descriptive and consistent names for variables, functions, classes, and files. She highlights how these naming conventions can enhance the readability and organization of the codebase, ultimately making it more maintainable and collaborative.
As a software quality assurance student, I found this article to be particularly relevant and helpful. The author’s clear explanations and examples have assisted my understanding of the role that code documentation plays in the success of test automation projects. I can already can imagine applying these practices in my own future work, where I will continue to create well-documented and easily understandable test automation code.
Furthermore, the article’s emphasis on collaboration and code reusability stays with me, as I recognize the importance of working effectively with cross-functional teams in the software development process. By prioritizing meaningful code documentation, I can make sure that my fellow team members can understand and build upon the automated tests I create.
In conclusion, “Elevating Your Test Automation Projects With Meaningful Code Documentation” is a vital resource that has pushed my thinking for the role of code documentation in software quality assurance. The author’s practical advice has provided me with the knowledge and tools to enhance the readability, maintainability, and collaboration within my own test automation projects. I am confident that applying these principles will lead to more efficient and effective test automation, ultimately contributing to the overall quality and success of the software I help develop.

April 7, 2024
andicuni
https://www.ministryoftesting.com/articles/elevating-your-test-automation-projects-with-meaningful-code-documentation

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.

Week 7 blog

HI everyone, welcome back to my blog. In this post, I will be talking about two patterns from the apprenticeship patterns book that was provided to us in the beginning of the semester. We will be going to go more in depth about how you should reflect as you work and how to record as you work, which I think goes hand in hand in my opinion. First, let’s talk about recording what you learn. There is this saying that my dad always used to tell me was that those who don’t learn from their mistakes are the ones doomed to repeat it. There are a lot of things that you can do to help you with that. For example, you can start recording your journey of what worked and what doesn’t in a sort of blog or personal journal. I know some people who write those things down and never go back and read them ever, what’s the point? Don’t just write it down, try to think about it and review it later, just to freshen up. You never know, you might discover something new or old that will help you and will help you avoid making the same mistakes again. I personally do not write anything down and I have a terrible memory, so I should probably start writing things down, and it will help me get better by giving myself something to look forward to and learn from.

The second pattern I want to go over is the ability to reflect as you work. Ask yourself questions, like how did I get here or how can I improve? It doesn’t have to be questions about yourself, you can say how can we improve as a team? This will make you observe and reflect on things about yourself and the environment around you. I believe that this goes hand in hand with the first pattern because you can observe yourself and ask questions regularly and then write the conclusion down of what you have learned from this experience. Personally, I will start my own daily private journal so I can be constructive with myself and honest to try and improve my everyday life.

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

Sprint Retrospective Blog #1

Hi everyone, my name is Abdullah Farouk, for those who didn’t know, 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 the first sprint. This sprint consisted of us getting familiar with libre food pantry more and to see how this scrum framework actually go. 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 teammates 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 didn’t work out well was how we weighed the issues in the beginning. Some of the issues took less than what we had anticipated, and some took way longer, to the point that we finished only half of the last issue left for the sprint and therefor had to leave the issue to next sprint. Another thing that we were struggling with was communicating outside of class time. I take some of the blame myself as I do not have discord installed on my phone and therefore, I only check it at night time or when I get home from work. 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 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, I will try to check discord more often to communicate better with my team. 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/generatewcfbreportfrontend/-/issues/33

  • Moved “commands” to “bin” and added a cspell folder to make sure the spelling are right. Merged and pushed the issue.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/32

  • I sat up to work with VS code in Gitpod rather than devcontainer which was a little bit tricky because I didn’t know what gitpod was until that moment.

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

  • Me and one other classmate looked at the check inventory frontend and examined the code to see what it was missing and what it could get better at.

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

week 5 blog

Individual apprenticeship pattern blog post- Use your title.

Hi all and welcome to my blog where today I will be talking about the pattern “Use your title.” This pattern caught my attention for several reasons that I will go through in this blog post in detail. First, let’s start by explaining the pattern itself and give a little context of where the title comes from. Let’s say you work at a job and they give you a certain title, like “assistant pharmacist”. Some time later they will want to promote you. The title of your position will change but you are still going to get paid the same amount. For example, I was known as “CAD assistant designer” for a little bit in the beginning of my job. I worked hard for like 3 years, then I got “promoted” to “CAD designer” which means I am no longer an assistant designer. My responsibilities changed with it. The pay might be the same but others in the office, or even outside the office, will respect you more because of that title. My responsibilities are much different now.

If the Job title doesn’t match the description of what you see yourself doing, then there are things that you can do to change that. It stated the job description is a distraction and should be kept on the outskirts of your consciousness, but I don’t think I agree with that. For me, a job title is something that you should be proud of. If I am not proud of my job title, that just gives me more fire to try and work harder to get the job title I deserve. To solve this problem, you should write down a description of your job title and make sure it fits the work you do in the office and try to give details as if a stranger is reading your job description. Sometimes your job title does reflect the work you do, you could be indicated into a position of authority on your team but it doesn’t state that in the job description which is fine as long as everyone respects you and sees the work you are putting in.

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

Apprenticeship Patterns Intro

Dave’s Story

The narrative of Dave’s journey serves as an illustrative example of how apprenticeship patterns can contribute to personal growth in software development. It emphasizes the importance of mentors, the willingness to expose ignorance, and the value of continuous learning and experimentation. Dave’s story underlines the idea that apprenticeship is a dynamic and evolving process, shaped by experiences, challenges, and the pursuit of improvement.

What Is Software Craftsmanship?

It critiques existing definitions of software craftsmanship, drawing inspiration from medieval craft models. While it rejects a rigid hierarchical structure but advocates for a modern craft studio where practitioners are free to innovate. The author also emphasizes the need for a community united by shared values, such as a growth mindset, adaptability, pragmatism, openness to sharing knowledge, and dedication to self-improvement.

Roles in Software Craftsmanship

The passage outlines three key roles in software craftsmanship: apprentice, journeyman, and master. Apprentices focus on personal growth, learning, and building foundational skills. Journeymen expand their responsibilities to include communication, mentoring, and portfolio building. Masters not only excel in their craft but also contribute to the industry’s advancement, mentoring others and creating tools or techniques that elevate the entire community.

What Is Apprenticeship?

The concept of apprenticeship is explored as a way for individuals to learn about professional software development. It is portrayed as a mindset, acknowledging that not everyone has the luxury of a formal apprenticeship and that many must create their own learning opportunities in less-than-ideal situations. The text encourages individuals to recognize their position at the beginning of their career and actively seek opportunities for learning and growth.

What Is an Apprenticeship Pattern?

The authors introduce apprenticeship patterns as guidance for career progression in software development. These patterns, extracted from personal experiences and practitioner interviews, offer flexible solutions to common challenges. The book is structured as a pattern language, allowing readers to choose, combine, and adapt patterns based on their unique circumstances.

Reflection

Through the reading felt very connected to Chapater 6 which focused on the
Idea that there is so much to learn but only one of you. I often find myself overwhelmed trying to learn as much as possible just to be versatile. Whether that be multiple languages, IDEs, frameworks, or anything in between. I finally was able to take some time to create a roadmap that I could follow that would better help me achieve my end goal of becoming a full-stack developer. This map focuses more on understanding over forcing content down someone’s throat and allowing the user time to properly learn and experience the tools needed to reach my goal.

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.