Dinosaur here. I think that these social programming ideas are nuts. At my first job writing production software, we did three things. We brainstormed. We wrote and critiqued designs. We coded (which includes writing unit tests and debugging).

There was basically no open source. If we needed something, we found it in libc, or wrote it, and if it was good, others in the company used it too.

It was incredibly productive and satisfying.

At my current company, I find much less up-front design. We don't do pair programming, so the collaboration tends to be at the end of the process, during code review. And good god, there is no end to the code reviews. I don't understand how anyone can do both good code reviews, and good software development. There isn't enough time or attention for both. I notice that when we're getting toward the end of a release, there is all sorts of shorthand in the code reviews. Reviews like "looks good to me", "nothing jumps out at me", "I only did a cursory scan", etc. This is shorthand for "our process requires code review, so I'm claiming that I've done a code review, but really I haven't." So we end up with no collaborative design at times. And of course, when code review does work, we're finding design flaws late.

There is far less NIH these days, and that's a good thing. There are high quality projects out there, and you can grab one, evaluate it, and save yourself a lot of time. This saves time on building things that are tangential to whatever it is you are trying to do.

But reuse can also go wrong in a few ways. You may spend a lot of time wading through crap. You may try something out, commit to it, and then discover the flaws only much later. You can spend a lot of time finding an open source solution to a problem, learn the API, tweak the internals to improve the fit, and then in hindsight realize that you would have been better off just writing the thing yourself. Frameworks are especially prone to this problem. Yes, they do a lot of things for you, but you have to drink so much kool aid to get the benefit. And then there is inertia, and you tend to fight the framework once you stray from the exact approved way in which it's supposed to be used. Another problem with just downloading something is that your less talented developers tend not to question how the thing works, and not have a good understanding of how it is best used, and what you'd better not try.

What I find is that with all this browsing, and downloading, and trying things out, and making things fit, and reading code, and fixing trivial things demanded by the process, and in general, just doing things in the modern way -- there is just no time for thinking about things hard, forming an idea, and taking the time to express it cleanly.

I won't even get into the latest, highly interactive project management cults. Daily scrums are the modern equivalent of TPS reports.

I haven't tried pair programming and I never will. I'll leave a job if asked to pair program. I'll leave the profession if necessary and program as a hobby. For me, the reason I put up with all the nonsense is those few hours a week when I can actually get a nice problem to work on, think about it, come up with a solution, make it simpler, simpler, simpler, code it, make it simpler some more, and make it fast. Put on the music, get into the zone, and think and hack. Seems much harder to do in recent years.