Hacker News Reader

Comment by logicallee | Hacker News Reader

I propose an extension to DRY (don't repeat yourself) called DRO (don't repeat others), meaning if anyone has ever done it you shouldn't have to do it again.

Then it's easy to tell whether you're googling or developing: "am I writing something nobody did EVER /trying to improve the state of the art of xyz?"

If yes, you should understand deeply and "develop", if no you should be searching and changing variable names.

If you're writing a new framework - then by all means! actually understand the code.

If not, you shouldn't have to.

View on HN

I don't agree with this. Developers should try to always understand the code they are working on. Keep your stack small, understand it as best you can, and use that knowledge to solve problems. That's what programming is.

Smushing a bunch of frameworks together until the code works isn't going to help anybody improve, and I think it's fundamentally contributive to the larger issue. If you don't understand the code you're writing or reading, it follows suit that it probably isn't going to work that well or be easy to maintain.

If everyone is keeping their stack small, everyone is doing the same thing over and over and over again. Why shouldn't we copy best practices over without understanding it?

Should you really spend an hour vertically aligning an element in a compatible way, when you could copy and paste in 30 seconds and go straight to testing the code you didn't read, write, or understand - and see that it does exactly as advertised?

Why shouldn't programmers have a division of labor? Why should everyone understand everything?

I'm not really prepared to explain why being ignorant about your tools is toxic to good work, but I'll offer this:

If everyone knew C, would they keep writing the same code over and over? Obviously not. They'd find new ways to compose what they've already written to create whatever they want.

It's not a waste of time for more than one person to know how to do something. People start from the bottom and learn their way up. In your example, what happens the next time they need to align another element? They either copy and paste whatever they did before, or google it again, right? If they had taken five minutes to learn it before that, they'd already know how to do it, and could just write it.

Redundant knowledge is not a bad thing.

Because debugging?

> Why shouldn't we copy best practices over without understanding it?

I'm surprised to see this question being asked non-ironically. I can see myself using a library function without fully understanding it, but copy-and-paste? This may be acceptable in something like CSS (since the comment mentions 'vertically aligning elements), but for solving any non-trivial problem, this is probably not a good way to go.

I have to disagree, unless of course you're okay with being a "developer" and not a software engineer. An engineer needs to know what goes on under the hood. I have seen enough harm done by software engineers who use tools and libraries knowing only their purpose and not their behavior.

Unfortunately someone already invented the NIH anti-pattern.

Reply on news.ycombinator.com