The only thing that will make you better known than making sweeping declarations, is making sweeping declarations and naming them after yourself (see Garrity’s Inverse Law of Congregational Intelligence). Joel Spolsky writes about The Law of Leaky Abstractions. He should shirk humility and call it Joel’s Law of Leaky Abstractions.
Unfairly simplified, Joel’s point is that you have to understand abstractions to use them effectively. You have to know how the tool does what it does to deal with problems and not to be bound by the abstraction. I enjoyed reading Joel’s thoughts – and they are good points. Ignorance of the meaning of abstractions is often the cause of one my least favourite business problems: “the computer won’t let me do that” (I’m getting mad just thinking about hearing that).
Joel correctly points out the weakness of abstractions. It can be helpful to know that when your turn the steering wheel in your car, you are not just pointing the car in another direction. Rather, you are turning the front wheels (unless you have that crazy-ass four-wheel steering) and the motion of the car and the friction of the wheels against the road is what makes the car turn. It’s good to know this when you are turning ice, for example.
This is exactly what WYSIWYG HTML editors don’t work very well.
What Joel doesn’t talk about, perhaps because it goes without saying, is how incredibly powerful abstractions can be. I often find myself saying things that go without saying.
I’ve always been fascinated by abstractions. It seems to be that abstractions could be our most powerful tool as a species. When I have to know how everything works, I am bound by the practical limits of what one person can come to know and understand in a lifetime. Print and transportation have made it easier for one person to learn more, but you can only read so many books. So in order for us to do amazing things like build bridges that go farther than you can see, or go to the moon (if you buy that story), we need to abstract. We need to rely on the knowledge and capacity of others. We use each other as tools.
In a previous post about abstractions in science, I wrote*:
When I call on a simple PHP function to show the date on a website, I don’t need to understand how PHP is interpreted. I don’t need to understand the network protocols used to transmit the process page to your computer. Basically, I don’t need to understand how computers work because someone else has done it for me.
I’m not sure what the move to abstractions means for us in the long run. It is certainly enabling us to do things on a grander scale. However, it also removes us from the source of our activities. Take food, for example. We seldom see where our food comes from or where it ends up. I could never gut a chicken, but I sure do like the mandarin chicken salad at Wendy’s (does a chicken even have a ‘gut’?).
Perhaps Joel is right; In order to use abstractions effectively, we need to truly understand them. Understanding an abstraction doesn’t mean you can’t take advantage of it. You don’t need to think about it all the time (that’s the point). Rather, you just need to be able to understand the abstraction when it breaks down (or ‘leaks’, to use Joel’s term). When your Subaru is sliding towards a ditch, for example, it helps to know why you steer into a skid.
* What does it mean when you start citing yourself as a reference? I’m pretty sure it means something.
This 
