>>> same goes for pair programming. Does it work better than the alternative? Yes? Great. No? Knock it off then. I've worked at small and large companies and I

>>> same goes for pair programming. Does it work better than the alternative? Yes? Great. No? Knock it off then. I've worked at small and large companies and I've had the same experience with pair programming. It's done as a means to supplant actual, formal training. It's utilized as a shortcut to get a dev vaguely familiar with the architecture of your system and do rudimentary tasks so they can jump in and start working in a day or so. The painful downside of not adequately training your developers is tasks take longer, other more experienced devs are sapped by helping other devs who continually ask them questions and keep them from getting their stuff done because they can't find something, or simply don't know the proper process. I've been on both sides and seems like proper training is really a thing of the past. No company wants to invest the time in their developers to give them the tools and knowledge to really do their job well. As a replacement, you get "pair programming" as a substitute to proper training program. And yes, I know this isn't the point of pair programming at all. But lately (last three years or so), this is how the companies I've worked at use it. The ironic thing is several of the companies I worked at had a two to three week sales training which culminated in a test to make sure you knew the companies products inside and out. Developers? Maybe a lunch with a lead dev, or a twenty minute whiteboard explanation about their system architecture.