

Ask HN: Knowing how some thing works vs Knowing how and when to use it? - freework

How does knowing how something works compare to knowing why and when to use that something?<p>I'm a self-taught programmer with a lot of experience. I know when to use a database index, and I know why they exist. I know the performance limitations, I know the tradeoffs, and I know when they are appropriate and not appropriate. But if you were to ask me about how they work, I have no idea. If you were to ask me to explain the computational complexity of selecting a tow on an indexed table compared to a non-indexed table, I have no idea.<p>How does this fact effect me as a developer? I recently got into a discussion on another forum about this topic. The consensus from that discussion seemed to be that not knowing the low level implementation details significantly hinders your ability reason about the technology. In other words, if I can't explain how a B+tree works, I'm pretty much worthless when it comes to understanding how to use a database.<p>The discussion came up when I noticed that just about 100% of the job interviews I've done, I'm always asked to explain how something works, rather than when to use something, or why you would use something. This means that I pretty much fail every single job interview, and probably will remain so for the foreseeable future.<p>To what extent does understanding the underlying concept effect you ability to reason about a technology?
======
rachelbythebay
Let's just see how this might work. Here's a question phrased both ways.

When do you use traceroute?

How does traceroute work?

In my experience, anyone can make up some kind of answer for the first one.
There's enough wiggle room in the language to let them say "when you need to
trace a route", only using different words. This establishes nothing in terms
of the candidate's abilities.

The second question is harder to answer without actually knowing something
about the problem domain. Granted, I've had plenty of people flat out lie and
make things up rather than saying "I don't know", but there are ways to catch
that. If they try to memorize the answer, perhaps because a question is
becoming too popular, then they'd better hope they learned it all the way down
to the bare metal, since that's where I'm going to take them.

Incidentally, for candidates who say "I don't know" to the second one, a good
followup question is "Okay, how would you build one from scratch?". The people
who know the domain but simply haven't dissected that particular tool will be
able to reinvent it on the spot. That's when you say "are you sure you didn't
know this?" to make them feel better about themselves.

Those who don't have any idea about what goes on with IP will be stumped.

This assumes perfect performance on the part of all involved. Bad food,
butterflies, jet lag, and other human anomalies can and will affect you.

So, bringing this back full circle, maybe you don't know how a B+Tree works
internally for whatever reason, but could you build one if you had to?

~~~
freework
From reading the Wiki page on B+Trees, it seems they are just a way to store
data so that is is always sorted. If I ever needed to store data in such a way
that it is always stored, I'd use a database+index. I don't know B+Trees
because I've always reached for a database when I needed to do what B+Trees
are good for. I've never had the need to learn B+Trees.

I haven't had the need to learn many low level things. Not having a computer
science background, there are tons of things I don't know, but those things
just don't come up ever in my day to day programming life (other than
interviews).

------
late2part
Grasshopper - you ask the difference between knowledge and wisdom. This is a
well understood question with not a well understood answer. Illumination is
left to dear reader.

[edit - added below]

Knowing how to do something demonstrates technical ability.

Knowing what to do and when to do it demonstrates experience, judgment,
finesse, and sometimes, political savvy.

Depending on what kind of role one is interviewing for, the interviewer may be
interested in whether you can do the things they tell you to do. So little of
hiring managers want people who can think; they want people who can do.

While I recognize that these hiring managers are short-sighted, I submit that
they are the majority.

In spite of their preference, certainly an implementor has to make decisions
about which choices to make all the time. Yet, many people view a 'programmer'
as a do-er, not a decision maker.

------
bdfh42
Maybe this is an overly simplistic response - but is it possible your question
is exploring the difference between "learning something" and being "taught
something"? I suspect that if you truly understand when to apply some
technology then you probably have some insight into how it works - the
opposite would be that someone has an imaginary table of "when this do that"
values prepared by some notional domain expert that they employ.

To get back to your issue with interview type situations - I think that there
is possibly some confusion between understanding how something works and how
then it should be applied - with a lot of people biased towards "how it works
in detail" as a key indicator for knowing how to apply.

For myself, I find it very difficult to understand the "when" (can I call it)
if I do not understand the "what/how" first - but I do understand that might
be just me.

