Read the content. I address that issue.

Well I'd you have so many data entry, yaml and toml are not that helpful either. They would present different sets of problems. You should use a database (perhaps sqlite) for that purpose.

Well, I mostly target the places where you don't programmatically generate millions of values. Configurations, entry metadata, etc. Indeed SQLite is much better for when you have a massive amount of data, and you need a better base that a file system. But when that is not the case, a file system is more advanced than whatever tooling are behind toml and yaml.

Yes. That is indeed a more interesting name. But think of the acronym.

• FDS is not as easy to say FAMF.
• FAMF already has an Urban Dictionary entry.

/key/=/value

I have one that has 69 (noice) files changed.

Famf is definitely is. Just put yaml there.

Sure. Why not :))

What would you do with billions of inodes?

I don't think I like vim or similar for the "productivity gain". It just feels much more smooth of an experience when I don't have to target, point at something visually and click all the time. Or move my hand to a 4 keys that are as far from my hands resting position as possible. I don't believe I have saved much time. But I had a blast working with it and want to continue this serendipity experience for the rest of my time.

So, I had the same sort of struggle a while back. And I have managed to fix it, recognizing what I had been doing wrong.

1. I did not know how to test different parts of my system. Going through other people' s testing example actually helped me a lot in this respect.
2. I did not separate the complex internal logic of my program, from its side-effects. For example put the mapping of the data in the same function as I was doing external requests. You learn how to manage problems like this by practice. But of course, be mindful of the side-effects of your functions. Avoid it when you can.
3. One other problem I had was that I wrote every test in the same manner. Tests that are not idempotent, and depend on external services, are useful, but you should use the facilities of your language to run them separately from your unit tests. In rust for example we use feature flags.

Testing and writing functions that can be tested are skills that need practice. For me, many of the patterns of the functional programming helped a lot. Since they insist on pure functions and pure functions are massively easier to test. Learning how people manage to write programs with pure functions may help you a lot, too.

That poor sheep did not have any choice. I cannot say the same about other characters in this picture.