Pair Programming at a Startup: time sink or saviour?(henrysztul.info)
henrysztul.info
Pair Programming at a Startup: time sink or saviour?
http://henrysztul.info/post/9079201249/peer-programming-time-sink-or-savior
18 comments
I agree with this - whenever I see that a company has actual pairing stations (computers with mirrored monitors and two keyboards and two chairs) I tend to shy away.
However, I still think everyone should have their OWN whiteboard, to enable precisely the conversations you mention. Easy enough if you have cube walls, but I've never seen a good whiteboard story in newfangled open-plan startup offices.
However, I still think everyone should have their OWN whiteboard, to enable precisely the conversations you mention. Easy enough if you have cube walls, but I've never seen a good whiteboard story in newfangled open-plan startup offices.
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'
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 in my experience excessive. Other then commercial pilots, I don't see other industries where experts always pair.
Also, if 2 people are better then 1 person...why stop there...why not have tri-coding or quad-coding?
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 in my experience excessive. Other then commercial pilots, I don't see other industries where experts always pair.
Also, if 2 people are better then 1 person...why stop there...why not have tri-coding or quad-coding?
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.
- 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.
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).
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).
Isn't pairing just a more immediate (and annoying) form of code reviews? I'd take code reviews over pairing any day.
Indeed. Pair programming is basically a continuous peer code review. I think you can get most of the benefits of pair programming from code reviews for a fraction of the cost.
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?
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?
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.
Also a huge benefit is learning. In that second example there is a lot of valuable skills transfer going on.
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.
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.
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.
> So the question posed here, is peer programming a time sink for an early stage startup? No.
> That being said peer programming is just another tool in an arsenal that startups should use in appropriate situations.
So the answer is, "maybe". Neat.
So the answer is, "maybe". Neat.
Emergent peer programming is the best. I've done 2-3 instances of it over the last 3 years and it definitely felt like we truly moved mountains during those couple of hours.
One time we wrote a quite complicated graph-based algorithm (as in, lots of bug potential, but it turned out bug free) and the other two times we fixed bugs that hounded us for weeks in just one session.
I definitely feel like it works best in those situations when both people can complement each other somehow. If it's just a junior/senior person it will probably not be very useful for the senior person (note I mean a true junior here with little programming experience, not just some non-senior engineers).
One time we wrote a quite complicated graph-based algorithm (as in, lots of bug potential, but it turned out bug free) and the other two times we fixed bugs that hounded us for weeks in just one session.
I definitely feel like it works best in those situations when both people can complement each other somehow. If it's just a junior/senior person it will probably not be very useful for the senior person (note I mean a true junior here with little programming experience, not just some non-senior engineers).
I am very much against the idea. I do think there are valuable excercises where you work in a pair to do software design, however the idea of sitting behind the same computer for 2 days with the same person does not sound great. That being said, I am always happy to have 2nd pair of eyes look at some of my code, just not in the moment its being written.
I do like these Shelby guys though, so I would love to hear from them in more detail of how it went?
I do like these Shelby guys though, so I would love to hear from them in more detail of how it went?
Pair programming is great since it's a mutual monitoring setup to prevent goofing off at work. You are far less inclined to read HN or Twitter if someone is sitting beside you watching. Likewise you are watching your coworker, too.
Think of the 2 to 3 hours real work done days? Now it's straight 8 hours of real work. You come out ahead even with two people at one job.
(just kidding)
Think of the 2 to 3 hours real work done days? Now it's straight 8 hours of real work. You come out ahead even with two people at one job.
(just kidding)
I actually think this is a valid point. The productivity gains from the lack of goofing off might not, by itself, cancel out the cost of two programmers, but in concert with the other benefits mentioned, like fewer bugs, it could result in a net gain in productivity.
I'm the happy partner in this week of peer programming. Great post and great results
Nothing wrong with pair programming, but it sure is easier to be "a profitable company that had two programmers sitting in front of one computer, writing code, together" if the company charges by the hour!
Studies have found reduction in defect rates of 15% to 50%
Correlation does not equal causation...other practices that usually accompany teams that pair include continuous integration and a strong focus on automated testing.
Correlation does not equal causation...other practices that usually accompany teams that pair include continuous integration and a strong focus on automated testing.
1 coder for the price of 2! What a steal ;-]
I'm not sure it's 2x productive, and can be annoying/tiring as hell. Much better used in moderation.
Remember "Hackers and Painters". Painters like to work alone. http://www.paulgraham.com/hp.html
Remember "Dabblers and Blowhards"
http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm
[deleted]
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 implementing is as fast (and usually faster) than sitting down at the computer and trying to bang something out from scratch.
When you do things this way you don't really need to have another person there because you've already agreed on all the important details.