I think Dan Pink's best point is actually, 'pay people enough so that they stop thinking about money and start thinking about the work'. It's impossible to be intrinsically motivated to build the world's best frobgasting tidwiddler for someone else when you are worrying about how you are going to feed your children tonight, or where you are going to sleep. It's only once our basic needs are being met on a sustainable basis that we can branch out and explore our interests and drives in other areas. As a species, we've taken around 196,000 years or so to get to a point where we don't have to constantly think about how to survive, and it's amazing how our culture has exploded in a veritable orgasm of complexity in the remaining 4,000 years. We're all in it for the money up to a certain point, because like it or not, money is survival - beyond that point is where all the interesting questions start to appear, and where we still have a lot to learn, it seems.

+1 anyone who commented that LINQ to SQL creates parameterized SQL queries that are re-used efficiently at the database. Compiled queries aren't very flexible because they don't support dynamic composition, which is arguably one of the best features of LINQ (and LINQ to SQL as well). The shape of a compiled query is static, and you can only perform parameter substitution when it is executed - you can't change its shape at runtime. This is fine for your basic SingleOrDefault() or Where() queries, but the vast majority of queries I need to write require some form of dynamic composition (add a filter when these parameters are specified, change the projection when this parameter is specified, etc). While you could attempt to factor a dynamically composed query into multiple static compiled queries, I return to the maxim, if it ain't broke, don't fix it! Compiling queries just for the sake of it is premature optimization at its worst, and shouldn't be done without exacting proof from a profiler, and an incumbent performance problem.