If that's what they wanted to prove they should have shown a better example.

In Zion National Park, there's a hike called Angel's Landing. For part of the hike, you go along this ridge, where on one side you have a cliff of 500 feet straight down, and on the other side, you have a cliff of 1000 feet straight down. And in places, the ridge is only a couple of feet wide.

Best practices can be like that. "Here's something to avoid!" "OK, I'll back far away from that." Yeah, but there's another cliff behind you, of the opposite error that is also waiting to wreck your code base.

Listen to best practices. Don't apply them dogmatically, or without good judgment.

DRY should honestly just be restated as "Avoid multiple source of truth", two pieces of code that look similar but have two separate goals are not something that falls under DRY unless you can pull out some common logic that actually is the same goal and can become the single source of truth for that goal.

Can concur. Mostly it was I causing the pain, earlier.

> Consolidating code is easy, pulling it apart is a lot harder.

I absolutely agree with this, and the only thing I would add is that is difference is even more pronounced in codebases using a dynamic language.

Sure it's not easy to navigate a bowl of duplicated spaghetti, but navigating opaque DRY service classes without explicit types is a nightmare.

Luckily as an industry we've realized the benefits of static typing, but your point still holds true there.

How do you consolidate code?

Good way to go at it is to isolate the functionality that is used many times and to pull it aside in its own function (or similar). That's just good code practice and also makes it easy to refactor and modify as needed.

I have 20 years in the industry and one of the rules I learned is: Articles justifying laziness are ALWAYS warmly welcomed and praised.

To get internet points easily, write something of that:

“Clean code is overrated”

“SOLID is holding you back”

“Tests are less important than profits”

“KISS is the only important principle”

“Declarative programming is only suitable for pet projects”

“Borrow checker is the plague of Rust”

and so on.

I basically agree, but doesn't this just mean, if I'm consolidating non-DRY code, that I'm now the one using DRY consciously, and the next dev will be cursed with all of my newly introduced DRY abstractions?

> Whenever I have to work with a project where someone used DRY []consciously[], I know I am in for a world of pain.

Huh. When you put it that way, that's actually a good point. In my experience, competent programming will try to consolidate repeated code, and then cite "because DRY" if asked why, but I can't think of any case where I or anyone else competent started with "needs more DRY" as the original motivation (as opposed to "this is a incomprehensibly verbose mess" or the like).

Conversely, starting with "don't repeat yourself [and don't let anything else repeat itself]" as a design goal does seem to correlate well with cases where someone temporarily (newbie) or permanently (moron/ideologue) incompentent followed that design principle off a cliff.

"Consolidating code is easy, pulling it apart is a lot harder."

My experience is the opposite. The less code, the better. I just spent a week on refactoring UI automation test code where they had copied the same 30 lines of code into almost 100 places. Every time with an ID changed and some slightly different formatting. It took me a few days to figure out that these sections do the same thing so I decided to introduce a function with ID as parameter. It was a lot of work to identify all sections and then to make sure they are really equivalent.

Saved us 3000 lines of code and now we can be sure that timeouts and other stuff is handled correctly everywhere. An we can respond to changes quickly.

that's DRY to me. Don't copy/paste code. Introduce functions. Ideally in the simplest way. When you have functions, you declare the same behavior everywhere.

example? duplicating (literally copy paste) is easier than even finding duplicated code with small differences.

Same. From what I've seen, most code is written with abstractions and DRY as a high priority rather than writing code that is performant and doesn't take jumping between 5 different files to make sense of it.

There's a certain psychological attraction to messy and confused situations which people are just too comfortable with but it explains why things like GraphQL (didn't have a definition for how it worked for years because "Facebook is going to return whatever it wants to return") inevitably win out over SPARQL (which has a well-defined algebra).

One of my biggest gripes (related to the post) is the data structure

   create table student (
      ...
      applied_date                         datetime,
      transcript_received                  datetime,
      recommendation_letter1_received      datetime,
      recommendation_letter2_received      datetime,
      rejected_date                        datetime,
      accepted_date                        datetime,
      started_classes_date                 datetime,
      suspended_date                       datetime,
      leave_of_absence_start_date          datetime,
      leave_of_absence_end_date            datetime,
      ...
      graduated_date                       datetime,
      ...
      gave_money_date                      datetime,
      died_date                            datetime
   )

which is of course an academic example but that I've seen in many kind of e-business application. Nobody ever seems to think of it until later but two obvious requirements are: (1) query to see what state a user was in at a given time, (2) show the history of a given user. The code to do that in the above is highly complex and will change every time a new state gets added. The customer also has experiences like "we had a student who took two leaves of absence" or "some students apply, get rejected, apply again, then get accepted" When you find data designs like this you also tend to find some of the records are corrupted and when you are recovering the history of users there will be some you'll never get right.

If you think before you code you might settle on this design

    create table history (
       student_id                         integer primary key,
       status                             integer not null,
       begin_date                         datetime not null,
       end_date                           datetime
    )

which solves the above problems and many others in most situations. (For one thing the obvious queries are trivial and event complex queries about times and events can be written with the better schema.) I can't decide if the thing I hate the most about being a programmer is having to clean up messes like the above or having to argue with other developers about why the first example is wrong.

If "No code" is to really be revolutionary it's going to have to have built-in ontologies so that programmers get correct data structures for situations like the above that show up everyday in everyday bizaps where there is a clear right answer but it is usually ignored.

You didn’t provide any evidence for this, you just stated your coding preference. Which is usually the case in these discussions. Some anecdotes, and then people making grand claims based on personal preference. Obviously, some programmers have thought the opposite and have their own anecdotes.