The Rise of the New Groupthink
My current company, a startup, has an even split of developers, half under 30 and half over 45. I'm one of the old guys. The development environment and approach, mostly set up by the young guys, is pretty modern -- lots of open source tools, hosting on launchpad, test-driven development, code reviews, all developers in one big open space, everyone does everything (as opposed to developers doing development, testers writing tests, build engineers creating build infrastructure).<p>The young guys seem to thrive in this setup. It's driving me nuts.<p>I am most productive when I have a problem to solve and I can immerse myself in it for hours every day, days at a time, without interruption. But now I have to do timely code reviews for others.  I also have to respond to reviews of my code. The encouraged way of working is to commit small, reviewable pieces, but then each commit involves several interruptions, and it's difficult to go on to part 2 while addressing everyone's concerns about part 1. The infrastructure is problematic, because no one actually owns it, so there are more interruptions to deal with problems there.<p>Everyone has an IRC window open, and while there isn't too much social chatter, there is a distraction every time that a message arrives. (I hate IRC. I was forced to it in my last job, when people would IRC my officemate to get hold of me.)<p>I recognize the benefits of some of these practices. Code reviews do catch problems. (On the other hand, a code review often acts as a substitute for a design review, so we actually end up reviewing and maintaining bad designs.) More people know more of the code, and we avoid problems created by a guy going into a cave for weeks at a time.<p>But there is no denying that this style of working really makes it difficult to concentrate, at least for me.