4 ms·

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 imag

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.

tych0 13y ago
I think it also depends on the language too. In languages with more expressive type systems, you can usually make an educated guess about something based on the type signatures it has. For the dynamic languages, though, reading the code is an absolute must.
- tterrace 13y ago
  It definitely depends on the language. The author mentions spring security so I'm assuming he's using java, where it's a massive PITA to manually hunt down and attach the sources to the 50 jars you have in lib/. Maven probably has something that will automatically do this but if your legacy project is just using ant then you're pretty much stuck.
  - jradakov 13y ago
    Java is exactly what I'm using, and you are correct... it is a massive PITA to attach sources. Unfortunately, we're not using Maven but plan to in the future.
    - tterrace 13y ago
      If you're using eclipse, I found this plugin helps a bit: http://marketplace.eclipse.org/content/java-source-attacher http://marketplace.eclipse.org/content/java-source-attacher . For most popular jars you can just right click and hit "attach source".
  - kaffeinecoma 13y ago
    If you use Intellij + Maven this becomes magically seamless. I assume there is something similar for Eclipse as well. Really worth your time to make this work.
- kaffeinecoma 13y ago
  I agree, and sadly it's way harder to locate relevant bits of code in dynamic languages. (Hey Steve Yegge- can we have Grok now, please?) But even in static languages it's a must for me. I find that Javadoc becomes largely irrelevant if I can just click through to the actual source.
- camus 13y ago
  strictly typed languages like java are harder to write , but easier to work with (and document ) since one can know what is what , and what a method expects. It's easy to write a hash in JS but harder to understand what parameters are expected when you are using a library that passes hashes as parameters. That's why i prefer languages with type inference rather than dynamic typing. You can be explicit when you need to and lazy when you want to. (Excuse my french)
gyepi 13y ago
>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.
jimmaswell 13y ago
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.
- kaffeinecoma 13y ago
  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.
lacksconfidence 13y ago
I feel the same. I don't know where i would be as a programmer if I didn't open up the code to libraries and look around. Reading through this thread I seem to be the odd one out, but generally after about a week of working with a library i skip the documentation and go straight to the source. Even more so on libraries that fake their documentation by auto-generating it from doc comments. Why would i want to read documentation generated from the source when I could just read the source and comments, having twice as much info? Additionally many projects documentation only gets to the level of 'why do i want to use this' and not the nitty gritty details. Those details are in the code, and thats where I tend to look first on any project I'm familiar with. I should add that i work with interpreted languages, so going from my code to library code is literally just a key combo that looks at the token under the cursor, finds it in ctags, and goes there. It takes a fraction of a second to be looking at the code.
eterm 13y ago
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 of a codebase they've never looked at (or perhaps even they have) but cannot despite this write a loop counting from 1 to 10. Any blank stare after this question would not be me not understanding that libraries have code bases but would be me losing track wondering where my next interview would be.
- kaffeinecoma 13y ago
  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.
  - TheCoelacanth 13y ago
    Generally major libraries have actual documentation that's good enough to make it counter-productive to look at the source. If you simply asked if there was ever a time where you needed to look at the source for a library, I could probably come up with something. However, I've never had to look at the source for anything that I would consider a "major" library because everything that I've used that I would consider a "major" library has decent documentation.
- sophacles 13y ago
  So what would you do if you were unclear on how to do something based on the docs and googling? Have you genuinely never done anything even slightly out of spec with library author's expectations? Do you never need just part of the functionality of a library and wonder what the right way to get it is? Do you always just decide "it's not documented in a way I understand it, time to roll my own"?
drivingmenuts 13y ago
Works or doesn't work, does what it says in the docs or doesn't. Those are the only true measures. Everything else is just opinion.

tych0 13y ago

I think it also depends on the language too. In languages with more expressive type systems, you can usually make an educated guess about something based on the type signatures it has. For the dynamic languages, though, reading the code is an absolute must.

tterrace 13y ago
It definitely depends on the language. The author mentions spring security so I'm assuming he's using java, where it's a massive PITA to manually hunt down and attach the sources to the 50 jars you have in lib/. Maven probably has something that will automatically do this but if your legacy project is just using ant then you're pretty much stuck.
- jradakov 13y ago
  Java is exactly what I'm using, and you are correct... it is a massive PITA to attach sources. Unfortunately, we're not using Maven but plan to in the future.
  - tterrace 13y ago
    If you're using eclipse, I found this plugin helps a bit: http://marketplace.eclipse.org/content/java-source-attacher http://marketplace.eclipse.org/content/java-source-attacher . For most popular jars you can just right click and hit "attach source".
- kaffeinecoma 13y ago
  If you use Intellij + Maven this becomes magically seamless. I assume there is something similar for Eclipse as well. Really worth your time to make this work.
kaffeinecoma 13y ago
I agree, and sadly it's way harder to locate relevant bits of code in dynamic languages. (Hey Steve Yegge- can we have Grok now, please?) But even in static languages it's a must for me. I find that Javadoc becomes largely irrelevant if I can just click through to the actual source.
camus 13y ago
strictly typed languages like java are harder to write , but easier to work with (and document ) since one can know what is what , and what a method expects. It's easy to write a hash in JS but harder to understand what parameters are expected when you are using a library that passes hashes as parameters. That's why i prefer languages with type inference rather than dynamic typing. You can be explicit when you need to and lazy when you want to. (Excuse my french)

gyepi 13y ago

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

jimmaswell 13y ago

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.

kaffeinecoma 13y ago
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.

lacksconfidence 13y ago

I feel the same. I don't know where i would be as a programmer if I didn't open up the code to libraries and look around. Reading through this thread I seem to be the odd one out, but generally after about a week of working with a library i skip the documentation and go straight to the source. Even more so on libraries that fake their documentation by auto-generating it from doc comments. Why would i want to read documentation generated from the source when I could just read the source and comments, having twice as much info? Additionally many projects documentation only gets to the level of 'why do i want to use this' and not the nitty gritty details. Those details are in the code, and thats where I tend to look first on any project I'm familiar with. I should add that i work with interpreted languages, so going from my code to library code is literally just a key combo that looks at the token under the cursor, finds it in ctags, and goes there. It takes a fraction of a second to be looking at the code.

eterm 13y ago

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 of a codebase they've never looked at (or perhaps even they have) but cannot despite this write a loop counting from 1 to 10. Any blank stare after this question would not be me not understanding that libraries have code bases but would be me losing track wondering where my next interview would be.

kaffeinecoma 13y ago
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.
- TheCoelacanth 13y ago
  Generally major libraries have actual documentation that's good enough to make it counter-productive to look at the source. If you simply asked if there was ever a time where you needed to look at the source for a library, I could probably come up with something. However, I've never had to look at the source for anything that I would consider a "major" library because everything that I've used that I would consider a "major" library has decent documentation.
sophacles 13y ago
So what would you do if you were unclear on how to do something based on the docs and googling? Have you genuinely never done anything even slightly out of spec with library author's expectations? Do you never need just part of the functionality of a library and wonder what the right way to get it is? Do you always just decide "it's not documented in a way I understand it, time to roll my own"?

drivingmenuts 13y ago

Works or doesn't work, does what it says in the docs or doesn't. Those are the only true measures. Everything else is just opinion.