RTFC is the New RTFM

  I nonchalantly told him to look at the source code of the library
  we were using. He looked at me like I had asked him to help me dig up a grave.

I can't imagine not examining the source code of the various frameworks I use on a daily basis.

I think the next time I interview a candidate I will ask them what major open-source libraries they use. Then I will ask them what they think of the quality of the source code, how it's implemented, what they find difficult to reason about, etc. Getting a blank stare at this point will be a kind of FizzBuzz moment.

Edit: I'm not suggesting that candidates should be an expert on the internals of the libraries they use (I'm certainly not). What I'm looking for is the ability to crack them open when you hit a wall.

One organization that I worked at had a firmware team that moved quickly, and wrote the interface layer to the PHY/MAC/Network devices. After they defined the interface, later on enterprise software teams, and utility software teams, would write the "User Friendly" tools that would be used to configure the networking devices, but the firmware team did write a tiny "shim" utility that they released with firmware, that could be used to control the firmware at a very raw/native level.

Whenever you were wondering what parameters to pass to this low level (very useful) utility, the answer was almost always, "Just check out the Code" - and answer that was actually surprising straightforward once you got used to it.

I have noticed the increasing paucity of documentation in many open source projects. In the past, this would annoy me when I had to context switch from a perfectly good flow state to a documentation reading state. However, I realized that I was doing it wrong; it meant that I was not spending enough time analyzing the code I was about to "adopt" and depend on for my project. Now, I read the documentation and source code for every open source program before I choose to use it. I also find correlations between the quality of the code and the documentation; good quality code sometimes lacks documentation but poor quality code rarely has good documentation.

Reading the code also provides the opportunity for learning beyond the documentation; there's a wealth of really good code out there just waiting to be read.

>I think the next time I interview a candidate I will ask them what major open-source libraries they use. Then I will ask them what they think of the quality of the source code

Sometimes, it is eye opening to read the source code to some popular libraries/frameworks and discover how badly the code is structured. Some definitely belie the notion that code is written for humans.

Something needs to be done to address this enormous problem.

One of the worst examples I've come across lately is Zookeeper (http://zookeeper.apache.org/), which should win an award for how confusingly useless the documentation is. The Java source is probably refreshingly concise.