> You may make your function 2x faster, at a cost of additional complexity, but you never run it enough in a year for it to pay itself back.

I'm not talking about increased complexity, I'm talking about extremely basic things that take zero extra time, like using the correct data structure. For example, in Python:

    In [8]: a = array("i", (x for x in range(1_000_000)))
       ...: l = [x for x in range(1_000_000)]
       ...: d = deque(l)
       ...: for x in (a, l, d):
       ...:     print(f"{sys.getsizeof(x) / 2**20} MiB")
       ...:
    3.902385711669922 MiB
    8.057334899902344 MiB
    7.868537902832031 MiB

Very similar structures, with very different memory requirements and access speeds. I can count on one hand with no fingers the number of times I've seen an array used.

Or knowing that `random.randint` is remarkably slow compared to `random.random()`, which can matter in a hot loop:

    In [10]: %timeit math.floor(random.random() * 1_000_000)
    31.9 ns ± 0.138 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

    In [11]: %timeit random.randint(0, 1_000_000)
    163 ns ± 0.653 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

> All of which will change in a few years, which is fine, if you're also committing to keeping _all that code_ up to date right along with it.

With the exception of list comprehension over large ranges slowing down from 3.11 --> now, I don't think there's been much in Python that's become dramatically worse such that you would need to refactor it later (I gather the Javascript community does this ritual every quarter or so). Anything being deprecated has years of warning.