Category Archives: cs-wsu

Keep the Code Simple.

In software development, simplicity is further required in coding. It is the foundation of how software genuinely works. Every line of code we write in system, from short programs to large systems, teaches us one major lesson: keeping code simple leads to stronger, cleaner, and further reliable software. When code is simple, it becomes easier to understand how each part of a program interacts, how data flows through the system, and how changes can be made without breaking additional components.

Throughout our computer science class, we learn that writing code is not just about making something run, it’s about designing how it runs. Concepts like encapsulation, abstraction, and modularity form the heart of this process. Encapsulation keeps data protected and managed within defined boundaries. Abstraction allows us to hide unnecessary details so that only the important parts are visible to the developer. Modularity divides complex programs into smaller, independent sections that can be developed, tested, and improved separately. These principles not only make programs easier to understand but also reflect how big software plans are built in real-world projects.

Simplicity also plays pivotal role in collaboration. When multiple developers work on the same clear and consistent code, it allows everyone to read, modify, and contribute without confusion. In our group projects, clear code helps everyone understand and contribute easily. Even when we continue working from home, the project feels simple and organized, not stressful. This clarity saves time, reduces errors, and keeps teamwork smooth.

Another reason simplicity matters are maintenance. As we study different programming software models, we see that maintaining complex code can become easy to modify and frustrating. Clean, readable code allows group members to trace logic quickly and identify issues before they cause system failures. This is why experienced programmers often say, “Code is read more often than it is written.” The goal is not to write the most advanced or impressive code, but to write the most understandable and dependable one.

Keeping code simple also encourages better thinking. It forces us to focus on problem-solving rather than decoration. By keeping things simple, we learn to study the requirements carefully, organize the program’s structure wisely, and create efficient code that works effectively without unnecessary lines. Simplicity shows real understanding of how software functions at its core.

As I continue learning software design, I realize that simplicity is not the opposite of intelligence, it is the best outcome of experience and clarity. The coders don’t make code complex; they make it clear. True creativity in programming lies not in how much we write, but in how well it makes as simple—and that always begins with keeping the code simple.

From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.

Blog Post for Quarter 2

October 21st, 2025

Recently, my class has been going over stuff regarding teamwork and ways to approach building a software or product. For example, the waterfall method, agile methodology, and scrum have come up in discussion. This has reminded me of POGIL since POGIL was a group used in the classroom semi-frequently.

Because of this correlation, I decide to look at blogs about POGIL. However, I noticed something interesting about the blog I chose. So I chose two just because I found some things interesting. The first was made with WordPress.com, much like the one I’m making here. It was about POGIL. The blog appeared to just be called “The POGIL Project.” Or, that’s what I have surmised after looking at the web address. Additionally, there was some interesting notes regarding how it appears to be designed for faculty teaching or implementing POGIL based team activities. However, the last post appears to be in 2015, which is not as recent as I’d like. (However, there appears to be someone who has the same name as the author of this blog who is cited to be impactful to the development of POGIL. Which is pretty cool, though I couldn’t concretely find evidence that they were the same person.)

So, I looked for an alternative. The author was not listed which isn’t great but it is recent. It appears to also be about POGIL. But the most interesting part was how it was applied to science as opposed to actual computer science. Actually, both blogs do that as well.

This new blog I picked was basically an overview of how POGIL works and why it is good to use. It overviewed the reasons why POGIL is used and what it is intended to do. It basically overlaps with what I know about POGIL already.

In a way, this is interesting in how this mean POGIL is both universal and useful. It isn’t just a weird Computer Science class thing we do, it’s an actual science thing. Which is definitely more interesting to know about considering I rarely encountered POGIL before college. It probably won’t really affect my opinion on POGIL but it is mildly interesting how it is something that I’ll see around. I guess I can keep that in mind.

FIRST INITIAL BLOG: https://thepogilproject.wordpress.com/

SECOND, REVIEWED BLOG POST: https://www.transtutor.blog/pogil-guide-high-school-biology

From the blog CS@Worcester – Ryan's Blog Maybe. by Ryan N and used with permission of the author. All other rights reserved by the author.

Blog Post for Quarter 1

October 5th, 2025

Recently, I’ve been working on using Git. This came in the form of using a little bit of GitHub, a little bit of GitLab, and the textbook made to help instruct me on how to use them. I began to learn the basics of repositories, and how to make edits and pull requests.

For example, I am now able to create a fork from a repository, create a remote origin, a clone of that onto my local device, make edits using Visual Studio Code, stage those edits, commit those edits, push those edits back to my remote origin, then establish a pull request. And a little bit more. So far, this Quarter of my class has been pretty interesting. I will note how the public changes and such are very interesting to me. I don’t usually like being in public places often because I assume I should be competent before doing anything in public, but oh well.

For the blog post I selected, I wanted to know just a smidge more about Git, since I was learning about it. (This will be linked below at the bottom of this post.) It mostly discusses the future plans for Git and potential for AI.

Honestly, there isn’t much for me to really do from this. I just note how AI appears to be Git stuff I currently use, so that’s mildly interesting. Though, I found it interesting that Git, much like I, is currently developing. It’s fun to think about how I learn and improve as a person that other things in the world are doing the same. While they are wildly different contexts, I find it cool. Everything is always changing and such. Even as I learn, I make notes that aren’t in the textbook to myself. Git will probably always get things added by various different people as well.

It encourages and intimidates me in some way. It’s very cool that by the time I “get caught up” it’ll be better than what I’m currently using, but at the same time, what if everything I learned becomes redundant? Though, for me, I was always a person to enjoy experiences, and I never really liked the idea of a limit. If anything, it is just more “fun” for me. There’s more to learn and I’ll never be caught up. My experiences will lead to my growth, so when the time comes, I’ll be much more suited to using the new tools that arrive.

https://github.blog/open-source/whats-next-for-git-20-years-in-the-community-is-still-pushing-forward/

From the blog CS@Worcester – Ryan's Blog Maybe. by Ryan N and used with permission of the author. All other rights reserved by the author.

Unlocking Encapsulation: Why Data Hiding Matters

I came across an article on Titled “Encapsulation in Object Oriented Programming”. It Explores in detail about the core principles of object-oriented Programming (OOP): encapsulations. Although I had already heard about this concept in computer science class, that time just covered the minor details and definition without really understanding why it is so important in practice. Reading this article helped me see encapsulation in a new way, especially through real-world examples and comparisons that made the idea much easier to grasp.

               Encapsulation is explained as hiding the internal details of a class and only allowing controlled access through methods. This is usually done by keeping variables private and providing getters and setters for interaction. According to the article, errors can easily occur when other program pieces change an object’s state directly in the absence of encapsulation. However, with encapsulation, updates are subject to predetermined guidelines, maintaining the system’s unity and security.

               One of the examples that stood out to me compared encapsulation to locking a house. If all the doors and windows are left open, anyone can come in and move things around. In programming terms, that would be like exposing all fields of a class as public. By contrast, encapsulation is like keeping the house locked and only providing a few keys for safe entry. In the same way that you wouldn’t give full write access to everyone on a GitHub repository, you don’t want every part of a program to freely change the internal state of your objects. Instead, you provide limited access—like adding collaborators with specific permissions or using pull requests for controlled changes. This analogy helped me understand why developers stress the importance of data hiding: it keeps things organized, prevents misuse, and ensures that changes happen in a safe, predictable way.

               The article provided an actual scenario using a bank account class. Any piece of code might set a balanced variable to a negative value if it is public, which would go against the program’s logic. However, the application may set restrictions like “balance cannot go below zero” if the balance is private and is only accessible via the deposit() or withdraw() methods. This demonstrated to me how encapsulation guarantees that critical rules are always observed while also hiding information.

               What I learned from the article is that encapsulation goes beyond coding style—it’s about safeguarding data and ensuring programs behave correctly. A helpful way to picture it is how GitHub handles collaboration. Instead of letting everyone edit the main project directly, contributors usually fork the repository, make changes in their own copy, and then open a pull request for review. This process keeps the main branch stable while still allowing improvements, like what we practiced in our CS343 and CS348 classes at WSU.

               Overall, the article provides the details we need to practice and build stronger knowledge in the basics of the field.

References:

“Encapsulation in Object Oriented Programming” by AKshay Raut (Medium)
↪ https://akshayraut.medium.com/encapsulation-in-object-oriented-programming-4cfb0ee28f12

FreeCodeCamp. (n.d.). The Four Pillars of Object-Oriented Programming. https://www.freecodecamp.org/news/four-pillars-of-object-oriented-programming/

From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.

Introduction Blog

Hello, My name is Aksh Patel, and this is my introduction blog. I am a senior year Worcester State University student. My major is Computer Science and i am more interested Design Technique.

I will take CS-343 class to learn about more in my interesting stuff.

From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.

Introduction to CS-348 Blog!

To all of the CS-348 students, welcome to my CS-348 blog!

This is where I will write about some new techniques that you may or may not be familiar with in computer science, particularly software management. From here, we can all learn together and share our knowledge, which can improve our programming skills throughout the semester.

A little bit about myself, my name is Nguyen Vuong. I’m a senior Computer Science major at Worcester State University. As a senior, I’m happy to share my knowledge and skills in the hope that it could help you get through the years more easily.

I also make mistakes a lot, and love to learn new things. So, feel free to share what you have, and we will all study it together! Let’s all look forward to a great year!

Nguyen Vuong

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Introduction to CS-343 blog

To all of the CS-343 students, welcome to my CS-343 blog!

This is where I will write about some new techniques that you may or may not be familiar with in computer science, particularly software construction and architecture. From here, we can all learn together and share our knowledge, which can improve our programming skills throughout the semester.

A little bit about myself, my name is Nguyen Vuong. I’m a senior Computer Science major at Worcester State University. As a senior, I’m happy to share my knowledge and skills in the hope that it could help you get through the years more easily.

I also make mistakes a lot, and love to learn new things. So, feel free to share what you have, and we will all study it together! Let’s all look forward to a great year!

Nguyen Vuong

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Blog Post 1

September 8th, 2025

Hello! This is a blog? Probably. As a current student, I will (hopefully) be blogging about my experiences in Computer Science. Otherwise, I don’t really know what to do with this. Anyhow:

I currently have some experience with code. I took AP Computer Science in high school, and a Game Design Class (technically twice by two different teachers due to a mix-up in my high school schedule, but frankly, they did different things so I don’t actually regret it.)
This gives me experience with both Python and Java, although at a beginner level. Additionally, my First Year Seminar class refreshed me on Python, and I took the beginner Unix Systems Programming, which taught me a little bit of C.

I did use Scratch to make a game back in high school but I was atrocious at it. I remember having a habit of over complicating my stuff too. Especially in my Game Design Class. I took AP Computer Science the same year as it and because all the other students were seniors, my teacher let me work on my Game Design stuff after the seniors graduated. I took twice as long as everyone else and barely finished my “game.” (Officially, I never finished it and passed in a partially modified older project.) I am near certain the teacher just let it slide because I was working despite having no official assignments in AP Computer Science and helping people in my game design class. (I have like, 2 unfinished projects? Both were intended to be my final program for my Game Design Class, but neither were passed in.)

The reason I decided to pursue Computer Science was pretty simple: I thought video games were cool. Then I just went for it, and it was okay. I had some classes in high school but nothing complicated. But as time went on, I eventually went into my AP Computer Science class which I did okay in. One day, the teacher said I “have a passion” for Computer Science. Frankly, I thought that was a weird statement since I didn’t really do that much coding nor was I particularly good at it, but it made me feel good about myself so here I am. (Nowadays I hear of my cousins swapping Majors from Computer Science to basically anything else so I’m either doing okay or making a grave mistake. Oh well.)

Anyhow, that’s my current experience with Computer Science and I guess I’ll give you all an update later on.

Thanks for Reading,
Ryan Nguyen

From the blog CS@Worcester – Ryan's Blog Maybe. by Ryan N and used with permission of the author. All other rights reserved by the author.

Nurse to Developer

One woman’s journey from animal medicine to tech

About

After 12 years in the veterinary medicine field as a nurse, I am actively focused on a career shift into computer science, specifically in software engineering.

This blog is where I will document my technological discoveries, achievements, setbacks, and anything else that contributes to conquering my career goals.

From the blog cs-wsu – Anna The Dev by Adrianna Frazier and used with permission of the author. All other rights reserved by the author.

Sprint 3

During sprint 3, I kept working on the frontend, like the last sprint, I had been stuck trying to get the backend up, while trying to work on the frontend. I had a teammate work with me for this sprint to complete it. We worked on two different branches, mine and Jason’s.  Inside my branch, I was having a problem starting up the frontend through development mode, so I decided to see the original branch and work back into the updates I had made. Jason was able to start the frontend without the backend using dev. This gave me the advantage of designing the frontend and seeing what would work. Working with someone this sprint improved the sprint overall for me because last sprint, everyone else was in the backend while I was working in the frontend. My teammates were helpful, but without working with someone directly in the frontend, it was difficult to get help on exactly what I needed.  

First starting on the design, I had noticed that I had to make the banners and everything the perfect size, or it wouldn’t be eye-appealing. Small things like having the top and bottom borders being same size were important. One of my biggest problems was attempting to make sure the page could fit on one page without having to scroll, because, first, designing the front end, there would be empty white space that wasn’t needed, or having the logos be too small. But I was able to persevere and have a design that I was proud of. I also have to give credit to Byron, who posted his design, which I translated into my design. It helped in choosing what logos should be prioritized and gives the frontend a coherent design.

  For this sprint, I would choose Kindred Spirits as the pattern that most resonated with me. This pattern highlights the importance of working together and working with someone who is like-minded and is determined to learn and accomplish their goals. This is great to have in a team because it allows teammate to grow together while also accomplishing their tasks. Working with a teammate this sprint greatly affected the amount of work I was able to accomplish. I was able to complete more in a shorter amount of time given. Directly working with Jason during this sprint gave me more insight into the issues we faced and helped me grow faster and feel more supported. Before this sprint, as I mentioned, I was isolated, working on the frontend by myself. It was difficult to troubleshoot my work with others because they were working on different aspects of the project, mostly in the backend. My teammates were helpful in what they could help me with, but there was always a disconnect because I didn’t want to slow them down on their work, and they were working on the backend. Working in collaboration with Jason allowed me to exchange ideas and confirm each other’s work. It gave me more confidence to ask questions because we were working in unison on the same problem. If I had been aware of this pattern earlier, I would have gotten a partner sooner because working in isolation isn’t a deterrent to just you but to the whole team.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.