Estinos

Obligatory mention for those who don't know yet : you can find what files a program use by using strace <command> (provided strace is installed). It actually logs all syscalls made by the program, so there will be a lot of noise, but in there you will find the access() and open() calls.

Additionally, if you want to strace programs that already are running in a convenient interface, htop has strace support (this is less useful to find configuration files, as those are usually read at the start of the program, but if you can trigger a save to the file, it will appear here).

Yeah, it's easy to miss. :) I think it's been there for something like about 5 years? (don't quote me on that). But it only appears if strace is available, and even then it's a bit hidden in the interface. I discovered it the way I learn new features in vim : by mistyping.

I've started learning C four years ago, after a career spent coding ruby/javascript/Go, so I guess I was in the same position than you. I started by reading the GNU C manual, then the Glibc documentation, and the man pages for headers and functions I was using (all glibc functions have a man page ; depending on your distros, it may already be installed or you may need to install a specific package to install them all at once). And of course, reading header files in /usr/include/ is always useful for using this or that library. Later, I discovered the book Modern C and it completed my education to feel at home with C. I can't say if it's the best path, but it worked for me.

I use it regularly in projects from other people, almost never in mines. It's a good tool when I'm completely in the dark, not knowing much about the architecture of the codebase. When I do know the architecture, I usually have a good intuition where the problem is coming from and I go poke the git log of the file or files related to that, it's always faster than bisecting. But in Terra Incognita, this is an incredibly powerful tool. You know this version worked, you know this one is broken, and you can just follow the process of git bisect to find the exact commit that introduced it. In FOSS projects, it's usually a commit that changes two or three lines and you can pinpoint immediately what the problems is. If it's a 1000 LOC change commit, you're in for more analysis, but at least you know it's somewhere there. :) So yeah, I would call that mostly a tool to contribute bugfixes in FOSS projects, at least in my usage.

It's even worse than that. :) I've read the 4 standards (which, to be fair, are very pleasant to read, we're lightyears away from xhtml docs), and I still don't understand how the search feature works in Lemmy and Mastodon. Because the standards are very minimalists : they describe what messages look like (the various activities a user can do), ActivityPub itself describe the http structure of the inbox and outbox (the requests to do to use them), and… that's about it. There is nothing about discovery, so I suppose now applications implement it as they see fit, which means on top of understanding the standards, you need to understand actual implementations (that's what I'm going to read next, at least).

I know of nothing more than what people mentioned in this thread, sorry. :) Except maybe… Have you considered writing? If what you're after is telling stories rather than coding, it's the easiest and yet most powerful way to explore your imagination, what you can do in a videogame is ridiculously limited compared to what you can do in a written story. And it's free. :)

RPGMaker sounds like something you would like (not open-source, though). You can do most things without coding, to just enjoy creating and telling stories. And when you want to do more, you can add code on top, learning at your pace and adding more and more useful stuff, if you find out you like that and stick with it.

With Godot, you would need to learn more about coding, but the advantage is when you know Godot, you're ready to make "real things". You could get a job just by knowing Godot, either to use it directly or to move to Unity, which is very close.