According to George: Planned Human Obsolescence

10/5/2011 10:50 AM EDT

Thanks for making me feel very old George. The first EDA application I wrote was in BCPL, the predecessor to C!

10/5/2011 11:03 AM EDT

Hi, Brian and George! I would stand behind the ideas of adaptability and lifelong learning, plus flexibility in working conditions. For the former, maybe applying C++ in a different area like embedded systems rather than mainframes or servers may be in order. And be open to working remotely by telecommuting, or even commuting if you can't relocate (which is harder these days in the US due to the housing market).

I've been seeing more people telecommute and commute in the last decade or so, regardless of the economy, and in many other fields besides technology.

10/5/2011 12:35 PM EDT

"What are the most important characteristics to a lasting engineering career?"

Flexibility and aggressive self-teaching. Not every monetary investment made pays off. Similarly, we should not assume that every educational time investment we make will pay off. Tech people need to keep track of the trends, hunt down and learn new languages and technologies before they become popular and not be overly concerned with how much you will use that language or technology.

If you never use - say Python - but become proficient in it, you get benefits none the less. Say your resume lists PASCAL, C, C++. I'd look at that and guess that you were coding at Apple back in the 80's or 90's and haven't kept up with the times. Likely a pass.

On the other hand, say your resume listed COBOL, FORTRAN, C++, Java, Ruby on Rails, ARM assembly, Python, MVC, Linux. I'd chuckle at COBOL and FORTRAN, but move on the other skills and see a trail of continuous learning. I'd bring you in for a chat.

10/6/2011 4:29 AM EDT

Is it enough just to self-learn and not *use* new languages etc.? Surely the first interview question will be: How have you applied these skills in a project? That said, it does sadden me to see very specific skill requirements being called for when flexibility is, IMHO, much more valuable. How many of us have been hired to do one specific job and, in the first month, been asked to take on something quite different as business needs change?

10/6/2011 5:40 AM EDT

You could poke a lot of holes in this argument easily. All you have to do, as an older engineer, is actually sit down and take some classes on "up to date" technologies with the boy and girl wonders, and then queue up with them for the jobs when you're on a technological par. Which one do you think gets hired, the boy wonder, or grandpa?

10/6/2011 11:56 AM EDT

You certainly can poke a lot of holes in my argument. Legal or not, there is a lot of age discrimination going on. However, I'm not speaking about guarantees. Just about improving the odds. Myself, having crossed over into half-century+ club, and not-that-long-ago unemployed, I understand well what it's like to compete with applicants that have to triple-space to fill even a one page resume.

Personally, I've had much better experiences hiring older, seasoned developers than I have youngsters (I've hired three in the last two years. One young and two not young). But not everyone will give both young and old an equal chance. Still, I've only hired older developers who have kept up with the newer technologies.

In terms of whether just self-learning (or class learning) is enough rather than having used it in a project; mostly. Having a decent set of recently learned skills gets you 60% there. It says to me as a hiring manager that regardless of age, you have a fresh and adventurous mind. And that's what I need in a developer skills and a fresh and adventurous mind.

Even better than just learning is to take that knowledge and just build something out of it. If you're into software, build out a web application or two or three for fun and be prepared to show it during the interview. If you design hardware, then build something. It may be more expensive than software, but for the price of a few dinners out, you can have a nice little microcontroller project to bring along.

None of this guarantees a job, but it makes the odds better. And - what have you got to lose? When I was self-learning and doing projects while unemployed, if nothing else, it made me feel better. It gave me more confidence when I did get called in for an interview.

10/6/2011 10:59 PM EDT

I tend to look at it like musical instruments. You can play the same tune on several instruments. This means the main thing that is different is technique between instruments. The question comes down to would a new musician master an instrument faster than a seasoned musician? If yes, then an older musician would not be a good choice to hire if the older musician just learned a new instrument. If no, then it makes since to hire the older musician because he has something that enabled him to have an advantage over the newer musician. Ignoring Front Office Appearance, fads, and looking at skills, older musicians can hang on as long as they can play. I believe the same thing applies to engineering and new skills. The problem comes when HR and not engineering types look at engineering hiring. HR looks at qualifications and mainly sees words to match while engineers understand those words and the skills behind the words. Older engineers may not know all the newest buzz words but they have the experience to understand the new buzz words and chances are they already know the said buzz word under a different older word. The HR person would say to the old engineer you lack qualifications but the engineer would say it means the same thing.

10/7/2011 8:57 PM EDT

I learned to program in color basic and fortran4, then I became very good at programming in UVOS. But I can also program in the Allen Bradley Micro-LOGIX languages, and write program performance specifications that tell a programmer exactly what the code must do. It turns out that being able to know exactly what must happen is more important than the actual language. And it has always been my impression that the choice of a language was determined by what had to be done.

10/8/2011 10:21 PM EDT

I have interviewed a lot of programmers for the past few years. My general impression is that if you list a lot of programming languages in your resume, you tend to disappoint me quickly when I ask a question that's just bit in-depth on one of the claimed skills. One the other hand, if you mainly list over 10 years of C++ experience, I'd chat with him longer with more interest. The people I work with who have in-depth skills on one language generally take about two weeks to learn to a new language of the same programming paradigm to start working on a new project and maybe another few weeks to become moderately proficient in that language. There are more important things in design and engineering than language names on the surface.

10/9/2011 1:15 PM EDT

My chihuahua likes to chase her tail sometimes, too.

10/11/2011 11:01 AM EDT

Hello all, excuse me. From my point of view programming skills are not really bound to any programming language. It is possible to implement object-orientation in C or even in assembly (with minor limitations) as well as implement procedural code in python or MatLab. The really important skills are not about programming languages but about system design and abstraction. Part of that comes with talent, a lot of it only with years of doing. That's what the boys and girls wonder are not able to offer :)