4 ms·

Why Every Startup Should Pair Program

9 points by jkopelman 14y ago

TheCoelacanth 14y ago
Just that picture of their office alone would put me off from ever working there. The level of distractions must be horrible.
- jpalermo 14y ago
  I've worked there for 5 years. The office does seem loud when walking through it, but not once have I felt that the noise interrupted me. Now, that may not be true for everyone, but we hire new people all the time, and I've never heard anyone raise it as a complaint (although I have seen many comments like yours over the years from people who have seen pictures of our office). A big reason why I think people don't get distracted is the pairing. Pairs do a good job of keeping each other focused.
  - michaelwww 14y ago
    From your site "As developers, we generally like to work across Ruby on Rails, JavaScript, iOS & Android" Pair programming probably works when you are hooking things up with glue code for the most part, that's my best guess. That's the only case where I could see it working for me and it would probably be kind of fun and interesting. I can't imagine doing anything that required a lot of sustained concentration however, unless your engineers are doing that when they get home from work and find some quiet time (probably.)
usea 14y ago
> Machines should be communal How do I configure things sufficiently? Color schemes, hotkeys, layouts, UI configurations, etc. I have about 40 hotkeys via an AutoHotkey script and innumerable changes to my OS that make me more productive. When I sit at somebody else's computer I feel like I'm swimming through molasses. How is this resolved? Also, what if you have a few coworkers with severe attitude and/or competency issues? I can't imagine pair programming would be an improvement from simply avoiding them.
- jasonwocky 14y ago
  To the first, these things tend to spread throughout the team over time, so by the end everybody will be using those 40 hotkeys if they're indeed helpful. If some people like them and others don't, they'll figure out how to resolve the difference with the least possible amount of fuss. With regard to color schemes, I've never seen a dispute over those, personally. People may come to the table with different preferences, but over time those also resolve one way or another. In my experience, severe competency issues are actually /better/ dealt with via pair programming than the alternative: pairing forces their competency issues to the surface, and can be dealt with more easily. Personality conflicts can be worked through, or the team can be changed up. When things like that don't work out, the worst thing you can do is make too big a deal out of it...reconfigure the team one way or another and move on.
  - usea 14y ago
    Thanks for the honest reply. I really appreciate it.
michaelwww 14y ago
"Software development is really about people and is a social activity." That's news to me. I thought software development was long periods of quiet concentration while attempting to keep a program in one's head.

9 points by jkopelman 14y ago

Just that picture of their office alone would put me off from ever working there. The level of distractions must be horrible.

jpalermo 14y ago
I've worked there for 5 years. The office does seem loud when walking through it, but not once have I felt that the noise interrupted me. Now, that may not be true for everyone, but we hire new people all the time, and I've never heard anyone raise it as a complaint (although I have seen many comments like yours over the years from people who have seen pictures of our office). A big reason why I think people don't get distracted is the pairing. Pairs do a good job of keeping each other focused.
- michaelwww 14y ago
  From your site "As developers, we generally like to work across Ruby on Rails, JavaScript, iOS & Android" Pair programming probably works when you are hooking things up with glue code for the most part, that's my best guess. That's the only case where I could see it working for me and it would probably be kind of fun and interesting. I can't imagine doing anything that required a lot of sustained concentration however, unless your engineers are doing that when they get home from work and find some quiet time (probably.)

usea 14y ago

> Machines should be communal How do I configure things sufficiently? Color schemes, hotkeys, layouts, UI configurations, etc. I have about 40 hotkeys via an AutoHotkey script and innumerable changes to my OS that make me more productive. When I sit at somebody else's computer I feel like I'm swimming through molasses. How is this resolved? Also, what if you have a few coworkers with severe attitude and/or competency issues? I can't imagine pair programming would be an improvement from simply avoiding them.

jasonwocky 14y ago
To the first, these things tend to spread throughout the team over time, so by the end everybody will be using those 40 hotkeys if they're indeed helpful. If some people like them and others don't, they'll figure out how to resolve the difference with the least possible amount of fuss. With regard to color schemes, I've never seen a dispute over those, personally. People may come to the table with different preferences, but over time those also resolve one way or another. In my experience, severe competency issues are actually /better/ dealt with via pair programming than the alternative: pairing forces their competency issues to the surface, and can be dealt with more easily. Personality conflicts can be worked through, or the team can be changed up. When things like that don't work out, the worst thing you can do is make too big a deal out of it...reconfigure the team one way or another and move on.
- usea 14y ago
  Thanks for the honest reply. I really appreciate it.

michaelwww 14y ago

"Software development is really about people and is a social activity." That's news to me. I thought software development was long periods of quiet concentration while attempting to keep a program in one's head.