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

1 pointspxska7mo ago1 comments

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?

1 comments

mmarian7mo ago

> I also find it hard to argue (in a work context, for example) my own views without just citing what I've read.

Pointing people to a good article is more than enough. If they're set in their ways, no amount of oratory skills will make them change.

> How do you evaluate which sources are worth trusting?

I don't; it would make me the same as people relying on social media influencers.

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

If the ROI ((quantifiable benefits - costs) / costs) for following it is high enough.

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

Looking at the ROI for following the advice. Though beware - you'll end up becoming less employable because you won't chase the shiny new thing :)

j / k navigate · click thread line to collapse