3 ms·

I don't understand how anyone tolerates pair programming. After many years of software work I still spend half to three quarters of my time googling/experiment

by lumost 5y ago

I don't understand how anyone tolerates pair programming. After many years of software work I still spend half to three quarters of my time googling/experimenting with how to do things. When I'm writing/tracing code I don't want anyone else on the keypad which I have to explain a half baked thought to. Sometimes I want to just see where a half-baked idea leads! Sometimes I want focus time as I know exactly how I intend to do something and don't want to be questioned every other line of code. I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together! Why would anyone want to do this?

thow_away_soon 5y ago
I think it depends on the nature of the task and on the experience of your pair. If the task is more mundane, you get someone to think about corner cases and other consequences while you code, or vice versa. This is a great way to onboard beginners, as you constantly show not only your code but your process and tools. If the task is more exploratory, a second person might still be helpful, specially if it is someone with more experience; they can provide real time feedback on your ideas and it might be valuable. For me, it is not just about getting the work done, it is about knowledge diffusion and code quality - I can't remember now and didn't search again, but there is some data gathered on IBM that shows that, while pair programming doesn't deliver code faster, it usually deliver code with less bugs. > I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together! This doesn't seem to be a problem inherent to pair programming; you'd need management or someone else to deal with those people in any scenario.
eternityforest 5y ago
If someone was literally questioning every line I wouldn't want to work with them at all, they probably fuss over details and have refactored 5 line functions multiple times in one day. Otherwise, pair programming keeps people from getting "brilliant ideas" that actually aren't, or having an episode of laziness and doing something obviously not best practice. If you parse HTML with regex, your partner can tell you to stop. It's also like a real time test of code quality. If they ask what you're doing, then you know your approach isn't instantly obvious. The only time I get annoyed is when I work closely with the simplicity-loving dependency-fearing types, and the hacker types who always want to solve interesting problems. My best skill as a programmer is finding ways to reinterpret a problem in terms of things that are already widely used, and make the whole project into just some glue code. I'm not too happy when someone is trying to replace my Ansible with Bash and my framework with vanilla, or my Etcher with dd. But even then, those people are very good at spotting weaknesses in whatever I was planning, and the product is better for it, once the best-practices solution inevitably wins put eventually.
throwaway984393 5y ago
> I'd imagine that pair programming You haven't tried it, but you're telling everyone what you think about it anyway?
- eternityforest 5y ago
  Ive done pair programming, just not formalized in the kind of high process culture they talk about.
- lumost 5y ago
  I’ve done it sporadically to help someone out of a tight spot, or for interactive deep dives on a code base as a teaching tool. I have found it helpful in short bursts for teaching a junior engineer how to work on a code base.

by lumost 5y ago

thow_away_soon 5y ago

I think it depends on the nature of the task and on the experience of your pair. If the task is more mundane, you get someone to think about corner cases and other consequences while you code, or vice versa. This is a great way to onboard beginners, as you constantly show not only your code but your process and tools. If the task is more exploratory, a second person might still be helpful, specially if it is someone with more experience; they can provide real time feedback on your ideas and it might be valuable. For me, it is not just about getting the work done, it is about knowledge diffusion and code quality - I can't remember now and didn't search again, but there is some data gathered on IBM that shows that, while pair programming doesn't deliver code faster, it usually deliver code with less bugs. > I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together! This doesn't seem to be a problem inherent to pair programming; you'd need management or someone else to deal with those people in any scenario.

eternityforest 5y ago

If someone was literally questioning every line I wouldn't want to work with them at all, they probably fuss over details and have refactored 5 line functions multiple times in one day. Otherwise, pair programming keeps people from getting "brilliant ideas" that actually aren't, or having an episode of laziness and doing something obviously not best practice. If you parse HTML with regex, your partner can tell you to stop. It's also like a real time test of code quality. If they ask what you're doing, then you know your approach isn't instantly obvious. The only time I get annoyed is when I work closely with the simplicity-loving dependency-fearing types, and the hacker types who always want to solve interesting problems. My best skill as a programmer is finding ways to reinterpret a problem in terms of things that are already widely used, and make the whole project into just some glue code. I'm not too happy when someone is trying to replace my Ansible with Bash and my framework with vanilla, or my Etcher with dd. But even then, those people are very good at spotting weaknesses in whatever I was planning, and the product is better for it, once the best-practices solution inevitably wins put eventually.

throwaway984393 5y ago

> I'd imagine that pair programming You haven't tried it, but you're telling everyone what you think about it anyway?

eternityforest 5y ago
Ive done pair programming, just not formalized in the kind of high process culture they talk about.
lumost 5y ago
I’ve done it sporadically to help someone out of a tight spot, or for interactive deep dives on a code base as a teaching tool. I have found it helpful in short bursts for teaching a junior engineer how to work on a code base.