Where Are Tomorrow's Embedded Developers?

An anonymous reader writes "In a similar vein to the previous discussion about the New York professors taking Java to task for damaging Computer Science education, Mike Anderson of the PTR group wonders why it's so hard to find good embedded developers these days. 'As for today's CS programs, it seems that long gone are the computer architecture classes, writing code in assembly language (or even C at this point) and engineering software economics. In fact, a large number of CS majors apparently believe that everything can be implemented in a virtual machine and that both memory and [CPU] cycles are infinite.'"

Comments

College Classes

[kmsigel]

I'm in my late 30s and have been doing embedded development since college. Back then we built finite state machines in PALs and complete embedded systems using microsequencers and UV eraseable ROMs. We both built (hand wired) and programmed the systems from scratch. Doing that gives you a very good appreciation for what's going on. That kind of stuff just isn't done much anymore in college. From what I can see, there aren't many good embedded programmers more than a few years younger than me. It looks like good embedded programmers (whatever their age) will be in demand and well paid for many years to come. :)

Re:College Classes

[jim.hansson]

I wonder is this a problem in USA only or is the trend spreading to other countries?
here in Sweden it does not seem as there should be any bigger shortage of embedded developers than other types.
Still embedded development are a lot more fun than doing some ordinary desktop app, or even worse webapps

Re:College Classes

[adpowers]

Really? Cause I seem to remember creating FSMs using PALs just last year in my undergraduate CS program (in a required 300 level class). We also had a class where we put together a microprocessor, put it on an FPGA, and wrote low level code to run on it.

A number of my friends took the hardware capstone where you did even more of this type of work. It still goes on, perhaps you just aren't looking in the right place? It seems the CE and EE folks take more embedded classes than CS students, so that is where you should look. CS is a huge field, and not everyone is going to follow the story's author's preference of study.

Re:College Classes

[secondstory756]

I have to agree. I'm a computer engineer at the University of Illinois. It's the computer engineers that are doing the lower level development. I've had extensive systems programming (in assembly and c) and every CE here makes both an OS and a 16-bit processor. CS students don't see that stuff unless they elect to take it.

I haven't seen a speck of java (or even c++) in my ECE (Electrical & computer engineering) courses, but that's all I've used in my CS courses. Furthermore, I have a lot of friends in CS that know very little about what the actual computers are doing on a bitwise level. (I had to help one of them work on bit masking last weekend.)

If you're looking for embedded people don't look at CS, look at CE.

Re:College Classes

[turbidostato]

"It's the computer engineers that are doing the lower level development."

Of course!

"a large number of CS majors apparently believe that [...] both memory and [CPU] cycles are infinite.'"

That's the difference between a computer ENGINEER and a computer SCIENTIST. After all, complete turing machines *do* have infinite memory and cpu cycles. /me fastly ducks away

Re:College Classes

[thegrassyknowl]

CS courses are supposed to be about computer science. If I wanted to learn how to make a webpage I'd just get a good reference and hack at it (or take a summer class).

I don't meet many CS graduates with any grasp on computer fundamentals. I was actually arguing with someone last week about why Java is the WRONG language to use for a once-off program to edit a column in a database. His response was "but Java is common and everyone knows it AND it's a database language, who knows Perl?". Shows how much he knows - a simple Perl script (or $DEITY help us a Bash script) that read, modified and updated each row according to the desired (not-quite-trivial) operation would have sufficed. The same CS graduate didn't get the concept of an inode-based file system and I thought that was fairly basic CS knowledge.

I've had engineers come to me and develop entire programs in Java then try and download their class file to a DSP. They sit there dazed wondering why the ICD tools won't accept their class file.

I've had other engineers develop entire swarths of MFC and DirectX code to do DSP (use GUI and Graph Editors to make program that just runs directx plugins to do "dsp" and not write a single line of C++ themselves) then wonder why they can't get the ICD to load their exe file. I even watched this one guy copy the exe to DSP memory and try and set the instruction pointer to the first word of it.

I met one CE grad who was tasked with writing a one-off sort. She took three days, spent most of it in books and on the phone to friends trying to work it out. This was a one-off sort that would have been run overnight on a production machine; they decided to change the data ordering. The simplest bubble sort in a 10 line C file would have solved the problem and met the requirements. She tried to write the most highly optimal sort algorithm (fine, I guess) but she couldn't even make it work. In the end I hacked together about 100 lines of code to read the data on stdin, sort it and write it to stdout. Wasn't hard. Didn't use too much memory and finished in about 30 minutes (well within the overnight parameter).

Of course, these engineers had one thing in common. Like many schools, they took their programming and algorithms classes in the CS faculty because the schools were trying to save money. The CS schools are doing their best to churn out people who know all the buzzword technologies (Java, HTML, AJAX, etc) but have little marketable skill. CS courses seem mostly a left-over from the dot bomb era.

I've yet to meet a CS grad who properly understands the difference between TCP, UDP and IP. I haven't met one who knows anything about algorithm analysis (or big O notation; I think they were all out getting a lot of Big-O's instead of studying).

The best computer programmers I've met are electronic engineers with specialty in microprocessor systems hardware and maths/physics people. They seem to get programming much more than the CS-types.

Re:College Classes

[StarvingSE]

Of course, these engineers had one thing in common. Like many schools, they took their programming and algorithms classes in the CS faculty because the schools were trying to save money. The CS schools are doing their best to churn out people who know all the buzzword technologies (Java, HTML, AJAX, etc) but have little marketable skill. CS courses seem mostly a left-over from the dot bomb era.

I've yet to meet a CS grad who properly understands the difference between TCP, UDP and IP. I haven't met one who knows anything about algorithm analysis (or big O notation; I think they were all out getting a lot of Big-O's instead of studying).

If you've met anyone that has a CS degree and gives you a blank stare when you mention big-O notation, then they either failed out or graduated from Rafael Alonzo's I.T.F. Technical Computer Institute.

And, let's be realistic here. Concepts such as TCP, UDP, etc are advanced programming topics and are either taught as electives, or in post-graduate classes.

Computer Science involves a lot of math classes, and then programming classes that implement those mathematical ideas in code. Yes, the school will offer classes like HTML and AJAX, but these are electives used to broaden a student's understanding of the buzzword technology du jour (in an effort to make those students more marketable after graduation). Your post just makes you sound ignorant about what is actually offered in a *good* CS department.

Re:College Classes

[xenocide2]

The trouble is, a great deal of CS graduates feel that Computer Science is the fastest way not to being an engineer or scientist, but to becoming a programmer. A disturbing number of my fellow students avoid classes perceived to be lots of work, which is exactly what this guy is asking for. Debugging embedded hardware is not easy or simple, and requires massive amounts of attention to detail to get anything to work at all.

Anderson's question might have been equivalent to "where are all the graphics programmers?" or "where are all the operating systems programmers?" but for one thing: this article presupposes a shortage to convince readers they need embedded skills, because PTR offers training in Linux embedded system programming. Frankly, the more important skill in embedded systems isn't pipeline stalls, but the Chinese language; most of the work has gone to where the embedded hardware is made: East Asia. Case in point: the only work this guy appears to get is defense contracting, where clients can't outsource / offshore the work.

Re:College Classes

[xenocide2]

This is what always bothers me about these "shortages" complaints: why do you feel the sample population you've encountered is a valid cross section? If you are a hiring manager, it could be that your HR dept. is failing you. Or it could be that your company's pay scales immediately dissuades talented programmers from applying. Can anyone honestly say they've accurately surveyed the graduating class of '0x?

Re:College Classes

[smellotron]

Some schools might offer good CS courses but the majority of grads I deal with know nothing more than buzzword garbage, and I am not alone in my views; I regularly hear associates complain that they can't get a CS person who knows their ass from an infinite loop.

I hear you, man. I am a recent graduate myself (UIUC), so I see this from the other side. Our program is pretty good compared to most things that I've heard on the net (and various people I've met from CMU/MIT/Standford/...), but a couple of things to point out:

• There were a good deal of idiotic undergrad slackers. I wouldn't trust these people to do anything except ride the wave of someone else's success. These were the ones who didn't understand why we used OCaml for one class here, or were expected to use Java at the drop of a hat (gasp, no hand-holding?).
• There were a few people that were adept at being thrown into a computery environment and just learning. This definitely isn't CS, but these people could set up subversion/trac/apache/whatnot on their home servers, or build a decent Makefile—in short, effective tools users.
• There were a few people (most of which ended up in grad school) who could really nail algorithms and "true" CS topics. Even though this is the heart of the program, I've met so many people who only came out with a weak grasp of the theory.
• There were a good amount of people who were capable of programming. Most of the good "true CS" people also fell into this category, since programming is the natural way to express an algorithm. These people showed up a lot in the higher level subject-matter courses, such as networking (yes, TCP/UDP/IP among other things), graphics (OpenGL, raytracing, general linear algebra), etc. Due to the nature of the program, there's not much opportunity for a lot of these types of classes unless you come in with a lot of AP credit or you stay an extra year. This set of people is probably the class of people that you've seen at interviews that seem like they have an OK head on their shoulder, but still don't seem to have a clue about developing software (which is OK, because it's a CS degree, not a 2-year trade school).
• No one touched assembly outside of the required MIPS coursework. My friends in Computer Engineering did a lot of low-level programming (mostly on x86), but the CS program only covered the bare minimum to understand the physics/logic of a computer, let alone be proficient in handling it.
• The only professor who cared about anything remotely buzzwordish was Ralph Johnson; that was essentially part of is role, since UIUC doesn't have a separate software engineering discipline. Even still, most of his focus was around architecture and decent real-world software design, rather than AJAX/Ruby/whatnot. Most of the people in his courses were the ones that had relevant software-development experience and would be excellent hires out of school... but they're still a different beast from the research-oriented curriculum that the rest of the school pushes.

Re:College Classes

[DaveV1.0]

They will come from people who bother to learn assembly and C and experiment on their own and can show their worth.

Re:College Classes

[Shinobi]

It is a problem here in Sweden too. Many of the colleges and uni's spend too much time teaching high-level stuff, and just a bare minimum on low-level. So what we get out here is people who need a ton of libraries to get anything done, who believe that Getting It Right The First Time is a waste, it's better to patch early and patch often(Rather anathema to embedded work, don't you think?) and who believe that if something doesn't quite work with the hardware available, you can just get MORE hardware....

And these guys were from KTH :/

Had to spend several hours teaching them about the realities of quite a few embedded projects. Such as the fact that the hardware we were targeting had a limitation of 256kB of RAM, of which 192kB needed to be available for data+processing, so no, you couldn't squeeze SSH+auto-patcher and some other stuff in there. Also, these were supposed to stand outside, in severe temperatures, so there were limits on the hardware itself. And, they were to be placed all over the country, to collect and pre-process weather and climate data. So yeah, we HAD to get it done right the first time... unless they wanted to travel around and handle reflashing manually?

Re:College Classes

[Z00L00K]

Not too bad to start with Java, but it's not really close to the hardware at all.

A starting language shall not be too unforgiving, and there is a small advantage with Java, and it is that it's very C-like. At least as long as you don't use a lot of built-in classes. If a student is limited to the "java.lang" package and isn't allowed to use anything else from the Java library it can actually provide a good learning base. But I assume that many teachers aren't into this... The really great disadvantage with Java is that the programmer relies completely on the garbage collector.

The "not to worry too much about memory or speed" is a REALLY stupid opinion. Hardware is good today in the upper-end systems, but even if the speed is doubled every 18 months or so the optimization of a program can improve speed a lot more. It's more a question of several magnitudes than percent if you find the right spot to optimize.

Learning C is really a good thing - it's small, efficient and fast. Of course - you can do stupid things in C too, but it will bite back pretty fast!

A really good course would be if students were to build their own computers and program them. Not too hard considering the components available today compared to the components available in the 80's when I built my first computer from a Z80, 2716, 6116 and a lot of TTL chips and a few other chips. I still have it, but I'm not sure if I can make it work anymore. Programmed completely in assembly.

Today it would have been either some kind of 8051 (like the nRF24E1) or an ARM. Neither are too bad, and the poison of choice depends more on power consumption versus performance. The only disadvantage with modern processors are that they aren't usually DIL packaged, which means that they are a lot trickier to use when throwing together something just for learning.

Re:College Classes

[TheGeneration]

I'm not willing to create things that have the sole purpose of killing other human beings. Sorry.

In addition, while I'd love to continue advancing my CS skills it has become obvious to me that the only way to make real money in our society is to get a degree of a fake science like economics/business in the form of an MBA. That way you can bullshit like a pro, cheat shareholders out of millions of dollars (maybe even billions!) and provide absolutely no value to anybody but yourself.

Well done America. We've come so far. The people that can actually DO stuff are second rate to the people who are just professional figureheads.

Used to, still could, but probably won't

[kninja]

Used to be an embedded developer for devices, but then I got interested in Ruby on Rails (it was much more fun).

I think there are probably more than a few people out there that have the skills, but have been moved into other paths by market forces. They will come back if you pay them enough, but that is unlikely to happen, so they will probably stay where they are.

Re:Used to, still could, but probably won't

[BotnetZombie]

Not only are there probably more than a few people that already have the skills, but I also think that it isn't necessarily too difficult to get people into the mindset needed. I learned programming in C++ but without any real concern for efficiency or memory usage. On a job much later on, I had to write a browser for very limited j2me devices (total memory of 64KB). The browser downloaded, parsed a subset of xhtml, displayed (including images), navigated according to user action and even accepted text input (of course someone will now say that they can do the job in 1024 bytes or less). It was a total pain in the butt to write - however, having to rigorously manage the data structures, memory assigning and releasing, unrecurse functionality that is intuitively recursive in nature etc, I think that this has made me a better programmer. Even though I haven't done any embedded programming I don't think it would be too much of a problem.

Re:Used to, still could, but probably won't

[j35ter]

True!
when comparing x86,PIC or (shudder) 8051 ASM to some more modern Python programming, I dont really want to go back anymore. Even though I maintain Python code with a curses GUI Yuck!

Last thing I worked on was a GPRS/GPS combo on an ARM device, which was quite fun.

Why such a long prelude? Well, I just cant find serious employment on the field of embedded devices in Eastern Europe. Most guys who need a developer are of the type with "A good Idea" and hiring a dumbass to do the work; you just cant feed a family from those guys payments. So, I'll just stick to my Python stuff and keep integrating some Brainfuck code, just so they cant fire me anytime soon.

And at night I dream of indirect addressing, C pointers and interrupt vectors...

There are not many Klingon programmers graduating

[arivanov]

The profession has become domesticated.

The new graduates are uncomfortable with: "Klingon multitasking systems do not support "time-sharing". When a Klingon program wants to run, it challenges the scheduler in hand-to-hand combat and owns the machine." They have to use java, schedulers, vm protection, etc.

On a more serious note, to do real embedded programming you need to know data representation in and out because you tend to manipulate your data directly, no band-aids allowed. Until the embedded systems will support band-aids as used in todays college it will be a profession for the myopic geeks with grey pony-tails or the ones who are way on their way to well developed pattern boldness.

I've Heard of That Machine!

[chromatic]

In fact, a large number of CS majors apparently believe that everything can be implemented in a virtual machine and that both memory and [CPU] cycles are infinite.

Good for them; Alan Turing believed it too.

Re:I've Heard of That Machine!

[nogginthenog]

He was right. Until Apple came along.

Eh.

[Mongoose Disciple]

I'm neither surprised by this nor do I necessarily find it something to get up in arms about.

There's not really time in a 4 year degree (well, along with all the other crap that goes into it) to teach someone the kinds of things you need to know to be a good business application developer and to teach someone the kinds of things you need to know to be a good embedded applications developer.

A good embedded developer needs experience with languages that run "close to the metal" of the machine, needs to know how to manage memory, needs to know how the machine architecture works, needs to know how to perform optimizations within that world, etc.

A good business applications developer needs experience with languages that abstract or hide a lot of the above details in order to let them focus on business logic, needs to know a decent amount about databases, needs to know about software architecture and design patterns, needs to know about networking, generally needs to know something about UI design, etc.

Yes, there's some overlap.

Speaking as someone with a college education emphasizing the former and a career emphasizing the latter, I'm not convinced this is a terrible thing. There are a lot more business style applications that need writing in the world than embedded applications. That specialization and the need for it I don't see going away any time soon, but it's the exception rather than the rule, and I'm not convinced there's something holier about understanding the guts of the machine than in understanding how to design a complex system for extensibility, maintainability, high availability, or whatever best suits the project.

The problem isn't virtual machines

[PhrostyMcByte]

The reason for Java/C#'s popularity isn't because of the VM, it's because of the huge accompanying frameworks that allow for rapid development which is in most cases much more important than efficient cpu/memory usage these days. Build one of these frameworks for C/C++ and you will find it much easier to compete with newer langs.

how many embedded developers are needed?

[trb]

I'm an old school UNIX hacker, I worked at Bell Labs in the '70's. These days I hack software that controls robots used for rehab of stroke patients. It's not exactly embedded, since the code runs on an Ubuntu/Xenomai COTS PC, but it's similar in nature to embedded hacking.

The relevant question is, how many embedded-system hackers are needed? If only .1% of job opportunities are for embedded-system hackers, then there really isn't much incentive for people to learn to hack embedded systems. If embedded hacking is a lucrative field with attractive opportunities, then hackers will follow. We saw it happen with other forms of hacking, we even saw it happen with web-page hacking. If there is a need for embedded hackers, it will be filled (guided by Adam Smith's Invisible Hand).

Re:how many embedded developers are needed?

[Shados]

Thats what I'm thinking. If you train people too much in niche fields, they're more likely to be attracted to these niche fields... And then you have a market saturation. There's a reason why everytime there's an article about IT jobs, you have a billion CS majors from Slashdot posting about how they can't find one (even though the market is currently starved and needing developers like never before): too many people trained in things that simply don't have a market for. Its nice (and even a must) to know the basics of that stuff...but god damn....

*Raises hand*

[Bugs42]

Yo. (Hopefully) future embedded software engineer right here. Currently majoring in Computer Engineering with a CompSci minor. I actually just enrolled in an embedded applications class this semester. Seems like a popular class, too - offered fairly often, and good enrollment each time from what I hear.
Even though the majority of the CS classes at my university are Java-based, there're still required architecture classes that use assembly and C, along with several EE courses. Just because many colleges are abandoning lower-level programming doesn't mean they all are.

From EE, not CS?

[SleptThroughClass]

Maybe the Electrical Engineering Department is training device programmers, not the Computer Science Department.

Re:From EE, not CS?

[Creepy Crawler]

That's right. EE are the teachers of embedded discipline. We have to know algorithms from CS, pure mathematics (enough for a minor at least), physics of light/energy/magnetism (as like math, enough for a minor), circuit design, OS design in theory and practicality, and a bunch of other things.

All together, that's what an EE is. If it's not on fire, we can program it ;D

Re:NOT Computer Scientists

[AuMatar]

You're confusing computer engineering with software engineering. Computer engineering is a hybrid software/hardware degree- depending on your electives its like minoring in EE and majoring in CS, or majoring in EE with an emphasis on digital circuits and minoring in CS. Quite frequently with tougher versions of some courses- the asm course taught to CS students at UIUC was a joke taught on simulators. By the end of the ECE asm class, we were programming video games on x86 without using external libraries.

Software engineering is a CS major with emphasis on process at good schools. At bad schools, its a watered down CS major.

Re:Digipen

[BSAtHome]

Sorry to be a cynic, but learning these things in classes does not make you an embedded developer. It is the experience in a variety of fields that makes an embedded programmer. For what it is worth, experience in the variety makes you a programmer for nearly all fields.
Let me give you a simple example; programming an interrupt service routine is probably one of the most difficult things to do the Right Way(TM). When things get smaller, it gets harder. That is where the experience kicks in and you "see" how things are supposed to work and how they hook together (and you finally know how to read data-sheets correctly). It takes years to learn this.

On the other hand, you have a good chance of getting the hang of it if you practice a lot, whereas the java-code-type-slaves probably never will understand the whole concept of a real embedded system (or what a stable program is in the first place).

Programming today's desktops?

[pdh11]

Perhaps tomorrow's embedded developers are programming today's desktops.

The desktop machine I learned to program on was an Acorn RiscPC. Later in life, I helped write the embedded firmware in the Rio Karma portable MP3 player. Rio Karma had two 90MHz ARM CPUs, 16Mbytes of RAM, and 20Gbytes of disk. That would have been one kick-ass RiscPC. If anything, programming and optimisation techniques learned on late-80s and early-90s desktops are too "embedded" for a lot of today's embedded programming.

And to those advocating hiring EE graduates for embedded programming: unless your device isn't far north of a toaster on the embeddedness scale, please also hire people with broader or higher-level software expertise for system design and architecture. It's not the same skill as squeezing one more instruction out of a loop, you find people with one skill and not the other, and any medium- or large-scale software project needs both skills (whether in the same person, or through good collaboration).

People go on about the spectrum of computing, software/assembler/logic/gates/transistors; what some don't realise is that there's a spectrum even within software. Some really good, tight, expert coders just can't see the bigger picture. I've seen medium-scale software architected by the toaster contingent: it wasn't pretty.

Peter

Re:Programming today's desktops?

[Samrobb]

Perhaps tomorrow's embedded developers are programming today's desktops.

Amen!

I more or less drifted into embedded systems work from a desktop/server background. I frequently point out to people that there's a lot of confusion about what an "embedded" system is. Some people use the term to refer to 8-bit mircocontrollers that have a whopping 4K of memory and no persistent storage. Others use the term to refer to 32-bit devices with 2-4 MB of memory and 256 MB of flash for storage. There's yet another camp that's really talking about dedicated-purpose desktop systems in a compact form factor.

The point is... there used to be a pretty well defined spectrum of what "embedded" meant. Economies of scale and new technologies have started introducing gaps into that spectrum, so there's not a single continuous spread of processors, memory and storage that qualifies as "embedded". When you can take a desktop system from 1995 and shrink it down into something like a Hammer board or a Gumstix... it may be small, it may be compact, it may be used for a dedicated purpose; but practically, you're developing on something that has massively superior capabilities when compared to the traditional idea of an embedded system. You are, in fact, developing for a desktop system - albeit a desktop system in a small package with some unusual constraints.

Re:Wouldnt'cha know..

[Rycross]

I wish I could jump on something like that too. As it is, I have a CS instead of EE, and no real embedded experience. I did want to pursue embedded systems early on, but as my first job was a .Net related job, I'm pingeon-holed into .Net jobs.

As it is, I'm looking at doing an English-teaching-in-Japan stint. I wholeheartedly agree with your sentiment.

Re:CS != Programming

[debatem1]

Yet I wonder - what is computer science without the ability to actually program the computer? Consulting.

Where are the jobs?

[Stevecrox]

As someone who finished whis BEng in Computer Engineering this year I have to ask, where are the embedded jobs?

I hunted around looking for any assembly/vhdl/c job I could find and only found one which didn't require 2 years expearence, they didn't get any message back to me until 2 months after I'd applied. I applied to roughly 35 "entry level" jobs dealing with embedded devices. None were interested because I lacked two years expearence. In the time it took the only one to get back to me I'd been contacted by a C++/Java company had a phone interview went up and been personnally interviewed and been offered the job.

The real kicker is the embedded jobs paid less, didn't mention any benifits and wanted more work out of me. I think the real issue is most companies aren't willing to invest in graduates unless its for business positions. It is difficult to get 2 years expearence when everyone demands 2 years for their entry level jobs. Which leads to a shortage since no one gets offered a embedded job so Universitys don't bother going into too much detail since 99% of their students will never use it.

Q: Where Are Tomorrow's Embedded Developers?

[dvase]

A: Sitting in Electrical Engineering classes, most likely in India.

Re:Wouldnt'cha know..

[Grishnakh]

I wish I could jump on something like that too. As it is, I have a CS instead of EE, and no real embedded experience. I did want to pursue embedded systems early on, but as my first job was a .Net related job, I'm pingeon-holed into .Net jobs.

This is a hard lesson to learn in technical/engineering jobs: be extremely careful what job you first take, because it will go a long way in determining what you do for the rest of your career. Employers always pigeon-hole people based on their previous experience. So if your last job was a .Net programming job, your next one probably will be too, because it'll be extremely difficult to convince anyone that you'll make a great Linux kernel programmer, for instance.

Re:CS != Programming

[John Courtland]

In your example, the Bus Factor is 1. Dangerous.

Lack of coursework in colleges

[Darkn3ss]

I agree, however for a much different reason. I feel that C++, *.NET, Java, etc. is the entire reason that computers need to be consistently faster and have more cores. The reason, being Object Oriented programming. The companies putting this crappy software out (all of the big names go here, with etc. at the end) don't have a clue how to make things efficient, they simply are paid to get the programs out the door as quick as possible, regardless of the performance. Embedded Engineers have to do things a completely different way. We don't have more time than perhaps 25-50 MHz to do everything that we need to accomplish, and with that time, we have to accomplish everything that a PC programmer takes for granted with an OS! I graduated as an Electronic Engineer. During my summer internships, I worked closely with an embedded developer with a background in CS. He didn't really understand the hardware like the Electronics Engineer does, but he was able to make it do what he wanted. During my time there, he convinced me to pick up a minor in CS. Because of my graduating, and my realizing after a year of attempting a CS minor, that I learned everything I needed to be an Embedded Engineer in my EE studies, so I decided to not finish up the minor and just graduate normally as an EE. Being hired on full-time, they paired me up with my original mentor's replacement. He was the type that belonged in a large team, and he would screw up his section of the project and take 3 weeks to update something that a competent person could do in 3 days, but the company didn't realize it until I started working closely with him, and went to the boss-man and told him that this fellow was holding me back. Just before he was going to get fired, he up and quit on me! I was upset, but he really didn't have a clue. Now, instead of the Embedded Engineer being the bottleneck, the Electronics Designer is the bottleneck because I work closely with him to write all of his test-software, which quickly turns into the finished product. However...there aren't that many people that I knew from college that wanted to go into this field. They all wanted to become GAME PROGRAMMERS! However, when they were seniors and job-searching, they realized that they were going to be developing desktop applications for the rest of their lives. The best programs I've seen for Embedded Engineers thus far has been at the local community colleges with tech degrees. Good luck finding them when you need them!

The industry killed the golden goose.

[GrpA]

What happened to the embedded developers? The industry got rid of them...

So if it doesn't have any now, then it really can't look elsewhere to blame anyone.

I started out as a R&D engineer working with video game technology, but essentially, it was all embedded work... I lived and breathed machine code and logic - to me software and hardware were one in the same, a symphony of technology with blurred distinction between the two. I remember sitting down with six spare GAL16v8s and a couple of low-power walkie talkies and a spare afternoon and built myself a radio modem for fun. That was the sort of work I used to do.

But there weren't many people like me - Assembly programmers were hard to find, even back in the 80s and most engineers fresh out of university just didn't know how to write real-time code in assembly language properly - didn't know how to write fault-tolerant code or build a spinlock as the starting point for your application. Didn't understand the necessity of understanding how many cycles an instruction took or how to watch for errors by measuring the duty cycle of the interrupt pin with a logic probe.

So the people who employed hardware designers (back then, if you knew machine code, you usually had a hand in the design of the system as well) found that it was difficult to get replacement engineers. As a result, they couldn't employ similar salary replacements and as old engineers got tired of being mistreated and poorly paid, they simply left and went off to do something different.

Industry responded to the lack of engineering by eliminating the need for the machine code engineers - they moved away from the embedded design with assembly to embedded design with C or even to outsourcing the product they needed, and the hardware got designed by dedicated hardware engineers.

Once again, any real skill in the area was lost as employers wouldn't pay for experience and the best engineers realised they would never be paid what they were worth, so left to do something else.

Then the industry got around this constraint by using really powerful embedded devices - basically a complete PC ready to run whatever PC programmers could write for it.

That's where we're at now. The skills left the industry because the industry wouldn't pay what they were worth... If you can make more money at another job (in my case at the time, selling PCs and Journalism) then why would you keep on developing hardware for a company that doesn't want to pay what you're worth?

I'm seeing the same thing now in Network Analysis... The world is full of network technicians (and I include many people who consider themselves engineers in that description, but don't really know how to actually measure things or understand the technology they work on) but has very few network engineers.

The solution for me? I got smart and moved to management.

I'm a lousy manager ( really, I suck at it ) but I try hard and for once, my contribution is recognised by the company I work for financially... And I have a family to look after.

Would I even go back to engineering or even embedded engineering?

I would love to go back, I really would. I can sit in front of circuits all day and build something and I enjoy every second of it, but I can't afford to do company critical work that won't feed my family or pay my bills.

So unless the industry is prepared to pay for skilled people, and by pay I mean pay them more than they would get being a manager or an accountant or even a journalist, then they will leave.

The other embedded engineers I know all did the same thing... One works on an offshore oilrig, another as a miner, one went to a call centre. One even opened a grocery business. These are all smart people and although they all miss working with electronics and embedded designs, they have families to feed too.

GrpA.

Looking at the wrong major...

[DCheesi]

If you want someone to program the low-level guts, look for a EE with some programming experience, or a Computer Engineer. CS major programs just aren't designed for that kind of work.

My company understood this ten years ago. I'm a EE major with a computer "concentration", which is typical of who we were hiring back then for programming work; we hired very few pure CS majors at the time.

When I started, we made home-grown OSes (or lived without them!) and had to really try for efficiency. Now, with modern processing power, we run Linux or an off-the-shelf RTOS, and program applications in much the same way as a PC programmer. Aside from interfacing with the peripheral hardware, we don't do much that's uniquely "embedded" anymore, and efficiency only really matters in a few specific areas. So now we can hire CS majors to do most kinds of work.

What truly time/space crunched design we do have mostly occurs in the specialty FPGAs, which are still largely the domain of EEs.

OMG, so true ...

[smcdow]

... large number of CS majors apparently believe that everything can be implemented in a virtual machine and that both memory and [CPU] cycles are infinite.

Not an embedded system, per se (more like a "headless system"), but I was involved in a project where certain aspects of the design (aspects that I had no input into) more or less assumed infinite memory and CPU.

The design itself on paper was beautiful: symmetric, orthogonal, intuitive, complete.

But when implemented, the design SUCKED because it ran like molasses on a cold day. Everything that could be done to increase its performance was tried, and in the end its performance still sucked. The whole thing had to be re-designed, and rebuilt from scratch. The original designers (C.S. degrees, of course) howled about "engineering hacks" the whole time.

The final design was uglier on paper, but it ran several orders of magnitude faster than the original.

HA!

[BrunoUsesBBEdit]

One perfectly chosen word!