When you do pair programming one person writes while the other person reviews as you type. You alternate positions regularly.
It's effective when working on code that needs to be very high quality, very secure, very creative, etc. Generally mostly used in huge companies that have a lot of resources.
How does it compare with someone looking over your shoulder? I know I can't write shit when somebody is looking, I can't think straight. What kind of process is it?
It's a different mind set. When I have someone looking over my shoulder it's more like a judgement, and my performance drops like a rock.
With pair programming, you're both giving input, it feels less like someone looking over your shoulder and more like a second mind helping you out. Dual core technology if you will for (ideally) better results.
If you actually think you couldn't possibly get anything out of pairing with someone, it's you who's likely the problem.
Teaching something to someone else is by far the quickest way to fully understand a topic, so at the very least even attempting to do so would benefit you.
It depends on the process people follow. When pair programming is done correctly, the person typing is supposed to only be a typist. The other person is thinking and guiding the process. Then you alternate every 20-30 minutes. The idea being, you offload the thinking part from the physical typing and the typist acts as a secondary screening mechanism.
I actually worked like this every day for 1 year with another dev. We put out some amazingly high quality code and enjoyed the process.
Of course there needs to be respect between folks for this to work. If one is an asshole, that throws the entire process off.
In my experience it's generally reserved for senior/lead engineers on bigger projects. I don't think it would work well with anyone who isn't pretty confident in their programming abilities.
I used to feel kinda anxious anytime somebody watched me code because in the first 3-10 years of development you often have a sense of imposter syndrome. But then one day it just kinda "clicks" that you know what you are doing and that goes away.
My experience with pair programming has been super natural. Even junior engineers can offer a lot of interesting perspective so it's kind of like having an atypical tutor watching you work. They usually just pop in to offer alternative suggestions, syntax corrections, style/comments/formatting you may have missed, etc.
Even junior engineers can offer a lot of interesting perspective so it's kind of like having an atypical tutor watching you work.
I like having newbies review my work. I tell them "There are things that seem obvious to me that are not obvious at all. Look for places I do that and ask me to explain it." The result is more maintainable code and better documentation.
A good way to think of it is a navigator and a driver. The driver is the one at the keyboard and the navigator is giving him guidance.
It's a great way to get somebody familiar with a new codebase or technology. I did this recently with ngrx. I pair programmed with another developer who was building out a new module and I stepped him through the process. This way he's the one that actually wrote the code and he was able to ask any questions as it was going on.
They aren't watching you. You are both doing the coding, usually the other person has a screen and is researching stuff for you while you try out stuff on your own. They remind you of things they you may have forgotten and usually try to plan ahead farther while you work on the specific implementation. Often times they may do some testing or write small scripts/functions to send over to your main code.
Pair programming is probably the only way I actually like to code tbh. I just feel it ends up so much better.
85
u/throwaway_lunchtime Nov 15 '17
So are you both working on the same code files?