> I suspect any developer reading this is aware of the DRY principle because it is just so ubiquitous. If not though, you just need to know that it stands for "Don't Repeat Yourself" and is generally invoked when advising people to not copy and paste snippets of code all over the place and instead consolidate logic into a central place.

Well, no.

What you actually need to know is the next layer out: DRY stands for Don't Repeat Yourself, sure, but Don’t Repeat Yourself isn't the rule, it's a short phrase that is supposed to be a memory cue for the principle “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”.

If all you know is “Don’t Repeat Yourself”, you don't know the principle, and you can neither apply nor critique it.

#1 is simply applying the memory cue as if it were the principle. Yeah, don't do that.

#2 is, well, no, you only refactor to extract a bit of knowledge to a common place where it is immediately reused: there is no presumption of reusability, it is demonstrated.

The specific example they use of how this might be done wrong is...so bad.

Starting with: the example code that they suggest is bad design but works does not work.

  make_pizza([left_topping, right_topping])

gives args a length of 1, not 2, but their function definition relies on it having length 2, and using that to distinguish from the simple case.