TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Pair Programming at a Startup: time sink or saviour?

11 点作者 henryaym将近 14 年前

17 条评论

davidsiems将近 14 年前
I'm a fan of 'Plan together, implement independently.'<p>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.<p>Bad design decisions concern me a lot more than a bug here or there.<p>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.<p>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.
评论 #2903913 未加载
评论 #2904006 未加载
bitsweet将近 14 年前
What is missing in most <i>pairing</i> debates is the amount of pairing day to day being discussed.<p>Periodic pairing can be a great team building exercise, way to mentor someone, and a great way to be exposed to different programming workflows &#38; tools. This idea doesn't seem very novel to me and hardly deserves it's own terminology, blog post, or article.<p>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 <i>always</i> pair.<p>Also, if 2 people are better then 1 person...why stop there...why not have tri-coding or quad-coding?
评论 #2904005 未加载
geebee将近 14 年前
I've done pair programming, and I enjoyed it, but I wouldn't want to make it my normal way of working.<p>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.<p>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).
wvenable将近 14 年前
Isn't pairing just a more immediate (and annoying) form of code reviews? I'd take code reviews over pairing any day.
评论 #2904349 未加载
socratic将近 14 年前
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.<p>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.<p>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.<p>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?
评论 #2904085 未加载
MrKurtHaeusler将近 14 年前
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.<p>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.<p>Combining those two practices is very powerful.<p>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.
_corbett将近 14 年前
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.
pavel_lishin将近 14 年前
&#62; So the question posed here, is peer programming a time sink for an early stage startup? No. &#62; That being said peer programming is just another tool in an arsenal that startups should use in appropriate situations.<p>So the answer is, "maybe". Neat.
iam将近 14 年前
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.<p>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.<p>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).
lallouz将近 14 年前
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.<p>I do like these Shelby guys though, so I would love to hear from them in more detail of how it went?
ww520将近 14 年前
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.<p>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.<p>(just kidding)
评论 #2904503 未加载
mkrecny将近 14 年前
I'm the happy partner in this week of peer programming. Great post and great results
100k将近 14 年前
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!
thomasgerbe将近 14 年前
Also relevant:<p><a href="http://en.wikipedia.org/wiki/Pair_programming#Costs_and_benefits" rel="nofollow">http://en.wikipedia.org/wiki/Pair_programming#Costs_and_bene...</a>
评论 #2903881 未加载
spinosa将近 14 年前
1 coder for the price of 2! What a steal ;-]
gte910h将近 14 年前
I'm not sure it's 2x productive, and can be annoying/tiring as hell. Much better used in moderation.
plain0x将近 14 年前
Remember "Hackers and Painters". Painters like to work alone. <a href="http://www.paulgraham.com/hp.html" rel="nofollow">http://www.paulgraham.com/hp.html</a>
评论 #2904309 未加载