Anti-Patterns. Worth studying?

[prestokeys]

Just when I thought I had all the design patterns in my grasp, I come across this:
http://sourcemaking.com/antipatterns/software-development-antipatterns
which lists a whole bunch of new patterns called anti-patterns that I've never seen discussed before. For those who are familiar with these anti-patterns, would you recommend I study these? My goal is to write my programs using the best choice of design patterns I can think of (so making the program work and optimizing performance alone is not good enough for me). Here are the names:
◦The Blob
◦Continuous Obsolescence
◦Lava Flow
◦Ambiguous Viewpoint
◦Functional Decomposition
◦Poltergeists
◦Boat Anchor
◦Golden Hammer
◦Dead End
◦Spaghetti Code (ok, this I've heard of before, but only as a bad thing)
◦Input Kludge
◦Walking through a Minefield
◦Cut-And-Paste Programming
◦Mushroom Management

[NoXzema]

They're called anti-patterns because they suck. You can learn them by realizing why they're bad.

[prestokeys]

Oh, I thought they were new patterns that go against the traditional but yet still work in their own unique way. The name "Dead End" should have alerted me.

[dhayden]

My goal is to write my programs using the best choice of design patterns

We had a guy who LOVED design patterns. He solved every problem with design patterns. Need a loop from 1 to 10? He figured a way to use design patterns. As a result, his code was astoundingly obscure and it didn't work. After he left I threw it away and rewrote it.

My point is that design patterns are good for solving complicated problems but you shouldn't use them to solve easy ones. The KISS principle applies: make the code as complicated as necessary to solve the problem, but no more complicated.