And, then there's the more ephemeral stuff. Let's say we have a team member who doesn't produce a lot of code and what they do produce isn't very good. But, they have a very good understanding of the application's architecture and have been instrumental in avoiding a number of pitfalls. What value does that person bring to the team? Personally, I like having people like that on board. But, how do you measure "pitfalls avoided through lunch discussions"?

This is a very key idea .. one of the reasons I love working where I am now is that I can get into a discussion with a co-worker in the kitchen, get something figured out, and get on with my job -- it's extremely efficient. The old guard methods of having a weekly all-hands meeting strikes me as incredibly wasteful. Development should be done way more as an interrupt-driven process and way less as a polling process. And by interrupt-driven, I'm not talking about going into someone's cube and interrupting them -- I mean Management By Walking Around, where you talk to each of the developers and find out where they're at.

Ultimately, it boils down to the fact that programming isn't engineering - it's sculpting or music composition.

Yes. I'm also a musician, and (sometimes) a composer, and I know that there are days where you're on -- good stuff just comes out of your hands and you make music, or write great code. Other days, it's just not happening. And that's when you need to take a break, drink coffee, look out the window for a while.

About twenty years ago I had a manager with a background in Tourism (really) who was bossing a crew of C developers, and he just didn't get that sometimes, developers need to stop and think, to figure out how to approach the problem. He thought that if you weren't sitting at your computer typing, you were goofing off.

Obviously, I heartily disagree.