A lot of the time I don't need the docs anyway, I just find what I'm looking for in the iltellisense/other suggestions because the OO model makes this work great.
A lot of the time I don't need the docs anyway, I just find what I'm looking for in the iltellisense/other suggestions because the OO model makes this work great.
unless I have a problem the documentation or google doesn't answer
Documentation/googling is definitely the right thing to do off the bat. But if they've never had a moment where they had to peek under the hood (or never thought to try, or didn't know how to) then yes, that's my FizzBuzz. I would perhaps not apply this to someone fresh out of school, but I would expect an experienced candidate to know how to "use the source".Obviously if you need to look at your code for pragmatic purposes, that's fine; but if reading third-party code becomes your modus operandi, you just might be using crappy libraries.
Documentation is ambiguous, and even document which is unambiguous is often wrong.
Maybe, but sometimes you're stuck with crappy libraries or even crappy frameworks. The last time I had to really dig deep into (ie spend more than 30 mins reading) 3rd party code was when I was trying to figure out if a method in Android's WebView was synchronous or not. [0] Maybe the Android framework, or the WebView specifically is a "crappy library" (the documentation in this case was definitely crappy) but "not using WebView" or "not using Android" wasn't an option.
[0] http://stackoverflow.com/questions/10962150/understanding-an...
Also, writing crappy code. If you are relying on undocumented behavior, it might well change under you. Looking past the abstraction is sometimes necessary, but it should be the exception.
turned out it was an issue woth out it used Properties.