A few misunderstandings of pair programming
I have a lot of programming experience accumulated over the past few years. Part of the experience I gained while working in my team, something while working with clients, and some experience came from coding dojo and working on open source projects.
For programmers who know how to use pair programming, it provides an opportunity to improve their performance. But you should not expect that programmers will significantly improve their performance from the very beginning. Pair programming requires constant training, as well as awareness by the programmers themselves of a clear difference between the performer (the one who knocks on the keyboard) and the navigator. Below is a more detailed description.
A. This is the one who constantly orders.
Those who like to give orders usually ask the performer to add a “)” at the end, and after it dots “...”. However, they do not care about the overall picture as a whole, but are more concerned about specific details in programming. In fact, such a person rather himself wants to quickly get behind the keyboard. So when you encounter someone who likes to command, just offer him your place at the keyboard.
B. This is the one who likes to correct spelling errors.
If the navigator is constantly sitting near you, correcting your every mistake, then he simply will not have time for real control. So when he starts to correct your mistakes again, just start talking to him or invite him to bring you a cup of coffee (or something else).
C. This is the one who criticizes.
The critic will criticize every line of code you write. If he really turns out to be right, then in the future he will not use it, and insistently demand his own. Try to change your roles, and then the critic will be completely satisfied with your code.
D. This is the one who quietly behaves.
A quiet person is someone who only expresses his opinion. He just looks at your work. Try to find out his opinion about what you are programming, or to find out what next test you need to write.
E. This is the one who has no thinking.
This is the type of people who serve only to constantly distract you, and not to offer you any constructive opinions and solutions to problems. So just let him go. You are quite capable and independently engage in programming, rather than doing it with a person who constantly bothers you.
A. This is the one who does not say what he is doing.
This is the type of people who just write code, without telling anyone what they are writing. The navigator must figure out why this code is needed. In this case, between the performer and the navigator there are no discussions about the chosen methods and methods of their implementation. The navigator just has to listen to opinions and learn about the plans of the artist.
B. This is the one who has developed a great conceit.
Such people usually ignore the proposals of the navigator, because they consider their ideas to be the best. Faced with a similar, it is better to just stop and start to engage in the next task. He who has his own self-esteem is too high, is unlikely to be a good navigator. It is likely that he will most likely only be able to give orders or criticize.
C. This is the one who does not know what and how to do.
Such people usually get little pleasure from pair programming. They are excited, and simply unable to cope with the current situation. Just make sure that you actually played the role of navigator in the best possible way. It is necessary to be extremely cautious, expressing your opinions, and, first of all, offer your support. Most programmers experience this at the very beginning. Therefore, you should not pin high hopes. First, allow him to be a navigator, or find another navigator who can work together with this performer.
D. This is the one who skips pieces of code.
Such a person likes to skip part of the code, with the result that the navigator no longer understands what's what. In such a situation, the navigator should slow down and learn about the future plans of the performer, and also make sure that he knows more hotkeys than he.
E. This is someone who is not familiar with the toolkit.
This type of people who do not use hotkeys in the development environment, because they are not aware of their effectiveness. Try to swap your roles, and show him your work techniques. Well, or just give him a ready cheat sheet with the entire list of hot keys.
For programmers who know how to use pair programming, it provides an opportunity to improve their performance. But you should not expect that programmers will significantly improve their performance from the very beginning. Pair programming requires constant training, as well as awareness by the programmers themselves of a clear difference between the performer (the one who knocks on the keyboard) and the navigator. Below is a more detailed description.
1. Misunderstandings about the navigator.
A. This is the one who constantly orders.
Those who like to give orders usually ask the performer to add a “)” at the end, and after it dots “...”. However, they do not care about the overall picture as a whole, but are more concerned about specific details in programming. In fact, such a person rather himself wants to quickly get behind the keyboard. So when you encounter someone who likes to command, just offer him your place at the keyboard.
B. This is the one who likes to correct spelling errors.
If the navigator is constantly sitting near you, correcting your every mistake, then he simply will not have time for real control. So when he starts to correct your mistakes again, just start talking to him or invite him to bring you a cup of coffee (or something else).
C. This is the one who criticizes.
The critic will criticize every line of code you write. If he really turns out to be right, then in the future he will not use it, and insistently demand his own. Try to change your roles, and then the critic will be completely satisfied with your code.
D. This is the one who quietly behaves.
A quiet person is someone who only expresses his opinion. He just looks at your work. Try to find out his opinion about what you are programming, or to find out what next test you need to write.
E. This is the one who has no thinking.
This is the type of people who serve only to constantly distract you, and not to offer you any constructive opinions and solutions to problems. So just let him go. You are quite capable and independently engage in programming, rather than doing it with a person who constantly bothers you.
2. Misunderstandings about the artist.
A. This is the one who does not say what he is doing.
This is the type of people who just write code, without telling anyone what they are writing. The navigator must figure out why this code is needed. In this case, between the performer and the navigator there are no discussions about the chosen methods and methods of their implementation. The navigator just has to listen to opinions and learn about the plans of the artist.
B. This is the one who has developed a great conceit.
Such people usually ignore the proposals of the navigator, because they consider their ideas to be the best. Faced with a similar, it is better to just stop and start to engage in the next task. He who has his own self-esteem is too high, is unlikely to be a good navigator. It is likely that he will most likely only be able to give orders or criticize.
C. This is the one who does not know what and how to do.
Such people usually get little pleasure from pair programming. They are excited, and simply unable to cope with the current situation. Just make sure that you actually played the role of navigator in the best possible way. It is necessary to be extremely cautious, expressing your opinions, and, first of all, offer your support. Most programmers experience this at the very beginning. Therefore, you should not pin high hopes. First, allow him to be a navigator, or find another navigator who can work together with this performer.
D. This is the one who skips pieces of code.
Such a person likes to skip part of the code, with the result that the navigator no longer understands what's what. In such a situation, the navigator should slow down and learn about the future plans of the performer, and also make sure that he knows more hotkeys than he.
E. This is someone who is not familiar with the toolkit.
This type of people who do not use hotkeys in the development environment, because they are not aware of their effectiveness. Try to swap your roles, and show him your work techniques. Well, or just give him a ready cheat sheet with the entire list of hot keys.
')
Source: https://habr.com/ru/post/147921/
All Articles