I wouldn't worry about it too much. People in the embedded world understand that somebody entering it for the first time will have a bit of a learning curve.
In general, the big thing to keep in mind is that, compared to a desktop system, the system is much more limited. You will probably have a lot less RAM, a much less powerful CPU, almost certainly no disk swap space, and most likely either no GUI or a very limited one. You may not even have an operating system.
Also, the code/build/test cycle can be really long, as in 5-10 minutes, and you may not have things like a runtime debugger on the device (e.g. no gdb, etc.). So rather than making little tweaks to see what happens, it's usually more productive to write a lot of code at a time, code very carefully, and add lots of printf-type logging to see what's going on at runtime. Depending on the device and its ports, you'll often want to send your logs to a serial port and pick them up using a terminal program on your desktop build machine.
The details of those limitations and what you do to compensate can vary a lot, as can how you build the executables and put them onto the device for testing. You'll have to find out about all that once you get on the job. Here are a few examples...
- On a couple of Linux-based ARM cell phone projects, I would simply build and test on a desktop, cross-compile for ARM, and transfer the executable to the device for final testing. Depending on the test hardware, the transfer could be done over a serial link, using an MMC or SD flash card, or (when I was really lucky) using Ethernet and an NFS export from my desktop development box.
- On another Linux/ARM tablet project, the above applied, but the system was powerful enough some executables could actually be built on the device itself.
- One digital camera project I worked on was deployed using Hitachi and Fujitsu 16-bit microcontrollers. That required really tight coding, and I wrote it all in "embedded C++", which limits the language features to prevent code bloat.
- 8-bit 8051 microcontrollers are still very common. They're used for all kinds of crazy things, like the automatic door openers on subway cars, and there's probably one in my coffee maker :-) But it's a really constrained environment and requires special skills and compilers.
Update... I forgot to mention...
Quality must be a priority for an embedded system to succeed. Often, you can't do field updates to shipped product ("Please insert this CD-ROM into your coffee maker."). And even if you can, it can be crazy-expensive - for instance, hundreds of thousands to millions of dollars per carrier to update a cell phone's firmware.
Also, all the "wisdom" about premature optimization goes out the window. If you have specific performance requirements, and defer meeting them, you may find you've painted yourself into a corner design-wise, and have to rip a lot of things out and start over. It's much better to write each component to meet its performance goals initially, and make sure it continues to meet them throughout the development process.