DRY is about modularization and identifying higher level abstractions when possible (and useful). When you have a domain driven mindset, it's much easier to put in practice. But really, you need to learn how to balance things. And you can only get that natural intuition with practice, lots of practice. If you give up early and think repeating is ok all the time, then you will never gain that intuition.

Regarding mocks, there are mocks that can hurt you and mocks that will help you. Mocks that can hurt you are mocks you generate by hand and it represents an idea of what production is, or maybe the untested, specified contract. Mocks that help you are the ones that are automatically generated representing actually what production has. Mocks like these have saved me from potential P1s many times - and millions in business losses. In an ideal world, I wouldn't need mocks, but also in an ideal world LLMs would do my testing.

I joined HN back in 2008 and I am mostly a lurker, but when I see an article that just plainly promotes bad practices with no samples of code or without going in depth. An article that would have been voted down or ignored to oblivion back in the early days of HN. I have to say something. I have seen enough bad code (specially in recent years) - I am afraid the new generation is getting their tips from all the wrong places.