We probably were not living on the same planet, then, you and me. :) From what I saw, in the 2000’, there were no “backend developers” either. We were all webdevelopers, then younger people started to call us “fullstack developers” when they specialized. But the hate against javascript is way older than that. Already in the early 2000s, it was considered a malware language. It’s only when prototype.js and scriptaculous introduced web animations that people started to consider it seriously. Even then, jQuery’s main sale point was that it allowed to do the least possible amount of js. Anyway, it doesn’t matter when and why you started hating, hate is always wrong, period.

Wow, people are still showing disdain for javascript? I thought we were done with that since “frontend development” became a thing.

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.

When that becomes a well-known bug, it’s past time to try an alternative.

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.

Omg, thanks for this. 😂 I could really have used it in those teams where backend devs thought that they didn’t have to try and use their feature in the browser : if the test suite pass, then it’s good. I hope I’ll never be in such a team again, but I keep this pic just in case. :)

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.

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).

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).