dylan bathurst

Synopsis of Working in Teams

In this post I discuss the differences between working with teams in college and in the professional world. There is a focus on working with websites but can be carried over to other professional situations as well.

In the transition from working on the web while at school to working for an established e-commerce website, I have learned many new ways of getting work done. One of the biggest and most difficult concepts to learn (I’m still learning), has been working on teams with others.

Teams in College

My team experiences in college consisted of about four or five students who reluctantly met outside of class for fifteen minutes to think out a website idea as fast as they could so they could get home to watch the latest episode of Heroes. Each member would then do the coding work on their own time and have to jam it together with everyone else’s code the day before it was due and hope it all synced well. 

They particular way that I would do my part of the coding goes as follows:

  1. Start writing my style of code. (back-end, front-end)
  2. Test frequently to see if it worked.
  3. Get mad that it didn’t work perfectly.
  4. Google the error message.
  5. Correct my code with code from google results.
  6. Return to step 1.

This style of coding would actually work out pretty well for me, and I got rather talented at finding the help I needed from Google search results, but was this really working in a team? Back then I would say yes, but now that I am getting more real world experience I am changing my answer.

Teams Out of College

In the short time I have been out of the college life and into RL, I’ve had some eye opening experiences with my team. One of said experiences was trying to explain how to set up an application that consisted of a JSON request using MooTools javascript framework. Having intermediate JSON experience, and no experience with MooTools I was a bit discouraged from the start. I have worked with javascript frameworks before but not MooTools itself, while many aspects were similar to other libraries they were different enough to confuse me. I was supposed to explain how to do this somewhat complex request with tools I haven’t used, over the shoulder of someone who has had minimal interaction with Javascript. 

Being discouraged temporarily blinded me from the learning experience that was right in front of me. Since I wasn’t able to test myself I was forced to think out loud about why our code wasn’t working properly. I was able to get feedback from my partner and openly discuss step-by-step what the application was supposed to do and why it wasn’t doing that. When we would both get stuck another member of our team was able to step in with some outside perspective that would open a door for us in our application. 

In Summary

After thinking about this experience and comparing it my college experience I can conclude that team dynamics can’t just be thrown together and expected to work. With such a large code base that goes into a e-commerce website, the team working with that code can’t afford to be un-collaborative with each other at all times. Building these relationships also works as a team building exercise that will be useful when figuring out who works well together for future projects.