@JeremyCherfas That was a lot of stuff. In general, when I’m getting started with a new toolchain, I will:
- Pick a popular editor for it and kit it out with whatever plugins the Internets likes. (Often that editor ends up being VS Code or Atom these days.)
- Set up a linter to get style and gotcha guidance, and make sure it works with the editor.
- Find a testing framework and some examples to crib from. Get that working so I can “ratchet” my progress on getting something working. (It never gets worse, only better.)
- Find a logging system with channels/systems and levels, so I can dial up and down log verbosity as needed without stripping out the trace that will let me scry what happened from logs.
- If needed, or if it’s easy (like browser JavaScript), set up and get the basics of a debugger working. I want to know how to say “stop here”, how to look at the data that’s around at that point, how to go step by step or just resume running code, and how to change data and interact with my program.
That gets things “good enough” that I rarely bake in more clever visualization and operator support.
I expect this to take a day or two when I start something completely new. I also look for style guides and exemplary code to read when I’m not actively coding, as part of acculturating.