[philote]

If you're able to automate a script for it, or make tests for it, it's not tacit knowledge.

Also, as someone else has said, why not just automate the prcoess? Why spend the time to write a test when that time could be spent on the automation and saving everyone's time in the future?

[ramses0]

There was a code quality tool (Snyk) which had a blog post [citation needed] about focusing fixes on only recently changed files. eg: You start adopting Snyk, it starts complaining about a bunch of stuff ("ERR: Too much whitespace in if statement..." or whatever), and you _would_ like to conform to that, but it's a massive undertaking to modify your whole codebase to support it. To be clear: much of the results from Snyk are actual functional issues, I'm just throwing out an overly simplistic example.

Anyway, their blog post mentioned something like "fix the tip of the wave, not the ocean", and that metaphor has stayed with me ever since.

Internally in your codebase, you may have `TheDatabase.GetUsers(...)`, and want to migrate to something like `PerformantShardingV2.GetSomeUsers(...)`. It's a perfect example of where something like this technique would work.

You would/could/should use code to `grep -l TheDatabase.GetUsers` and get a list of filenames _known_ to use the old-and-busted way of doing things. You would/could/should have a test that says "ERR: $new_filename uses TheDatabase, but is not pre-approved, use PerformantShardingV2 instead!".

Additionally, it'd be great if there was a way to say something like: "ERR: Your PR modified files that use `TheDatabase` but you didn't migrate to `PerformantShardingV2`, please upgrade!".

Long way of saying: the technique is incredibly useful for gradual (not big-bang) changes/rewrites, which is mostly what you should be doing. Standards, compliance, and best-practices do tend to change and skew over time, and having a technique like this is very valuable.

Why you wouldn't have `just make-a-new-enum-json` as you're suggesting? It isn't very discoverable (unless you have a VERY good business vocabulary and constant training) and if you don't know you'd need to use it then you wouldn't have used it in the first place. Additionally, you'd still want to have this double-checker to prevent errors or standards/best-practices violations from getting in to your codebase.

This _is_ automation that saves everyone's time in the future, and is complementary to some of the automation that you're talking about.

[BizarroLand]

Practically all knowledge was once tacit knowledge. I bet protohumans found fire from a lightning strike long before they figured out how to make it themselves.

Even the idea of a city, say London, is just a non-tacit version of the idea of the area where London is.