A question on SQLTeam a few weeks ago got me thinking about the idea of what language you THINK in.  Do you remember the movie Firefox?  (Okay, that came out in 1982, before some of you were even born, but at the time I was a Clint Eastwood fan and into military aircraft, so back off!)  The key to the movie is that the jet (codenamed Firefox) has a neural connection and the pilot controls things like firing armament by thinking the command.  Of course, it being the 1980s, the bad guys we were stealing the plane from were the Russians (or probably more accurately Soviet Union) so Clint had to THINK in Russian.

Okay, maybe you don't like that example, so let's talk about learning any foreign language.  You know you're truly fluent when you can think in that language instead of thinking in your native language and translating.  You may be able to translate on the fly pretty fast, but you're nowhere near as efficient as someone who thinks in that language.

So when you're building systems, what language do you think in?  Thinking in Access SQL is different from thinking in SQL Server T-SQL and both of those are very different from thinking in Oracle.  And the differences are even greater when you're talking about stored procedures instead of ad-hoc query syntax.  Another contrast we see on SQLTeam a lot is people who think in procedural languages like VB or C# versus those who think in set-based languages like SQL.  You can tell what your thinking language is by looking at your initial thoughts on how to tackle a problem.  A good friend and client of mine, who is very smart technically, tends to think procedurally.  I can think procedurally, but I've also learned to think set-based.  The difference often comes out when we are talking about various approaches to a problem.  For example, his idea might be to extract a set of data and iterate through it categorizing and perhaps performing math; whereas my approach would be to see if we can craft a single SELECT statement with the right grouping and aggregate functions to have the database engine do all the hard work for us more efficiently.  My approach works better when you can use a set-based language like SQL.  His works better on some of the legacy systems we deal with that just don't support the syntax I would need.  But it's interesting to see what causes us to come at the same problem with two very different solutions, and that being whichever language we are thinking in.

As for the question on SQLTeam...you'll notice that the person is essentially asking for a translation from Oracle, the language he's thinking in, to SQL Server syntax, but the recommended answers are to scrap that approach and instead learn to think in SQL Server.

So, what language do you think in?  Is it the same one that you're currently being paid to use?  If not, you are not as efficient as you could be.  And your code may be horribly inefficient, too.