Written by Gabriele.

The importance of teamwork as a crucial asset for a companies output quality cannot be overstressed, and usually is an aspect that everyone assumes to be merely a rule of common sense. That is not always the case, depending on where you’re coming from. What I’d like to share is what I learnt having worked in a team after years of the one-man band experience.

At my previous job at a small but respected independent book publisher, we dealt with the diverse array of publishing functions letting every member of the company take care of a singular aspect, empowering him with the ultimate responsibility (and pride) of his job, and such an approach proved quite successful: it reduced the overlap to zero, and allowed the deadlines to be respected (well, most of the time); we were concerned with quality and feeling a great degree of accountability in case of failure, helped us to keep focus. It also meant that we worked a lot but also that the success was incredibly rewarding. That was my case, and there’s nothing like taking care of an idea from the beginning to the end, and feeling ultimately proud of the final result.

That also meant that we only had the opportunity to put our results up for scrutiny much later in the process, not seldom only at the final stage, and that learning from our mistakes proved particularly difficult. More often than not, we ended up sketching very defensive strategies to minimise the chances of failure. That, combined with a very conservative business model, drastically reduced the available room for change and innovation, which is on the exact opposite side of the spectrum when you’re looking for improvement and enhancements. You can’t be defensive all the time, when times call for a radical change in your everyday practices.

That’s the turning point when you join a company like Leto, which is an agency for digital innovation: things move faster than ever these days, and you’ve got to be bold and brave.

But again, what does it really mean to work in a team of people, dedicated to the same problem you’re facing, with similar goals and different opinions and strategies? How does this reflect on your everyday tasks and solutions?

The first thing is that you’re going to ask and give feedback constantly, not just at predetermined stages. This is incredibly valuable and time-saving, meaning that you’re not going to waste a lot a time following the wrong strategy or taking the longest road to accomplish something. Someone will help you see a shorter path that you simply couldn’t notice at first. Sometimes you will also experience problems you would ignore otherwise, when someone will take your stuff and try to make it do something you didn’t plan beforehand. That’s something you want to avoid at any cost, since letting problems slip out of your hands means that a user is going to meet them sooner or later.

Second, not everyone does the same thing in the same way as you do. This is true for nearly anything in life, but it’s especially true for software development: there’s (usually) more than one way to do something with almost any programming language out there, and it’s important to learn to see the alternatives, since one of them could be actually better than your usual way to do it. That’s true for a variety of specific aspects: coding conventions, coding styles, choice of design patterns.

This goes nicely along with developing a habit of writing clean and understandable code: you’re not the only one expected to read your code and make sense of it, but every line you write today will eventually be someone else’s legacy code, and you want it to cause as less inconvenience as possible to your future fellow. But it also mean that you’re responsible for your today’s team sanity: so no smart hacks only you will ever be able to understand, no convoluted code that is hard to grasp quickly when scrolling your object’s method, and stick to established design patterns unless you have a very good reason to come up with something new.

Having a team to work with also means that you’ll gain exposure to a whole set of alternative methodologies, philosophies, frameworks, languages and stacks: someone will sooner or later express their enthusiasm for some new thing he’s been playing with and will voice such enthusiasm to you during lunch break. That’s one of those moments, when you are presented with the opportunity to learn some new trick that might be useful at work or simply inspire you to learn more about it. Consider how everyone in your team is on the same page as you, but might come from a considerably different background — not unlike the ones we have at Leto — so he may have loads of inspiring insights to offer.

And while you’re dealing with an enthusiastic colleague, talking for example about functional programming, why shouldn’t you try to defend your not so enthusiastic opinion on the subject? Discussing things, trying to defend your point in a friendly situation is the perfect training for situations when you’re expected to give advice and explaining your reasoning for that. Confronting diversity is an excellent occasion to question our own beliefs and correct them, if they prove incorrect or obsolete. Sooner or later, you’ll be wrong, and being wrong is much more valuable than being right if you want to improve as a developer.

In a short period of a few months, I’ve seen myself in every single one of those circumstances: it was different from what I was accustomed to, but it felt really good.