Patterns are common solutions to common problems. It's good to be familiar enough with them to recognize when you have one of those problems. Then you can consult the pattern and see if the solution fits. Some times it happens the other way. You don't recognize the problem but you recognize your code is starting to look like one of the solutions. Then you might consult the pattern and see if there is anything you haven't thought of yet. If the pattern looks appropriate, you might rename and restructure your code to look more like the pattern. That will help future readers spot it and identify what you're doing at a higher level. There's even a whole book called
Refactoring to Patterns that might be a great read right now.
When I first became aware of the Gang of Four book, one of my colleagues breathlessly told me he had built reference implementations of all of them. This turned out to be quite useless except for making him read the book carefully. You almost never apply the solutions exactly as they are in the book, and they'll almost always require some customization and translation into whatever problem and language you have.
The last thing you want to do is get excited about the latest pattern you read and go hunting for a place to apply it. It's common to try to hammer a pattern into a hole where it doesn't fit. I'm probably guilty of having a few favorites I use too often; I try to keep that in mind and stop before I abuse something.