Tagged: old programmers

We Love Older Programmers

I was on the phone yesterday with a senior level hiring manager from a potential new client, and she said something I hadn’t heard in a long while.

We love older programmers.

When I speak with CTOs and hiring authorities about their dream hires, some are more cautious than others when stating their preferences. I’m not a lawyer and don’t know specifics on the rest of the world, but here in the U.S. we have laws that try to prevent discrimination in hiring. Some company representatives will describe ideal candidates to recruiters in conversations that could be approaching a somewhat gray line from a legal standpoint, and in these cases a recruiter should clarify that he/she will present all qualified candidates regardless of whether they are a member of some demographic.

Image title

We read so much on ageism working against the most senior in the industry that sometimes we forget that there are firms that prefer some gray hair. The problem, of course, lies with the numbers. As I said, I hadn’t heard a strong desire for hiring the most senior level resources in a long time, and we generally don’t see companies using language in ads that would tend to attract older applicants.

Job specs penned by HR or internal recruiters may describe the company as being young and having energy without any disambiguation as to whether the reference is to the employees themselves or the newness of the organization. “We’re a young company” can have more than one meaning – maybe it means “we’re all 22 years old,” or perhaps it means “we’re in an incubator and angel funded.” We may read about established and stable companies, but how often do you see a reference to a “mature team”?

When we look at company websites that show photos of their entire development teams or just a few select profiles, it can give a sense as to the type of culture the firm is trying to portray. These are usually smaller companies and startups with photo choices varying from the serious and dignified to goofy costumed photo booth style shots that are rather shamelessly trying to appeal to a younger audience.

Maybe it’s because I’m in my mid-40’s, or maybe it’s because of the ageism I hear about (and defend my clients against with words) in my resume writing business, or maybe it’s because I spent 15 years running a Java Users’ Group that had its share of gray hairs, but I’ve always been sympathetic to the plight of the older developer. It’s refreshing to hear someone state that they are welcoming to the most senior talent, and I hope to hear that more in the future.

Why Hire Older Engineers

Another day, another article about age and technology. The comments of these articles usually escalate into some generational war played out with mythology and anecdotes regarding relative energy levels and productivity, work hours, the value of experience, and general competence. These discussions usually make no progress, while some useful topics are ignored.

As someone who has been around programmers (and ran a Java Users Group) for about 15 years, I often guide senior technologists in marketing their skills. When doing business with clients, I find myself advocating on behalf of older coders regularly. During the first dot com boom multiple six-figure job offers were dealt to anyone at any age who could spell J-A-V-A, but the landscape is much different now.

Most companies I’ve worked with give candidates of all ages a fair shake, although I’ve witnessed some who have been less friendly to industry veterans. For firms that need additional justification for hiring older workers, here are a few additional considerations that may go beyond the more common topics of discussion.

mainframe picture

Recruiting – So your efforts to scale your team came to a screeching halt? Inevitably the friends and family network dries up and firms rely on internal recruiters or outside agencies to identify talent. Although young hires may be more connected due to early adoption of social networks, older workers usually come with established professional networks. These contacts are not just other senior engineers, but will also include younger former co-workers. When you consider the costs of recruiting (not to mention the costs of a bad hire), the ability to tap into the network of highly experienced engineers might even justify paying a higher salary.

Beyond just the network a senior engineer may possess, having experienced talent on staff will appeal to young candidates who understand the value of learning and career development. A predominance of junior engineers will typically scare off older applicants, and it’s also likely to be a red flag for some subset of the young. Graduates are typically encouraged to find a career mentor, and they will seek experienced professionals to serve in that capacity.

I generally advise my clients on employing some senior level engineers who are strong coders but will also serve a secondary purpose of attracting other less experienced hires. The term I usually use is “hire magnets“, and those magnets may fit a few different profiles. The magnet could be a recognized authority on a topic, an involved tech community leader, or simply a knowledgeable and charismatic developer who enjoys sharing knowledge.

Fad recognition – Industry experience may give engineers a sharpened ability to sniff out the difference between a passing fad and the genuine article when considering new technologies. This of course isn’t by rule, but once an engineer has seen enough shiny things being hyped by marketers and evangelists it should theoretically become easier to evaluate trends with less bias. Hires with this skill may save a company time, money, and many developer hours.

Less performance unknowns – Older engineers with a documented work history, a list of credible references, and demonstrable work experience should be easier to vet than juniors coming from their first or second job. The ability to rely on past performance to predict the future is a benefit, though never perfect.

Retention/stability – Employee retention is a serious concern and cost for many firms, with demand for talent contributing to turnover. Older engineers and those with families should be less likely to consider relocation for new positions, which limits their other employment options to local or regional opportunities. Although both junior and senior level engineers may have bills to pay, the breadwinner concept changes perspective and may result in satisfied and fairly-compensated developers staying put.

Senior level developers often reach a point where compensation plateaus and money ceases to be an incentive to change jobs. Employees less driven by dollars are surely driven by something. It could be something as simple as proximity to their home or a desire to solve complex technical problems, but competitors are less apt to change these factors and often need to compete with pay.

From my experience, most engineers see fewer significant increases related to job change around their 15th year in the business, and by the time someone reaches that level of seniority it isn’t unusual to have once taken a pay cut. Junior level talent in competitive markets view job change as the most reliable means to salary increases, while the relatively minor compensation differential for senior engineers may not outweigh the uncertainty of a new employer.

Unique situations – There are some scenarios that happen in development shops that are nearly impossible to replicate in a classroom or lab setting, and the ability to face the unexpected comes from being there. This could refer to crisis management when a server goes down, handling difficult customers, or knowing how to navigate office politics. Prior exposure does not guarantee preparedness, but should make the second experience less shocking.

On-the-job learning – Older engineers may now be on their second or third set of platforms and corresponding tools. Developing the ability to learn new languages and tools in a work environment is a skill. It is quite valuable to know how much (or how little) to read before starting a project with an unfamiliar component, or which methods are most effective for you when seeking knowledge.

Any that I missed?