I spent so many years writing C code that I still tend to “think” in C when considering an algorithm. That’s true even when, as is mostly the case now, I’m going to write the algorithm in Lisp. A lot of that has to do with the fact that C is basically a universal assembly language. For example, when considering alternative Lisp strategies, I tend to think about the corresponding C code because it helps me understand what the machine will do for a given piece of code.
Time marches on, though, and many younger developers are unfamiliar with C—their experience is entirely with higher level languages such as Ruby, Python, or Java. Those languages are fine and, for most uses, a better solution than C. Still, those higher level languages do nothing to help you understand what the machine is actually doing. Even if you seldom use it, C is worth knowing because it helps you reason about what a given piece of code is actually going to do and how much it will cost in memory or time.
If you’re a programmer whose experience is restricted to languages like Ruby, Python, or Java and would like to learn some C—if only to help you understand what’s going on under the hood—Simon Tatham has a nice overview of C features and idiosyncrasies that may seem confusing as you dig into C. His purpose is not to teach you C but to give you a little context so you can understand why C is the way it is.
I used to say that everyone should learn assembly language so that they can understand what the machine is actually doing and how it is doing it. That ship has undoubtedly sailed but I do think having a working knowledge of C is useful for the same reasons. Read Tatham’s post for an idea of what I’m talking about. If you want to be the best possible developer, you have to have an idea of what’s happening on the metal.