Throughout the span of 4 months, I worked with a random team of 10 individuals to create a web app in meteor and react. Every 2 weeks, the team would show off it’s newly made progress. At the end, we created a web application that can filter through thousands of bills, forward bills to corresponding legislative authorities, and implemented the cycle of legislative approval into the design. Users have corresponding responsibilities and levels of actions they can take. Their authority is taken into consideration as you need to be at a certain level of authority to forward bills to a higher level.
Truly if you work alone, then the tension is unparalleled. You begin to understand the pace and competence everyone works at so you can change yourself and raise your competency to the next level. Working in a group is a check and balance where nobody wants to be the one who falls behind, but someone will while someone will inevitably shine. It creates a bit of a small competition, but a little tension won’t kill anyone. From this I can see how ahead and skillful people my age are and improve. When you have clients to show off work in 2 weeks, you do need a bit of tension or you will show trash with a smile, something I think no dev wants to do.
Somehow it just felt like everyone was better in every single aspect and I was here with a single class’s knowledge of JSX Web Apps. Is this what Imposter Syndrome is? I got down to the basics of JSX, which cured all my misunderstandings on how uniquely the code was written. There was a lot of knowledge about JSX, but most of it seemed unuseable as working code seemed to fail for absolutely no reason. Later on I realized that our Data Structure was completely misleading and actually JSX was easier than I thought. After a few weeks, I was able to point out flaws in my teammates work and finally made some good contributions to the team.
It’s not always good to be in a team because of the constant effort overwriting people do. You can reserve an issue to work on, take a week to finally finish it, present it to the team, and realize that someone had already taken on the work without anyone knowing. This happened twice before I figured out that our Github Issue Board was practically useless. One issue can encompass multiple issues, but people won’t close those multiple issues. If you ask everyone beforehand, well everything is subject to change. There’s always one way that someone can not know that an issue is being worked on.
The obvious solution is to make issues as atomic as possible so there is no possible way of overwriting effort. However, this is not possible since issues are created because nobody has a good understanding on how to solve them, thus they must be broad and inconcise. But even with the inefficiencies in the miscommunication, a group is always faster in development (although Smilegate has proved this to be true until you have to manage 1000+ workers).
This experience helped me grow as a person. Work Ethic, Scheduling, Communication, I change them all to be a better version of myself. There is always a mountain above you, so you can climb to see the next peak.