Ajarn Mark Caldwell Blog

Bringing Business Sense to the IT World…

What Language do you THINK in?

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.

Legacy Comments


thibbard@engraph.com (tim hibbar
2004-06-25
RE: What Language do you THINK in?
Good article. I find that I think for very efficent, low cpu intesive code, as most of my first production projects were on old school palms and 200 mhz PII's.

Seventhnight
2004-06-25
re: What Language do you THINK in?
Well said!!

James Curran
2004-06-25
re: What Language do you THINK in?
(Plot hole is FoxFire: The scientist who was help Clint steal the plane *specifically* states that he must think in Russia, and that thinking in English and translating wouldn't work --- yet Clint is *clearly* doing the latter in the movie)

Ene Ugo
2004-07-30
c++
I think in C++