Older engineers are a bargain for any company. Their knowleged makes them two or three times more productive and they make fewer mistakes, because they have already tried all of the quick and dirty routes and know that they do not work.
Too many young engineers fail to tap the resource of the older engineers to their detriment. Just a few moments to have them check your approach can save you many hours/days of debugging time.
Yes, older engineers will dash some of your ideas, but would you rather stop and think before you waste a lot of time and money or after you have lost all that time before you ask the question?
Just a thought.
It's important for older engineers to keep that agile mentality. You may have always done it this way, but will this way always be the right way to do it? It's also very important for older engineers to avoid becoming complacent in their jobs. Times are changing quickly.
I do think that in general, employers look for the younger set, and I agree, it can often be to the employers loss.
One thing comes to mind that might help the job seeking engineer though. The younger engineer can't offer the wisdom and experience that a good 50+ engineer can. Over time, of course the engineer will gain it, but then will be 50.
I do, however, think that an older engineer can deliver much of what employees look for in someone new to the job. I think they see younger folks as being full of fresh ideas, the latest techniques and an abundance of energy.
It's incumbent upon us to keep abreast of new technology, to find a way to keep being fascinated with things that are small, powerful and fast. If the world wants C or C++ on 32 bit MCUs, deep knowledge of assembly on an 8-bitter isn't enough.
The real value we can deliver is in having that new knowledge plus the years of experience in the technologies that got us here.
Being one of those engineers.
Old means we 'know' more by intuition than we used to . The new DDR5 or whatever is similar to DDR3, so we need to learn less.
Old means we 'know' more by intuition than we used to. We dont always may be possibly notice / appreciate the new bits. The old way worked, so we keep using it.
two sides of the same coin.
Older Engineers..Younger Engineer here.
I read these articles from time to time, I get some pleasure out of reading the lament and derive excuses about why companies wont "hire us wrinkly ones".
It has nothing to do with what you know, or how up to date you are. I'm sure most old ones are up to date, maybe more so than the younger ones.
This is no conspiracy. If I run an engineering group... I need basically 1 or 2 old engineers and the rest young. Why? Well another way to say this is, I want 2 expensive and the rest cheap. As long as they have one old guy for the young to ask questions to I essentialy get the same productivity I would have if I had all old engineers...Same reason they don't hire an entire company composed of engineers....Can't have everyone be chief's...mystery solved.
There is also a peculiar dynamic occurring in engineering education. I've interviewed hundreds of candidate engineers and I've generally found that the older candidates intuitively understand the fundamentals of computing, while the younger ones, more often than not, blazed past the fundamentals into java and other 4th gen languages and in doing so lost touch with how computers really work.
This tends to make them panic-stricken debuggers, which is 50% of the job.
I believe it's this hard-won, intuitive understanding of the fundamentals that keeps the older engineers such strong competitors for real-world engineering jobs.
Come on guys. It's not a matter of how old and what they (we) can do. It's a cost thing. It's business. Business is only about money.
A hiring manager will buy the best tradeoff of productivity vs. cost. If entry level fits that bill, entry level is hired at entry level wages. Generally, younger persons demand lower pay so the bias is to hire younger persons. It just that simple.
And not to forget the total costs of hiring, with health care ones spiraling out of control. A mix of older and younger is probably the most judicious, with those older ones actively staying abreast of developments.
At least some of the more grotesque aberrations of the fashionable Total Quality Management "gurus" have for the most part fallen by the wayside, where older folks were looked at askance and their experience and wisdom discounted. No, they said, just throw all that out and do various design of experiments stuff and Taguchi this-and-that, with inexperienced people, and you will surely trump all those old fogies. One proud expositor of this looked at me with thinly-veiled contempt mingled with pity when I suggested that actual experience and a grasp of basic principles was still key. He had told us about his training in Japan, which included various team-building "exercises" and the ilk. He didn't invite me to do a fire walk but I could see the glimmer in his eyes.
I suspect he's selling used cars now, or maybe life insurance.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.