= 27d567bc2d48d9f40e9ccc20ea370b15)
matt comments on Anti-akrasia remote monitoring experiment - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (114)
This is like pair programming except you don't have to cut your productivity nearly in half.
To clarify: I've always believed that most of the benefit from the practice comes from the fact that work is actually being done for an increased portion of the time in front of the monitor, and that the costs and benefits of discussion roughly balance.
Pair programming reduces variability in productivity rate, so looking back on a pairing session you should expect to remember occasions when you felt that you'd been slowed down, and should not expect to have noticed occasions when you'd saved time.
Alistair Cockburn has a study up somewhere showing (from memory) a small increase in work hours to first thunking you're finished, a large reduction in bugs, and an improvement in subjective measures if code quality. Trike's experience matches this study - we think pairing is awesome. .