4 ms·

Is embedded work, in general, well paid? And is it relatively easy to get new work once you've broken into it? It seems to be not very visible. I'm under the i

Is embedded work, in general, well paid? And is it relatively easy to get new work once you've broken into it? It seems to be not very visible. I'm under the impression that some "not very visible" work is well paid and not going away any time soon. I'm thinking of some cobol or pascal developer called out of retirement at great expense. Or is this like being at the edge of new/exotic web 2.0 where you are continually looking for the next job, re-learning tech over and over. I know this is a big topic and perhaps there is no correct answer overall. If anyone has any resources to job sites or further articles I'd love to read them.

bsder 10y ago
> Is embedded work, in general, well paid? The trick is breadth of knowledge. If you can just program a microcontroller, you've got a lot of competition. If you can program a microcontroller AND an FPGA, your competition dropped by orders of magnitude (this is the biggest step and probably the easiest to tack on--Verilog isn't that hard but you WILL foul up until you get race conditions and concurrency properly beaten into your head--do everything synchronously and synchronizers are your friends). If you can program a microcontroller, program an FPGA, AND design the board--you are in rare company. If you are good at debugging these boards, people will worship you as a god. If you have domain knowledge on top of that, you should be starting a company. > And is it relatively easy to get new work once you've broken into it? Well, it's networking like anything else. If you've been doing it for 10 years, things seem to just drop into your lap. Otherwise, you have to beat the bushes. However, if you do a good job, the good people around will notice quickly. And those good people are often at capacity so they will throw stuff over to you. Obviously, being near a tech hub helps. > I'm under the impression that some "not very visible" work is well paid and not going away any time soon. The problem with "not very visible" is that it also means "executive level may not appreciate it". I've seen medical device companies trying very hard to get rid of the single person who actually understands their hardware. > Or is this like being at the edge of new/exotic web 2.0 where you are continually looking for the next job, re-learning tech over and over. No and yes. :) ARM is dominating the embedded space currently. So, especially at the Cortex M end of the spectrum, the base programming environment looks pretty much the same. This hasn't changed for quite a lot of years. In addition, 8-bit development is mostly going away. The delta between an 8-bit micro and a 32-bit micro is now so small that it makes no sense to use anything other than 32-bits unless you have a very specific use case. For FPGA, the tools are similarly stable over long time frames. The peripherals, on the other hand, completely differ from manufacturer to manufacturer. And have bugs from revision to revision. So, that is like learning stuff over and over :( However, what the peripheral are supposed to DO is stable. Once you understand that, you will be very good at ferreting out the small differences and your life gets some easier. > If anyone has any resources to job sites or further articles I'd love to read them. You can read a lot, but doing is better. Go get a Nordic BLE development kit for $39 and build something. http://www.digikey.com/product-detail/en/nordic-semiconductor-asa/NRF52-DK/1490-1053-ND/5773879 http://www.digikey.com/product-detail/en/nordic-semiconducto...
- branchless 10y ago
  Thanks, this is by far the most comprehensive reply I've ever had on HN. I appreciate you taking the time, I'll look into your suggestions. I actually have an atmega 8515 but I've been a little distracted learning the finer (if that's the right word) points of c++ recently. Do you think the 8515 is "appropriate" ?
  - kbart 10y ago
    I'm not the original poster, but starting with bare MCU might be too tricky at first. A better approach imho would be to get some of many available kits (i.e. Beaglebone) and try to make it live from scratch: don't use prepared bootloader/OS, but try to build everything yourself. Setting up a toolchain, grasping cross-compiling, downloading and debugging "doesn't start" kind of problems are the key and every day problems in embedded programing. When you are familiar with the build-download-debug process, get into peripherals: GPIO, UART, SPI, memory interfaces etc. After this, you should have enough experience and spent enough time on reading obscure datasheets to start designing your first, simple boards. Sure, you also need some electronics knowledge to read, understand and layout schematics, but provided you don't get into RF or analog electronics, it's not too difficult.
    - bsder 10y ago
      I'm going to disagree here about the Beaglebone (or RPi) first. There is a LOT of complexity in those that simply isn't in the Cortex-M (especially M0) series. For example, try to figure out what the maximum bit banging rate is on a Beaglebone Black. Good luck. Getting up and running on an Eclipse/ARM/Segger toolchain sucks. No doubt. But you have to chew through it. After that, it's about 3 lines to get an LED to blink.
HeyLaughingBoy 10y ago
I don't think there's a general answer. From what I could see pay was on par with most enterprise development. Well above basic web stuff though. Like the other poster said, if all you do is code, then your position is pretty weak. I have an EE background and I'm pretty good with mechanical things, so I could debug the electronics and figure out issues with mechanisms, etc. (most of my programming career has involved writing code for things that move) My skillset pretty much goes from low-level assembly code up to writing simple web apps, so I was generally able to handle anything thrown at me. I'm also pretty good with creating documentation, understanding the business and built up my domain knowledge at any company I've worked for. In this field, the more you know, the more valuable you become because it tends to require a wide range of expertise. IME, the people who have done well are always generalists.
- branchless 10y ago
  Yes my impression was EE would be extremely valuable, thanks for the input, no idea why HN is downvoting this reply.
taneq 10y ago
Generally not, compared with the difficulty of it. (And the first dozen posts are all bang on the money, and you have to deal with all of those things AT ONCE.) You have to be a multidisciplinary wizard and you will never get paid what some VBScripter gets paid at $bank. When you're developing a product, hardware iterations take most of the budget. As 'the software guy' your job is to be handed a piece of hardware and some vague requirements, and to make it work the way the end user (who you probably never get to meet) expects it to. The product will already be over budget and behind schedule, so you don't get funding and you're probably already late in delivering the product (no, your deadline does not move due to this). It's hard to find embedded work because the people who 'need a software guy' for their hardware product don't know any software developers so you have to be lucky to meet potential employers. That said, there is opportunity for some COBOL-style big bucks later on, when suddenly they need to make another production run of the product you worked on back in the day, and they want a few tweaks, and you're the only person on the planet who has the faintest clue how to build the software and program the hardware, so you get to pull your hair out all over again but this time for a more reasonable wage.

bsder 10y ago

> Is embedded work, in general, well paid? The trick is breadth of knowledge. If you can just program a microcontroller, you've got a lot of competition. If you can program a microcontroller AND an FPGA, your competition dropped by orders of magnitude (this is the biggest step and probably the easiest to tack on--Verilog isn't that hard but you WILL foul up until you get race conditions and concurrency properly beaten into your head--do everything synchronously and synchronizers are your friends). If you can program a microcontroller, program an FPGA, AND design the board--you are in rare company. If you are good at debugging these boards, people will worship you as a god. If you have domain knowledge on top of that, you should be starting a company. > And is it relatively easy to get new work once you've broken into it? Well, it's networking like anything else. If you've been doing it for 10 years, things seem to just drop into your lap. Otherwise, you have to beat the bushes. However, if you do a good job, the good people around will notice quickly. And those good people are often at capacity so they will throw stuff over to you. Obviously, being near a tech hub helps. > I'm under the impression that some "not very visible" work is well paid and not going away any time soon. The problem with "not very visible" is that it also means "executive level may not appreciate it". I've seen medical device companies trying very hard to get rid of the single person who actually understands their hardware. > Or is this like being at the edge of new/exotic web 2.0 where you are continually looking for the next job, re-learning tech over and over. No and yes. :) ARM is dominating the embedded space currently. So, especially at the Cortex M end of the spectrum, the base programming environment looks pretty much the same. This hasn't changed for quite a lot of years. In addition, 8-bit development is mostly going away. The delta between an 8-bit micro and a 32-bit micro is now so small that it makes no sense to use anything other than 32-bits unless you have a very specific use case. For FPGA, the tools are similarly stable over long time frames. The peripherals, on the other hand, completely differ from manufacturer to manufacturer. And have bugs from revision to revision. So, that is like learning stuff over and over :( However, what the peripheral are supposed to DO is stable. Once you understand that, you will be very good at ferreting out the small differences and your life gets some easier. > If anyone has any resources to job sites or further articles I'd love to read them. You can read a lot, but doing is better. Go get a Nordic BLE development kit for $39 and build something. http://www.digikey.com/product-detail/en/nordic-semiconductor-asa/NRF52-DK/1490-1053-ND/5773879 http://www.digikey.com/product-detail/en/nordic-semiconducto...

branchless 10y ago
Thanks, this is by far the most comprehensive reply I've ever had on HN. I appreciate you taking the time, I'll look into your suggestions. I actually have an atmega 8515 but I've been a little distracted learning the finer (if that's the right word) points of c++ recently. Do you think the 8515 is "appropriate" ?
- kbart 10y ago
  I'm not the original poster, but starting with bare MCU might be too tricky at first. A better approach imho would be to get some of many available kits (i.e. Beaglebone) and try to make it live from scratch: don't use prepared bootloader/OS, but try to build everything yourself. Setting up a toolchain, grasping cross-compiling, downloading and debugging "doesn't start" kind of problems are the key and every day problems in embedded programing. When you are familiar with the build-download-debug process, get into peripherals: GPIO, UART, SPI, memory interfaces etc. After this, you should have enough experience and spent enough time on reading obscure datasheets to start designing your first, simple boards. Sure, you also need some electronics knowledge to read, understand and layout schematics, but provided you don't get into RF or analog electronics, it's not too difficult.
  - bsder 10y ago
    I'm going to disagree here about the Beaglebone (or RPi) first. There is a LOT of complexity in those that simply isn't in the Cortex-M (especially M0) series. For example, try to figure out what the maximum bit banging rate is on a Beaglebone Black. Good luck. Getting up and running on an Eclipse/ARM/Segger toolchain sucks. No doubt. But you have to chew through it. After that, it's about 3 lines to get an LED to blink.

HeyLaughingBoy 10y ago

I don't think there's a general answer. From what I could see pay was on par with most enterprise development. Well above basic web stuff though. Like the other poster said, if all you do is code, then your position is pretty weak. I have an EE background and I'm pretty good with mechanical things, so I could debug the electronics and figure out issues with mechanisms, etc. (most of my programming career has involved writing code for things that move) My skillset pretty much goes from low-level assembly code up to writing simple web apps, so I was generally able to handle anything thrown at me. I'm also pretty good with creating documentation, understanding the business and built up my domain knowledge at any company I've worked for. In this field, the more you know, the more valuable you become because it tends to require a wide range of expertise. IME, the people who have done well are always generalists.

branchless 10y ago
Yes my impression was EE would be extremely valuable, thanks for the input, no idea why HN is downvoting this reply.

taneq 10y ago

Generally not, compared with the difficulty of it. (And the first dozen posts are all bang on the money, and you have to deal with all of those things AT ONCE.) You have to be a multidisciplinary wizard and you will never get paid what some VBScripter gets paid at $bank. When you're developing a product, hardware iterations take most of the budget. As 'the software guy' your job is to be handed a piece of hardware and some vague requirements, and to make it work the way the end user (who you probably never get to meet) expects it to. The product will already be over budget and behind schedule, so you don't get funding and you're probably already late in delivering the product (no, your deadline does not move due to this). It's hard to find embedded work because the people who 'need a software guy' for their hardware product don't know any software developers so you have to be lucky to meet potential employers. That said, there is opportunity for some COBOL-style big bucks later on, when suddenly they need to make another production run of the product you worked on back in the day, and they want a few tweaks, and you're the only person on the planet who has the faintest clue how to build the software and program the hardware, so you get to pull your hair out all over again but this time for a more reasonable wage.