Something not stressed enough in the early stages of technical education is just how effective working in teams can be. Professors go to great lengths to ensure individuality in work. While this works great in theory to maintain students’ understanding of coding, in reality, this has negative consequences.
Forcing budding developers to work on their own ingrains into their practices that they should always look for their own solutions — even in times when an out-of-box one exists. This reinforces isolating habits and can make young developers reluctant to ask for help. They’re led to believe they don’t know enough, and that may be an influence on why they experience imposter syndrome. It’s when they begin working with others that they shatter these misconceptions. They realize in that moment that actually, this isn’t half bad.
Four Hands Are Better Than Two
Consider this: You begin work on a feature for a website you’re building. Everything’s running smoothly and all your ideas are translating perfectly onto your screen — it’s all great! That is, it’s great until you realize that you’ve completely forgotten to set up the framework router. The 573 warnings in the console are beginning to bother you, and you’re losing track of the pages you’ve made.
How can you possibly fix this without taking away from the time you’re spending on everything else? The answer: look to your teammate.
With your teammate’s help, you’re able to continue to build out pages while they configure the routing system. Within three or four hours, your console is clean — you also now know exactly how to get to each page! That’s three or four hours of work you would have spent other than working on content that was instead carried out by the person beside you.
Maybe you’re trying to send an image to another server, and your website’s API falsely states the server received it. You investigate if your API got the image, and your teammate investigates if the database received it. Two completely separate, potentially time-consuming tracks of work completed in parallel. It’s a win-win.
“But where’s the problem?! …Oh.”
Sometimes, you need multiple eyes on an issue to realize that the solution is simple. You might be overanalyzing, trying to find out what’s wrong only to realize that it was that one tiny detail. I’ve personally experienced this.
One of the projects I worked on involved connecting an app to a remote API through our own custom API. I was testing the connection to the remote layer to verify I had set up our layer correctly. The instructions implied I could utilize their test endpoint — so, I sent it a request to validate my work.
I received error after error. And for the life of me, I couldn’t get anything else.
Of course I was confused — it was a public test endpoint! It was even named as such! Why was it not working?
Now, up to this point, I had been trying to figure this out on my own. I spent two days on this without referring to anyone other than myself and the documentation. At the end of the second day, one of my coworkers asked me what I had been working on. So, just to vent a little, I explained the situation.
“Are you sure you’re using the right endpoint?” They asked me.
I was reluctant to try it — again, I was using what should have been a public test endpoint. That said, up to this point I had tried everything else. What did I have to lose?
I changed the endpoint to ours and sent the request again. In came the massive JSON object I was expecting, and all it took was someone to point out that one detail.
Bruh.
“I have a wacky idea…”
Sometimes, trying to solve the problem at hand will take you through all the possible solutions, only to find none of them quite fit. You and your teammates will try everything and find nothing is an out-of-the-box solution, or nothing fits even with modifications.
It’ll take one of you to say, “This may sound crazy, but…” to lead you in the right direction.
You may find that what the documentation says, or what you automatically assume to be the “right” way to solve the problem, won’t be a perfect fit. There will be technical debt or incompatibilities that you’ll need to solve at some point down the line. Almost every time, the best way to deal with this is to, instead, think out of the box and suggest something that wouldn’t typically work.
This can occur more frequently as you’re working with others. As you and your teammates cross out potential solutions, you’ll begin to think about what you want your result to look like, and how to get there from where you are now. It might not even be you who thinks of the idea. Instead, a teammate might suggest it, inspiring a “Eureka” moment in everyone else.
“So are we sure we still need to have this meeting?”
As an unintended consequence of the above, you may find that your team no longer needs the dedicated meeting time. This might come unexpectedly, or maybe it’s part of why the preliminary work was done in the first place. Either way, it’ll free up time needed for working in a group for other tracks that need progress.
Yeah, this sounds like an antithesis to my entire premise. Just hear me out for a second.
Suppose you and three others had planned to mob together for two hours on a feature after a few of you worked out a knot in the data flow — resolving that issue may have a cascading effect of simplifying the next feature lined up for work. The lessening of that estimated weight can lead to a re-evaluation of how many people need to be working on that next story and may eliminate the need to mob altogether.
Two hours per person — eight developer hours in total! — are now free. You can allocate those to other tracks of work that can be done in parallel, which takes us right back to our first point. Those eight developer hours can be used to work on four two-hour stories or any other way you and your team decide to divvy up the free time, which leads to increased efficiency between everyone.
And you’ve fixed a work-blocking bug in the process, as a team. What’s not to like?
The Power of a Teammate
It’s entirely possible that at some point in the future, you or I may run into another issue where we’re overanalyzing on too grand of a scale, only for our teammate to turn around and say, “You missed a bracket here”. It’s important to recall that we are, in fact, not incompetent — the entire point of working in a team is to help each other, especially if we’re tripping up over something small.
We may not even realize just how trivial our issue was at that moment. Once we acknowledge this, we will have the grace to not be hard on ourselves for our misdirection and remember that this is part of the developer experience. It is through our teamwork that we can make the things we make, as quickly as we do.
Repeat after me: Together, we can accomplish great things.