Ahh goingware is looking at doing embedded work.

I started out doing embedded programming, and over the years realized that I was doing OS programming (right on the hardware, size restrictions, dealing with nasty, undocumented electronics, etc.) and started playing with Linux drivers as I saw somewhere I could help out. Flash forward to today, and I'm doing pure kernel work (but still dealing with the same constraints of embedded work.) In short, if you're comfortable writing kernel driver code, writing embedded code is a very short step.

Unfortunately, I second Zaitcev's statement about embedded programmers personalities and the general state of the environment in which they work. Typically you are working at a hardware based company, and have to live with design decisions made by people focused on the bottom line of product cost (remember, in production the firmware is free, and no one will recall the 6 months that it took you to get a beeper not to warble, even though they could have solved it with a 5 cent part in the design up front.) Because the company started out as a hardware environment, no one will understand the programmer's point of view, and you will be rarely brought into the hardware design process (or if you will, you will be ignored by them, as "they could produce the required code in this size EEPROM").

That being said, I loved it, but hey, I love writing Linux kernel drivers, what kind of a person likes doing that? :)

On a related note, I would like to publicly apologize to the Cygnus employee that I talked to at the 1997 Embedded Programmers Conference, and asked "what are you all doing here, I thought gcc was free?" I later realized what a jerk I sounded like, and I hope you are retired somewhere on an island due to the buyout by Red Hat :)