A very popular stereotype of a programmer describes him as a shy person, an introvert who is afraid of people and sits somewhere in his dark room away from the hustle and How is such a person supposed to work with other people? Is ter stereotype true, or is it a typical stitch?
Over the past 10 years, I have worked with many different people in different companies and models. Starting from office work, hybrid work and 100% remote work in distributed teams. I’ve seen a lot already, and I wonder if all these changes in the work of programmers that are happening nowadays are changing anything in the way how they work? Are these changes for the better or for the worse?
Cooperation between developers
You are probably already working in a team of some kind, and if not you will start. Even when you’re a freelancer, that’s how you’re going to work and communicate with other programmers. This cooperation is not as obvious as in other professions. Programmers work together, but each one has own word (and look at his computer). Theoretically they are working at the same time on the same thing, but in fact they are not physically doing the same thing.
Bricklayers when brick a wall, they usually see what they are bricklaying all as a team, helping each other with their work. They physically do an activity together at one time.
Programmers do things differently. If programming were masonry, each programmer would waste his part, and at the end he would bring his beautiful masonry building and want to combine it with other parts built by other mason-programmers.
The worst part is that this could work better than many attempts to merge code from developers. Especially those who have as much in common with each other as José Mourinho’s teams have with offensive football – that is, nothing, and that means, they don’t know each other (these programmers) are often from other cities, countries, have communication problems, in fact, they hardly talk to each other at all. Welcome to distributed teams.
In the model, when all the programmers are in one office they can, in the meantime, approach others and ask, chat, solve a problem together. In distributed teams and remote working, this is no longer so easy. Especially when your colleague is sleeping because he is from a different time zone. How would this cooperation even work?
A process is needed
Process equals corpo, corporation, but are you sure? Is it possible to deliver code that meets some standards (not necessarily EU standards) and at the same time meets business needs without having any process? It probably can, but on a very small scale. When the team grows and at that time other teams are formed in the organization, which in some way have to cooperate with each other, and what they are building is supposed to form a larger whole in the end, it turns out that the so-called “team” is not a team. YOLO development and pushing to mainwith force flag does not necessarily work.
Pleasant with useful
It is possible? Programming is cool, a little less cool as in addition to programming you still have to write tests, documentation, share knowledge and (omg) get out of the garage and talk to people. I don’t know how much of my time is taken up by communication and cooperation with other people, despite that it is certainly important (which is why I am writing this article). Really. Ladies and gentlemen, let’s talk about effective collaboration techniques!
Techniques of collaboration
I will focus here on collaboration techniques that have been around for many years, and I probably won’t discover America. On the other hand, not everyone uses them, and in my opinion they are especially important in remote or hybrid work.
Pair programming
There are several types of pair programming, as this technique is still evolving while it can be described in general as a technique where two programmers sit at the same computer and work on solving a given programming program. One programmer physically writes the code, while the other is an observer while also influencing what the former writes.
Pair programming in remote work
I’ll freely admit that when I worked in the office, we didn’t use this technique directly whereas when there was a bigger problem to solve, we would sit down at one computer and try to solve the problem.
The analogy is with remote work. When something difficult comes up, developers “get together” and try to solve the problem together. There is one difficulty here, because in the office work in a tricky situation the observer could take over the keyboard, while in remote work he usually looks at the screen provided. Fortunately, there are appropriate tools to help carry out pair programming in remote form.
Mob programming
The concept of Mob programming is similar to pair programming, only in this case more than two people work together. Programming in this way seems chaotic, but despite this, it is a very good approach that allows you to use a lot of “brains” to create a more efficient solution. In such a model, the person who is the navigator and facilitator is tasked with leading the meeting and moderating the collaboration so that the developers engage in the collaboration and, of course, so that they don’t kill each other. Although… you can’t kill anyone by working remotely.
Communication
Once a programmer gets out of his garage and wants to talk to others, he has several ways to do so. He can write on Slack, send an email, arrange a meeting, or go to a meeting organized by someone else. At a time when a period placed at the end of a sentence is called a hate period, and the absence of an emoticon a sign that someone is offended, communication is difficult.
It can be difficult to feel emotions at video meetings, sometimes it’s hard to see someone when they have the camera off. Meetings by themselves are boring, and meetings remotely, where there are more than two people, can sometimes be awful.
Effective communication
I think there are some general ways of communication that work for both remote and officework.
Respect
The first thing is respect. Each of us is different, has different views (even on programming) and the basis is to respectfully listen to others and respectfully speak to them.
Openness
Respect is followed by openness, that is, a willingness to understand another point of view. More and more often I listen to people who have a completely different point of view on an issue, because it allows me to better understand an issue and learn often something new.
Flexibility
If we were to compare our work to a movie, we are the lead actors in our movie. People who work with us – these are people who have supporting roles, but at the same time they have their own film in which they play leading roles.
What I’m getting at is that the moment we need something from someone else, we can’t expect them to leave everything and suddenly throw themselves to our rescue. We should be flexible and realize that we are not the navel of the world and the problems and tasks of others – are at least as important as ours in the bigger picture.
For me, flexibility in the context of communication means understanding others and not forcing someone to respond immediately to our messages and demands.
Concretes
What you can say in two sentences, say in one, and what you can write as 1,000 characters – shorten it to one paragraph. Short, concise and to the point. Be straightforward about what you need and your expectations.
Teamwork in the age of remote work
Is remote work for everyone? This is a very interesting question, because usually remote work is praised to the skies because it gives you flexible working hours and takes away standing in traffic (obviously). Unfortunately, remote work, like everything, also has a dark side. Flexible working hours can become a horror when you lose the boundary between life and work, and sitting at home all day (because you don’t have to go to the office) will make you miss face-to-face contact with people.
You can deal with these pains and come up with a “system” of work that is optimal for you. It is noteworthy that there are people who openly say that remote work is not for them, and that is fine. Everyone has their own way of working and living.
Teamwork – summary
Teamwork is quite a challenge for developers, and even more so in an era of remote work and globally dispersed teams. There are problems with communication, understanding others and unnecessary stress. Respect, openness and flexibility in communicating with others will give you the foundation for good cooperation. There’s also something I didn’t mention earlier – you should start with yourself to work effectively in a team and communicate with others. Take care of your health, well-being and fitness. When you feel good about yourself – others will also feel good about you and work will be more enjoyable.
