DRY is a good principle to default on, juniors need to learn to pick this up - I constantly need to fix this kind of thing in reviews, they haven't learned to r

DRY is a good principle to default on, juniors need to learn to pick this up - I constantly need to fix this kind of thing in reviews, they haven't learned to recognise when stuff should be factored out and they also write buggy code so it's easy to show them that writing the code once, isolating dependencies and testing it is a better approach than coming up with the similar code over and over in ad-hoc fashion. Once you start getting it you tend to go too far (everything is a nail when all you have is a hammer) and experience helps you learn to judge when to use it - but it's an invaluable tool and you need to use to get the experience - so I would suggest extract shared code by default - inline when it gets too complicated.