> Yet people insist on you naming a design pattern in interviews, like it's a secret handshake, or asking a carpenter if they know any kinds of wood. What does it prove? Nothing.

Looking at someone's code is more useful than asking if they know patterns. But some knowledge of patterns is a good thing IMHO.

For example, if I can point at some of my code and say "Yeah, that's kind of like a factory" and know I'm understood by my teammate, then that's a good thing.

One goal of the design patterns movement was to introduce a terminology that could be shared and understood. I think they succeeded to some degree, because employers are looking for familiarity with this terminology. Why is it such a PITA?

> Programming isn't paint by number, every day you make decisions on what to write and how to design or structure the code in a continuous basis.

But wouldn't it be quite cool if you could check your thinking against other peoples successes and failures? Patterns simply catalogue problem/solution, I don't think you're supposed to implement them in a paint by numbers fashion.