Where Are Tomorrow's Embedded Developers? 245
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.'"
There are not many Klingon programmers graduating (Score:5, Interesting)
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.
Re:Used to, still could, but probably won't (Score:2, Interesting)
Re:Digipen (Score:3, Interesting)
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).
Lack of coursework in colleges (Score:2, Interesting)
Re:College Classes (Score:2, Interesting)
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 (Score:5, Interesting)
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 [theptrgroup.com]. 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 (Score:3, Interesting)
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:
Re:College Classes (Score:4, Interesting)
Looking at the wrong major... (Score:3, Interesting)
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.
Re:College Classes (Score:3, Interesting)
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.
OMG, so true ... (Score:3, Interesting)
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.