Team Programming Psychology

When several people work on the same project (code), the software development process begins to differ significantly. With this fact one cannot but agree. A number of additional factors come into play. The overall result is a decrease in development speed, and sometimes the quality of the software being developed can also decrease.

How to be then? After all, there are projects that can not be written alone. In this article I will try to show one psychological aspect of working in a team of programmers. I will arm you with some theoretical knowledge, thanks to which you can improve the efficiency of programmers and their overall emotional background.

What is the reason for the decrease in efficiency and quality of software?

Factors reducing the effectiveness of programmers can be divided into objective and subjective.

Subjective factors affecting efficiency

Rejecting banal interpersonal hostility, suppose that in our situation we have a team of several programmers with a sufficient level of emotional understanding and respect. However, even in such a team there may be problems.

The fact is that the programmer develops a sense of ownership to the code. After all, the code is something that he created, and it is something tangible (it can be seen on the monitor screen). The programmer can perceive the code as an object ( I wrote this code ) and as a space (when this code is open in my editor, I feel comfortable ). Thus, the code can be “mine”, “not mine” in the same way as a chair or as a room. This is my chair, and I'm sitting on it (I wrote this code). This is Vasya's chair, and Vasya uses it, and I am emotionally uncomfortable sitting on it (Vasya wrote this code).
')
I want to emphasize that we are now talking about the subjective self-identification of the programmer with the code that he sees on his screen.

A programmer, while working, may feel that this code is “his” or “not his.” This self-identification with the code is pretty important. If a person believes that the code is "his", then he:

• will not feel rejection (something like "your shit does not stink so much")
• The overall emotional feeling of the programmer will be elevated. He will feel himself in the comfort zone and “at home” (think how he will feel when working with someone else's code ... 8 hours a day ... for several months in a row)
• he will have a sense of owner and owner (even more primitive: the feeling of a leader, after all, mostly programmers are men). These feelings provoke a man to show initiative, responsibility and a proactive attitude towards the object of ownership (to the code, in our case)
• in "my" code, it is not scary to do refactoring. Something like "this is my property, and I do everything I want with it"
• modifying "your" code, the programmer will make just as many changes in the code as necessary to make the necessary adjustments and maintain the architecture of the code. But if the code were “alien”, then the programmer would most likely try to make the minimum necessary changes. Adding functionality, but not supporting the architecture, he would most likely have “stuck” the new functionality on the side to the existing one.
• people tend to be cautious in a strange / new place: if the programmer is required to make significant changes in the “alien” code, he will spend a lot of time familiarizing himself with the code (will try to make this code “his own”) and will tritely feel more emotional by making the necessary changes. In the worst case, it will simply “stick” its code to the already existing one (see the previous paragraph)
• By ruling the “alien” code, we emotionally affect its owner. Consciously or subconsciously, programmers recognize the ownership of other programmers in areas of code in the same way as in a family at the dinner table every member of the family is secretly recognized. Consciously sitting on the "alien" chair at the table, you feel discomfort due to the emotional impact on the "owner" of the chair.

Also, I note separately that we are now talking about revisions in the code. Reading the code and especially using (calling "other people's" functions) does not affect the emotional state of programmers.

Objective factors

There is also an objective component: it may be that the programmer knows this code, or does not know this code. By “know the code” I mean remembering the names of the functions and what they do. It is not difficult to notice that this knowledge is really objective - they either exist or not, and it doesn’t matter how our poor experimental programmer feels. In order to make the correct changes to the code, a person must know it objectively.

Concrete and Problem Statement

What do we have? A theoretical ideal state for a project would be: all programmers objectively know all the code and all programmers consider all code to be “their own”. But tell me, please, can one toothbrush have 2 hosts? Unfortunately not. Any programmer “touching”, making changes to the code, makes this code more “alien” in the eyes of the author of the code (the “current” owner).
Purpose : each programmer should work (the maximum possible time) with a code that he knows, and which he considers "his". That is the result is already possible to achieve.

The solution of the problem

In the process of software development, objective knowledge about the project and the subjective self-identification of programmers to the code will change. Our task will be to influence the distribution of knowledge and feelings of ownership in order to maintain the goal set in the last paragraph. The more the programmer knows about the project or the more code he considers “his”, the better. Porridge butter will not spoil. We have nothing to lower these things for, but it is always useful to increase them.
Another thing is that increasing these factors takes time from our programmers. And here the question of rationalization arises: programmers can spend 2 hours a day getting to know their project and 2 hours a day to increase their sense of ownership ... But then they will only have 4 hours a day to productive work: (.
Before we get to the issue of rationalization, let's look at the levers of influence. To enhance the objective knowledge of the code are suitable:

• the most proven way is to be the author of the code :)
• any written documentation about the code
• verbal and written communication between programmers

To enhance the sense of ownership of the code, the following methods are suitable:

• again, method number 1 - to be the author of the code
• objective knowledge of the code. Still, it’s easier to recognize for your “own” the thing in which you at least understand your work.
• code reviews - when the author of the code shows the code and consults with another programmer, this other programmer has an effect on the code (perhaps even some of his advice will get into the code). Peculiarly, the author “acquaints” the second programmer with the code, and some kind of “our” property arises.
• sticking to the code design standards increases the “mine” property among all team members, but there are some reservations (about them below)

Separate paragraph about code design standards (another way to increase the sense of ownership, just too long)

Code design standards (whatever they are) mainly aim at unifying the appearance of the code. So they make it easier to read the code, and they also contribute to increasing the identity of the programmer with this code, even if he sees it for the first time.

But it was not there. The code can be designed identically, but the logic that the code follows will differ from the one that our experimental programmer would use (our programmer would use the while loop, and the code is written foreach ). These differences between the logic of the code and the logic of the one who reads this code, and lead to the fact that a sense of ownership in the end is not created. That is why the requirements for the design of the code do not give the full expected result on the one hand, on the other hand they to a certain extent constrain the freedom of programmers and add another layer of bureaucracy.

One solution would be to force all programmers to think the same logic, to implant the one and only correct logic (or to detail the requirements for the design of the code up to when to use while , and when to use foreach ). But this is utopia. In addition, all people are different, and why "clone" 10 programmers for a carbon copy.
It is better to cultivate mutual understanding among programmers and help them get acquainted with the logic of their fellow programmers. In particular, code reviews, can make programmers know each other’s logic quite well. The magic of code review is that the programmer Vasya gets into his hands the code written by programmer Petya, but Vasya does not have to edit anything in it. He only studies the work of Petit and after that, tells Petya his thoughts (Vasya suggests Petya to change something in Petit’s dining chair, but the chair itself does not touch). While Vasya and Petya communicate, they manage to understand how and what both of them like. Thus, in the future, Vasya, seeing the code of Petit, will already feel much more comfortable knowing the logic of Petit.

Rationalization issues

How to find a balance between the fact that programmers continue the development of the project, but at the same time always worked on the code that they feel “their”? The answer to this question will depend very much on the context. I will only show you 2 of the most radical methods, and these 2 extremes are unlikely to ever be appropriate for use in a living situation, rather you will need to find a balance between these 2 opposites.

Method number 1. Separation of responsibility and "personal rooms"

If the specifics of your project allows you to:

• clearly break the project into several subtasks, virtually unrelated to each other
• have irreplaceable programmers (if the programmer leaves, the project will collapse or suffer greatly),

then give your programmers little minks where they will be the sole masters of the situation. You will only need to clearly agree on how these “minks” will interact with each other, and the internal implementation of each mink will be taken over by its “master” (responsible programmer).
This is a rather radical approach, and therefore it has quite significant drawbacks:

• you will have irreplaceable programmers (if the mink owner leaves, it will be difficult for someone else to accompany this mink)
• if all but one “mink” are ready, then programmers who have already completed their work will not be able to really help a programmer who is behind the schedule, since do not know the specifics of the "mink" and rather will only annoy the programmer

Pros:

• one can do without documentation of intra-mink processes. Since one mink is supported by one programmer, he can keep all this in his head
• programmers practically do not spend time on communication

Method number 2. Forum

Forum - area for mass communication. Similarly, your software can be turned into an area for mass communication, when everyone will know all the parts of the project and will interact very closely with each other. The advantages and disadvantages of this method are practically the inversion of the advantages of the “personal mink” method.

Conclusion

In addition to the correct distribution of programmers and communication between them, it is also important to take into account the way the project is managed and developed. Is it often expected to change the vector of development and often change the current tasks of the project? Is this a mature project? Take into account the peculiarities of your programmers, maybe there is a genius among them, but he simply cannot accelerate and fly upwards under a huge amount of bureaucracy? How confident are you about the responsibility of your programmers and that they will not leave you halfway? Think and decide.