alt Hacker NewsI did not mean "everybody has to learn the vocabulary". I meant the opposite, actually: it's fine not to know the word for the tool (I don't enjoy reading about patterns just to learn about patterns, it's not my thing at all).
Say I build a tool that makes it easier for me to drive a nail and call it a "Naildriver". If I show it to a colleague, they may be able to tell me "oh, this is generally called a hammer!". Maybe they will even tell me how I may improve my hammer, because they happen to like to learn about hammers in their free time. Or maybe now that they said it's a known concept, I will enjoy reading about hammers online (doesn't mean I will now read the entire encyclopedia of tools).
The fact that there is a name for the concept ("it's called a hammer") does not say you have to know the word. It's just useful to have a word for it, because then we can reference it in discussions and share knowledge about it more easily.
The other thing that design patterns allow, is to learn pitfalls, applications and other attributes about them.
To keep in your analogy, if you have a 3KG naildriver with a 2m handle you'll quickly find out that driving nails into a drywall with that leaves you with no wall. And that it's a bad idea to use a "Naildriver" to drive these "spiralled-slothead-nails" (aka screws) into wood.
But with a common language, such as design patterns, you can easily learn where they are good, what their limits are, in what cases other patterns fit better, and what pitfalls to avoid and so on.
If I search the web for "why is it so hard for my naildriver to drive in spiralled-slothead-nails" I'll get zero results. But when I search for "why is it hard to hammer in a screw" I'll get good results. May sound like a silly example, but for me that sillyness illustrates how obvious designpatters should be.