Ask HN: Knowing how some thing works vs Knowing how and when to use it? | Hacker News Reader

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

4 pointsfreework5 comments

How does knowing how something works compare to knowing why and when to use that something?

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.

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.

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.

To what extent does understanding the underlying concept effect you ability to reason about a technology?

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?

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

The pragmatic maxim:

"Consider what effects, that might conceivably have practical bearings, we conceive the object of our conception to have. Then, our conception of these effects is the whole of our conception of the object." --C.S. Pierce

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.

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.

Reply on news.ycombinator.com