One idiosyncrasy I've noticed I have as a coder is referring to various processes halting or failing as being "killed." I've been saying it for years, I noticed about a year ago that I was really the only person I knew doing it, and I just figured out, finally, where it comes from.
In Perl it's very common to use die("some message") as a de facto breakpointer. You think, well, these method names, they're just metaphor -- but somewhere in my brain the metaphor took hold. Fast forward a few years and every bug gets the violent descriptors "this is killed here" and "that is killing it." After a while the habit started weirding me out, so I've basically stopped, but I still do it from time to time when I'm thinking about something else.
It's totally idiosyncratic and anecdotal, but it makes the Sapir-Worf Hypothesis a lot more credible to me.
Calls to mind something Gerald Sussman said:
It is not exaggeration to regard this as the most fundamental idea in programming:
The evaluator, which determines the meaning of expressions in a programming language, is just another program.
To appreciate this point is to change our images of ourselves as programmers. We come to see ourselves as designers of languages, rather than only users of languages designed by others.
In fact, we can regard almost any program as the evaluator for some language...Seen from this perspective, the technology for coping with large-scale computer systems merges with the technology for building new computer languages, and computer science itself becomes no more (and no less) than the discipline of constructing appropriate descriptive languages.
I think this goes a long way towards understanding why people feel studying language design makes you a better programmer. It certainly makes me a lot more interested in RSpec than I've been in the past. I saw Dave Astels speak about this at Canada on Rails, and I was extremely skeptical. I think at this point that I just failed to see the point, but it's a valid point all the same.