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 :)