Group Work

Since this Capstone project is a group project, I thought it would be nice to talk about some important tips to effectively work in a group.

Set clear expectations

One reason some groups fail is that the team members don’t know what they are responsible for and what they need to work on. If there are no clear expectations, they might be working on something slightly (or completely) different than everyone else. This lack of coordination can lead to technical debt and adjustments when action items should have been winding down. You can avoid this by having a good project plan. In the project plan, you should at least have three important items: 1. detailed description of your initial thoughts on the structure of the project, 2. a thorough and complete description of what each team member will be accomplishing for the project and 3. some graphical examples for the project. The clearer the plan is, the fewer misunderstanding your team members have. Also it is a good way to know if your project is on track or not.

Set deadlines and stick to them

Once a good project plan is created, stick to the deadlines. To make sure that you can meet the deadlines, divide major action items into smaller tasks and work on those. Sometimes individual items have multiple dependencies and would otherwise block downstream tasks. If you can’t hit a deadline, it’s important to notify your team members as soon as possible. Also, project management tools like Asana, Jira, Pivotal Tracker, and Trello make schedule management easier. Not only you can see your project progress and deadlines, you can also check other team members progress.

Communicate Clearly

Good, clear communication will help projects succeed. You might get delayed, but unexpected bugs or other events happen. Do not be shy and try to hide it. Be honest and seek some help from your teammates. When you chat or talk with team members, make sure that your communication is easily understandable. Other people should not have to guess what you are trying to say since it can cause future misunderstandings.

Respect team members

Always respect team members. You might finish your tasks quicker than other team members or might not agree with team members suggestions all the time. However, each member has different a life outside of work or school, and they might have different communication styles. Pointing out someone’s issues usually do not end well in group work. If you and your teammates are having issues, listen carefully and try to understand what the issues are and come up with solutions together. In the end, you would rather be someone who is patient and considerate rather than inpatient and selfish.

Challenges as a Junior Developer

In my previous blog, I mentioned that I started my position as a software engineer intern at my company. I work as a full-fledged software engineer now, but was the path easy? No, it was very challenging.

Overwhelming codebase

When I started the position, all I knew was some introductory level C++ and JavaScript. However, at my work, we use the .NET framework with C#. Although, C# supposed to be easier than C#, those two languages looked very different to me. I thought I could write/read code okay because I was doing really well in my classes, but I realized that I was only familiar with a small amount of code that I worked on at school. I was completely overwhelmed at the size of the code base and all the downstream items that my changes could affect.

It took me one year to overcome this feeling. How did I do it? I just kept reading code and spent endless time trying to understand what was going on. I created several notes (most of them didn’t make sense because I was lost most of time) and I even created some diagrams to understand the flow of our systems. I wanted to ask questions to senior developers. However, they were all busy, and I didn’t want to bother them. I just kept on reading code everyday. The first half year was miserable. Facing all the unknowns was very frustrating, and the code base was just too overwhelming. Every once a while, things started to click. Once it started clicking, a lot of the code base started to make sense, and things became much easier. I probably spent too much time trying to figure out things by myself and often went down rabbit holes. Asking more questions would have probably sped things up, but I think that solving the issues on my own was integral to my development as a software engineer. Solving these unknown issues is now one of my strengths, and I am confident that I can figure out a lot of issues by myself!

Writing code that fits in with the existing code

One day, I was given a task to fix a small bug. I wrote several lines of code, tested it, and confirmed that everything worked nicely. I submitted the code for review. Soon after, the ticket came back and said “Hey, you can just call this method, ABC()”. All my work ended up just being a single line of code.

As mentioned in above section, reading the codebase definitely help learning the existing style and methods that we use, but I can’t spend all day reading and wasting time to just fix a small issue. To overcome this issue, I just started looking for similar functions. If I was working on scraping a website, I looked for another job that did something similar. I checked what libraries and classes they were using and imitated those. This worked pretty well for me, but we have some legacy code that I have to be careful with sometimes.

Another issue was that sometimes I thought I had a great fix, but I broke something else! This happened to me several times in the beginning, because I was only focused on the one issue that I was given. I wasn’t paying attention to the the bigger picture and how it would affect other processes. I did two main things to overcome this issue. First, I worked on understanding the reason behind the code. If I was dealing with data, it meant understanding what the data was for and how it was being used. Next, I checked what else was using the same method that I modified and verified that my change didn’t affect other sections of the code.

Ticket management

At the beginning, I easily spent hours working on one ticket, because I got stuck on a problem that I couldn’t figure out. I also felt like I would forget everything if I had to work on another ticket that was higher priority. Unlike the assignments from school, I usually had multiple ongoing issues or tickets that I needed to work on. I couldn’t work on one ticket all the time.

I was able to overcome these issues by implementing a few changes in my workflow. One crucial item was leaving good comments in the code and tickets. Another thing I found helpful was creating sub-tasks and dividing work as small as possible. Once a small task was completed, I would either keep working on the next issue on the ticket or move on to another ticket that was higher priority. Using this method, I was able to easily multi-task for some tickets, and it was easier to keep track of my progress.


There were a lot more challenges that I faced in the beginning, and there are still a lot of things to learn everyday. Now, I can confidently say that I am a software engineer. Although, there are times that I feel like I am still not good enough. I think a lot of junior developer face the same issues that I had, and I hope this blog will make someone feel better in the future.

My CS Journey

Welcome to my first post! My name is Eriko and I am OSU Post-Baccalaureate Computer Science student. I am originally from Tokyo, Japan and moved to United States in 2013 with only conversational level English. I was lucky enough to get my first job here in the US, but none of the opportunities that existed for me were challenging at that time. I was only able to find work for admin/operation positions that required a Japanese speaking ability. I wanted to have a job that was challenging, rewarding, and something that I could keep learning. That’s when I started to look into this computer science program!  

My CS journey started back in the summer of 2020, and it has been a long journey! Before I joined this program, I wanted to know whether I like programming or not, so I started learning programming by using freecodecamp. I soon got obsessed with their projects and spent many hours working on the various projects they offered. I completed the freecodecamp certification in four months and decided to move forward to join this OSU program. 

A little after I started the OSU program, I was able to get an internship position as a software engineer. The first year was very challenging, because I jumped into a large code base from with only my limited knowledge from freecodecamp and introduction to computer science I&II. I learned how to read and write good code every day. At the same time, I learned the fundamentals of computer science at school. Working on assignments was very time consuming, and it was challenging especially after being exhausted from work. However, it was interesting and rewarding to learn as I handled some real issues at work. That feeling gave me more energy and kept me learning everyday. For example, I was using an SQL database at work everyday but not everything fully clicked me until I took the introduction to databases class. I felt very fortunate that I was able to learn from school and work at the same time.

Now I work as a software engineer (no more intern!) and this is my last semester at OSU. I am excited to work on the last project, and I will continue to update my blog as my journey continues with my last quarter here at OSU.