51–60 of 136 posts
> Sit so that the monitor is between the two of you. No. Use two monitors that are mirrored or with screen sharing, so that each person can sit comfortably centred on their own screen.
We tried out Live Share (collaborative editing) during pair and mob programming sessions. I enjoyed it a lot - made it feel like a multi-player game. Sometimes it did allow for the equivalent of a pair programmer taking over the keyboard rather than explaining how to solve a problem. I’m curious if anyone has any Live Share patterns / anti-patterns.
I recommend to instead let your pair in through SSH (a reverse proxy, like ngrok, is useful), and then sharing a tmux session.
The greatest pattern is explaining your goals and seeing if other people's goals align with yours.
The chances of that conversation resulting in 'pair programming', is 0%.
Earlier quoted context omitted.
> I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. IMO this is a very wrong way to look at pairing. It's not about one person being incapable of delivering a solution on their own, it's that having multiple perspectives on the code will lead to a higher quality and more we…
My experience is that pairing is deeply disruptive to my exploration of a design. It forces me to slow down and verbalise something that I can clearly visualise in my mind, when the fastest way to externalise it for me is often to write the code and show it. I'm happy to walk people through a prototype afterwards and discuss it and if necessary throw the thing away and start over or significant revise it. I'm not hap…
I also find that getting stuck alone on a problem kicks me into a procrastination spiral whereas I tend to find it easier to push on when I'm stuck with someone. It also helps prevent me from getting into a spiral of second guessing every technical decision ive made in the last month.
I dont really think people take to pairing or not on the basis of its prima facie effectiveness though, but rather whether they enjoy programming as a solitary or social activity.
Really, I think teams should be set up to ensure people who like pairing to be together and vice versa, coz i feel just as miserable working alone all day every day as you do pairing.
I work at a place where we do exclusively pair programming (a software consultancy). A project always has at least one pair. Each workstation has a computer, 2 monitors, 2 mice and keyboards. When someone can't be at the office then we sometimes use Tuple, and it's a great tool, unfortunately still only works on Macs. Pairing works for us because it's more efficient than working alone, less bugs and better thought ou…
Which company do you work for? I researched pair programming companies a while back and didn’t find any.
I'm not sure about pair programming. I never really understood why we stop at two people. Why not have 3 or 5 people working together? And indeed that's what we do when for example doing system design and it's incredibly useful. Writing mundane code in pairs sounds like a brute force solution that should be solved by training, higher quality code scanners or other code quality tools.
Having larger groups collaborate like that is called "mob programming". I'm not sure how popular it actually is but I see it talked about on HN and Reddit all the time.
Earlier quoted context omitted.
> Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming. I think this is the key takeaway with one missed point. IMO it definitely does produce more work vs. solo programming but that work is sub-par. The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and…
The part of my brain which thinks deeply and produces elegant solutions simply shuts down when I constantly have to explain my thought process to someone else. I actually have the same problem in pair programming interviews - my brain tends to freeze up and comes up with strange, hacky workarounds at best. Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who p…
This is the key in my mind. Pair programming doesn't work for me, based on past experience. Pair design works great, and rubber ducking into a slack channel (that people expect that kind of thing to be in); those are things I find highly useful. But when it comes time to actually write code, I tend to work best alone.
I think part of the reason for this is that I tend to work through designs and possible implementations in my head, but by writing code. Then I'll discuss those designs to come up with some possible issues (pros/cons/etc). Then I'll work on implementing what seems likely to be the best choice (which is may not be once coding starts). By the time I get to coding, most of the impact of someone else being involved is just going to be catching typos. Or possibly code written in a hard to maintain way... but code reviews will catch that just as well (probably more so, because the person reviewing it _wasn't_ there when it was written).
I'd rather two people independently understand and solve a problem and compare solutions.
There was some research in the early 90’s over multiple implementations as a way to avoid bugs. I still feel like it was dismissed prematurely or could be revisited.
Earlier quoted context omitted.
Which company do you work for? I researched pair programming companies a while back and didn’t find any.
Large consultancy, pair programs all the time, Java... I would guess Pivotal
Using two input devices on one PC never occurred to me. Is it just plug and play or does it require some setup ?