41–48 of 48 posts
Documentation is ambiguous, and even documentation which is unambiguous is often wrong (or perhaps more kindly, "out of date").
Earlier quoted context omitted.
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…
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.
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...
Actually, it's more like not having chairs at a dinner party. It's a significant discomfort, not a lack of a luxury.
"The Spring Security documentation says it best…
It is much easier to debug your application or to work out where a problem lies if you don’t treat the external code you are working with as a black box which you never look inside. The first thing you should do when an exception you don’t understand is thrown from an open source library is jump to the class and line number and take a look to figure out what the code was doing there. Otherwise you’re missing out on much of the benefit of using open source code."
Sorry, but it's a lot easier to debug your application if you have documentation that tells you under what conditions the library throws a particular exception.
Having to understand the source code of a library to be able to figure out its behavior eradicates much of the benefit of using a library in the first place. And the average product these days relies on so much open source software that you can't possibly have the time to dig through the sources to solve every little problem. Would the author of this statement be happy if he had to dig through Linux kernel code, or Apache web server code, or the code of the dozens of Java libraries that Spring is dependent on? I don't think so.
Earlier quoted context omitted.
Wow, I hope you never interview me. FizzBuzz was a filter to filter out people who cannot code. At all. It was never designed as a competency measure, it was designed as a filter, to remove people who are mistaken into believing they can do something they cannot do at all. What you have is a very precise measure, which would not even filter out the BSers who could probably happily talk for five minutes on the merits…
So you'd be unwilling to discuss a major library that you've used in your career (say Spring, or Rails) with a potential employer? The "filter" I'm looking for is to weed out people who cannot crack open the source to something that is standing between them solving a problem. I'm not asking them to be an expert on the internals of everything they use. Apologies if my comment was unclear.
Earlier quoted context omitted.
I don't look at my libraries' source unless I have a problem the documentation or google doesn't answer. that's really going to be your fizzbuzz? 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…
turned out it was an issue woth out it used Properties.
Earlier quoted context omitted.
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.
> 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…
Earlier quoted context omitted.
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.
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.
This worries me a little, because it cuts against the ideas of abstraction that are central to most software engineering. Don't get me wrong, I'm not against reading the code if and when it is available. I just worry that reliance on this MO goes against the idea that you can specify a programming interface for your system and people can develop against that without knowing the implementation. This is rather powerful…