I already mentioned Coders at work in an earlier entry. The point of this one is not to write a review, but to make a note for myself of what I've gotten out of the book. I think I could do better to read more books with a pen and a pad so I have a better chance of exploiting the content.

So these are notes to myself. I wouldn't take it upon myself to summarize a more general listing of notes that would somehow apply to the average person, because I think we're all in very different places in the universe that is called "learning to program (well)", and every person has to figure out for himself what he most needs to learn relative to where he now is.

Advice: Read code

Read other people's code, "open black boxes". This is something I never really do, I should start. Just take some codebase and check it out, get used to the practice. Reading code is not the easiest thing to get into, so here are some tips:

1. First, get it to build.
   Sometimes everything you have to do to build it already teaches you a number of things about the codebase. And once you have it built, you can start making changes to it and try out little things dynamically.
2. Read while building.
   Making builds for any codebase can be hairy and painful, so parallelize this activity with code reading. Great way to use the time you'd otherwise waste in between debugging the build.

Advice: Write unit tests for new library

You've found a library for something that you've never used before: how do you figure out how to use it? Write unit tests. Some libraries have bad unit tests (or no tests) to begin with, so it could be a way to improve it. In any case you can test your basic hypotheses of how the library works.

Ideas to investigate

1. OO and classes vs prototypes (JavaScript).
2. "There is a lack of reuse in OO because there is too much state inside". Libraries must expose too much of their innards through APIs, functional programming model should be better at this.

Pointers

Articles:

1. Richard P. Gabriel - Worse Is Better

Blogs:

1. How to read code – a primer

Books:

1. Douglas Crockford - JavaScript: The Good Parts
   In the absence of the book, Crockford's lecture series on JavaScript is probably a good start.
2. William Strunk, Jr. and E.B. White - The Elements of Style
   For writing better English.
3. Steve McConnell - Code Complete
   On software engineering process and best practices.
4. Gerald Weinberg - The Psychology of Computer Programming

Talks:

1. Joshua Bloch - How to Design a Good API and Why it Matters