Can somebody explain the obsession with patterns and anti-patterns in programming? I ask because I have absolutely no idea what any of the patterns mean. When faced with a programming task I think about the problem for a little bit, write down some data structures that I think will be relevant, prototype a solution, separate out some modules and iterate. Nowhere in the process do I think "Oh, I need FunkyLookyTastic pattern here".
A pattern is a common approach to solving a common type of problem; nothing more, and nothing less. By knowing and understanding them, you can make use of other people's experiences to guide you towards the kind of solution that's been shown to work well, avoid pitfalls that have been encountered in the past, and discuss the solution using terminology that's familiar to others who know that pattern.
Of course, you can come up with a fine solution without explicitly using a pattern, and equally well come up with a bad solution by trying to apply a pattern that doesn't really fit your particular problem. I think the "obsession" you observe generally comes from people who have just discovered the concept, and think that it is rather more powerful than it actually is. Most people will quickly recognise them for what they are: a useful tool, not a magic bullet.
Anti-patterns, on the other hand, are commonly observed behaviours that tend to reduce code quality. Again, it is useful to know and understand some of these so that you can avoid such behaviour, and try to correct it (with reasoned arguments) when you observe it in others. Some would describe the overuse of patterns as an anti-pattern.
Most developers will cringe at any new paradigm or methodology that comes in. I did to when I first heard about design patterns. Design patterns are just what the name suggest: a design or template for creating classes and modelling their behaviour and interaction in a predictable way
Take a look at houses. They have some similarities. Every house has a living room, kitchen, bedroom , bathroom, toilet for a minimum. No one will build a house without a bathroom, right? Apartments have a pattern that is different from bunglows. Castles have a different pattern altogether. Clothes too have patterns. A Jacket and a formal shirt both have the same basic design, yet they have different behaviours: you won’t wear a cowboy jacket for an interview. Similarly classes and their actions can be grouped according to their behavior and design. Looking at the common elements in their behaviours gives you design patterns for classes.
Design patterns in my understand are only important if reusability and expandability are primary concerns. If you create small apps (say less than 10 classes), you may not need them at all. But large projects, especially those which have large teams working on them and have a long maintenance and feature addition cycles, will definitely need patterns. It isn’t even an option in large projects.
Take a look at some online tutorials on patterns. Wikipedia has a good set of articles. This site is good too: http://sourcemaking.com/. If you are an experienced programmer, you will find that you have come across a few patterns, maybe even implemented something similar yourself without knowing it by a particular name.
Don't ignore them altogether! You may find them useful in the future if not now. The key to approaching Design Patterns with an open mind is to ask: "What will happen if I don’t use design patters?" Patterns aren't meant as "cures" (although you can use them as a cure for a problem); rather, they embody the dictum "prevention is better than cure".
All the same, I would caution against an obsession with implementing patterns wherever and whenever you see a small pretext to use it. I faced this problem in one project where the architect was convinced that without DP the project would be a complete disaster. We had a group meeting where the engineers shifted through the design and pointed that many patterns that he recommended would have no use at all other than showing "wow look at the beautiful patterns". It took a lot of convincing and some bargaining to reduce the number of places where patterns were used to a need-only basis.
Patterns are both the distilled knowlege of programmers in a cookbook, and a useful way for programnmers to communicate.
As other answers suggest, patterns really are common solutions to common problems. The benefit is that you can often get better solutions by using an existing pattern or discover probable pitfalls before you start coding.
The other benefit is when you're talking to someone about your code. Patterns are another type of jargon that condense lengthy descriptions into a few words. Try explaining "then we have an observer added by the factory" without referring to patterns. You can do it, but it takes a long time.
The people who answered are correct in terms of "pattern-based programming" as its normally thought of. I have a slightly different definition that I find more relevant to what I'm doing and I tend to use "pattern-based programming" to describe a plugin approach rather than a planning approach.
Since I program jQuery plugins, a CMS cloud plugin and eCommerce plugins, "pattern-based programming" from that perspective means to look at the core technology and what use cases exist and hit the most statistically relevant ones. Plugins in particular have to be very pattern-based so they fit within the programming context well.
However, it is best to apply a pattern AFTER you see valid use cases on multiple projects so it is statistically valid for reuse.