Learning how to work in a group

The problem

When I started university, I carried all the projects by myself. I was better at programming and even non-programming stuff than any of my peers and the projects were pretty small so I just told them to not worry and let me do the work. I was more interested in learning and doing everything myself than having meetings with my team and plan how to work together.

And that worked amazingly. I got close to perfect grade for every project. I did so well for some of them that the professors were very surprised. And all of this was before AI so a really good project was very rare.

In my second year, projects were starting to get bigger and I was finding it hard to do all projects all by myself. Still, I got perfect score for them but it was taking a real toll on me. This was just as language models were coming out but still were very bad for coding.

So after the first semester, I gathered the three most capable people in my class and created a “supergroup” for doing all the projects together. I was a bit traumatized that my previous teammates had been lazy or incompetent and I had to carry for them and almost burn out. Or, at least, that’s what I thought was the problem.

I thought I was going to be working much less and we could think of doing more advanced projects since we had a “supergroup” now. I was just assuming we would work optimally. Instead, it was the most burned out I have ever gotten. The results were good because we/I somehow powered through but it was a big failure for me. I realized that my lack of leadership and collaboration skills were the problem, not the skill levels or dedication of my teammates.

Through all those mistakes and bad decisions, I learned a lot about how to properly work on software projects in a group. I had a talk with my professor, who is now my mentor, and he told me all the things I wish I had knew before starting the project. I started working with in a group with him over the summer where I saw how those principles are actually applied to group projects and, for the first time, learned how a group project is done properly.

This year, in my third year in university, I’m applying everything I learned and things are going a lot smoother than before. I’m producing the best work of my life with a great team and am nowhere near burnout.

So here’s everything I learned that I’m doing now.

Don’t Overcomplicate It

• Start with a super simple viable (gets the job done) plan
• Jot down ideas for future improvement (if you finish the simple one early) but don’t plan extensively
• If you have to choose certain technologies, plan for testing them on a super small scale for critical operations you want to do.

Probably the biggest mistake we made in the beginning was being to ambitious. We started super early, so we had a lot of time to think about all the cool ideas we could do and all the different technologies we could jam into the project. We actually started the actual work later than we were supposed to because we were planning all the complex things we were going to do.

Instead, we should have planned for the simplest way we could get the job done and then iteratively improve on it once we had finished building it. This enables you to get to work faster and have tangible results earlier. Thinking about cool ideas you could do at some point in the future is fine, but extensively planning and over-architecting it is counter-productive.

Github

One of my biggest regrets is that I didn’t have enough experience with Github. Sure, I had used it for my own projects for years at that point. But, I just pushed to main. there was no logic or convention to what I was doing. No branches, not merges, no CI/CD. No issues, no pull requests. I didn’t know what those even were.

I tried to get ahead of this by going deeper on Git, but I didn’t learn about how to use Github’s features that help collaboration. As a result, our communication was all over the place. I had to physically take my computer to my colleague to show him what I was doing. It’s really embarrassing at this point.

In my summer work with my professor, I learned how to use Github properly in a team. We created Github Issues for everything we wanted to do. These automatically showed in our Github Project which is a Kanban board where you can drag and drop issues by their status.

The issues were the perfect place to discuss… well, the issues. In my disastrous project, we used Whatsapp and conversations were all over the place. Here, we could comment on each issue specifically and discuss our ideas and what we wanted to do.

I learned the proper workflow of using Github. I assigned myself to an issue and started a new branch to work on it. I tried my best to use conventional commits and write good commit messages. When I was done, I would make a pull request with a description that explained what I was doing and why. I would also reference the issue so my team members would have the context of what I was trying to solve. Then, a team member would review my pull request and give me feedback. The feedback I received on my pull requests made me a much better engineer because they were unnoticeable by me. I would also look at other team members’ pull requests and tried to give them my feedback. With this, everyone had a good idea what others were working on and how the project and codebase was evolving.

At some point when the project had become relatively mature, we created a CI pipeline with Github Actions that would run our test suite automatically on Pull Requests. This would be a good check that everything still works before you request a team member to review your code.

Agile Principles

Using Github properly makes asynchronous communication much easier. But, you still need to have some points where you sync with your team and plan for the future. The most important points I learned were very helpful were standups, meetings after sprints, and points of releases.

Standups

Standups are short “meetings” you have with the team where everyone explains: 1. what they have been doing. 2. if there’s anything blocking their work and 3. what they need for the blocker to be removed. They need to be a meeting, they can be messages in Slack or Discord, but they are very helpful to keep everyone on track and updated. In my university projects we have this casually between our classes and it works very well.

Meetings after sprints

A sprint is basically a week (or two) of working on a specific goal. There’s a whole bunch of detail you can go into about sprints, but you basically say “this week we are working on tasks related to X”. At the end of the sprint, you have a meeting (longer than a standup) so everyone can show what they have done and plan for the next sprint.

Points of releases

In the small team I was working in with my professor, we sometimes focused on different tasks. As humans, we have a tendency to prolong what we are working on. There is always more to do. The point of a point of release is to set a deadline for you to have to push and release what you’re working on so you keep your tasks to a controllable size and don’t create a big mess you can’t get out of. This is what we should have had in my project.