how to work in a team of programmers?

How to work in a team of programmers?

One of the most effective ways to work in a group is to work in pairs. Such mini-teams are often called “feature teams”: a small group stands out, usually 2-3-4 people, and they work together on one single feature. They have a goal in front of them, they fully know and understand it. In such a team, communication links are well established, people are in the dense context of their work.

Working in pairs is very inspiring and gives rise to the concept of “collective responsibility” in the minds. If one of the participants does not have time to complete his part of the tasks on time, he must immediately notify his colleagues and correct the path of the entire team, otherwise the work of the team will fail. You should always try to find a common language and be ready to help. In our Internet Lesson, in one of these pairs, the frontend developer was ahead of the work of the backend. After a quick consultation, the guys decided to draw up a “contract” and cover it with “mocks” so that the frontend could continue to integrate, and during this time the missing part of the development on the other side was completed.

There is no such thing that the coherence of work in a team is perfect, and the pace is synchronous. Someone is bound to be on to something. At the same time, you need to try to keep the team moving at the same speed, and remember that this speed is always measured by the slowest person. It happens that a team of professionals is formed – a locomotive that rushes forward without brakes, and not everyone can withstand such a speed. Perhaps some participant is not yet ready for such a pace, and then he needs to be moved to another team, where he will show the greatest efficiency and results.

How to work in pairs where a project colleague misses deadlines or makes serious mistakes?

If a colleague does not pull, makes a lot of mistakes and allows bugs, the speed of the whole team drops. In modern development methodologies, such as Scrum, Agile, etc., there is a “retrospective” meeting. At the retrospective, there is a team that works on one project, and if the department is not very large, then the entire development group. The purpose of the retrospective is to find out what problems and stoppers were identified during the work during this sprint. At such a meeting, it is necessary to talk about the problems that have arisen. Do not be shy and think that you are “knocking” on your partner, this is wrong. It is necessary to highlight the issue, to say that such a problem arose in the feature team, and on the side of a particular person there were jambs or delays in terms. The main idea here is to openly discuss your problems, as well as to receive collective help. At the meeting, there must be a leader, a team leader who will pick up the issue.

The reasons for breakdowns can be completely different, from a difficult period in life and a lack of knowledge to an unfair attitude and parallel work on the side. A decision must follow from this. If a person has not matured yet, he needs to be paired with another specialist. In any case, the team leader takes control of the problem, watches the lagging behind, sees how he manifests himself. If, after a series of measures taken, a change of team and partner, the employee repeats the mistakes, most likely you will have to say goodbye and not waste the nerves of both parties.

If speed is important in your team, you need to build pairs of approximately equal strength, otherwise you risk failing the work of the entire team and demotivating your employees.

There is a practice: if a colleague does not have time, the whole team should rush and help the lagging behind. This altruism does not always help. Sooner or later, and most likely sooner, the team will get tired of doing this. It’s one thing when a person doesn’t understand something, turns to colleagues, and they help him catch up (if there is a mentor, you need to contact the mentor to pull him up). And if we talk about “covering and dragging on our hump”, of course, this will only result in negative and will be reflected in the whole team.