Oh how I hate this. Hard to hear, no subtitles, 24 minutes long, and I have no idea beforehand whether it will be interesting. The only clue I have is that someone here on HN thought it would be.
Is there a transcript? Summary? Abstract? Anything? I'm not going to sit through several minutes of hard-to-hear video just to find out if there might be some value.
I skimmed the video by listening to 20 or so seconds every few minutes of the video, so forgive me if my take away missed out on something. This is what I got from it:
Change workflow from string (Person A takes Issue A, Person B takes Issue B, Person C takes Issue C) to a "swarm" (Issue A taken by People [A-C], Issue B taken by People [D-F])
Multiple eyes pass the code = more bugs caught. Social pressure to be working on the project (group of 4-5 people). If things fall too far behind, revert to "string" method of each person working on an individual issue.
Results in less time wasting (FB/Twitter) due to social pressure. Some study said a pair of 2 is the most productive, but they feel the social pressure is too high in that scenario, hence group of 4-5 to relieve social pressure while maintaining the benefits of collaborative work.
Not worth the time. Not all that interesting. Mostly saying stuff that many "lean startups" have learned. That pair coding increases productivity. They just applied this to their queue instead of only new features or something.
Nadya - Thanks the summarizing the video! You mentioned that other lean startups have done this, could you point me to other lean startups working in this methodology? I'd love to learn how others are approaching this idea.
I've also found while many accept that pair-programming increases productivity it's rarely implemented. The video we created outlines an approach that is an alternative to pair-programming but maintains many (if not more) of the benefits.
Colin - Thanks for the feedback. I was trying to put up the content as quickly. I'll go back and update the post with a summary/abstract or talking points.
That would be great. Possibly create a page with summary points, book, narrative, take-away highlights, and a link to the video. Then people would know at least roughly what it's about, and have something to hand as they watch the video.
And thank you for the positive response, and apologies for being rather grumpy in my reply.
5 comments
[ 2.8 ms ] story [ 24.9 ms ] threadIs there a transcript? Summary? Abstract? Anything? I'm not going to sit through several minutes of hard-to-hear video just to find out if there might be some value.
Change workflow from string (Person A takes Issue A, Person B takes Issue B, Person C takes Issue C) to a "swarm" (Issue A taken by People [A-C], Issue B taken by People [D-F])
Multiple eyes pass the code = more bugs caught. Social pressure to be working on the project (group of 4-5 people). If things fall too far behind, revert to "string" method of each person working on an individual issue.
Results in less time wasting (FB/Twitter) due to social pressure. Some study said a pair of 2 is the most productive, but they feel the social pressure is too high in that scenario, hence group of 4-5 to relieve social pressure while maintaining the benefits of collaborative work.
Not worth the time. Not all that interesting. Mostly saying stuff that many "lean startups" have learned. That pair coding increases productivity. They just applied this to their queue instead of only new features or something.
I've also found while many accept that pair-programming increases productivity it's rarely implemented. The video we created outlines an approach that is an alternative to pair-programming but maintains many (if not more) of the benefits.
And thank you for the positive response, and apologies for being rather grumpy in my reply.