3 ms·

Not directly related - but it's something I come across so often when mentoring newbie devs that I thought I'd mention it in passing just in case anybody has th

Not directly related - but it's something I come across so often when mentoring newbie devs that I thought I'd mention it in passing just in case anybody has this problem. A pattern I sometimes see with newbies who understand the value of DRY is - as soon as they get to the point when they're about to repeat something or about to copy and paste - they stop themselves and start refactoring to remove the duplication they haven't typed into existence yet. They see adding the code that will produce the duplication as bad / waste. Don't do that. It's hard - because the code that they've not typed or copy/pasted doesn't exist or work yet. It's still in their head. Make the duplication explicit first. Type it out. Copy and paste. Change those two branches so they have exactly the same structure. When you've done that - and everything is working and all tests pass - then refactor the heck out of it. Much simpler, faster and less error prone.

ufo 14y ago
I don't know if I agree 100%. Sometimes the extra abstraction helps you solve the problem in the first place. In my experience the OP is right. The worse problem is when you eliminate duplications in the wrong place or using the wrong abstraction, leading to brittle abstractions that break in the future.
- adrianhoward 14y ago
  Yeah - there are probably exceptions ;-) However what I've seen happen on multiple occasions is somebody merrily driving along churning out code then suddenly hitting the "ohhh - duplication is bad" wall and halting as they feel their way around the duplication and abstract they may need (or may not - since they've not written the code yet). Duplication is not a mortal sin. Having it sit there for a few hours while you work out the meat of the problem isn't going to kill any kittens. And often the easiest way to fully grok the abstraction that you need is to make the duplication really, really obvious.
einhverfr 14y ago
It depends. Sometimes it is obvious what refactoring will need to be done, sometimes it isn't. I do agree that for newbie devs, your approach is a good one, but I think that as folks get more experience, shortcuts often are appropriate.

ufo 14y ago

I don't know if I agree 100%. Sometimes the extra abstraction helps you solve the problem in the first place. In my experience the OP is right. The worse problem is when you eliminate duplications in the wrong place or using the wrong abstraction, leading to brittle abstractions that break in the future.

adrianhoward 14y ago
Yeah - there are probably exceptions ;-) However what I've seen happen on multiple occasions is somebody merrily driving along churning out code then suddenly hitting the "ohhh - duplication is bad" wall and halting as they feel their way around the duplication and abstract they may need (or may not - since they've not written the code yet). Duplication is not a mortal sin. Having it sit there for a few hours while you work out the meat of the problem isn't going to kill any kittens. And often the easiest way to fully grok the abstraction that you need is to make the duplication really, really obvious.

einhverfr 14y ago

It depends. Sometimes it is obvious what refactoring will need to be done, sometimes it isn't. I do agree that for newbie devs, your approach is a good one, but I think that as folks get more experience, shortcuts often are appropriate.