SoylentNews is people
SoylentNews
When we're confronting a vexing problem, we often gather a group to brainstorm. We're looking to get the best ideas as quickly as possible. I love seeing it happen—except for one tiny wrinkle. Group brainstorming usually backfires.
In brainstorming meetings, many good ideas are lost— and few are gained. Extensive evidence shows that when we generate ideas together, we fail to maximize collective intelligence. Brainstorming groups fall so far short of their potential that we get more ideas—and better ideas—if we all work alone. As the humorist Dave Barry quipped, "If you had to identify, in one word, the reason why the human race has not achieved, and never will achieve, its full potential, that word would be: 'meetings.' " But the problem isn't meetings themselves—it's how we run them.
[...] Collective intelligence begins with individual creativity. But it doesn't end there. Individuals produce a greater volume and variety of novel ideas when they work alone. That means that they come up with more brilliant ideas than groups—but also more terrible ideas than groups. It takes collective judgment to find the signal in the noise and bring the best ideas to fruition.
Source: time.com
From HIDDEN POTENTIAL by Adam Grant
I am sure most of you have spent time "brain storming" ... was it productive or wasted time ?
(Score: 4, Interesting) by JoeMerchant on Thursday October 26 2023, @02:34AM (3 children)
In high school we went to a regional "programming contest" where other high schools like us fielded teams of 5-7 students to solve programming problems live. I think there were 2 or 3 sessions around 90 minutes each with problems like: determine if a string is an anagram, compute and display the Fibonacci sequence... some slightly more complex stuff... We were working on Atari 800s, as were some other teams, and of course there were more Apple IIs and C64s. The type of computer didn't seem to matter, we were pretty much all using BASIC. What did matter was how the team approached the problems.
We had 5 computers, and the 5 of us worked independently on the problems... we were plagued with bugs that were not too hard to solve, but were too time consuming to solve in the allotted time. The more successful teams would all stand behind a single typist on a single computer and work on one problem at a time. Like the old internet saying: "If you want to get lots of people to respond, just post something incorrect" - the "observers" behind the typists were quicker to find and fix bugs than the solo programmers blasting through the code start-to-finish and missing their mistakes along the way.
Of course, that's an example of inexperienced students solving trivial problems on a ridiculously short time scale. In real-life I found the independent work approach checked by someone who knows if the thing is right or wrong by looking at it after a day or two to be better for most things, but occasionally something like implementation of cubic spline interpolation would come along and _that_ is a problem that lends itself to pair programming, especially when one of the pair has no confidence that they can do it correctly.
For real "brainstorming" (generating new ideas - instead of implementing things you can find in a textbook, or on Stack Overflow and similar these days) the main benefit of having "the team" in the room is if "the team" is bringing knowledge of applicable blockers - able to quickly shoot down ideas that just won't work because X. Of course, some people love to shoot down ideas like that and don't really know if the blocker is real and/or insurmountable, but they'll act like it is - such actors should of course be banned from creative sessions and sent to accounting to fight with the IRS instead, they're usually happier there anyway.
🌻🌻 [google.com]
(Score: 2) by tangomargarine on Thursday October 26 2023, @03:30AM (2 children)
Was going to mention this myself...has anybody else here been on a paired programming team? I was for a year, but they cut my position before I got really familiar with the codebase :P So I don't feel qualified to comment on how well the idea works.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 3, Informative) by JoeMerchant on Thursday October 26 2023, @11:48AM (1 child)
In my experience, paired programming works brilliantly in very specific circumstances. Doing it all day every day is too much for me. Doing it for a 2-4 hour session with a "compatible" partner can be as productive as 12+ hours of either partner working alone. At most, I used to do that 2 or 3 days a week, and generally no more than 6 or 8 days in a month. YMMV, and I have certainly also worked with partners where 30 minutes was about the limit of productive paired work.
🌻🌻 [google.com]
(Score: 3, Insightful) by coolgopher on Thursday October 26 2023, @09:45PM
I agree with Joe. There are situations where pair programming really enhances productivity, and there are situations where it does the opposite. The more fiddly and complex the problem, the more likely a second brain is to be valuable. Cases where it's clear where you're going and how to get there, a second brain is more likely to be a distraction (and it bored).