When reading code don't treat the task like that of reading a book, the best way I find is to interact with the code that you are reading. So it's crucial to g

When reading code don't treat the task like that of reading a book, the best way I find is to interact with the code that you are reading. So it's crucial to get it to run, then get it to do something useful, then refactor it slightly by making functions shorter and giving the new functions specific name. E.g. instead of saying (first lst) maybe say (node-name lst), ideally the library functions should have names to do with the languages/library data structures and your fns should have names which correspond to the problem you are looking at. This is the approach I take when I want to rewrite something. If you want to use the code as in a library, then try not to read the details of it until you really have to. Use the interface or write an appropriate interface for you to use. Work through some examples in the debugger to see what it does. If you need to fix the code then you need to read the code. I try to focus on just the problem, rather than understand the whole thing. This approach makes it much simpler, I get in and out really quick, just focus on the problem and fix it. If I find something else that's a problem then I look at that too, otherwise I avoid figuring out how the code works.