Hacker News Reader

Comment by otras | Hacker News Reader

This is such an interesting approach. I’ve read about this at Pivotal, and it’s interesting to see how it’s described on their blog vs Glassdoor. I greatly enjoy working with another engineer to solve an especially tricky problem, but only pair programming seems like it would be exhausting.

What do you like and dislike about it?

View on HN

I totally agree it is useful for particularly tricky problems. It is not a coincidence that what I like the most about it is the initial discussion on the potential approaches to solving the problem. But then when we move into the implementation phase, that is when things get tiresome after four months of continuous and permanent pairing, because in my case, I appreciate silence and time to focus and think at my own pace. Maybe permanent pairing is just not an useful thing honestly. I guess I'm wondering if anyone has successfully done it for months at a time.

That definitely makes a lot of sense, and I also value the balance between hashing out an approach together and the silence and focus that thinking at my own pace allows. I've never worked at a job with permanent pairing and don't plan to, but I'm always interested to hear what it's like on the ground. Thanks for sharing!

It's not clear which aspect of the pairing makes it tiresome for you.

Do you feel that you are the 'typer', or that you feel pushed, or being corrected too often?

Maybe for a change you may reverse the roles, or swing the pairing partner. Besides, it's not like the process is set in stone, each pair's dynamic could be different. Some pairs don't match well or wear out.

Bring it up, after all it's not a policy for its own sake.

I dislike someone sitting next to me telling me what they think I should type for 6-8 hours a day.

I noticed you mentioned before that you are currently a company founder; was your full pair-programming experience at a previous job? Was that what it was like, and were you forced to work with an individual in which that was the dynamic?

My guess would be that full pair-programming wouldn't be uni-directional (you type, I tell you what to type, all day, every day), but I could definitely see that being the worst-case scenario.

Yes at a previous job and all of us were in one location so it was more common to sit in the same cubicle, the one person typer probably arose from that. I was not forced to do it, I imagine if I would have complained accommodations would have been made but I'm fully capable of working like that so I stuck it out. There were days where I was not the primary person typing and I would always try to steer the work towards larger sets of changes that could be completed by one person in a predictable amount of time, once found I would suggest they work on that while I step away and work on something else. It might be that the programming I have been involved with is so banal that I have not encountered a problem that could not be described in advance well enough to allow all engineers to work on a separate piece of the application. I also found that pairing sometimes led to excessive non work related conversation.

I would say your last statement is correct, each team needs to find working dynamics that make all members successful. I finished the project on that team and accepted a contract position in another city for a larger client.

We have a new project though, a graph backed transaction management platform, that will require more collaboration than our usual crud app but we will still not have a policy that involves "sit down and write the code together."

Reply on news.ycombinator.com