system
Given the following post, respond as if you're commenting on Reddit:
human
Anyone here in the embedded devices field, or programming with C or C++? How do you like it? What are the pros and cons of your workload?

I’m pretty sure i can get a job offer to do embedded device engineering working with C and C++. I’ve never worked in either of those languages, and I’ve never worked with embedded devices. I’m debating if I should even go down that route but I admittedly don’t know enough about the languages and workload to even know if i’ll like it. I’m curious what your thoughts are around the field. Pros and cons?

For some context, I’ve been a software engineer for 3 years and have mostly done full stack with C# and JavaScript etc.
gpt
Embedded device work is typically a completely different animal to client, back-end or full stack development.  The severity of the departure from what you're used to will depend a lot on the nature of the embedded devices you're considering.

There's a world of difference between what is essentially a full-blown PC, hidden within, say an ATM vs. a PIC or microcontroller in a garden hose timer (which might have just 128 **bytes** of RAM, a very rudimentary and slow processor, and a couple of KB of program space).  Yet both are examples of embedded development work.

For what generally is considered "embedded device" work (i.e. smaller, lower-powered devices, that don't rise to the level of using a SoC or SBC) as opposed to just "embedded" development:

* You're working much closer to the metal.  Libraries, beyond the standard C library and maybe a hardware interfacing library, that come with the microprocessor or board you're targeting, may be off limits (typically due to resource constraints).
* Direct memory management and manipulation (pointers, manual malloc/free), without a safety net, is the norm.
* Bit-twiddling is common.
* Resource constraints often meaning optimization concerns in both time and space complexity - for situations which in full stack development you wouldn't even bother optimizing.
* Special/clever "tricks" become things necessary to get the job done, rather than being frowned upon because they're hard to read/understand.
* Comprehensive testing becomes a major factor, as for low cost devices it may simply not be possible to update them if you find issues post manufacture (never mind after sale).  

If your embedded device is a "controller"of some kind, you'll usually need some basic level of electronics knowledge as well.  Understanding the reason for, and usage of, pull-up and pull-down resistors, why you need to and *how* to debounce inputs, applying PWM and PDM, DAC and ADC capabilities and so on, how to read a basic schematic etc.

Optimization can be a bear, and there's frequently a strong drive to do it; developer time is cheap if you're making 1,000,000 widgets and you can optimize your way from needing a $4 microcontroller and get the job done with a $0.50 PIC instead.

That can mean the "comparatively beefy" microcontroller you started with, that had 2 KB of RAM, 16 KB of program space, 10 I/O lines, a 32-bit CPU at 16 MHz, suddenly becomes a device with 128 bytes of RAM, 2 KB or program space, an 8-bit CPU at 4 MHz and only has 4 I/O lines.

Well, now you don't have the space for a full 8-bit pop-count (count the number of set bits in a byte) lookup table, and your CPU is slower so the fact it was a lookup table in the first place (trading time for space complexity) meant you were already performance constrained!  So it's clever tricks time!

In this case, that might mean embedding the lookup table in the program space block (if you're able, it's not always possible).  Or it might mean using a 4-bit set-bits look-up table (requiring 1/16th the space of an 8-bit one), and processing the upper and lower nybbles of each byte separately, and then add them.

And those six I/O lines you lost?  Well, now you've got to come up with a multiplexing scheme for the four you do have, so they can act as eight.  And that'll require working with the hardware guys.

Oh, and to deal with any value larger than 255, you're now manually dealing with carries and multi-byte representations, rather than simply being able to treat 4 bytes as word with a 4-billion value range.

\---

That seems a like a lot of "doom and gloom".  Again, it depends on what you mean by "embedded device".  There are lots of "embedded" systems that run on essentially normal PC hardware, with maybe custom input or display devices, and those are not nearly as far from what you're doing as "controllers" and simpler "embedded devices" will be.

And in the middle, there are more powerful microcontrollers, and SoCs that, while still requiring a different way of looking at things, aren't nearly as constrained  in terms of power, development model, tooling and so on.