Collaboration is the key

The worry

Nearly from the beginning of the course in January I witnessed the lack of interest in collaboration among many students….

My worry was that what if I get paired with those who don’t want to collaborate in the final capstone project. Thankfully I got paired with top collaborators in my cohort. So the module started with positive energy.

Working

We knew each other from our previous modules. We knew we were responsible, passionate, and good team players. Maybe not the best, but we were also good in our programming skills. Soon we started to work. We came with different ideas (based on the core requirements of Microverse). Among all (almost all were good), we chose to make a website for mentorship. Not only we could relate to it, we could imagine it to be a real project (rather a useless car renting app which would remain the same after project submission) in the near future. We spent time to choose name and make logo for it. We chose “Al mentoria” which has a mixed vibe for Spanish and Arabic in it.

We had discussion on how to divide our work. While we could divide tasks into two groups of front and back-end, we decided that all of us work on all parts. Each had its own benefits. I was supporting front/back division, but at the end I think the group decision was better (despite its problems).

One interesting issue was that we had much more ideas than the project requirements. We wanted to make any ordinary user be able to apply for having mentorship profile. We wanted to use TypeScript. Unlike other group projects in which my worry was that the other teammates were not working, this time the issue was how to manage this motivation in a way we could keep the integrity of the app and still deliver the final project in best quality as per the minimum requirements.

Apart from the above example, there were many other cases of disagreement. For instance I believed that it would be much better if we would implement the HTML/CSS design first and then convert it into React app. Others found it unnecessary, and of course we followed the group decision. In another case, we had disagreement on how to implement authentication on front end. The task we used to think shouldn’t take more than two hours, took two days to come to a relatively robust implementation. In all cases, whenever we had an issue that could impact everyone, we all were getting involved actively to make the best decision.

As mentioned before, the unfortunate norm among many students in Microverse (despite the Microverse attempt for change) is that many students do not appreciate team work. In the morning sessions many students prefer to keep their mic and camera off; hardly some would attend mob programming. Standup is worse. People only attend for attendance while it could be a fun session to wrap up the day. But our group was totally the opposite. Right from morning till evening we had fun sessions while helping each other. Even there were days in which we continued our sessions after standup, not just for work but to have chat about other topics.

Challenges

I mentioned before that our issue was how to limit ourselves. I was the leader in the group, and I tried my best making sure all ideas are heard. We made a list of desired features and refactoring candidates. I assured everyone that we will implement all these good ideas but let’s focus on delivering the first version according to the project requirements as best as we can. Thankfully the team accepted this proposal.

We had another challenge: we all must have roughly equal contribution to the project. The rationale behind this condition is legitimate. Where many students do not do their tasks effectively in a group, Microverse tries to push people to work equally. This limitation pushes the fast teammates to work with others and help them to work better. But in our case, this rule was a big barrier. It prevented us utilizing our extra time and energy to add more features while others were working on their own features.

It was interesting that after finishing our own tasks, instead of going and resting, we all would come to see if we could offer any help to the other teammates. We never said (or even thought) something like “I have done my task, you should do yours”. We all considered the whole project as ours. We respected others autonomy while tried to offer help.

Outcome

We presented our project on time. Not only we implemented all the core requirements, but also we implemented a relatively robust authentication and error handling in front-end. We wrote 100+ test cases for back-end and 50+ for front end while it was not a requirement. And for the design, we tried to be as loyal to the proposed design as possible despite having disagreement with some part of it. I think we achieved this fully. So from technical point of view, we were successful.

To me (and I guess other teammates), the main success was in our collaboration. We had three fun and joyful weeks. We worked together and much more than that. We were working, laughing, joking, and totally enjoying each others’ company. We strengthen our bond and friendship. And this is the most valuable achievement of this project.

We made our project not in our personal profile but in an organization called “UpliftLab”. We made our own workspace on slack to keep remaining connected and work collectively on projects that can help ourselves and other junior programmers to develop skills.

At the end, I want to thank all my teammates: Ammar Hamlaoui, Awais Amjed, and Soufiane Boursen, for their contributions in this wonderful experience. I want to thank Microverse (despite all limitations) for its attempts to improve the students skills as developers and as effective team players especially in a remote environment.

And the final word: value collective growth.