There’s a guide in the SuperCollider documentation called “Writing Unit Generators”. There’s also a nice cookiecutter template to quickly get you started with a project: GitHub - supercollider/cookiecutter-supercollider-plugin: cookiecutter project for SuperCollider server plugins
There are also some useful links in this thread: How to Write UGens
I think they have a different name on linux, for reason that could maybe be explained by someone that’s more of a Linux pro (this has always been a source of confusion / minor problems).
Faust can be a great way to try out building SuperCollider UGens.
I would say - if someone has general experience with imperative programming (even something like sclang or javascript), it might be easier to experiment with writing UGen’s in C++ (using e.g. the cookiecutter template). There’s a small jump required to understand some C+±isms if you don’t know them already, but your actual DSP code ends up being pretty straightforward to write.
If someone’s coming from a less programming-intensive background - or is more comfortable thinking about things through a math / signal processing lens - Faust is probably a better option. It’s unquestionably a better way to represent signal processing (vs. imperative C++ code), but I think can be counterintuitive for someone who just wants to write a for loop where they do some math.
Finally - writing UGens is a great exercise to learn DSP-related programming things, and there are SOME kinds of processing that are hard to do in SuperCollider unless you write them into a UGen (e.g. IIR filters or processing that involves processing very short delay lines). But, it’s a common misconception that something written as a UGen will be faster/better than something you build in sclang as a SynthDef. This isn’t true - most of the core UGens are highly optimized, which means that unless you’re ready to dive deep into hand-optimizing C++ code, using normal math operators in a SynthDef will be faster than the (non-optimized) equivalent in C++.