Hacker News new | past | comments | ask | show | jobs | submit login

I often struggle trying to explain to more junior developers that there are times when it's OK to write code more than once. There is a mindset that you should only ever write code once. It exists for (very) good reason. But if you follow it dogmatically, you may end up with an unmaintainable tangle of dependencies that can only be resolved with a rewrite.

Sometimes, it's OK to write the same thing twice if the alternative is a major refactor - such as inventing your own stack.




You are fortunate if you only have to explain it to juniors.

This seems pretty prevalent among senior developers too, in my experience.

The most egregious case was, this guy I worked with, who would just straight up start with abstractions to avoid any duplication and enable other use cases. Now, 9 out 10 times the use cases catered for by the abstraction failed to materialise (bloody customers) but boy did he let you know when he hit the abstraction lottery and what he'd done neatly fitted in with a new use case.

I think the term for what he created was ravioli code although maybe some of it was lasagne code


>hit the abstraction lottery

Thanks, I'll use that from now on. A lot of wisdom in those 4 words.


Duplication is always more extensible and maintainable than a bad abstraction.


I like the rule I read somewhere called Rule of 3. Goes something like, don't bother to write a shared version of some piece of code until you've already written it in at least 3 different places. This simultaneously ensures that

1. There is actually a need to use this code in multiple places

2. You know where the places that need this code actually are, and what they need, so what you write will actually be practical for all of them to use

3. Or maybe you can tell that, despite the seeming similarity, the different places are too far apart or too different for sharing code to actually make sense


At the very least you need to repeat yourself in as much as repeating the names you defined for constants, variables, macros, and functions when later invoking them. A program written in the limit of the style of don't repeat yourself either repeats these names many times and/or has too many layers.


Hi there, sorry to hijack this post. We actually had a brief exchange a few months ago here (https://news.ycombinator.com/item?id=18133835). I didn't notice you had responded until now and that is now "locked." Are you still working on RPA? If so can you reach out at george@soroco.com? Thanks a lot!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: