By 2008 China expects to graduate some 600 billion EEs each year, starting work for an average salary of eight Yuan per day, or about 12 cents an hour. They'll be Six Sigma black belts and highly skilled at TSP, XP, TDD, SCRUM, FDD and will join CMMI Level 5 corporations.
Even today, India's 250 million software people create most new high-tech products, from televisions to the space shuttle. Lockheed Martin announced that it's sending all F-22 development to that country, which is expected to reduce the aircraft's current cost of $330 million each to about a buck fifty-seven. Or $100,000 gassed up.
[STOP! Don't hit that email button! I'm getting slammed with emails from people disputing the numbers above. It's a joke, folks, an obvious (I thought) exaggeration to make a point and hopefully provoke a grin.]
Clearly Western engineers are doomed.
Or are we?
An article on Today's Engineer Online reports that, though EE employment has declined in the last couple of years, so has unemployment.1 They believe this odd finding suggests large numbers of engineers are changing careers. You, too, can leverage years of college calculus and electromagnetics into a rewarding career in the food service or in real estate industry.
In its 2004 unemployment survey the IEEE reported offshoring was the number two reason for engineering job losses.2 That's a catchy headline, but 62% were given the boot because of a business downturn. Only 15% were victims of offshoring.
The November issue of the Communications of the ACM claims college computer science enrollments are down 60% in the last four years.3 Of the remainder, 35% to 50% switched majors to a nontechnical field.
Yet according to an article in the Silicon Valley/San Jose Business Journal, the California Employment Development Department thinks 43% more software developers will be needed by 2012.4
This data suggests there's a shortage of engineers. Time to ramp up those H1-B visas, congresspeople, to keep America competitive.
Oops. Intel's Craig Barrett thinks otherwise: "Companies can still form in Silicon Valley and be competitive around the world," he said. "It's just that they are not going to create jobs in Silicon Valley."
But in January, The New York Times reported an increase in hiring in the Valley.5 The tiny 0.2% uptick represents only 2,000 jobs, but it's hopeful.
Meanwhile, industry publications print helpful how-to articles for companies trying to export engineering jobs. Ironically, IEEE Computer, funded primarily by dues from the engineers whose jobs are at stake, ran "Successfully Outsourcing Embedded Software Development" in January.6 Do you feel you're getting your money's worth from your IEEE dues?
Are we doomed? Of course not. There will always be a healthy demand for engineers in this country. If college enrollments really are declining then the demand will increase. Salaries will go up. Now that the last of the debris from the dot-com implosion has been cleared away I'm seeing an upswing in job openings.
Are we doomed? Of course we are. Business is changing faster than it has at any time in history. Though offshoring is currently only a small facet of this industry, it will expand till it becomes an essential fabric of firmware development. CEOs have a fiduciary responsibility, by law, to maximize shareholder value. They're required to cut costs if possible, and an army of low-wage very smart people are ready to help with that task.
It sure would be nice if CEOs would start cutting at the top, though.
Offshoring is but a symptom of the changes awaiting us as we're faced with impossible and conflicting forces that will drive engineering in new directions. Time to market is heading to zero while firmware size skyrockets. Debugging tools have taken a giant leap backwards (for example, the in-circuit emulator being replaced by much less capable background debug modules) yet safety-critical applications demand nearly perfect code.
In times of stress great new opportunities appear. I'm convinced we're approaching an inflection point that will benefit engineers attuned to the new realities of the business world.
Self-help
Get some self-help books to guide your career decisions in the right direction, like Chad Fowler's My Job Went to India (And All I Got Was This Lousy Book).7 Oddly, this book only occasionally addresses the offshoring debate and just marginally touches on Indian developers. Fowler notes that some number of jobs will go to low-cost countries but then moves on without debating the pros and cons of offshoring. Though the title sounds somewhat hysterical he calmly (and rightly, in my opinion) notes the trends and implications.
Instead of being yet another rant, the book is a useful guide to taking charge of your career. In the olden days of lifetime employment one could reasonably rely on the company to steer you in the right direction. No more.
The book's 185 pages read like a James Patterson novel--short, punchy chapters a page or three long. Each ends with a homework exercise designed to make you take charge of your career today. Some are thoughtful; others, like "learn to type," seem oddly out-of-place for advice targeted specifically at software developers, who presumably already pound a keyboard at 80 WPM or more.
Fowler believes in investing in one's career, making a continuous effort to grow and improve. He feels that the only way to combat offshoring is to become both a much better programmer and a much broader employee, one who fulfills greater business needs than simply banging out code.
You'll find some of the book trite, some silly, but the author offers plenty of sound advice.
The new you
Today's engineering landscape is vastly different than that of a decade ago. Tomorrow's will be unrecognizable.
Increasing product complexity coupled with shrinking time-to-market windows means that firmware development will inevitably use larger and more geographically diverse teams. Since pressure to drive costs down will be to some extent mitigated by management's desire to ship something soon, there will always be a healthy market for engineers in both the first and the third world. Developers will work hand-in-virtual-hand with other team members spread all over the globe. While some folks will manage reasonable careers cranking code (probably for salaries that make a Wal-Mart executive cackle in glee) stellar opportunities exist for a new kind of engineer.
Consider the facts: the declining number of EEs means firmware people who "get" the hardware will be in high demand. If your reaction to some problem is to call the hardware guy, you'll be pigeonholed as one with only moderate abilities. You don't need to be an ASIC designer, but if you learn enough about the hardware to troubleshoot common problems, if you can go to the EEs and say "this is the problem," your value to the company will go up considerably. When bad times come—and they always do—the boss will first dump the narrowly focused individuals who constantly require support from other team members.
To future-proof your career, get a good grounding in the hardware.
Shorter schedules and the demand for high-security, reliable systems means our current development practices have to change. We know today how to develop products one to two orders of magnitude less buggy than average code—with the same or better productivity. So of course we choose to ignore these approaches.
As professional software developers we're, well, not professional if we remain ignorant about these better methods. Are you familiar with design by contract?8 Correctness by construction?9 These techniques (which, by the way, scale to both big up-front design and some agile methods) yield dramatically reduced bug rates. On the C-130J aircraft program Correctness by construction yielded code 10 times less buggy than the already fabulous stuff produced to the highest U.S. avionics standard.10 Yet the development costs were half that that typical for non–safety-critical code.
Wow.
Have you gone through the Personal Software Process?11 Though formal training is available, more than a few engineers have slogged through the tough but effective A Discipline for Software Engineering by Watts Humphrey on their own.12 It, too, results in much better code, more predictable schedules, and a way to track one's performance.
To future-proof your career master effective alternative development strategies.
Touch + tech
Better development processes are essential but not enough. The successful highly paid engineer will understand that this is the communications age. Oddly, we're the engineers who invented this remarkable global telecom and datacom net, yet many of us have nothing to say.
Watch teenagers to see the future. They're communications junkies, needing a cellphone, instant message, e-mail, text message, and Blackberry fix every few seconds. Long ago business guru Tom Peters predicted that high tech would be accompanied by "high touch;" using technology to help us work closely and personally with people.
Your boss likely doesn't know as much about creating C code as you do; she's probably equally unfamiliar with the details of programming 50 control registers in just one of your product's peripherals. She relies on you to translate the company's business needs into a pile of ones and zeroes. The CEO is even more clueless about technology issues.
Great, irreplaceable engineers will be expert communicators. They'll be able to discuss system design with the engineering team in Boise, structs and enums with those cranking code in China or India, feature sets and benefits with the customer, and profit and loss with the head office. That means we engineers will be techies, salesmen, and management consultants.
To future-proof your career learn the language of business. An MBA or similar is not a bad idea.
Two thousand years ago Marcus Vitruvius Pollio wrote "De Architectura," the oldest-known engineering book. Apparently the author was a great engineer and a terrible writer, as one historian noted: "He writes in atrocious Latin, but he knows his business." Another wrote: "He has all the marks of one unused to composition, to whom writing is a painful task."
Things haven't changed much. Instead of chiseling bad Latin onto blocks of stone we type barely comprehensible English into a computer. Our written reports, e-mail, and web postings reflect on our ability to think clearly. Since so few engineers write well, those who create literate and insightful written reports, who can use the language to effectively bridge the communications gap between project stakeholders, will be in great demand.
To future-proof your career, learn to write well. Practice often.
Today being a good communicator also means you have to be able to present and influence. That's more than building a few pretty PowerPoint slides. It means having the confidence to stand in front of a perhaps antagonistic crowd, explain your viewpoint clearly, demonstrate the data that backs you up, and to even entertain and charm disbelievers. Tough? You bet. But imagine how valuable the CEO will find this sort of person.
There are a lot of engineers. Most are pretty good technically. Some understand how a particular technical decision affects the bottom line. Nearly none can also bring the meaning and implications of a bit of techie magic to people who don't know the difference between a zero and a one. As software becomes an ever-larger component of companies' revenues and strategies the demand for these stars will soar.
To future-proof your career, become a competent presenter.
Finally, to future-proof your career, network relentlessly, even when employed. No job is forever. Build a Golden Rolodex. Those people are the key to a new gig when things go wrong.
I'm suggesting you do a lot. The days of Ward Cleaver punching out of the office at exactly 5:00:00 are long gone, for better or worse. The ideal of a benevolent corporation kindly watching out for its employees' best interests lasted just a handful of years and will never return. There's only one person who can future-proof your career. You.
Rewire your profession. Prepare for the new future. Those who do will prosper. Don't, and be swept away by the flood.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com.
Endnotes:
1. Harrison, Russell. "Employment Data Paints a Disturbing Picture," IEEE Today's Engineer Online, September 2005: www.todaysengineer.org/2005/Sep/pulse.asp
Back
2. IEEE. "2004 IEEE-USA Unemployment Survey Results (11/29/2004)": www.ieeeusa.org/careers/pdf/EmploymentSurvey2004Report.pdf
Back
3. Denning, Peter. "The profession of IT, Recentering Computer Science," Communications of the ACM: November 2005, p. 15–19.
Back
4. Roberts, Timothy. "Engineering makeover seeks image upgrade," Silicon Valley/San Jose Business Journal, November 4, 2005 print edition: http://sanjose.bizjournals.com/sanjose/stories/2005/11/07/story2.html
Back
5. Flynn, Laurie. "In reversal, Silicon Valley added jobs in '05," The New York Times, January 16, 2006: http://www.nytimes.com/cnet/CNET_2100-1022_3-6027409.html Now available only through archive.
Back
6. Rottman, Joseph W. "Successfully Outsourcing Embedded Software Development," Computer, January 2006, p. 55.
Back
7. Fowler, Chad. My Job Went to India : 52 Ways to Save Your Job. The Pragmatic Programmers, September 2005: www.pragmaticprogrammer.com/titles/mjwti/
Back
8. Eiffel Software has a good web page on its trademarked version, Design by Contract: http://archive.eiffel.com/doc/manuals/technology/contract/
Back
9. Chapman, Roderick and Martin Croxford. "Correctness by Construction: A Manifesto for High-Integrity Software," Crosstalk, December 2005: www.stsc.hill.af.mil/crosstalk/2005/12/0512CroxfordChapman.html
Back
10. Amey, Peter. "Logic versus Magic in Critical Systems," Springer-Verlag. Published in Lecture Notes in Computer Science 2043, D Craeynest and A Strohmeier (Eds.): Reliable Software Technologies—Ada-Europe 2001, 6th Ada-Europe International Conference, Leuven, Belgium, May 14–18, 2001: http://praxis-his.com/pdfs/Logic_versus_magic.pdf
Back
11. Software Engineering Institute. "The Team Software Process (TSP) and the Personal Software Process (PSP)," Carnegie Mellon University, 2006: www.sei.cmu.edu/tsp
Back
12. Humphrey, Watts. A Discipline for Software Engineering. Addison-Wesley, NY NY: 1995.
Back
Reader Response
AMEN!
- Andy Kunz
Sr. Firmware Engineer
Transistor Devices
East Hanover, NJ
Excellent article, and one I can relate to. After having been employed by a major electronics firm for 21 years, I am now starting up my own business where I need to develop myself in all six future-proofing areas Jack mentioned. The hardest one I'm working on now is to develop my writing skills. An online college-level technical writing class is helping. After that, I'll sign up for Relentless Networking 101.
-Gary Stringham
I tend to disagree with Jack.
Honing oneself to near perfection with more technical skills (of whether SW, HW or FW) is only headed towards investing in obsoletion. Jack's examples of broadening one's skill bases from FW to HW and ASIC design assumes that there are engineering projects with de facto presence in the U.S.--while actually, entire engineering OPs and divisions are being shifted to India. If Jack has not taken notice, it is not just SW that is offshored, but also FW, HW design, RTL, circuit design, and validation--the whole nine yards of embedded development.
This is especially true of embedded- and consumer-oriented devices, where competition is intense and margins are whittle away very quickly. Ditto for all standards based communications products. Better programming methodologies are the last and the least in the minds of the CEOs whose primary goal is cost cutting through offshoring.
The only hope for the "pure" engineer is to engage in location-bound engineering products and services--defense, strategic, govt and heaving engineering come to mind.
The impure way is to switch to an MBA.
- Ram Kandrevula
Santa Clara, CA
It is important to be aware of changes around you however subtle. We also have to be in touch not only with the people concerned with our department but also other departments.
Above all as Jack mentions in this article developing your presentation and communication skills should be included in your continuous learning process. Good luck and God bless.
- Anil Varghese
Sr. Tech Engineer
Yosun Singapore Pte. Ltd.
India
I couldn't agree more with your advice on how to future-proof your career.
I myself learned electronics in the air force, programming at community college, and after 12 years as an embedded engineer picked up a journalism degree, with a concentration in advertising.
That about fits your description neatly.
Why did I do it? Because, like you, I can see the writing on the wall.
The lines between company departments are breaking down, and with that comes the demise of the extreme specialist.
- Craig Pataky
Software Engineer and all-round guy
Oregon Embedded Development
Washington, DC
I am an old bloke with a EE degree from the early '70s. I did
a lot of stuff (diversified) and then arrived in SIlicon Valley
in 1981. I never had trouble getting work as, unlike many
US trained Engineers, I could do a lot of things to glue
a project together. I state this again: I was hired because
I was diversified. Trained diversified. Practiced diversified.
I am home again. Due to the tech wreck there are few jobs for
product developers. Now I am doing Product Management for a
while. Done Project Management. Done training and even now
I am using OO tools to document a business evaluation and improvement
project.
I have a mate, a very good software developer and businessman
(and a US born Engineer), who is starting to design FPGA's.
The tools are good these days. He can cut a reasonable FPGA.
It may have logic in there that is a long way off being optimized
but what the heck! He cannot use the all the space in
the thing anyway.
So you software guys. Cutting code is low level tasks now. Yes,
low level. Most times you can write awful code and the compiler
fixes it up "real nice like". I write high school code.
Code cutters hate me for it. But in general it does not matter
since the product fails most times because it is not specified
correctly or it is designed and tested so poorly that
it fails due to buggy operation or too high support cost.
I have seen too many "real good hardware and software implementations"
that were put in the shredder. On the other hand
there are enough other products that got the marketing analysis
right but were developed by "clueless jerks" who did terrible
things in hardware and software but made successful products
that met customers needs.
Jack is better than right again.
Lassies and Laddie's, nearly all of you will have to diversify
to survive. Please follow the lead from us, the little countries
of the OECD. You WILL need to be able to UNDERSTAND the
whole process of product development and the effect that
your prime role has in its success. Communicating with users,
managers and the customer are the key.
- Lee Eldridge
Australia
600 BILLION EEs??? I didn't know this solar system has that
many people. :)
- Peter H.
From more of a hardware oriented perspective, John Cooley's ESNUG website presents an interesting engineering career picture that includes comments from leading EDA company insiders.
www.deepchip.com/gadfly/gad031406.html.
- Bill Mills
Redondo Beach, CA
Thanks for the article. I'm glad our profession has someone like you out there acting as a sentinel. Also, your comments about the IEEE are very telling.
I've been a member of IEEE for many years; so I feel entitled to make that comment. Like you're saying; with every door that shuts, another one opens. I'm finding new opportunities everyday. If people really think that engineering is locked up by offshoring, then they really don't know a lot about the profession.
- John C. Westmoreland, P.E.
Become a member to take advantage of more features, like commenting and voting.
Register or sign in today!