Byte Club with Ally

I have always been told how important communication is. In sports, in school, and in life! I thought I understood this importance and communicated well with others. This quarter really took my understanding and communication skills to the next level, and it was essential to save our project from getting stuck.

In the Beginning

During the last quarter and the beginning of this one, I would have said our communication was really good! We set up a Discord server as soon as the group was created and everyone gave regular updates. We had regular meetings with our Project Partner, worked on assignments together, and communicated if something came up to make us fall behind or just be a little inactive. Almost every day, all members were active in the channel. This was great! The epitome of good communication. Or so I thought.

Things Head South

For reader enjoyment, the heading dramatizes things quite a bit. Nothing really ‘went south’. We didn’t miss any deadlines. Our project meets the minimum viable product, and everyone survived. But things became a little less ideal about halfway into this quarter. My team is a big one (6 people including me), so we decided early on to split the work and the group into frontend (that I was a member of) and backend sections. This was an idea that we all agreed on, and I would say, looking back, that it was effective. However, it did create a divide in communication. Now, we also needed to communicate with our subteams and the team overall. This is where things started to get hairy.

One day, while we were filling out the weekly progress report, one of the frontend team members said they “didn’t really know what they were supposed to be doing right now”. This was obviously a big red flag. We didn’t have a lot of time to develop our project, so we needed every one on board. This also meant our style of communication maybe wasn’t working as well as we thought it was.

The Solution

As a response to a team member being lost, the frontend team decided to have a Zoom meeting. The communication had been pretty asynchronous up to that point, and maybe a sit down discussion in real time would help. And it did! As a team, we made a list of everything that needed to still be done and how we were going to do it. Then we made a weekly to-do list with each member’s work for the week. This worked wonders. By the end of the week, we had made more progress than we had ever before. We decided that this meeting should be a weekly thing. A short evaluation of what needs to be done, what problems came up, and a new assignment of tasks.

Reflection

My experience this quarter taught me a lot about communication. At the beginning of the project, I think that we were largely communicating with a focus on ourselves. This is what I got done. This is what I struggled with. Our communication was really just individual updates. They weren’t really team communication. It made me think of my communication and work in the team context and not just things I was assigned to do. It also taught me that sometimes you really do just need to have a meeting. Email and Discord are great, but a synchronous meeting can sometimes be better.

AngularJS is indeed not the same as Angular, and I learned this the hard way. Having no experience with Angular at all, I set out to learn it because it is the framework our project uses. I was blown away by the AngularUI built-in components in their material library, drooling at all the things I was going to do with Angular version 19. My reverie was abruptly ended when I downloaded our project requirements and saw Angular version 1.8.3. It was indeed not Angular, but the discontinued, archaic AngularJS.

Learning AngularJS

This is a fast-paced class, and I didn’t have time to dwell on my big mistake. I needed to start learning AngularJs right away. I found the resources, however, very limited. Especially because I needed to learn a new technology to an intermediate/advanced level to keep up with the current codebase.

To help others who might have to learn AngularJS, here are some of the resources I found helpful:

1. Net Ninja
   • The Net Ninja on YouTube has a great playlist with his course in AngularJS. He goes over each main concept with live examples, and all example code is also included in his Git repo. I loved how simply he explained each topic.
2. W3Schools
   • W3Schools has a whole course on AngularJS. As a very visual learner, I didn’t use it as a course but as a reference. For example, a lot of my work this week had to do with creating tables. Using the reference on AngularJS tables was so helpful. They showed different ways to use the ng-repeat and filter options.

Thoughts on AngularJS

While initially, I was a bit disappointed that it wasn’t the cool and modern version of Angular that I thought we were going to be using, I have come to really enjoy it. In fact, it may be my favorite JavaScript framework.

One thing that I really like is how intuitive the syntax. Want Angular to do something conditionally? Angular if (ng-if). Want Angular to repeat something? Angular repeat (ng-repeat). By reverting to caveman speech patterns, you can effectively intuit the correct directive for AngularJS.

I also found the controllers very intuitive. I liked how a whole grouping and views were under one app, but that app may have many different controllers. I have found this is a really great way to minimize HTML code but maximize the functionality.

The one thing I still struggle a bit with is AngularJS routing. Luckily, the routing is already completed for the project. For future projects, however, I will need to put more work into this concept.

Conclusion

Overall, I not only did I learn a new framework, I also gained a valuable experience learning a new framework with fewer resources in a short amount of time. I believe that every time you learn a new tool or language, you get better at adapting and acquiring new skills. I look forward to improving my skills with AngularJS during this quarter and adding it to my developer toolbox.

No programmer likes looking at their old code. It’s like looking back at pictures of your horrible haircut from middle school. You cringe and think, “Why is it so bad? What was I thinking?” This repulsion you get looking at old projects is likely because of the code smells and bad habits. It’s great to think of how much you’ve improved, learning better practices, as you were exposed more to good, clean code. You also probably hung on to some bad habits, or code smells, that still stink up your work today.

This is my story. And for this post, I read two great articles (linked and referenced below) and applied them to my current coding practices. With this new awareness, I hope to fix up some bad habits and create new ones to replace them and write cleaner code.

What’s That Smell?

How can you tell if your code stinks? How can you fix it and keep the code you write in the future smelling rosy? Well the Refactoring Guru on thier blog explains the common smells in five different categories: Bloaters, Object-Orientation Abusers, Change Preventers, Dispensable, and Couplers. A few smells in these categories looked a little too familiar to me.

Long Methods

First up, from the Bloaters category, we have long methods. This is a smell that is very familiar to me, and it’s in so many of my projects. Sometimes when you have an idea and are on a roll, you just keep adding and adding to the method and the class. Then you end up with one giant class and a huge do-all method.

This smell makes debugging, maintaining, and adding to your code very difficult [1]. For example, let’s take this JavaScript code I wrote two years ago for an interactive cleaning game:

const drying = async () => {
    console.log('drying');
    textBox.textContent = "";
    switchBackground('1');
    startType();
    typeWriter("Let's dry this plate. Take a deep breath in.");
    await sleep(4000);
    endType();
    countingPop();
    textBox.textContent = "";
    await sleep(3800);

Doesn’t look too bad, right? Wrong. It goes on for 80 more lines. All in the “drying” function. Most of the code is very repetitive too (we’ll talk about this later, *wink wink*). Debugging this code was a mess because I remember not knowing where the code was broken, but because there was an error, the whole chunk of code wouldn’t work!

Even though this was from two years ago, it is a bad habit I still have. I always say I will “Get back and break them up later” but I never do. Moving forward, I want to make a conscious effort to break up my methods and functions to smaller, more-specific pieces.

Repetitive Code

Repetitive code is my kryptonite, my downfall. I have the habit of finding something that works and then copying in my code again and again. If it works once, it will work everywhere, right? While this is true, it is also a code smell. It makes your files so much longer and takes much more time to write than just making a helper function or even a few (if we want to keep the methods small) to cover the repetitive tasks. Then a simple, one-lined call will replace a whole block of code.

The Refactoring Guru has some great advice to help that I really think would help me in the future. They say to use the “Extract Method“. This is a way to combine two different functions that have very repetitive code. You put all the re-used code in one function, then in a separate function or two, you put the different code from the original repetitive code. Then you can simply call two functions instead of writing an entire block of code. This is a great idea, and I can’t wait to add it to my code to help me avoid repetitive code.

Cleaning Up

Writing clean code is an important practice for any developer. It is a way to make your code more readable and maintainable. If you want to become a better programmer (and I do) this is a great place to start.

Mert Oz writes on his blog that writing clean code is not easy! The most important thing to remember when wanting to become a better programmer who writes clean code is to not give up. It takes discipline, practice, and the ability to spot bad code to be good at writing clean code.

In this section, I will take a look at some clean coding practices I struggle with and would like to implement in the future.

Comments

In Mert Oz’ article, he quotes the famous Brian Kernighan who once said, “Don’t comment bad code – rewrite it.” [2]. If comments are meant to make unclear code more understandable, then it is just like treating the symptoms and not the cause. The solution would just be writing code that is easier to understand. This practice of diligently looking at your code and evaluating its readability is difficult and time-consuming. However, the more you do it, the easier writing clean code the first time will be. Soon you won’t need to rewrite sections so often. This practice of not relying too heavily on comments is something I would like to start doing more often.

Naming

I am a lazy namer! When I first started learning how to code, I didn’t see the importance of good naming practices. The programs were so small and simple that I couldn’t imagine anyone not being able to understand what my variable “x” did. Now, I see the importance, but it is a hard habit to break! Names should be meaningful and enhance the readability of your code [2]. Improving my naming practices will even help me with the previous clean coding practice of comments! With better names, comes less comments explaining the variables.

Conclusion

Eliminating code smells and writing clean code are not easy thing to do. They require you to be conscious of the code you write, and forces you to become an honest evaluator of your work. With time and practice, I plan to improve my skills by focusing on less reliance on comments and better naming. I will work towards making my methods and functions smaller and reduce repetition. I hope to look back at my code a year from now and be proud of my progress, instead of being embarrassed by my bad coding habits!

References

[1] “Code Smells,” refactoring.guru. https://refactoring.guru/refactoring/smells

[2] M. Oz, “Guide on Writing Clean Code – Trendyol Tech – Medium,” Medium, Jun. 12, 2022. https://medium.com/trendyol-tech/guide-on-writing-clean-code-496bb1100cde (accessed Jan. 15, 2025).

‌

‌

The end of the quarter is nearing. Finally. I can’t wait to turn in my last assignment and kick back for the rest of the month. For my last blog post of this quarter, I decided it would be a good time to reflect on my personal progress, in both this class and others. What did I do well? What did I epically fail on? What will I do differently next time?

The Good

Taking Breaks

This quarter, I have done a really good job at knowing when to take a break. I would spend hours straight debugging a single assignment. This always ended up in me being frustrated and exhausted, with little to no progress done on the assignment. This quarter, I started using the Pomodoro Method more. This method is a ratio of work to rest, usually 25 minutes work and 5 minutes rest. After doing 2–4 rounds of this (1-2 hours of work), I would do something else for a bit. This forced me to be conscious about how I am using time and to not focus on one thing for too long.

Asking for Help

Working with a group for my Capstone this quarter has also improved my ability to ask for help. I used to be nervous to ask for help from TA’s, Instructors, or my peers. I would get nervous that I was being annoying or asking stupid questions. For the Capstone, I am really lucky to have a great, supportive group. If I have a question, I know I can put it in the group chat and someone will help without making me feel like a burden. This has made me more comfortable asking for help in different classes and in different areas of life.

The Bad

Setting Realistic Goals

I love writing my daily to-do list in Notion. Every night, I look over what I got done that day and plan what I need to do the next day to stay on track. I write down those tasks, and the cycle repeats. The thing I have been struggling with is writing down tasks that I can actually get done in a day.

The Solution

To help me do better with this next quarter, I plan on making sure to read the assignment descriptions before putting them on my to-do list so that I have an idea of what they entail. Knowing the requirements will allow me to break up the assignment into smaller pieces and add those pieces to my tasks. Also, remembering that a list is a tool and not a rule-book will be beneficial. I don’t have to do everything on that list if I find something else that needs to be done. Conversely, I can do things that aren’t on my list if they need to be done.

Goals for Next Quarter

One goal I have for next quarter is to participate more in live lectures, office hours, and optional class discussions. I have previously done a better job of this, but it’s something I neglected a little this quarter. Participating more in my classes not only enriches the online experience, but it adds to my learning of course content. It is also just fun and a great way to make new friends. By making a more conscious effort to engage with my courses and peers in this way, I will get the most out of my last few quarters at OSU.

Conclusion

This quarter has gone by so fast! I’m glad to have a time to reflect on all the things that went well, all the things that didn’t, and what I want out of my next quarter. I am excited about the new opportunities it will bring!

A look into my room or the +10,000 unread emails in my Gmail would tell you all you need to know about my organization skills – or lack thereof. Generally, I can get by with my scattered brain and even more scattered things (I have a system, I swear), but when working with a team, this simply won’t work.

This past 1.5-ish months, I have learned a lot about organization and group work, so now I will pass it on to you all. Get ready to take notes! Class is now in session!

To-Do or Not To-Do

A To-Do list is your best friend. There’s really not much more to say here. Not only do they help you sort out your life, they give you so much satisfaction when you can check another task off your list. I like to write To-Do lists for each Day, Week, and Module (for each class). I write the due dates next to items for my weekly or module list. For example, Write Blog Post (DUE 11/12). If something is high priority, it is in all caps or maybe with a lot of exclamation points! Whatever works for you is the best method.

Team lists also help immensely. I have found when writing our team documents that creating a To-Do for each document, listing the required sections and who is going to do it, has been a game changer. Everyone knows what they are responsible for getting done, and the whole team can see how much progress we have made towards our assignment. It is a great way to see which members may be falling behind and need help, and prompts group communication.

Which software do I use? Why, thanks for asking! I am absolutely in love with Notion! I use it to take all my class notes and lists. It is so customizable, and allows things like code, image, and video embedding. You can also get the app on your phone. 10/10 recommend!

Outlook Calendars

All students at OSU have an Outlook account, so what better resource to use! We all get notifications, and all have access to important dates and email reminders. Setting up our weekly/biweekly Zoom calls with the Outlook calendar has been an amazing addition! Not only do we all have the link and meeting information, our Project Partner does, too. With the Outlook events, team members can RSVP, so you can see who will be there and who won’t. Team members also get emails if the meeting time or date changes. This is so important when working as a team with a wide range of time zones and schedule availability.

Discord: The King of Communication

Group communication is the most important part of any project. Without it, a group cannot be successful. Finding a method of communication can be difficult. Email is very rigid, text is too informal, and meetings for everything are overkill! Solution? Discord.

Discord is a very easy method of communication. Most people have it on their phones, so sending a message while away from your computer is easy. I get message notifications, so I can keep up with group conversations and chime in. It also makes a quick check-in very easy. Sometimes you are really busy – life happens! – but you need to tell your team you are still alive. A quick message in Discord saying: “Hey, guys! Super busy the next few days. I plan to get started Thursday” is all it takes. You have now communicated with your team that you are aware of a deadline and are working towards it. So simple!

Discord also allows for Polls, which have been instrumental to my group. Should we have a meeting on Halloween? Which diagram design looks better? And questions like these can be quickly answered by the whole team. Another great feature allows for pinning messages. Important updates, deadlines, or links can all be pinned, so the team can find them easily.

Google Drive

Google Drive is a great team organization tool for obvious reasons. Working on a document together requires keeping it in a place where everyone can access it. But the benefits go beyond this. My team has made the Google Drive into a treasure chest of resources. Meeting notes and recording, cool resources, summaries of YouTube videos, and more can all be kept here.

Not only has this made our group and individual assignments easier, it has made them more fun. An exciting part of learning something is sharing it with others. By adding an interesting article link or a YouTube video that answers the question we were perplexed by last meeting, we are learning and sharing this experience with each other. And it’s all in one place!

Conclusion

Staying organized is hard, especially in a group setting. There are deadlines, resources, and life events that come up. You need to find a way to organize them all and communicate them with your team. I shared some great resources like Notion, Outlook Calendar, Discord, and Google Drives and some tips to use them! Hopefully they will help you as much as they have helped me.

Until next time!

It’s 11;19 pm. A disheveled figure sits at its desk, hunched over its keyboard. Sweat is beading at its brow and streaming down its face in salty rivulets. The creature paws desperately at the collar of its shirt, desperate for some air. Desperate for an escape. This being has been given a task, a task it vowed to do never again after choosing its path, years ago. The poor, miserable brute had to write.

The brute is me, a CS student who hasn’t written more than a paragraph at a time in years. 

Who Am I?

My name is Ally. I am a Computer Science senior (though you already knew that), minoring in User Experience Research. I am a powerlifter, tap dancer, avid crocheter, literature enthusiast, film fanatic, and human. 

Why Computer Science? (this one may shock you!)

I used to watch so much House, M.D. that I thought I could very easily become a doctor. This was not the case at all because of a little thing called Chemistry. I took my first two years of college while being in high school and hated chemistry so much that when I transferred, I searched for a major that wouldn’t require any more Chem classes. My choices were very slim, and I decided that Computer Science sounded the coolest. I had absolutely zero computer science experience prior to my first day of class at OSU. This is a very serious story, and is really what happened, I swear. (sorry for the clickbait title)

Any Regrets? – A Computer Science Journey at OSU

Full transparency, I very much regretted my decision during my first year as a CS student. It was hard, and there were no shows I liked about computers to keep me going. I had always struggled asking for help, and I sometimes felt that I didn’t belong because I had no prior experience. Then I took Computer Architecture and Assembly and Data Structures and found the now-canceled British TV show I.T. Crowd, and I experienced a paradigm shift. 

The challenge of learning new things and solving complex problems started to excite me. I learned what RAM is and became obsessed. I was introduced to the language of control freaks dreams, Assembly. Most importantly, I met my true love: hash maps. Since then, I have only become more interested in Computer Science, and more dedicated to my education at OSU. 

So in short, no, I don’t regret it. 

The Project I’ve Got My Eyes On

The project I would like to do is Enhancing Localized Deformation Analysis in Materials Science Using AI/ML: A Comparative Study of Traditional DIC and AI/ML Approaches. In this project, we would create a ML model that would learn from Scanning Electron Microscopy (SEM) images to create a predictive model for material behavior as they near their weak points. 

This project immediately got my attention because of my interested in Machine Learning and Statistics. Becoming more familiar with some tools and techniques I have already been briefly introduced to would be an exciting experience for me. I love a good challenge and throwing myself into something new. I think this would broaden my horizons and push me to become a better developer and learner. Plus I could live out my dream of studying materials and their breaking points like Tony Stark in Iron Man II when he creates a new element in his basement. 

How Am I Preparing?

While I await my project and team assignment, I am keeping busy. As a refresher of main concepts, I did a speed run of Google’s Machine Learning Crash Course. It is a great introductory resource to the main topics and methods of Machine Learning.

I have also been spending a lot of time looking at data collections on Kaggle, like the LeetCode of ML, but have yet to make a model. I am still putting out feelers for all of my courses and getting a sense of their loads and requirements.

Foretold Obstacles

I can imagine quite a few challenges I may face as I work to finish the capstone. So I have created a list:

• Course load and life – I have other classes to take and other things to do! I struggle to find balance sometimes, and I can see it being a challenge with this project.
• Group work – I have improved a lot, but I still prefer to work alone. I will need to further improve my communication and collaboration skills.
• Lack of ML experience – I have some experience, but it is fairly basic. It will require a lot more for this project, so I will need to spend a lot of extra time learning about it and material science.

In Conclusion

My journey with Computer Science at OSU has been an interesting, if not enjoyable one. I am very excited to do any project that I get assigned to because they all look great. I look forward to (at a much, much lesser extent) to writing on this blog to improve my skills on this weird programming language called English? Inglish? I’m not sure, it’s been a while since I used it. And to keep everyone up to date on my progress.

If you have any questions, comments, concerns, or movie recommendations, please reach out.