When several people are working on the same project (code), the software development process starts to differ significantly. One cannot but agree with this fact. A number of additional factors come into play. The overall result is a decrease in the speed of development, and sometimes the quality of the software being developed can also decrease.
What then? After all, there are projects that cannot 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 increase the efficiency of programmers and their general emotional background.
Subjective factors influencing efficiency
Putting aside banal interpersonal hostility, suppose that in our situation we have a team of several programmers with a sufficient level of emotional understanding and respect. Nevertheless, even in such a team there can be problems.
The point is that the programmer develops a sense of ownership of the code. After all, the code is something that he created, and it is something tangible (you can see it on the monitor screen). A programmer can perceive code as an object (I wrote this code) and as a space (when I have this code open in my editor, I feel comfortable). Thus, the code can be "mine", "not mine" just like a chair or a room. This is my chair and I am sitting on it (I wrote this code). This is Vasya's chair, and Vasya uses it, and I feel emotionally uncomfortable to sit on it (Vasya wrote this code).
I want to emphasize that we are now talking about the programmer's subjective self-identification with the code that he sees on his screen.
The programmer, while working, can 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 doesn't stink that much")
the programmer's overall emotional feeling will be heightened. He will feel in his comfort zone and "at home" (think how he will feel, working with "someone else's" code ... 8 hours a day ... several months in a row)
he will have a sense of the owner and the 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 position in relation to the object * of property (to the code, in our case)
refactoring is not scary in "my" code. Something like "this is my property and I do whatever I want with it."
When modifying "his" code, the programmer will make exactly as many changes in the code as needed to make the necessary adjustments and maintain the code architecture. But if the code were “alien”, then the programmer would most likely try to make the minimum necessary changes. By adding functionality, but not supporting the architecture, he would most likely "stick" the new functionality on the side of the existing one.
people tend to be cautious in someone else's / new place: if a programmer is required to make significant changes to a “foreign” code, he will spend a lot of time familiarizing himself with the code (he will try to make this code “his”) and will simply feel more emotionally constrained making the desired changes. In the worst case, he simply "sticks" his code to the existing one (see the previous point)
By editing someone else's code, we emotionally affect its owner. Consciously or subconsciously, but programmers recognize the ownership of other programmers to pieces of code in the same way that a family at the dinner table tacitly recognizes a place for each family member. Sitting deliberately on a "foreign" chair at the table, you feel discomfort due to the emotional influence exerted on the "owner" of the chair.
Also, I will separately note that we are now talking about edits in the code. Reading the code and especially using (calling "foreign" functions) does not affect the emotional state of programmers. Learn more about how to improve team relationships
In the process of software development, objective knowledge about the project and subjective self-identification of programmers to the code will change. Our task will be to influence the distribution of knowledge and 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. You can't spoil porridge with butter. There is nothing for us to lower these things, but it is always useful to raise them.
One solution would be to force all programmers to think with the same logic, to impose the same and only correct logic (or to detail the requirements for coding, down to when to use while and when to use foreach). But this is a utopia. Besides, all people are different, and why “clone” 10 programmers as a carbon copy.
It is better to cultivate rapport among programmers and help them familiarize themselves with the logic of their fellow programmers. Code reviews in particular can do a pretty good job of getting programmers to learn each other's logic. The magic of code review is that the programmer Vasya gets his hands on the code written by the programmer Petya, but Vasya doesn't have to edit anything in it. He only studies Petya's work and after that tells Petya his thoughts (Vasya invites Petya to change something in Petya's dining chair, but he does not touch the chair itself). While Vasya and Petya communicate, they manage to understand how and what both of them like. Thus, in the future, Vasya, seeing Petya's code, will already feel much more comfortable, knowing Petya's logic.
Top comments (0)