Category Archives: Week12

Version Control: Why It Matters in Software Development

Version control is something I’ve used before in classes, but I never fully understood its importance until I read the Atlassian article, “What is Version Control?” (https://www.atlassian.com/git/tutorials/what-is-version-control). I selected this resource because Atlassian explains technical concepts in a way that feels practical and industry-focused, which fits perfectly with what we are learning in CS-348. Since this course emphasizes collaboration, documentation, project organization, and professional tools, I wanted to learn more about how version control actually supports real-world software development.

The article defines version control as the practice of tracking and managing changes to code. What stood out to me is that version control isn’t just for “saving work”, it’s a full system that captures every change, who made it, when it was made, and why. Atlassian highlights how this creates a long-term project history that developers can search through, compare, or revert. This directly connects to our CS-348 topics like software maintenance, project management, documentation standards, and team collaboration, because version control supports all of these practices behind the scenes.

The resource also explains how version control allows teams to work on separate branches, make experimental changes, fix bugs, or build features without interfering with one another. This connected with my experience in this course because when we work on group projects or assignments, version control prevents us from overwriting each other’s work. The article also discusses merge conflicts, and reading about it made me feel better about the moments when I’ve run into conflicts myself. Instead of seeing them as mistakes, the article made me realize they are a normal part of teamwork and software development.

One major takeaway for me was the idea of traceability. Every commit tells a story, not just about the code, but about decisions, goals, and teamwork. This encouraged me to treat commit messages more seriously so that my future teammates (or even future me) can understand the purpose behind changes. The article made me realize that version control isn’t just a technical tool; it is a communication tool. This is something I didn’t appreciate before reading it.

This resource affected how I view my future practice because version control is required in almost every professional software environment. Reading about how teams rely on it to avoid lost work, manage parallel development, and maintain high-quality software helped me understand why CS-348 emphasizes collaboration tools, project organization, and documentation. Going forward, I plan to use branching more intentionally, commit more frequently, and write clearer commit messages. I also want to apply what I learned outside of class by using version control for my personal and club-related tech projects.

Overall, this article helped me connect the technical skills we practice in CS-348 to how real development teams work. It showed me that version control supports not just code, but communication, teamwork, and professionalism — all skills I want to continue developing.

Source

Atlassian. What is version control. Retrieved from https://www.atlassian.com/git/tutorials/what-is-version-control

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi 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.

Draw your own map

As the semester comes to a close and I’m getting ever so closer to entering the workforce, the Draw Your Own Map pattern stuck out to me most. Especially since there is much unknown coming soon, and as I start my career, I am sure that I’ll encounter many situations that I would not expect or be familiar with.

Essentially, the Draw Your Own Map pattern deals with your goals and how you achieve them. Although it might be straightforward and easy to say, I want to be at XXX company in X years, or try to save YYY after Y years, it is much harder to break down the smaller short term goals, and that is what the Draw Your Own Map pattern deals with.

As important as it is to have long term goals, without the smaller steps along the way, you might find yourself lost as you pursue your dreams. Not only that, but these small steps allow you to formulate or cement your long term goals too! For example, if you find that as you work on your short term goals, you might realize that your goals in the long term actually aren’t where you want to be. It’ll allow you to pivot if you need to, and if you find that things are perfectly fine, then all the more reason to keep on striving for what you need to do!

Another important part of the pattern is that your map is connected with many other things in your life. A solid map will allow you to connect with “Kindred Spirits” or it’ll give you more “Sustainable motivations.” It’s all interconnected! A solid map will be your road map to course your journey, and though you can never plan for everything. After all, a map with some directions is better than none at all!

And finally, though I realize the importance of a map, if anyone is like me, I think it is also okay to NOT have a map. At least, right away. A map should be made soon, hopefully the earlier the better, but things are always unknown. It’s very easy to just say hey, do this, or do that, but in actuality, it is a bit more difficult. Especially when it comes to something as important as the course of your career or even your life. Instead, it’s okay to make a smaller map. Whether it be a map charting your next 100 steps, or a map for your next three, the point is to just draw a map!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Nurture Your Passion

I chose this pattern this week because I really need to work on growing my passion for the craft. I need to sit down and find something I love and make a correlation to software. This pattern taught me different ways to nurture and grow your passion so that you can dive deep into complicated projects, for fun. The authors mention 3 other patterns to help you grow your passion. These other patterns are Kindred Spirits, Study The Classics and Draw your own map. These three patterns will help you take the next step to loving the software craftsmanship.

My favorite excerpt form this passage was:

“To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This might mean you leave work while the rest of the team stays late, that you walk out of a meeting that has become abusive, that you steer a cynical conversation toward constructive topics, or that you refuse to distribute code that doesn’t meet your minimum standards. The result could be that you get passed over for pay raises, promotions, kudos, or popularity. But these boundaries are necessary if you are going to break free of hostile conditions and keep your passion strong.” – Adewale Oshineye, Dave Hoover

Basically, the authors are saying to stick to your code and don’t let yourself be abused. If you or your skills are being abused in the work place, it can greatly damage your passion for working on software. You want to stay positive and continue to love what you’re doing, it is the only way to cease your passion from leaving.

As I mentioned before, this pattern is important to me because I need to work on finding my passion. It isn’t always easy to sit down and work on a fun project just for the hell of it, but this pattern shows me that it truly is invaluable. All you need is time and patience to further your knowledge and skills of the craft. Developing a passion is something that I have been trying to do with school projects and what not but it needs to be more. Being passionate about a project would just be a kickstarter to become passionate for every step of software development.

 

You can find this pattern here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s04.html

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Pattern : Reflect as You Work

Pattern Overview :

The author begins this chapter by introducing the importance of reflections in one’s career. As a software developer, the more progress  and tasks you complete everyday in your line of work inches you daily to mastery level. This comes along with an acknowledgement of strengths by your leaders thereby often leading to a promotion or elevation in position where your knowledged skills and expertise can be passed on to someone else. This is why the author encourages us in this pattern to constantly reflect back on our work. Being a good leader covers a wide range of expectation but one of the biggest  leadership qualities is to be able to lead by example. You can’t preach clean coding when you haven’t taken the time to introduce clean coding in your own coding practices. 

 

Reflection:

I agree with the author on this pattern greatly. This is because through out my little experience in life, i have had many opportunities to lead and i have realized that understanding yourself, methods, shortcomings and practices helps you become the best leader you can be. And the only way you can accomplish all the above mentioned feats is to take the time and reflect. I bring up all these points because as you continue to lead the team, there will be days when the questions and daily challenges will force you to define and defend your views and methods as a leader. If you have not taken the time to reflect and acknowledge what needs to be acknowledged about you, moments like this will eventually be your downfall as a leader. It will send a messages of incompetence.  As a leader, its part of your job to ensure that your voice somehow become the sound of reason for your team when things go downward. 

Conclusion :

I would advice everyone to practice some of the methods the author talked about especially the personal practice map. This is because, it gives you a vivid image of your progress through the years and also gives you a reference point to share with your team members who have similar issues and questions. It also helps you to highlight your observations, reflections, and changes that has happened throughout your programming years.  

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Clean Coding- Coding Blocks

Episode 49 – Clean Code – Comments Are Lies

 

 

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, the authors discuss about creating good and clean code and eliminating as much comments as possible. Initially, I was very confused with this concept by pro developers because in my first intro to java class, my teacher emphasized on making sure that we adequately commented thoroughly on methods and functions that we wrote. There were even points that was taken for now properly commenting codes then all of a sudden, my CS 443 my professor tells me that commenting is not really a good practice since your code should be written so well that understanding the though process and program should very easy. But the more I thought about this, the more I understood what was being taught by the teacher and now this podcast episode. No one writes comments for print statements because it’s so rudimentary that, everyone basically understands it by looking at it. That’s how our algorithms should be designs. Code Readability and understanding should be the goal of all developers who walk out of school. Again using comments in clean code has its pros and cons. They almost never get updated while the code gets updated and fix. They tend to mislead because they are not often updated. They propagate lies and misinformation’s because as the code gets modified and updated, they are often left untouched. The only exception to this rule of thumb is when one is coding a public API that would be used by other developers. Comments are looked as a way for programmers to make up for their shortcomings in programing. If methods and variables are named and designed properly there would be no need commenting. Time used to create comments can be used to optimize the software program to increase its readability and logic flow. Another bad thing about comments is when they are not obsolete but just misleading. Also inaccurate comments put the developer in the wrong frame of mind and logic. The proper approach is utilizing refactoring and clean code techniques that build program structure and design instead of attempting to explain bad coding with comments. Ultimately, it makes sense that developers wanted to explain their thoughts and processes with comment but its just more effective when the thought process is explained in the logic and functionality of the codes and method.

 

 

Link – Episode 49

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/episode-49-clean-code-comments-are-lies

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

#6 – Testing Talks

Testing Talks – Episode 169 With JeanAnn Harrison.

 

In this week’s testing podcast episode, Joe interviews JeanAnn, a Software testing manager who has been in the software quality assurance field for over 2 decades. JeanAnn begins by addressing techniques and best practices that make for a fluid testing process. I chose this particular episode because JeanAnn addressed automation in testing and critical thinking in testing. With the development of modern technology, software automation is the next big thing in the world today.

Another big thing she talked about was critical thinking. Critical thinking often refers to the ability to try different thought processes and develop new methodologies to achieve an already familiar goal. The ability to think outside the box, pushing yourself to look at things in a different way. To evolve ones thinking ability in testing, we can try to look at things outside the software-testing field. By doing this, one is able to develop logical means that are often necessary to find product boundaries and limits. Asking yourself questions like how? , when? , what ? , where ?. These simple questions often answers most of the questions for the software testers and help develop solutions and bugs that need to found. By asking these questions, you are able to see how the software or product could be integrated into computer systems, the kind of problems that can arise by implementing the new product/technology and what can be done to resolve issues should they arrive. Another big thing that she addressed was understanding software’s users and customer base. Developing apps and programs without expected audience leads to many problems in the software world. Imagine developing a mobile application for 70 year olds but its integrated into the latest iphone technology. This would not work out because most of the people in that range no longer have the ability to adapt to new technology or even use a cellular device. Again imagine developing a walker for blind people which has an activation switch installed on the side with an on and off reading. This will be physically challenging and difficult for the blind to optimally use the product. It might be the best product that all blind people needs but its inability to incorporate and account for the blind would instantly make it a bad design or a bad product to acquire. Simply put if you know your user base, you are able to find out what needs to be designed for the product to properly fit the needs of the users and customers.

 

 

LINK

 

https://testingpodcast.com/169-critical-thinking-in-testing-with-jeanann-harrison/

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.