I was recently consulting at org where two separate engineering teams were all in on two different, incompatible deployment platforms and using AI to accelerate adoption of each.

Management was mystified why their engineering leads kept telling them they couldn’t deploy a complete implementation of their solution.

Now imagine you had the tools to do a diff across all those repos simultaneously, and classify, group, and review those patterns. What could you learn NPM teams and practices?

Now imagine you could pick best of breed, and propagate those back to all the other projects automatically to improve their productivity, security, etc. How fast would your productivity improve and your engineering culture change if everyone could automatically learn the best of what everyone else had to offer?

Companies like Spotify have sophisticated tooling for detecting repo changes and enforcing policy like that, and they run that experiment 1,000 times a day. Small evolutions in what was an identical build script, like a version bump, are detected, and if it passes a threshold it can be rolled out everywhere else immediately.

Having all the copies that you can sync up centrally periodically puts natural selection to work on internal best practices.

Basically, things work differently at scale. When the number developers you employ approaches a meaningful percentage of the total number of developers globally, your internal diversity starts to mirror the global diversity. So you have to manage that diversity. If you freeze policy entirely, you fall behind the global average. If you let things run wild, your company fractures technologically.

So, make a 1,000 copies, see what pops up, adopt and enforce things that look good, then do it again. Evolve to the next best place you can be from where you are.

It may also be that "space" and "time" are emergent properties, much like an "apple" is "just" a description of a particular conglomeration of molecules. If we get past Planck scales it may turn that out that there are no such things as "space" and "time" and the Planck constants are irrelevant. We currently don't know but there _are_ a few theoretical frameworks that have yet to be empirically verified, like string theory.

It may be that one day we come up with a more refined model. But as of today, it’s not clear how that would happen or if it’s even possible.

Imagine going from 4K to 8k to 16k resolution and then beyond. At some point a “pixel” to represent part of an image doesn’t make sense anymore, but what do you use instead? Nobody currently knows.

As a counter-factual, imagine if every time you wanted to smoke you had to decide if one particular type or brand of cigarette was good for you.

…If you used AI and can still explain to me why code works and what it does, even better. You have learned how to use new tools.

(have not tried the randomized question approach to compare, but I’m curious to try it and see what happens)

IMO, a function _can_ be an interface in the broadest sense of that term. You’re just giving a name to some set of code you’d like to reuse or hide.

I don’t think you need only 20 test cases for open(). Sometimes, more than 20 is valid because you’re saving across some other dimension of complexity. That happens and I don’t dispute it.

But the fact that you need >20 raises the question: is open() a good API?

I’m not making any particular judgment about open(), but what constitutes a good file API is hotly contested. So, for me, that example is validation of the principle: here’s an API that’s behaviorally complex and disputed. That’s exactly what I’m suggesting would happen.

Does that help clarify?

If you start there, you have room for your abstraction to bend before it becomes too brittle and you need to refactor.

Almost never is an interface worth it for 1 implementation, sometimes for 3, often for 5-20, sometimes for >20.

The trick is recognizing both a “unit of complexity” and how many “units” a given abstraction covers. And, of course, different units might be in tension and you have to make a judgement call. It’s not a silver bullet. Just a useful (for me at least) framing for thinking about how to manage complexity.

Do I need 5-20 non-trivial test cases to cover the range of inputs this function accepts?

If yes, function is probably about the right level of behavioral complexity to add value and not overhead.

If I need only 1 test or if I need 200 tests it’s probably doing too much or too little.

Rarely, a function with a single line or an interface with a single element or a class hierarchy with a single parent and child is useful. Mostly, that abstraction is overhead.

Often, a function with 5-20 lines or an interface 5-20 members or a class hierarchy with 5-20 children is a useful abstraction. That’s the sweet spot between too broad (function “doStuff”) and too narrow (function “callMomOnTheLandLine”).

Sometimes, any of the above with the >20:1 complexity ratio are useful.

It’s not a hard and fast rule. If your complexity ratio falls outside that range, think twice about your abstraction.

It’s like a secret unlock code for domain modeling. Or deciding how long functions should be (5-20 lines, with exceptions).

I agree, hugely usual principle.

At mega-scale, even IDE based tools are skipped in favor of automated tools such as Refaster/OpenRewrite that can refactor 10s of millions of lines of code at once.

I do find myself occasionally using, say, a regex find/replace to change something project wide. But most of the time (95% to put some arbitrary number on it), once I’m beyond the scope of single function, I use AST-based tools to ensure changes are correctly reflected in other files or parts of the project.

So, I’m trying understand to who lives in my 5% long enough that they the need what is essentially a highly specialized regex. Are they doing cross-project changes based on text? Do they have giant functions where that’s not a concern? Are their projects just smaller and they have many of them?

I definitely see the allure of having a smaller, faster editor. How far are people actually able to push that paradigm?

What I don’t understand is the development workflow that includes so much text manipulation. If you’re writing new code, there’s nothing to manipulate. If you’re refactoring existing code, wouldn’t you want the support typical AST-based refactoring tools provide? Where’s the sweet spot where shuffling strings around makes sense?

That’s not sarcasm. I’m genuinely asking.

Performance is only adequate if it’s at least as good as the engineers of the other players in your industry. Otherwise, you’re losing ground. As long as anyone in your market space is actively trying to manage their engineering talent (recruiting your top performers, releasing low performers, being more selective in hiring) so must you just to keep pace. An “adequate” engineer may make the company money, but the opportunity cost of not hiring someone better who could make even more money can be higher still.