Ask HN: How do you differentiate good development advice from dogma?

I'm ~4 years into my career and have been learning a lot from various books and talks, e.g. "The Pragmatic Programmer" or Eskil Steenberg's "Architecting Large Software Projects".

The problem is: I also see plenty of backlash to these sources. Some say the ideas can't be applied universally, or that principles like DRY can be harmful if treated as rules instead of guidelines.

As someone still early in my career, I don't feel like I have the experience yet to separate timeless principles from context-dependent advice. I also find it hard to argue (in a work context, for example) my own views without just citing what I've read.

So my questions are:

* How do you evaluate which sources are worth trusting?

* How do you know when advice is valuable vs. dogma?

* Any tips for developing this critical lens earlier in your career?