I like how this digs into pair programming using these two as an example - pair programming, at least when I was coming up, was seen as a panacea to all software development problems. However, in our field, suffice it to say there are "difficult" personalities or people much more comfortable working alone, and in practice, I've rarely seen success with it, personally, more than someone looking over your shoulder every now and then to debug something. As a primary working method, which it seems like the subjects of this article are doing, you definitely need to find someone who thinks like you.
I've had things that were close, but usually devolves into multiple short 10-20 minute meetings, division of tasks, then reconvene, rinse/repeat. That typically works well and I don't have to deal with people nitpicking how I use my editor or how many chrome tabs I have open.
It's not like I don't like reviews or cannot work alongside another person. It's I cannot learn while someone is talking to me or trying to make me place the cursor somewhere.
I'm all in for code review, even in pairs. In fact, I do that with a junior dev I have assigned and it's working well for us. I leave him thinking and come back to evaluate his solution.
I find reviewing him paired, is time saving for me. I make him lead me to the right code spots, rather than finding out on my own. I fire 3 quick questions and we're aligned on the spot.
I'll never work again on a 100% pp position but I think I've found my sweet spot with the technique.
I agree that, if no other safeguards are in place, using pp you can avoid real bad code. But without deep thought, you'll mostly converge to an average solution, when social dynamics are very much leading.
It was really special to see how this pair basically laid out the foundations of large-scale distributed computing. Protobufs, huge parts of the search stack, GFS, MapReduce, BigTable... the list goes on.
They are the only two people at Google at level 11 (senior fellow) on a scale that goes from 3 (fresh grad) to 10 (fellow).
I don't enjoy these types of lionizing articles, badically these types of articles is what you give $10k-$50k to a PR team and they start to write these articles yo elevate your reputation in the industry ...
JohnMakin ·126 days ago
I've had things that were close, but usually devolves into multiple short 10-20 minute meetings, division of tasks, then reconvene, rinse/repeat. That typically works well and I don't have to deal with people nitpicking how I use my editor or how many chrome tabs I have open.
_zamorano_ ·126 days ago
It's not like I don't like reviews or cannot work alongside another person. It's I cannot learn while someone is talking to me or trying to make me place the cursor somewhere.
I'm all in for code review, even in pairs. In fact, I do that with a junior dev I have assigned and it's working well for us. I leave him thinking and come back to evaluate his solution.
I find reviewing him paired, is time saving for me. I make him lead me to the right code spots, rather than finding out on my own. I fire 3 quick questions and we're aligned on the spot.
I'll never work again on a 100% pp position but I think I've found my sweet spot with the technique.
I agree that, if no other safeguards are in place, using pp you can avoid real bad code. But without deep thought, you'll mostly converge to an average solution, when social dynamics are very much leading.
Show replies
gandalfgeek ·126 days ago
It was really special to see how this pair basically laid out the foundations of large-scale distributed computing. Protobufs, huge parts of the search stack, GFS, MapReduce, BigTable... the list goes on.
They are the only two people at Google at level 11 (senior fellow) on a scale that goes from 3 (fresh grad) to 10 (fellow).
Show replies
bell-cot ·126 days ago
And 102 comments on HN at the time: https://news.ycombinator.com/item?id=18588697
williamDafoe ·126 days ago
Show replies