First, congratulations. You're making the right decision. Programmers who are ignorant of C leave certain roles and problem domains closed off to them. Even if your primary language is something else, not being afraid to roll up your sleeves and fix performance and correctness problems in the compilers and runtimes themselves makes you more valuable, more confident, and better able to reason about how the runtime will map your input to the machine. And proficiency with system-building languages and tools is a prerequisite if you ever aspire to be a "head surgeon," "10x programmer", "ninja", or whatever the heck the kids are calling it these days :).<p>K&R et al. are fine, but I'm a particular fan of two slightly oddball, but great, books about C:<p>1. van der Linden's Deep C Secrets. Short of implementing a C compiler yourself, reading this book is the surest path to completely understanding some aspects of the C linkage model, and the distinction between arrays and pointers. It's also entertainingly written, which always helps.<p>2. The Lions Book, an annotated source listing for the Unix v6 kernel. The subject matter is one of the most beautiful and influential programs ever written. This ~10k-line program is completely understandable in six weeks' study, a couple months' tops, yet it staked out almost all of the abstractions that still underly modern operating systems. It is also C's native environment: C was literally invented to write this program. And while it's dated in some of its peculiarities ("=+" where we'd write "+=", identifiers only being significant in the first 8 characters, no typedef yet, a lot more reliance on the register keyword, etc.), it's damned fine code, by any standard. Each page brims over with good, informed engineering trade-offs; the sweet spot may have shifted since the days of 128k core and 16-bit CPUs, but the thinking that goes into those trade-offs is mostly unchanged.