At the golden area of freelancing it is tempting to say that coding is a one man job.
However, we are forced to observe that most big tech companies didn’t externalize developers as they did for designers and there is a reason for that.
Even if writing code is a task that can be done by one man, maintaining a legacy code is more complex and often requires more than knowing how to write the code itself. Sometimes it is based on business reasons that are specific to the company and to its functioning.
That’s where team play matters, in an environment where people are playing individually and compete with each other it is easy to get stuck on even simplest tasks and it is also really hard to keep knowledge.
Competition is toxic
That is due to the fact competition is based on ego and pushes developers on a wrong path by forcing them to fight with each other and that leads to not providing the right information to their teammates.
Why would you give information that will help someone else to grow when your objective is to stay the best?
However, that’s also damaging the project on another point.
Knowledge is an always additive resource that means that you lose nothing to share some knowledge with someone. However at the end they know something more and from two people knowing the topic now we have two.
This simple process is way slower in a selfish environment where people value the exclusivity from the information more than the performance and the efficiency of the team.
This making also really difficult new entrants to make propositions and makes the old structure from the system relying on one or two seniors encouraging a Pearl Harbor syndrome.
Pearl Harbor syndrome
Pearl Harbor syndrome is a situation based on the real decision process from USA officers just before the famous attack on the military base of the same name by the Japanese in 1941.
Officers were in a situation where every new person in the team was scared of contracting their chief that got a long experience on the base and was thinking for sure that Japanese can’t attack.
However the vision from this officer was old and based on 1st world war conflict and times changed since then.
Every young officer was aware of that change but the pressure they got prevented them from contradicting the senior officer and nothing was planned to prepare the base for the attack.
This led to the catastrophic event of Pearl harbor where US troops were attacked by surprise and where a big part from the US naval fleet got sunk.
In the same manner, never accepting new ideas in a company is something that can put a company in danger not only on a technical field but at every level.
In a team this issue can be solved by letting new entrants expose their visions first and if possible seniors try to help adapting the solution to the context of the company or by debating on the solution.
Team play for the win
Where competition is based on a sentiment of hate to the others to progress, collaboration is in fact based on a sentiment of compassion resolving even more easily conflicts.
All of this helps also in a lot of other topics such as taking responsibility from mistakes as a team instead of an individual and making the best effort to prevent multiple steps from the process often involving multiple team members to change their habits instead of just one.
Now that we know that collaboration is important in a team, the next step is indeed how to instore a collaborative atmosphere in a tech workspace.
For that the base will be to collaborate and for that there is a lot of way. However I would like to introduce you one way more than the others as it allows everyone to collaborate and get to know each other.
Pair programming
This technique is coming from an organization of coding called extrem programming and is called pair programming.
Even if it has way more values than what we gonna see in this article let just focus on its advantages for creating a teamwork atmosphere.
Maybe the best start will be to understand what pair programming is and where it comes from to understand its benefits.
Every human can make mistakes. That’s why today in roles where these mistakes can be fatal we introduce a system to provide as much as possible these errors and pair programming is exactly based on that system.
A good analogy to understand pair programming would be the job of pilot and co-pilot in a plane.
During each flight at least two pilots randomly picked in the fleet from the company are present:
- One will be pilot flying that means we will do the actions to drive the flight.
- The other will be pilot monitoring and will be in charge of external tasks such as doing announcements but also verifying that the pilot flying is not making any error.
These break down and double checking allow a relatively low human error in the cockpit and making even more sure any flight as human error is the main flaunt in that domain.
In pair programming we will be on the same concept with one developer that will code and another that will review and do documentation research to help the coding programmer.
This allows indeed to reduce the number of errors in the code but it also makes programmers know each other and work together forcing them to share the knowledge they have and sharing responsibilities for the code written.
It is in fact now impossible to blame one person for the mistake and that could be even more hard if you instate a QA service inside your team.
A note for competitor persons
To finish I would like to address competitors or challengers people that feel a bit flamed during this article.
I am also a competitor as I played sports in competition when I was younger. However in coding I feel like the competition is healthy only if two conditions are respected:
- The first one is to compete with yourself, not others.
- The second is know your limits, your body can’t endure being at 100% 24H / 7D. You need some rest but as everyone is different you need to know when to stop otherwise you gonna burn yourself out and from a star you will become a burden sometimes even without knowing it.
Leave a Reply