As of writing this blog (February 9, 2022), I am in the middle of the term in regards to classes. This means: learning more in-depth topics in modules and writing code for more complex projects. For me in particular, reaching the middle of the term meant working more collaboratively with my group mates to create a Midpoint Project Archive together, and to get a demo running of our project.
From this past week, through working with my group mates, I was reminded of three essential components when it comes to working together on a development project.
Communication
One of the most salient mantras I learned at OSU is “Remember the Human.” As E-Campus students, we’re fairly more isolated than students who are earning their degree on-campus. With this isolation, I think sometimes we tend to forget that we have course-mates (and major-mates) who are also human, and have lives outside of class. So when we’re put together in a group to work together, two things could potentially happen: 1. You are expected to communicate with each other at all times and must respond within one minute of receiving a message, otherwise it’s assumed that you have abandoned the group, or 2. You and your teammates don’t talk for weeks on end, until the final project is due and you all have to scramble to put something together. (Joking, these are hyperbolic, but you can see what I’m trying to get at).
In regards to communication, it’s really important to be in the middle ground, have clear expectations, and to set boundaries. Otherwise, you might end up with scenarios 1 or 2 mentioned above. I also wanted to point out that it’s crucial to have open communication with the people you’re working with, to avoid tension and building conflict later on down the road. Remember to be honest, polite, and kind.
Git
Git, also known by my worrisome self as “the best thing ever, because I can go back into the past before I broke a project and figure out where I went wrong,” is absolutely essential when it comes to working on a collaborative development project. You can basically work on your segment of the project, without fear that your code will break the “stable” version that is in the main branch. Once I learned how to use Github, it was a game-changer for me because I no longer had to be afraid of ruining anything that the rest of the team had worked on. But if things did go wrong (after a branch was pulled into main), as a team, we could figure out what was wrong and revert the change. As someone who errs on the side of caution, I would say that Github gave me the confidence to make mistakes– and learn from those mistakes.
Code Reviews
Code reviews are what helps one become a better programmer. While we’re working on projects on our own, we tend to overlook the problems in our code, because we don’t notice anything wrong with it. However, having someone review your code can be incredibly enlightening. The reviewer could suggest algorithms to lessen the run time of your code, point out that some lines can be refactored, or that there’s a logical hiccup in your code. Moreover, having your code reviewed and praised is really validating as well.
Being the reviewer for code reviews can be really illuminating as well. Reviewing code helps you practice reading code to understand what another person has written, and gives you the chance to learn about new techniques you might not have known about before.
A key thing to keep in mind while you’re doing code reviews is to give and receive criticism constructively. For the giving portion of criticism, it’s important to remember that your comments should be helpful, useful, and polite (“Remember the human.”) When you’re receiving criticism, it’s vital that you don’t take the reviewer’s comments personally– They’re not trying to attack you, they’re trying to help you improve your code.