Hacker News new | ask | show | jobs
by Edmond 4523 days ago
>However, others (and I include myself in this camp), are completionists. Abstraction is an annoyance, and not knowing is like an itch that needs to be scratched.

I think this a common fallacy that many developers fall victim to. Our entire modern lives consist of using things we don't understand, by this logic you should also not fly in a modern aircraft because I am sure you don't fully understand how they work. Better yet, you should refuse to drive your car.

>Super duper high levels of abstraction is a real problem.

Not at all. If an abstraction saves you a ton of time, you should accept it by all means. If you are your boss whose money is being wasted because someone refuses to use a time saving abstraction, I am sure that person would not be your employee for long.

4 comments

> refuse to drive your car

If I were engineering a car or a service tightly integrated with one, I would be pretty interested in knowing how cars works.

> If you are your boss whose money is being wasted because someone refuses to use a time saving abstraction

That's a bit out of context, don't you think? The article was making a claim regarding how beginners should learn web development - not how businesses should be run.

However, since you bring it up - in my experience misunderstood abstractions are at the root of many, if not most, security vulnerabilities. Trusting the system without understanding it is often quite irresponsible.

>If I were engineering a car or a service tightly integrated with one, I would be pretty interested in knowing how cars works.

But if you aren't, you don't. If you're building a web application, you're the delivery driver, not the mechanic. You just need to know how to use the car.

> If you're building a web application, you're the delivery driver, not the mechanic.

That's a flawed analogy. Delivery drivers aren't responsible for configuring or providing maintenance on the packages they deliver.

However, this is drifting pretty far out of scope of the original discussion, which concerned learning strategies for aspiring developers.

While I think it's a good idea to have an understanding of the systems we build on top of, that's just my opinion. We'll have to agree to disagree.

If I was flying in an aircraft I would expect the pilot to have at least some understanding of how/why it stays in the air!
Good luck with that. As a pilot school alumni, I can safely say that the Bernoulli principle, and more importantly how it applies to an open system like an aircraft wing, is pretty fuzzy for most of my former classmates (I know because I was tutoring them on flight physics).

Understanding the cause and effect between your interactions with the flight stick and throttle is one thing, understanding the physics behind it is another entirely.

It reminds me of something I've noticed watching artists work. Professionals will either know all of the underlying technology to get the result they want, or they know very little of it but are so familiar with the input/output they can get the result they want.

Most all photographers know basic exposure rules, but there are some very good photographers that don't know much beyond that. They rely on trail and error to get consistent results and probably know their tools better than someone who spent that time jumping around to different tools but know the concepts really well.

Funny you say that about photographers. I learnt from trial and error, and after a few years was taking some photos that I'm still proud of today. Then, a few years ago I decided to learn the concepts and apply them to what I'd already learnt, and now I feel I'm even better. My best photos now are as good as (or a bit better) my older best photos, but I can capture them more consistently. It's really fun.

As an aside, the best thing I did was force myself to use a 1963 Minolta rangefinder, with one film type and speed only, for an entire year. Manual everything. This allowed me to really learn those concepts properly, but it was still steeped in trial and error; reading the concepts, then coming up with them afterwards from first principles is easily the best way for myself to learn a topic :)

I really wish I could have thought of some specifics to make my point better. Most professional photographers do know basics of exposure really well, but may not know things like the inverse-square law when applying to flash photography (especially with the newer flash systems out there). Instead of using a light meter to take careful measurements, they fall back on abstractions, trial and error, and rules of thumb--like sunny 16 rule, their experience, and looking at the back of the LCD.

The only example I can think of is that I've heard Paul McCartney can't read or write sheet music.

Some people (like myself), feel the need to understand the underlying technologies in order to become competent. I don't feel like that's the only way to competency.

Wasn't there an argument that Bernoulli principle is a wrong model to talk about how aircraft flies, and that the Newtonian dynamics is a better one? What's the state of the art?
As taught about 12 years ago, the Bernoulli model was accurate; it just requires you to identify that the other half of the traditional diagram (a narrowed venturi) is the atmosphere above the wing.

After reading about the application of the Newtonian dynamics on life via wikipedia, honestly, the best description is probably a mix of both; Newtonian dynamics explain the action on the bottom of the wing, while the Bernoulli principal (directly related to the Euler derivation of Newton's second law) explains the acceleration of the airflow over the top of the wing and the negative pressure generated there.

Its worth noting that the negative pressure generated by the Bernoulli effect is greater than the positive deflection pressure, else planes would have a hard time stalling since the greater the angle of attack. Stalling is caused by the separation of the airflow over the top of the wing from the wing itself, resulting in a loss of lift, at extreme angles of attack (which would thus present greater angle and surface area for deflection).

I understand the basic laws of physics, and I understand the premise of internal combustion. Sure, there are a lot of details that I'm missing, but I get the basic idea. Similarly, I may not be able to design a modern processor from scratch, and I don't have the time to build my own robust Web framework, but I know at least the basic idea of every layer. That's enough to make me comfortable using a framework. I don't have to be intimately familiar with every line of code, at least to begin with, I just need to understand how it works in broad strokes.
Your knowledge of basic physics is a function of your education and merely coincidental that it could be of help in understanding internal combustion engines...unless you purposefully took physics classes for this reason.

Abstractions are a basic requirement for any sort of advancement, there is no inherent virtue in knowing what's under the hood unless you have a good reason to dig deeper.

When you get sick you take drugs that may actually kill you, you don't say I am not going to take this pill because I don't know how it works. Heck, I have no idea how the lowly Tylenol works and I take it all the time:)

How do you know if it is a time saving abstraction or a time wasting abstraction without knowing how it works?