Pick a hardware to tinker with. I'd suggest a development kit rather than some cheap mcu-psu-downloader-only board. Now listen, it may be more on the expensive side, but you don't have to deal with hardware trouble first since many development board usually provide a lot of functionality to play with.

Second, check the official documentation for said devkit and play with it. You'll ended up immersing yourself on your selected manufacturer but that's fine for learning.

After you've more understanding of the workflow for embedded development, then I can safely advice you to start exploring. A simple one would be programming the same board but using a different workflow. You may ended up with the manufacturer IDE, and wondering how to get to your beloved editor for example. Then you start to learn the build workflow until download and debug step.

I never understood this argument. Why does having common first letter bad? If you mean subjectively then sure, it may not be for everyone, but objectively?

Ahh, then the modification must be done on the AST level not the in-memory representation since anyway you do it, you must retain the original.

...and the nipple never comes out like how a human nipple can get erect? Forgive my lack of biology, I am an engineering major.

TARS and AVA not being switched is a crime

I agree, the point is that we need to define "alive" itself clearly which as you stated, is currently beyond our understanding.

If being inert constitutes as not living then yes, virus is not alive. Their "evolution" is not because of their doing/needs but rather due to their construction. In that case I think virus is more akin to a poison. The substance itself can be not dangerous, but due to a metabolism process inside a specific organism/cell, it becomes a dangerous substance. The side effect in this case is just so happens to make another copy of the virus. But this process is prone to mutation as their building block is quite prone to do so, and we get the "evolution".

I prefer concise and accurate documentation than clean code tbh. The reason is that if the documentation stated that it should perform something with side effects a,b,c then I at least know what to expect. When contributing, this also makes it easier to implement something because we have the requirement at hand. Understanding shitty code is easier than understanding human requirements. Shitty code is the language we use to talk with a computer, so at least you'll know exactly what will happen.

So CAD is simple stuff huh. So does CFD, mathematical modeling of a complex control system, robotics... Man, if only mechatronics is so simple. I daily drive arch btw.

Off topic but man, the term sounding has been forever ruined for me

Yeah, that's the thing with electronics. Sometimes the damage is not visible but the component doesn't behave as expected anymore. Timing can be off, more bit flip happens, all sorts of crazy stuff, including a resistor that is not up to spec or damaged ADC. Haunted it is.

If that were true, then you probably should calculate the difference in energy density. How do they achieve that effect while increasing energy density?

My bad, I worded that badly. What I meant is that the website now has access to those features via the browser (js or some other mechanism). Now suddenly fingerprinting a device can be made easier.