After learning about test driven development in class a couple classes ago, I found myself confused as to why this process would prove itself successful in software development so I did some research and found a video on YouTube from a channel called Fireship called, “Test-Driven Development //Fun TDD Introduction with JavaScript“ While, of course, JavaScript is not currently one of the programming languages that I primarily work with, the video proved informative and educational nonetheless. The video begins by emphasizing the importance of the phrase “Red, Green, Refactor” and describes test driven development as a technique where a programmer describes the behavior of the code before proceeding to implementing that code. “Red, Green, Refactor” describes the process of, firstly, writing a failing test, then writing some code to get the test to pass, then going back and optimizing the code in a manner that suits the project requirements. 

Although I have no doubt that the majority of the confusion around this topic comes from inexperience and being in the process of learning, I certainly had questions and confusion around how and why it makes sense to put forth an implementation process for code before even writing a single line. Conceptually it makes sense to lay out the general steps to a project and attempt to anticipate some of the issues that may come up beforehand, but something about testing code that doesn’t exist is a confusing concept for me.

The video talked about different types of testing at the different levels starting with unit testing and working into more complex testing methods. Each testing method is built to cater to a different type of program that is being tested.

Generally, after watching this, it sparked curiosity around what software development would look like without testing and how the continual development of the testing process has allowed for programers to not only improve the way they work but to create more robust and successful outcomes in the results of their code. 

I think it’s interesting looking back at the first three or so years of computer science classes, learning to code in multiple different languages with different use cases and styles and intents and outcomes. Not one class between the two schools I went to and the three years I was in school worked with testing before the higher level senior year classes. This made me wonder why something so important and integral to software development such as testing code was left out of the learning process until very late.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

There is a video on YouTube from a channel called The Digital Project Manager about Project Management called, “Agile project management methodology explained (with burgers?!)”. This video talks about Project Management, a topic from our course, but more specifically, agile project management. I found this video particularly educational and informative because instead of explaining agile project management in typical terms, the methodology is described using burgers. The video explains that agile project management is all about flexibility and adaptability. The agile project management style runs through multiple cycles of project production and release, taking feedback and input from the customer and users after each release cycle. This is a very effective and efficient method of project management because it allows a smooth flow of progress while making a more accurate product based on the customers’ desires. The way that the video compared this method of project management to burgers is by suggesting that there could be a goal of making the world’s best burger and in order to do that the chef would have to make a burger, get feedback from those who try it, then make changes to the burger in order to improve it. Agile project management implies that after every round of changes, the product should (hypothetically) get better and better. This made me wonder, in a professional setting, how each of these phases of the project would be tested and improved. Further, at what point could the project/program be determined as complete and who has the authority to make that decision? Agile project management is also inherently iterative. This means that multiple iterations or cycles can be completed throughout the process of completing the project. This method is particularly successful with dynamic projects and environments such as game development and software development because the requirements for these types of projects tend to be constantly changing and developing. Agile project management is also a more flexible form of project management. Because multiple cycles of development will occur, not all of the planning for the project has to be done prior to the developing stage of the project. This allows for more flexibility and a more robust and high quality product to come out of the process. During agile project management, each sprint can be broken down into five parts: Define, Craft, Develop, Deploy, Evaluate. The evaluate phase is what allows for this method to be iterable and flexible to multiple rounds of work.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

I happened to stumble across a YouTube video by a channel called Licenseware by the title of, “A Brief History of Software Licensing – Why it exists, and why it is so important”. This video covered information about how software licensing came to be, how it is used, and why it is important in the world of software and coding. The video explains how our world has developed to become, ultimately, reliant on software for organizing and controlling everything from transportation to communication. Because of all of this, the software industry has gained many rules and regulations around when, where, why, and how software can be used. These rules and regulations are more commonly known as Software Licenses. Software Licensing is one of the topics we covered relatively early on in our course, going over the different types of licenses and their uses as well as when and in what scenarios they worked or didn’t work. The history of licensing stems from the history of copyright which came from The Copyright Act of 1710 (The Statute of Anne). This act, passed by the British Parliament, stated that authors had the right to publish and sell their work for a renewable period of time. This is relevant because Software Licensing falls under the category of Copyright Law. This is because software is ultimately seen as a type of literary work. The video goes on to talk about how the Free Software Foundation (FSF) introduced the concept of open source software which led to the development of the open source software movement and the creation of the General Public License. I found this video very interesting because, prior to watching it, I hadn’t realized to what extent and depth software licensing was similar to and fell under the umbrella of a legally documented copyright. This confusion came from the fact that open source software creates an atmosphere of open communication and sharing that doesn’t typically appear in other copyrighted pieces of work. I find it interesting that software seems to be the only field, at least to my knowledge, that has this type of sharing of information and work between other users and developers. The collaboration between maintainers, leaders, collaborators and users allows the field to expand and advance quicker and more efficiently than other fields. This video helped solidify my understanding of different licenses and the importance of not only having an active license in place but also the correct license in place. This also gave me a better concept of what to do in the future if I should choose to post any of my code online as open source material.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

This is my first blog entry! This blog will encompass the information I learn throughout my journey to achieve a degree in Computer Science. It will also contains some of the struggles, the conversations, and the growth that I experience as a minority in the field.

As a Middle Eastern Woman in a male dominated field, there have always been struggles with exclusion, micro aggressions, and passive aggressive views towards women not belonging in the field.

This blog will aim to destigmatize the idea that women don’t belong in the tech industry and shine a light on some of the discriminatory behavior that women in STEM experience in the classroom setting.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.