Reading this I realised I've kind of drifted away from the idea of refactoring for the point of it.
The example with the for-loop vs. map/filter in particular - it's such a micro-function that whichever the original author chose is probably fine. (And I would be suspicious of a developer who claimed that one is 'objectively' better than the other in a codebase that doesn't have an established style one way or the other).
Refactor when you need to when adding new features if you can reuse other work, and when doing so try to make minimal changes! Otherwise it kind of seems more like a matter of your taste at the time.
There's a limit of course, but it's usually when it's extremely obvious - e.g. looong functions and functions with too many parameters are obvious candidates. Even then I'd say only touch it when you're adding new features - it should have been caught in code review in the first place, and proactively refactoring seems like a potential waste of time if the code isn't touched again.
The (over) consolidation of duplicated code example was probably the most appealing refactor for me.
I'm a bit sceptical of the exponentially harder debugging claim.
First it looks polynomially harder for the given example :p.
Second other engineering domains arguably have additional dimensions which correspond to the machine learning ones mentioned in the article. The choice of which high level algorithm to implement is another dimension to traditional software engineering that seemingly exists and corresponds to the model dimension. This is often codified as 'design'.
The data dimension often exists as well in standard learning software engineering. [Think of a system that is 'downstream' of other].
It's probably a lot simpler to deal with these dimensions in standard software engineering - but then this is what makes machine learning harder, not that there are simply 'more dimensions'.
The delayed debugging cycles point seems a lot more valid.
For reference I think this probably partly explains my reluctance to use A.I. to help me code.
If I ask e.g. ChatGPT to just code something for me then the code it outputs is a black box, and there is no 'theory usage' in the parlance of the article. [Or I guess I'd have to recover the theory from the code it writes].
I've accepted by now that I'm putting myself at a disadvantage by not using A.I.
at work however. Maybe another way to think about it would be that A.I. allows us to use our higher level theoretical understanding when we interact with codebase.
This is nonsense. The demand curve as a concept only deals with singular prices, and the slope of it is particular to a particular product.
The Pareto principle (80% of good thing x comes from 20% of input y) is over-used everywhere, this is the first time I've seen it applied to pricing. Funnily enough the first time I saw it wasn't in economics but in a human interaction course.
While the 4x multiple of pricing tiers might be a good idea, this article certainly doesn't make a good case for it.
One might say that sites like reddit and hacker news are just archaic versions of the same recommendation engine, but the friction is actually an important feature, and keeps the experience from devolving into lowest common denominator clickbait.
I'm not certain about this seems like it would depend on the algorithm in question. In any case not certain I understand exactly what the friction you're referring to is, and how it helps devolution.
The example with the for-loop vs. map/filter in particular - it's such a micro-function that whichever the original author chose is probably fine. (And I would be suspicious of a developer who claimed that one is 'objectively' better than the other in a codebase that doesn't have an established style one way or the other).
Refactor when you need to when adding new features if you can reuse other work, and when doing so try to make minimal changes! Otherwise it kind of seems more like a matter of your taste at the time.
There's a limit of course, but it's usually when it's extremely obvious - e.g. looong functions and functions with too many parameters are obvious candidates. Even then I'd say only touch it when you're adding new features - it should have been caught in code review in the first place, and proactively refactoring seems like a potential waste of time if the code isn't touched again.
The (over) consolidation of duplicated code example was probably the most appealing refactor for me.