How to work with a team?

The inevitable

For long, I have kept my work only to myself. In my sophomore year of college, I saw too much group projects went wrong because of problems of communication, or sometimes just straight laziness of some members. That’s why I decided to do all group projects all on my own, because I felt like the effort spent coordinating with others cost more than the extra work I have to do. Also by then each software project I had was still pretty small(no more than 1000 lines each), so working alone seemed to be the better option at the time.

However, by the time when I went into Google, and facing its gigantic internal code base, I realized that I had to collaborate with others, or I couldn’t build anything. So I moved to learn about collaboration skills, how to communicate with other engineers to get the job done. Now that I am back to college, I am open to groups for uni projects. For the past few weeks, I have grown a bit skeptical about it, and I will get to it in a bit.

Full time working with a team

Before I talk about what’s happening with some of my uni projects, allow me to discuss a few things I learnt in my internship. To give a bit of context, I was on a three-people team, myself included, but constantly I had to ask engineers from other teams all sorts of stuff, such as they libraries, their implementation strategies, and so on. What I felt like was that in reality teams try to incorporate Software Engineering Methodologies, but in the end we use a mix of many strategy templates. In the case of my own, because the goal of project is less clearly defined, I used some sort of Agile process. I had a rough idea of the goal, but would change it as I moved along with the project.

In terms of communication, which is probably the most important aspect when it comes to teamwork, I could ask my manager just about any time, since he was sitting right behind me. We also hold bi-weekly meetings with the product manager and teams responsible for other part of the product. My take is always try to say something in a meeting, maybe even just give an update of my progress. This is not to show that I have not been slacking; I believe keeping work progress transparent is helpful for the team, since other people may be depending on your code, and they would like to know where you are at, without actually asking you.

One important thing to keep in mind while working with a team is that you always want to add value to others, and that would cost some of your time on your own work. A recent video from Dave gives a better account of its inner workings. I also recommend you checking out the whole playlist of Software Developer Life from him if you are new to the industry and want some stepping ground and advice. Personally, my mindset at the time was: I have been helped by others so much, and I am gonna help others, wether asked or not, to the best of my capabilities.

Uni projects: very different

After returning to college from LA, I was pretty determined on the idea that teamwork is awesome, and I would be open to it. As expected I got a group project, with three other students. One nice thing about uni projects, and some from the industry might disagree, is that the development process is usually defined for you before the project even starts. So we had a clear roadmap in mind and went into the project.

After the past two weeks, I have had a few feelings about it. Before I say anything, these are all subjective so please don’t them as general understandings. The biggest difference between uni projects and actual work is commitment. This does not mean that uni students aren’t working as hard as graduates, what I mean is that the time we have on the project is significantly less than a real-life software project. Students have many other things in life they have to worry about: other courses, exams, off-time socials, etc. We can’t spend 40 hours a week focus on one project.

Also, communication is somewhat harder when it comes to uni project. I don’t know if this is only me or an actual thing. Normally if you are waiting for someone else’s work for too long, pinning the person would solve the issue pretty quick. Everyone has a different priority assignment to things they have to do. When there’s a mismatch, it gets very thorny to get the other person work on the stuff you are waiting for. To be honest, the best thing you can do is try to split work with less coupling, so you can still work on something fake some library you are depending on, check it in, and leave a TODO for others to fix it. I feel like this is a less ideal approach. If you have any suggestions, please leave them in the comment section. Thanks in advance.

Conclusion

So what does this leave you? For one, teamwork IS awesome, but you have to establish clear protocols and rules. Also, when you get blocked by others’ work, don’t push them because it might just not be at their top priority at the moment. Instead, try to help them as best as you can, and in time they will appreciate the help and help you back when they can.