I had heard about "The Law of Leaky Abstractions" some time ago; now, it again caught my attention, because Philip Wadler mentioned it on his blog. Reason enough to read Joel Spolsky's post (written November 2002) more carefully.
Spolsky's "Law of Leaky Abstractions" says
All non-trivial abstractions, to some degree, are leaky.
He explains his "law" mainly on the example of the TCP protocol (his actor analogy is brilliant and funny) and concludes:
I said that TCP guarantees that your message will arrive. It doesn't, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can't do anything about it and your message doesn't arrive.
This is what I call a leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can't quite protect you from.
Spolsky is absolutely correct with his description on TCP -- but I do not agree to his conclusion. There's nothing leaky here. Take network designers. They are fully aware of the services and the quality of the services TCP provides to the next layer in a protocol stack; they also know the limitations of TCP. They know that TCP can fail. And you do as well! What makes ebay so freaky exciting? To deliver your last bid on the very last moment before the auction is over -- and hope the very best for your network connection. You are very much aware that your network might go down in that very moment; TCP won't safe you! Right?!
If you forget that TCP might fail completely, you weren't that pedantic on understanding TCP. You were quite sloppy with your abstraction -- that's all.
The difference between a junior and a senior developer is that a senior doesn't have that many sloppy abstractions a junior has.