Embedded Developer's Survival Guide, 2005

An anonymous reader writes "LinuxDevices has published the full keynote address delivered at the Embedded Systems Conference 2005 by Wind River CEO Ken Klein. The hardnosed speech presents a five-point action plan for device software developers who are interested in keeping their jobs -- as opposed to becoming "roadkill," as Klein puts it. The speech is decidedly short on warm fuzzies, but does offer a few practical considerations for engineer job survival in the post-recession era."

Comments

summary

[klossner]

It's all pointy-haired boss stuff. Starts out with an incorrect premise:

We [engineers] don't do development well: More than half of embedded designs are completed 3-4 months behind schedule; 24 percent -- nearly a quarter -- get cancelled

In my twenty-mumble years of engineering, pretty much every time these problems have occurred it's because the requirements were changed in mid-project. Often for excellent reasons, but the consequences do not reflect an engineering deficiency.

Don't write new code, leverage existing software. Buy it from us.

Hardly unexpected.

Re:summary

[rjshields]

It's all pointy-haired boss stuff.

Quite so. I find it hard to stomach what this guy is saying - first he purports that he is one of us engineers because he has a science degree, then says he has 500 people reporting to him and sits on a board. Which is it? Suit or techie? Suit, obviously. Then he has the gall to proclaim that it's the engineers' faults that 30-40 percent of projects fail. IMHO the following factors are most likely to cause a project to fail:

• Poorly defined requirements
• Bad project planning
• Bad project managment
• Scope creep

None of these are in the remit of the engineer. The engineer is the guy who gets the job done by doing what he is told. If the person doing the telling is useless, what chance does the project have?

What practical considerations?

[mutterc]

I actually RTFA, and didn't really see any practical considerations. It's written by a boardroom type, and so all it has is the usual management drivel we all get every day:

• If you get laid off, it must have been your own fault for not keeping up with management's desires.
• Make sure to change to whatever job management wants you to do, without complaint.
• Don't be threatened by outsourcing; learn to manage the contractors. (Because, of course, every engineers secretly longs to be a project-manager, and there will be plenty of PM jobs to soak up all the unemployed engineers...)
• The CEO's job depends on your doing your job well. (Curiously failing to mention that, if the CEO loses his job, a golden parachute kicks in, he cashes out a buttload of stock options, then finds a new job without much trouble - none of which is available to us).

It never ceases to amaze me how companies try to hire people smart enough to develop good products, and then expect them to fall for such transparently self-serving bullshit.

Maybe instead of the article's suggestion of "don't take change personally" (really!), I should learn to not take insults of my intelligence personally. If only I could mod the article "-1, Troll"...

Re:What practical considerations?

[computational super]

You forgot to mention:

• Your "technical skills", although they were the ONLY thing we looked at when we reviewed your resume and the ONLY thing we talked about in your job interview and the ONLY thing we discuss in annual reviews, are completely meaningless; we could replace you with a poorly-trained monkey because it's your "people skills" that matter. In other words, you have to be able to do my job for me AND an engineer's job. I, luckily, only have to be able to do my job. And you'll be doing that for me anyway. Plus, you'll still be the one on the unemployment line, and the years you spent doing my job will stagnate your "technical skills" so that nobody else will even look at your resume.