30 ms·

I see a huge opportunity to mentor Junior devs by doing this.

• poulsbohemian 9y ago
  Completely agreed, but this is probably the only real use for this technique. For experienced (read: expensive) developers, the cost overhead of having two or three developers working on one problem (which is likely a one-person task anyway) is too great. I'm certain proponents would push the quality angle -- that two or three pairs of eyes and brains focused on the problem improves quality -- but there are other ways to boost quality while maintaining a more realistic productivity and cost structure. For less-experienced developers though, this would be a great way of building team cohesiveness, training/mentoring, plus likely boosting productivity.
  • taoistextremist 9y ago
    I would argue it's also useful for new team members in general, or for teams that have in the past been unorganized. At my current job I've spent a lot of time refactoring code so that there's some more unity among everything, because everybody does their own thing and doesn't really collaborate, which makes maintenance a pain in the ass. Something like this that kind of forces people to work together and create some kind of unified style could be very beneficial. Not to mention when I've seen experience developers show something they've been working on for the past two weeks, only to be told what they've shown is a disaster because they never had any other eyes on it to question their design decisions.