From Alone to a Team: The Learning Curve

Austin Wilshire
3 min readDec 15, 2015

--

The Basic Difference

For the first few months of 2015, I tried developing a data analytics tool by myself. This was an extremely large burden to bare with no team mates for backup, support or motivation. I ended up abandoning this project even though it was so close to completion, because I was burned out and wanted to start something new.

A few projects later, nothing was gaining traction (probably because the ideas were a bit trivial) and I knew I needed to find some more like minded people with stronger ideas. Then, one fateful evening on twitter, Walt Spence messaged me, we got talking and by the end of the night I had been invited to be a part of the team at EnLab. I couldn’t have been happier to be part of such a great group of people so passionate about creating something useful for other people.

So now I’m at Enlab, and I need to work with the team and not myself. So far, these are the main differences I’ve found.

  • GitHub — I had never had a need for GitHub, and had never used it seriously. However, in a team setting GitHub is an invaluable tool for product version control and collaborating with team members. It was tough to pick up at first, but when Jean told me that “most companies use Git, not for open source, but for version control” it clicked that I would need to learn this regardless of where I worked.
  • Documentation — When I worked solo, I never bothered with documentation, I would usually just sketch some screen designs down on paper and start making what I drew. This worked really well for me, because I could jump in almost straight away and see results. In a team, this strategy does not work well. Thought out plans need to be made so all members of the team understand where development is heading. Although this isn’t much of a difference from a few sketches, I still need to make sure I’m on the same page as everyone else.
  • Deadlines — This is a huge one. Working solo meant that I had very flimsy time frames that were far too flexible, which is why many things never shipped. At a company like EnLab, deadlines are a must have. This increases productivity for the development team, and forces us to ship something on time.
  • Time Zones — Obviously this is different, working with a global team based in America and Brazil, organizing meetings and catching up on the previous day’s work can be challenging. By myself there was no need for meetings, but I’ve found that using Appear to meet with the other members has been a fun part of being at EnLab, and hearing future plans excites me.
  • Knowledge gap — Working by myself, I could choose the stack I’m most comfortable with and know well, and there would be a very low learning curve to projects I did. After joining EnLab, it was clear that I had catching up to do. I’d never used the EmberJs Framework, Gulp, SASS and at first didn’t understand some of the lingo they used. I’m fortunate enough to have very patient team members that answer questions I have and don’t seem concerned when I don't know something.

Being in a team is such a positive learning experience, and now that I’ve tasted team work with such a talented and driven group of people, I don’t know how I ever worked alone for so long. I’ve already learned so much in the short few weeks I’ve been at EnLab, and I hope that my internship with them will continue strongly. I would like to tell anyone working alone and feeling the burn out to reach out to people and build a team, things will get easier and stress will be relieved.

This story is part of EnLab’s series on Building: Teams

Follow Dev Science for all the latest from us at

--

--

Austin Wilshire

Australian student, systems engineer interested in distributed computing, SRE and finance