Potluck Programming (or UWWFY)

Have you ever found yourself spending more time trying to learn patterns than actually designing or coding your application? It's easy to do. With the maturation of .NET, suddenly everywhere you look you see presentations, books, and blog posts talking about this pattern or that pattern, each asserting that the other is inferior for some obscure reason. And you, being the mature .NET developer that you are, follow these conversations, desperately trying to find the "magic" patterns that will make your next project perfectly maintainable, easily extendable, and consistently scalable from the get-go. I know, because I've been there.

Now, there's nothing wrong with patterns. In fact, they're very helpful in moderation. They allow developers that implement code to benefit from the long winded thinking done by developers that have time to think about the absolute best way to do things. The problem, though, is that there is no "absolute" right or wrong way to do things. There are better  and best ways to do things for specific scenarios (as learned from collective experience), but no one can tell you the "right" way to write your application. And left unchecked, it's easy to wander down the rabbit hole of pattern research and get lost in "Patternland."

So, I'm coining (or re-coining, as the case may be) the term "Potluck Programming." Or if potluck's aren't your thing, UWWFY™- "Use What Works For You."

The concept is simple, but essential. When setting-out to improve your development with patterns, find patterns that help solve problems you have (not problems you think you'll have- YAGTNI), find patterns that make sense for your project (not every project is a huge enterprise, super complex application with the need for IoC containers), learn the patterns, and then start writing some code!

And don't feel guilty if you don't follow the pattern 100%. I like to quote the wonderful piece of 21st century cinema Pirates of Caribbean to explain this. In the words of the digitally-enhanced (or is it degraded?) Captain Barbosa:

"The patterns are more what you'd call guidelines than actual rules. Arrr..." (loosely quoted)

Patterns are supposed to help you write code in a way that avoids the problems other developers have encountered, but they're not supposed to be a paint-by-numbers guide to coding your application. Use what works for you and don't let patterns bog you down. And if you find yourself getting bogged down, step back and write some code. If nothing else, that will help provide more context for the pattern so you can learn it more quickly.

Hopefully this simple advice will help you avoid the productivity drain that pattern research can become. Have you ever found yourself crawling down the pattern rabbit hole? Sound-off in the comments.