== Vim or Emacs ==

Just pick one and force yourself to use it to the exclusion of other editors. Future you will thank you later, because you'll still be using it 20 years from now. "We are typists first, programmers second" comes to mind. You need to be able to move chunks of code around, substitute things with regexes, use marks, use editor macros, etc.

== 6.824: Distributed Systems ==

http://pdos.csail.mit.edu/6.824-2013/ Do each lab. Read the discussion and rtm's course notes.

== Tarsnap ==

https://www.tarsnap.com/download.html How to write C. Study the "meta," that is, the choice of how the codebase is structured and the ruthless attention to detail. Pay attention to how functions are commented, both in the body of the function and in the prototypes. Use doxygen to help you navigate the codebase. Bonus: that'll teach you how to use doxygen to navigate a codebase.

== xv6 ==

http://pdos.csail.mit.edu/6.828/2012/xv6.html

http://pdos.csail.mit.edu/6.828/2012/xv6/xv6-rev7.pdf

http://pdos.csail.mit.edu/6.828/2012/xv6/book-rev7.pdf

Read the book. Force yourself to read it in its entirety. Use the source code PDF to study how to turn theory into practice.

== Arc ==

http://ycombinator.com/arc/arc3.1.tar

You're not studying Arc to learn Arc. You're studying Arc to learn how to implement Arc. You'll learn the power of anaphoric macros. You'll learn the innards of Racket.

Questions to ask yourself: Why did Racket as a platform make it easier to implement Arc than, say, C/Golang/Ruby/Python? Now pick one of those and ask yourself: what would be required in order to implement Arc on that platform? For example, if you say "C," a partial answer would be "I'd have to write my own garbage collector," whereas for Golang or Lua that wouldn't be the case.

The enlightenment experience you want out of this self-study is realizing that it's very difficult to express the ideas embodied in the Arc codebase any more succinctly without sacrificing its power and flexibility.

Now implement the four 6.824 labs in Arc. No, I'm not kidding. I've done it. It won't take you very long at this point. You'll need to read the RPC section of Golang's standard library and understand how it works, then port those ideas to Arc. Don't worry about making it nice; just make it work. Port the lab's unit tests to Arc, then ensure your Arc version passes those tests. The performance is actually not too bad: the Arc version runs only a few times slower than the Golang version if I remember correctly.

== Matasano crypto challenges ==

http://www.matasano.com/articles/crypto-challenges/ Just trust me on this one. They're cool and fun and funny. If you've ever wanted to figure out how to steal encrypted song lyrics from the 70's, look no further.

== Misc ==

(This isn't programming, just useful or interesting.)

Statistics Done Wrong http://www.statisticsdonewrong.com/

A Mathematician's Apology http://www.math.ualberta.ca/mss/misc/A%20Mathematician's%20A...

Surely You're Joking, Mr. Feynman http://web.archive.org/web/20050830091901/http://www.gorgora...

Zen and the Art of Motorcycle Maintenance http://www.arvindguptatoys.com/arvindgupta/zen-motorcycle.pd...

== Above All ==

Don't fall in love with studying theory. Practice. Do what you want; do what interests you. Find new things that interest you. Push yourself. Do not identify yourself as "an X programmer," or as anything else. Don't get caught up in debates about what's better; instead explore what's possible.