I would claim that 70% of software engineers would love taking an electronics course. It's like programing, with electrons.
I suspect the next link in the cycle will be how you can make music on an old AM radio, if you attach a length of unterminated wire instead of a cap!
I very much think all software engineers should take an electronics course. At least an introductory one. Knowing how things work will improve your code, and will give you an alternate way of thinking about programming problems.
But I'll admit my bias: I came to programming by way of a digital electronics course as a child. Since I was a child of a poor family, I couldn't afford to actually do electronics projects at home, though (this was well before everything got so inexpensive), and shifted to programming because you could do that for free if you had access to a computer.
On the other hand, FPGAs and really fast microcontrollers are a thing now, so you could probably get a chip with a nice internal ADC, digitize the output voltage, and use an actual computer program to drive the H bridges, thus making an extremely non-cost-effective class D amplifier :)
Issue with doing what I tried to do and FPGAs is that the overall architecture of this kind of DSP is perfect example of a thing that does not match the FPGA architecture. It boils down to ridiculously long shift register, few bits per tap of parameter data and reducing tree for the result, ie. most of that is ridiculous amount of 1bit SRAM cells.
And well, in the end I realized that idea, in not-even-that-fast-for-the-time ARM11TDMI and software and 24b samples at 96kSps (both of which is realistically a total overkill for this application), but without the DSD input (in theory the code that produced the output can be inverted and used to convert DSD to some sane representation, but well, I did not really care)