Live data from Hacker News

Pair Programming at a Startup: time sink or saviour?

henrysztul.info

11–20 of 27 posts

Re: Pair Programming at a Startup: time sink or saviour?

#11
post #7

What is missing in most pairing debates is the amount of pairing day to day being discussed. Periodic pairing can be a great team building exercise, way to mentor someone, and a great way to be exposed to different programming workflows & tools. This idea doesn't seem very novel to me and hardly deserves it's own terminology, blog post, or article. Personally I believe "pair all the time" is what is controversial and…

Yes, this article sort of follows this logic:

- We tried pairing for one day

- Pairing was immensely productive for that session

- Therefore pairing is AWESOME all the time

Pair programming ought to be considered like trimming your nails. Don't do it everyday or it's going to hurt. A lot.

Re: Pair Programming at a Startup: time sink or saviour?

#12

I'm a fan of 'Plan together, implement independently.' I don't need someone looking over my shoulder hunting for bugs while I program. What I need is someone to bounce high-level ideas off of so that I don't get paralyzed by indecision, or overlook an important edge case. Bad design decisions concern me a lot more than a bug here or there. In my experience, planning with someone else away from the computer, and then…

I think once a month you should pair program randomly with someone. I think programming effectively involves combining thinking in the large and implementing in the small. Ive found that occasional pair programming teaches me new keyboard shortcuts, tools, workflows, idioms and when pair programming with a great programmer also gives me a very clear feedback that much remains to be learnt. In short Ive found that pair programming is great about teaching me about 'implementing in the small'

Re: Pair Programming at a Startup: time sink or saviour?

#15
I have seldom done it well. Normally one person rushes off to "just quickly try this idea", without really explaining it ("just wait a minute, it will be quicker to just type it in than explain it") so the other person is limited to basically spotting errors which is slightly useful, but probably not the best way to spend a second programmers wages.

It excels in combination with TDD. One person writes a test, and the other person makes it green and writes the next test and so on.

Combining those two practices is very powerful.

Another time I don't like to pair is when debugging or trying to understand some old legacy code or something. If two people have different strategies for doing that it doesn't really make sense to pair. I like to write a lot of stuff down on paper for example, another guy likes to click "step" in the debugger on a lot.

Re: Pair Programming at a Startup: time sink or saviour?

#16
I'm confused by people who pair all the time, because it seems like the benefit of pairing varies heavily depending on the current programming activity.

For example, when I'm debugging, I can easily be several times more productive with someone else trying to guess what is going wrong. On the other hand, for most "glue programming", it feels like a huge waste of time to be looking over someone's shoulder while they try to figure out the best library to play sound or how some website API works.

Regular programming where all of the libraries and general plan are known seems in between those two extremes. Sometimes a second person can help detect problems and/or keep the first person on their game, but sometimes basic conflicts over code style can arise.

I've never been part of a pair programming shop, but I've tried pair programming with similarly inexperienced pairs before. How do people who pair all the time resolve problems like redundancy when looking up or learning information? Relatedly, how do they solve situations where basically one person is the only person who understands how to solve the problem (either because of skills like statistics or because of knowledge like understanding some API), and the second person is just along for the ride?

Re: Pair Programming at a Startup: time sink or saviour?

#17

I'm confused by people who pair all the time, because it seems like the benefit of pairing varies heavily depending on the current programming activity. For example, when I'm debugging, I can easily be several times more productive with someone else trying to guess what is going wrong. On the other hand, for most "glue programming", it feels like a huge waste of time to be looking over someone's shoulder while they t…

I think it generally tends to reduce the amount of surfing around for information, as the chances of one of two people knowing what to do or where to look are twice as great.

Also a huge benefit is learning. In that second example there is a lot of valuable skills transfer going on.

Re: Pair Programming at a Startup: time sink or saviour?

#18
my co-founder and I don't pair program per se but we both are familiar with each other's main domain and often switch (front end/back end) when the other is stuck or frustrated. this works pretty well, I've found, and has the added bonus that we both know the product back to front.

Re: Pair Programming at a Startup: time sink or saviour?

#20
I've done pair programming, and I enjoyed it, but I wouldn't want to make it my normal way of working.

As a math major, I was far more successful when I went to study groups, spent hours trying to prove theorems with other students, or the TA or professor, and so forth. In a way, you could say that's a kind of "pair math", at least the part where you try to work on a proof with another person.

I'd say stay very social and engaged with other people, and don't go dark, but I think tough coding problems require a lot of quiet focus in a place with minimal distractions as well. Like, I'd encourage programmers to find work from a local university library (for some reason, this works better for me even than a private, quiet office).

Post reply on HN