Mainly the key is to start tinkering, rather than jump from book to book. Just start with a very informal v1 and start hacking stuff together. When you run into a design dead-end, you'll know it because it will become increasingly hard to make forward progress.
And that's the tricky situation. When you run into a design dead end, what do you do?
Books! :) And that's where SICP might end up useful.
Or think about the problem really hard, and write down the answer. I've occasionally pulled that off.
Oh, I thought of one other suggestion: linkers and loaders. It's another classic. And unlike all the other references, there's no Lisp.
I second HtDP for both its material and fact that it has batteries-including, GUI-based tooling to go with it in form of Racket Scheme. Once you know it, you can approach the other resources much better. You can also use your familiarity with macros/DSL's to prototype features you find interesting from other languages in Scheme for your own programs. You can experiment with different styles since the LISP's are among the easiest to do multi-paradigm languages in. Lastly, you can even embed low-level, imperative constructs in DSL's to get benefits of LISP when doing efficient, unsafe coding much like Galois does for Haskell and C with their Ivory language.
sillysaurus3 is right about the MIT books being held on pedestals. It's not just them but happens with lots of "elite" colleges. There's usually much better books for learning. Now, where I disagree is that SICP is a good book with plenty of value in it for people that know Scheme. I loved reading all the sections on deriving interpreters. It was so clean-looking compared to what I did in imperative languages. It's just best to learn programming and Scheme elsewhere first.
I think the thing that made it all click for me was learning how Pratt parsers work, easy to get something up and running in a jiffy while just playing around -- especially if you play around in python. Tons of blog posts on the subject these days.
My current parser fetish is Earley parsers but they're a bit more complicated to get from (possibly multiple) parse trees to an AST you can do something with, still trying to grok how that all works. Probably doesn't help I've been playing with a C++ grammar in my experiments.
Christian Queinniec’s “Lisp in Small Pieces” (LiSP) has always intrigued me: it contains a sequence of interpreters and compilers for scheme-like languages that demonstrate a variety of ways of implementing languages.
