3 ms·

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

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".

frenchy 13y ago
There is a difference between knowing how to do something and thinking it's a good idea. 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.
- dllthomas 13y ago
  > you just might be using crappy libraries 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.
- jamieb 13y ago
  I'm using Spring 3.1, Jetty, various OWASP, guava. I am in the code of Spring and Jetty on a daily basis, and OWASP when I first used it. I learned guava by writing unit tests to verify my assumptions - assumptions I learned from the documentation - and which turned out to be mostly wrong. Documentation is ambiguous, and even document which is unambiguous is often wrong.
  - frenchy 13y ago
    Writing unit tests is a nice way to work when you're not working in an environment that requires young goat sacrifices or some such thing to perform unit tests. I'd also say that some kinds of unit tests are also a limited form of documentation. They don't tell you why something works the way it does, but they do tell you how it works.
- spacemanaki 13y ago
  > you just might be using crappy libraries. 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-androids-webview-addjavascriptinterface/11572941#11572941 http://stackoverflow.com/questions/10962150/understanding-an...
  - frenchy 13y ago
    Yes, this is certainly a reality for a lot of programmers.
jimmaswell 13y ago
I actually looked at the sfml source once to find out why vector*.x/y wasn't returning an lvalue in .net. Only time I can think of though. turned out it was an issue woth out it used Properties.

frenchy 13y ago

There is a difference between knowing how to do something and thinking it's a good idea. 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.

dllthomas 13y ago
> you just might be using crappy libraries 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.
jamieb 13y ago
I'm using Spring 3.1, Jetty, various OWASP, guava. I am in the code of Spring and Jetty on a daily basis, and OWASP when I first used it. I learned guava by writing unit tests to verify my assumptions - assumptions I learned from the documentation - and which turned out to be mostly wrong. Documentation is ambiguous, and even document which is unambiguous is often wrong.
- frenchy 13y ago
  Writing unit tests is a nice way to work when you're not working in an environment that requires young goat sacrifices or some such thing to perform unit tests. I'd also say that some kinds of unit tests are also a limited form of documentation. They don't tell you why something works the way it does, but they do tell you how it works.
spacemanaki 13y ago
> you just might be using crappy libraries. 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-androids-webview-addjavascriptinterface/11572941#11572941 http://stackoverflow.com/questions/10962150/understanding-an...
- frenchy 13y ago
  Yes, this is certainly a reality for a lot of programmers.

jimmaswell 13y ago

I actually looked at the sfml source once to find out why vector*.x/y wasn't returning an lvalue in .net. Only time I can think of though. turned out it was an issue woth out it used Properties.