Being A Team Player

Salym Senyonga
Jul 10, 2017 · 3 min read

Last Friday, July 10th, I had to collaborate with a group of individuals
to complete an assignment. For the assignment, we had to build a functional
command-line utility. From past experiences I knew that building a consensus, for the kind of outputs we had, was likely to take time. So I came up with a quick prototype of the U.I and a draft of a bunch of the other stuff we had to get out of the way before actually getting to write code for the application and I pitched to the group really early on.

As is usually the case with distributed development teams, we were not all in the chat group at the same time, having not committed to a uniform time initially. This, I believe was the biggest mistake we made. You see because of this we did not get time to hear from every one before we started making hard-to-reverse decisions.

After a lot of time, of assuming every one was on the same page, we hit a snag. With about 2 hours to the expiry of the deadline, some members of the group decided that we scrap the whole thing and build from scratch. The main reasons for this radical decision were that the initial code was hard to understand and folks were having trouble setting up the project on their local development environments. Because of these problems, folks weren’t able to test the application locally or extend it.

From my experience the problems raised were much easier to resolve than trashing the entire application. I proceeded to to try and mitigate the issues the other members had with the initial code until I realized that it was all in vain. Having come to this grim realization, I had to figure out a way to make the idea of going from something to nothing because that is literally what,
“lets ignore this code and start afresh with a new repository” meant.

Luckily, another member of the team had built another implementation of
the application, which seemed to have incorporated the libraries that
the other members of the team were happy with and we managed to agree on that. I don’t think I’ve been happier to dodge a bullet. You see, for a second, when my teammates started suggesting that we trash the current implementation, I saw my future in the bootcamp come to an uber painful end.

So we made the new implementation work and everybody was content.

My takeaway from this is that, in settings where you have to collaborate
with other folks, you have to be able to accommodate different view
points. These view points can include ways of doing things that you are
“sure” are not the right approach. Despite your disagreement, what
matters in the end is a ready deliverable. So in my case I had to yield
to the fact that we were switching out implementations at the last hour.

Perhaps the biggest lesson I took away from this experience was that in distributed team settings, time is really important. You see, if we had agreed on the time we were all supposed to check in and pitch our ideas, we would have had ample time to examine all the ideas and select the best ones without deadline pressures.

Salym Senyonga

Written by

Software Engineering apprentice. Ruby, Rails, tennis, F1 and Real Madrid. Unintentionally pedantic ;-)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade