I speed read--but not books. I like books too much to speed-read them. But I do speed-read code. When coding, I am bottlenecked not by my ability to program,

I speed read--but not books. I like books too much to speed-read them. But I do speed-read code. When coding, I am bottlenecked not by my ability to program, but by my ability to come up with ideas. And one of the best ways to come up with ideas is to read other peoples' code. So, as a video encoder developer, I've gotten into a habit of reading through the entire codebase of other video encoders and decoders. I've gotten it down to almost a science where I can sprint through an entire codebase--understanding most of the basic structure and spotting anything "interesting"--at a few hundred lines per minute. I went through the entire libavcodec H.264 encoder proposal ( http://research.edm.uhasselt.be/~h264/ http://research.edm.uhasselt.be/~h264/ ) in just 7 minutes. I went back later and spent over an hour reading it--and found I missed absolutely nothing of note. And then I stole its strategy for level-code VLC tables for x264. Other codebases I've read include most of libavcodec's MPEG-related code, dirac, schroedinger, a lot of Intel IPP stuff, libmpeg2, and some proprietary stuff I've had access to from time to time. And probably lots of stuff I forgot. It is quite easy to speed-read code, of course, if you already know everything the code is going to do, and you're only interested in the implementation or algorithm. Another thing I do is read changelogs going back years (especially svn/git logs). They often offer even more insight than the code itself.