I can see why Design patterns are thought of as difficult to understand.
Best Practices, are on the other hand are easier to follow and review.
Most Process oriented companies have ‘Golden Templates’ and ‘Coding Guidelines’ to make it easy for the programmers and other stakeholders.
Architectural vision – This is trickier than propagating the CEOs vision and the Product Roadmap. Architecture is something better explained in ‘High Level blocks’, when explaining to a Novice audience (a broad knowledge may help!).
To get to know it better, it requires one to look at the ‘Forest’ without losing sight of the ‘Trees’. The ‘Big Picture’ as we call it.
1. Why are Design Patterns difficult?
Programmers are people who work with Logic, and Logically they do not seem to get it because, “You are getting the desired Runtime Output you wanted, the User cannot see the code, What are you cribbing about?” So, most are not open to it, till they are given a maintenance project or Someone else’s code to work with.
I have tried to consciously do this with beginners before “Pair programming” became fashionable.
You learn both ‘Good’ and ‘Bad’ practices by observing others code, and hence hopefully, be a better programmer. To understand why something is better, one has to be introspective too.
Applying design patterns is all about ‘Unlearning’, and any unlearning takes a conscious effort on the part of the programmer. Does that mean we should start with Patterns, NO, that would be a great mistake. It is not about ‘Giving’ and ‘Accepting’, It is more about making the student ready to ‘Accept’, Something like a good Advertisement or a Jingle, it works on your subconscious, and makes you open to experiment.
2. Do Design Patterns need to be difficult?
Not at all! Why do most of us point out GoF book to those who want to learn Design patterns, why not a HeadFirst book? – I did not learn by my C++ from Bjarne Stroustrup, I did it from Stanley Lippman, and Scott Meyers.
I have favored the ‘Top Down’ approach to learning Design patterns.
Actually I found it very helpful to go through Michael Duall’ s ‘Non Software Examples for Design Patterns (pls Google it). If you search with “pdf” along with the above string, you get a good pdf of the content on the website.
Giving more real-life examples, makes the abstractions of patterns sensible. We tend to see application of patterns in code instinctively, that is when we know all the hard work has not been wasted :).
All good Code generators and Open Source frameworks use patterns.
With the advent of Open source, coding has generally improved :), we tend to do something better, if we know, there will be other eyes watching it.
We speak so much about ‘Scientific Temper’, I think it is high time, we spoke about ‘Pattern Temper’ :).
SheshPai
CodeVelle 
Coding guidelines for beginners
These are not language specific.
1. Code should be READABLE. If not…please don’t code!
2. If you are using a DESIGN PATTERN, check with your lead, whether it is the right one in the given situation.
3. If you don’t COMMENT your code, you have not documented it.
4. If you did not make NULL CHECKS, your code will fail!.
5. If you use STATIC everywhere, you leave yourself open to memory issues.
6. If you do not handle EXCEPTIONS, you should not code, or review it.
7. If your code is not UNIT TEST able, you have not written it right.
8. Do not add Numbers directly as FLAGs or ENUMS, use readable constants instead.
9. EXTERNALIZE all User Visible Strings. (Keeping it flexible for Multi-lang apps.)
10. Add Parameters that could change, in CONFIGURATION files.
11. Do not use Popup Message Boxes for Testing, use Console PRINT statements instead. You will forget to remove them!
12. Using LOGS in proper places, can enhance code, and avoid 11. in many cases. This is the only thing that will help you in remote communication from the customer end. Also helps in timing the functions and troubleshooting performance issues
13. Expose commonly used Utility Classes in UTILS package. Keep a note on its size, as not all Classes may need the whole package, it is a good practice.
14. Avoid practice of STAR importing (i.e importing whole Package e.g. java.lang.*)
15. When Synchronization is not needed, avoid using Synchronized Classes (e.g Do not use Vector when ArrayList would do the work).