URL: https://semaphoreci.com/blog/test-driven-development
The blog in question was written by Ferdinando Santacroce on Sephamore. The title is Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software. He walks his readers through many topics related to Test-Driven Development. These topics include TDD as a design practice, TDD as a well-established engineering practice, and many others.

Test-Driven Development caught my attention because it implies that the inverse of traditional testing should be done. Instead of writing tests for existing code, you should rather write tests for code that has yet to be written. This is confusing in some ways and also misleading when considering only the phrase “Test-Driven Development.” However, as we all know, every concept means more than just the words it comprises. And TDD (or Test-Driven Development) follows the same rule—it is much more than simply writing tests first.

I would personally call it a way of thinking or a different point of view on how tests and code are written. TDD resembles Agile and Scrum’s approach to software development. It shifts the developer’s focus from simply producing and creating large amounts of code—where everything eventually becomes one big entity—to a much more structured and manageable process. As Agile methodology suggests, it is better to build, review, test, and repeat. This method, combined with Scrum, takes this perspective further. Small chunks of functionality are built in shorter time frames, allowing for continuous review and feedback.

TDD applies the same principle with one key difference: test first—or at least, write your tests first. By writing down what should be tested and what a program should return or produce, you now have a clear goal. This method shifts the traditional way of thinking and provides a clear path to the main objective. This objective is then broken down into many smaller pieces that are easier to understand. Another benefit of TDD is the constant feedback, often called a “pleasing side effect.” Continuously receiving feedback on your code gives you a steady sense of accomplishment.

The outcomes of introducing Test-Driven Development into one’s development process can bring many benefits. However, beneficial outcomes are not guaranteed for every single person who applies this methodology. That said, I would argue that certain developers may benefit more than others. Developers who often feel lost, confused, or disoriented may benefit greatly from Test-Driven Development. This approach provides them with a clear understanding of the code’s structure in a more modular and organized way. By separating the code’s functions into different sections, building blocks, or containers, TDD creates a more structured and efficient development environment.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

URL: https://getdx.com/blog/software-collaboration/

During this past semester, I learned more about what collaboration is and why it is so important. Collaboration is something that I personally find essential and key in software development. However, this semester, I learned the hard way how problematic the lack of collaboration from someone can be and how harmful it can be to a team. It doesn’t just divert attention from the focus, but it also disrupts the workflow and creates unnecessary stress. I don’t say this because I am the most collaborative person—believe me, I’m not. At times, I can be a difficult person to collaborate with. But through experience, I learned an important lesson: when team members don’t collaborate effectively, progress is slowed, creativity is hindered, and learning opportunities are missed.

You might ask me, “How would you bring together four or five different people from diverse origins, cultures, and sometimes even languages, and make them work seamlessly as a team?” Well, I don’t expect perfect communication or total synchronization—such perfection is simply unattainable. However, that doesn’t mean that everyone shouldn’t do their best to contribute. Does this mean the solution is cherry-picking people with similar backgrounds, races, and beliefs to simplify communication? The answer is still no. The strength of a team lies not in how similar its members are but in what they can contribute and their shared desire to grow and succeed.

Diversity within a team is also essential for solving complex problems. Individuals with different experiences and perspectives can offer unique insights and approaches that others might never consider. When people bring their varied backgrounds and creativity to the table, the possibilities for innovation and success increase significantly.

Ultimately, what matters most is the effort and willingness of each team member to collaborate and complete the work. Agile methodologies and Scrum are two approaches that I have found particularly effective in fostering a culture of communication and collaboration. Frequent check-ins, meetings, and milestone-based planning make it easier to stay aligned and on track as a team.

One blog post I came across this semester made me reflect on the importance of addressing issues directly. Ignoring problems, whether personal or within a team, doesn’t make them go away; it only exacerbates them. This realization pushed me to focus on self-improvement by being more open to new and different ideas. Even if an idea isn’t the most ideal solution, it can still lead to success.

Finally, open-source software is something I was unfamiliar with before. Now, I’m eager to contribute to such projects, especially those aimed at making a positive impact on the world.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

URLs:
Article on SOLID: https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/
Video mentioned: https://www.youtube.com/watch?v=j-6N3bLgYyQ

One video has always caught my attention because it clearly illustrates why SOLID principles are so important. I will reference two sources in this post for better understanding, in case you want to explore the topic further. However, I kindly ask you to watch the video linked at the beginning for my comments to make sense.

I chose an article to complement the video because it offers a more approachable explanation of SOLID principles and, as stated, explains them in plain English. The video features a dad following instructions from his kids to make a peanut butter and jelly sandwich. The issue here is that such a task may have become so automatic for us that we no longer think about every single detail involved.

How is that related to programming and SOLID principles? Well, it’s quite similar. At its core, code consists of lines and lines of instructions written for a machine to execute. To achieve the intended goal, these instructions must be precise and correct; otherwise, we can encounter numerous issues. As the video demonstrates, the lack of precision in the kids’ instructions led to some funny outcomes: first, the dad stacked two slices of bread on top of each other without doing anything else. In another instance, he ended up with a piece of bread with a “bit” of peanut butter on it, a whole bottle of jelly, and another slice of bread on top.

Did I just make a typo by saying a bottle of jelly was between two slices of bread? No, that did happen. This highlights what occurs when you assign certain instructions—or, in programming, functions (Single Responsibility Principle)—more than one purpose or intent. While a peanut butter and jelly sandwich recipe might not fully embody all five SOLID principles, the Single Responsibility Principle (S in SOLID) alone is enough to demonstrate the importance of clear and focused design in coding.

The lack of clarity and precision in the sandwich instructions led to various unwanted results. Although the instructions made sense to the kids, they didn’t work well for anyone else. Similarly, when writing code—whether for homework, work, or even personal projects—these principles should never be overlooked. I believe following such practices is part of a developer’s ethical responsibility.

At the end of the day, even if I’m the one reviewing my code a year later, I might struggle to understand it without proper adherence to these principles. You might wonder, “How is it possible not to understand what you wrote yourself?” Well, that’s exactly what happened to me yesterday while refactoring some old code. I encountered several parts that I couldn’t make sense of, so I had to revise and apply these principles to make them comprehensible.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.