Far as design patterns go, I work in an environment where there are a lot of dependencies between components, so the adapter pattern comes in handy. Especially so when trying to introduce seams in the code for unit testing support. The idea there is that you set up a wrapper around a third-party (far as your code is concerned) interface that your code relies on and that wrapper is responsible for translating your code's requests into whatever the third-party API wants.
I also see Factory used where we need to provide ways to instantiate objects defined in the supporting infrastructure code from its consumers.
Your question, however, also talks about different architectures like MVC and MVVM. I haven't used MVVM myself, but they're really two side of the more or less the same coin. It doesn't matter if you use MVC, MVVM, MVP, or anything else - separating your UI concerns from your business logic and from your data access (if any) is a good idea. I don't work on UI anymore, but when I did, I spent a fair bit of time doing just that.
(Note that ASP.NET MVC is a framework onto itself. It's making use of the MVC approach, but be careful when referring to it simply as "MVC". You can and likely will be misunderstood and people will go "what smart URLs?")
Other than that, I'm a big fan of the SOLID principles:
- Single Responsibility Principle - an object should only have one responsibility
- Open/Closed Principle - entities should be open for extension and closed for modification. In other words, you should be able to extend the behaviour of a class without having to modify its code.
- Liskov Substitution Principle - subclasses should be usable in place of a base class without the consumer noticing
- Interface Segregation Principle - only expose the things the client needs. Many small specialized interfaces are better than one large generic one.
- Dependency Inversion Principle - depend on abstractions, not on concretions.
I use all of them as much as possible. There are good introduction videos for each principle on Dimecasts.
And now for something a bit different...
All that being said, I think you're approaching this from the wrong direction. While only some patterns and approaches are popular, I think it's important to learn as many of them as you can regardless of their popularity. I'd definitely say that you should learn (at least at a basic level) every pattern you come across. You never know when an obscure pattern can make your life easier. You can always go into more detail and learn a pattern in-depth when you need to... but you don't know when you need to unless you know it exists at all and have a rough idea of what it's about.
Take a look at the programmer competency matrix, see where you are, and that'll give you a slightly less muddy path to overall improvement as a developer.