Wanted to provide a brief update on my CS467 class at Oregon State. This week, we hit our midpoint, so I’ve created this fun demo video to talk more about where the team is at, what we’re working on, and what we have left to do.

In my video, I call this out, but one of my favorite dynamics of our group is our weekly group programming. I’ll dive more into how our group is really using this to drive our project forward.

Group Programming

Each week, my teammates and I meet for 2-5 hours across 1-2 meetings. The purpose of these meetings is to give updates and brainstorm, but it’s turned into one of the best places for us to knock out key initiatives.

Our project involves 15 rooms and a parser to navigate between those rooms and perform actions on objects within those rooms. This makes it incredibly easy for each group mate to own 5 rooms and the functions that occur in their rooms. However, we quickly recognized that there was some shared navigation and other verbs that crossover between our rooms.

In the first week we started coding, we transitioned our group meeting from an update meeting to an actual working session on navigation. Then our second meeting to a working session on our parser. These incredibly important brainstorms and group programming sessions has allowed our group to not spin our wheels independently working towards the same solutions but rather put our heads together and knock out things much more quickly.

These group programming sessions have been fundamental to us staying ahead of schedule and have made it so much easier for each team member to knock out their sections so much more quickly. Because we’ve worked as a team to discuss these things and all get on the same page, there’s no confusion on how to use these overlapping functions when we begin to work independently.

Implementing Group Programming

Though this is likely not the perfect solution for every project, I’ve found it incredibly valuable and a great reminder that taking the time to source feedback and brainstorm with others, though sometimes time-consuming, can actually allow a team to operate at a much higher efficiency.

This also doesn’t have to be independent to the actual backend or programming. I can think of several scenarios in my own work in Revenue Operations where I’ve been presented a problem, gone about executing a solution, and then been sent back to the drawing board when it didn’t quite meet the moment upon roll out.

There’s a lot more people involved in workplace solutions than just the programmers, developers, and project managers. Though you may not want to bore a salesperson, customer or other end user with the actual execution, it’s so critical to consistently be re-engaging with these parties to make sure you’re staying on track with the end goals and not getting too deep into just making the code work.

What’s Next?

The rest of our project timeline is dedicated to knocking out our individual portions independently and using our group time to improve the game’s usability. I’m feeling really confident about where we’re heading and even more confident that the dynamic we’ve built as a team is allowing us to do that much more quickly.

I’m really learning a ton in this course and surfacing some new ideas for collaboration that I’d really love to take back to my workplace. Group projects can be incredibly difficult, but I’ve been pleasantly surprised at how well our team has worked together and want to scale that dynamic into other projects I’m working on outside of school.