Why you shouldn’t hire old programmers

This is a reply to Josh Marinacci’s excellent blog post.

Josh wrote a brief essay advocating hiring older and more experienced programmers. This is a difficult topic - not in principle, but because there are substantial cultural, educational, and professional issues that many older workers are not interested in overcoming. If you’re an older worker, think of my response below as a list of Anti-Patterns to consider when thinking about your habits and behavior. These traits aren’t ubiquitous - but they’re common and hard to see in yourself. I’m 351 at the time I wrote this, and I’m writing from the perspective of Anti-Patterns that I’ve seen myself pick up over the past few years, as well as the Anti-Patterns demonstrated by many of the senior/staff engineers I’ve worked with.

If you’re a younger worker interviewing an older candidate, don’t take this too seriously. Ageism is a real problem in the tech industry, and while there may be some legitimate complaints that correlate with age and experience, age-based discrimination is unwarranted, and the benefits will generally outweigh the consequences.

Experience Breeds Arrogance

Older software engineers often rely on their perspective as much as they rely on their individual contributions to add value to their organization. In most industries, that’s very helpful, but software engineering is a weird one. Just because the graybeards had to implement some optimization2 or work around some pitfall3 five years ago doesn’t mean those problems are still relevant. When you bring an older engineer onto the team, you bring their biases.

Garbage collection is evil. Multi-threading is toxic. Black-box designs are scary.

The tools have changed - we’re relying more and more on massively parallel and distributed systems that incorporate machine learning in our day to day lives. Mastery of the tools and the technologies that are on the way - and already here - will be essential to building growing businesses and generating value.

Many older workers focus on improving their social networks instead of their core skills. In terms of younger businesses, they quickly obsolete themselves as individual contributors. Many succeed through cronyism - make friends and move up4. Networking (human/social) requires a substantial amount of effort, and older workers with families can be more limited in the time they have available for self-improvement. One of the ugliest consequences is that older workers, specifically the ones who tried to climb the ladder and stumbled, can be weak technically.

Older workers need to look beyond the next job or promotion and ensure they are maintaining mastery of relevant skills that allow them to build sustaining value. Otherwise, there is no shortage of “Staff Engineers” who have “had their day in the sun” and are content to spend all day relaying useless stories about failed projects5.

Stop The Bull Sessions

This is not the fault of older engineers. There’s nothing wrong with friendliness and amicability. The problem is that while these traits elicit apparent rewards from business and society, these traits become reinforced toxic behaviors that are difficult to identify and correct. Otherwise, most people enjoy good conversation. But we’ve gotta make sure we’re spending more time (on the clock) talking about code and design than we are planning our fantasy football leagues and basketball brackets.

Alarming Gaps in Knowledge

I get it - I was self-educated during my first few years in tech. There’s a fundamental problem with self-education as an approach, though: most self-educated engineers have alarming gaps in their knowledge. Through exposure they learn how to construct complicated things, but don’t have the foundations to really grasp what they are doing. Self-educated engineers tend to create bugs that are exceptionally difficult to identify and fix.

SQL interfaces are my go-to here. Self-educated engineers don’t always understand issues like atomicity. They know transactions exist, but are working from a framework of (sometimes incorrect) assumptions. They are concerned about engineering out unsolvable scaling problems, meanwhile they refuse to use prepared statements or configure the database server for authentication.

String concatenation was good enough when I was 25, it’s fine now that I’m 45.

Once again, this is not entirely the fault of older engineers. As a college student, we have an opportunity to absorb vast amounts of knowledge in a relatively short period of time. Instructors organize knowledge to facilitate learning and comprehension such that we build foundations as our knowledge expands.

But for many engineers, the best-case formal instruction is the bevy of one or two week classes, often providing “continuous learning points”. There was no opportunity or mechanism to apply any of the knowledge they were exposed to.

Big businesses take heed: you need to change the way you are training your employees if you want them to be able to apply the skills you’re paying so much money for.

In terms of training, college has this figured out - but so does the United States Department of Defense. Servicemembers, particularly those in highly technical fields, are expected to spend months at a time undergoing extensive high-value training. Some servicemembers spend 50% (or more?) of their tour of duty undergoing focused training. The costs of a failed military mission are much higher than a missed software deadline, but we can still learn a valuable lesson in terms of maintaining an excellent team. If you’re on a short-staffed team, you’re probably already missing out on the most basic learning opportunities.

Design By Analogy

An older developer provides criticism on a user interface design. He hates it. Is the design bad, or just different than the way that developer had made something similar in the past? The problem is when developers allow their experience with previous projects to dictate newer designs. When inappropriate, this behavior is a terrible bane. This is as difficult a problem to address externally (ie, by people not the engineer in question) as it is to assess the quality of the design objectively. One solution, then, is to construct the design in terms of testable metrics and requirements.

Some portions of the tech stacks - databases, memory management, and networking haven’t changed all that much over the past 2-3 decades. (Sorry, whippersnappers, it’s true. We might not have called it containerization or orchestration, but we’ve been doing it for a long time.) Other areas, though, have changed fairly radically - user interfaces and human-computer interactions is the example du jour.

If analogy is the weakest form of argument, then specification by analogy is the weakest form of design.

This is as much a problem among users (who hate change) as it is among developers (who may hate implementing change). If a developer is familiar with a particular technology, perhaps there’s little value to be added in terms of reaching for something new. If client-server works as well as P2P, why bother with the additional complexity? If native applications are fast and responsive, why bother with a cross-platform HTML5 interface? If SQL works, then why bother with fixed-length fil… ahem NoSQL and a bucket of JSON?

If a design analogy increases reliability or speeds time-to-delivery, fine. But that sort of decision needs to be made consciously and in terms of clear outcomes. Despite the mantra of code-reuse, redesign is often the best approach. Tools and hardware have gotten much better, and let’s admit it - we developers almost never write enough documentation, and when we build modularity into a design, we usually get significant parts of the architecture wrong. So if your legacy (cringe) API was used on just one prior project, maybe it’s not mature. If it is mature, it’s probably full of a lot of cruft that makes it hard to port to modern programming constructs. Imagine using your grandfather’s matrix math library in Rust. No, seriously, go take a look at ATLAS and tell me that it’s a good idea.

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp..

I’m not advocating a rewrite in Common Lisp. What I’m trying to point out is that when a lot of large projects “reinvent the wheel” (or re-implemented Common Lisp), they don’t do a very good job. Then that code becomes something the (now senior) developers carry with them and keep as part of their portfolio (probably more common with larger businesses than with smaller ones). Most of us are probably guilty, some times we get smart and open-source it, but more often than not it’s just dangerous.

Cutting Corners

Over the past few years, there have been many conversations about how younger (medical) doctors often make fewer surgical mistakes compared to older doctors. The concept is that younger doctors, being less secure in their abilities, are more likely to research a procedure before undertaking it. Likewise, the older doctors, maybe not so much. Their experience breeds false confidence.

I see this same sort of behavior in software engineering often enough. There’s a perception of a point in an average young engineer’s career - maybe when they are about 27 - that the quality of their work is the best. Prior to that, they are still gaining skills and perspective, and after that, they think it’s all figured out and stop researching6.

Inappropriate uses of analogous designs (or Design Patterns) are another example. If prior projects solved all the problems new projects were intended to solve, we would have far fewer new projects. Going against the spectre of Common Wisdom and Best Practices is difficult but often necessary.

Have you heard statements like:

Hunger

Older employees are usually more established - if they want a house, there’s a chance they’ve already bought one (or at least, are paying a mortgage). They’re probably getting paid more than younger employees given the same job. There’s a good chance they’re vested in one way or another, whether it be stocks or a 401(k). They’ve probably got savings - if not “fuck it money,” than at least enough to say “fuck you” during a bad situation. They might have friends or a spouse and children that they’d like to spend more time with than their professional colleagues. They’ve seen friends and colleagues get abused and burn out. They’ll have health issues, they’ll take maternity/paternity leave, they’ll have to take care of sick kids and sick parents.

Older employees often aren’t as hungry as younger people. They may not see or share in the perceived importance of some epic last push, not when this means disappointing loved ones.

And they aren’t wrong. Not usually, at least. Plenty of younger companies are full of arbitrary deadlines, or deadlines that are a result of poor leadership. Sure, every business has to “time the market” sometimes, and older employees can be there right with everyone else. But older employees have lived through fire drills before and know what a sinking ship looks like and sounds like.

Conclusion

Perhaps this essay is as much my own catharsis and search for things I shouldn’t be doing - I am certainly anxious about ageism and maintaining competency as I headtoward 40.

Caveat - I’m guilty of all of these.

There’s a lot to be said about the stereotypes. That older engineers are arrogant and chatty, that they don’t understand the latest tools, trends, and technology, and that they cost more than younger people and contribute less. Some of these, we’ve earned.

On other fronts, we’re confronted with an unfair marketplace. Older engineers are more likely to have families, meaning we want higher salaries so we can be providers, and we have less time to build skills and contribute value to our organization. To a substantial degree, our experience can off-set that. But, like younger engineers, older people have their own insecurities and egos. Older engineers can also engage in behaviors that are learned in the workplace that are disruptive to progress. We, young and old alike, need to take substantial responsibility in fixing this.

Home


  1. I’m not old. At least, I don’t think I’m old. But I have to admit my colleagues are getting younger and younger and, much to my dismay, I spend a lot of time trying to figure out what team members should be doing.

  2. like the small angle approximation ahem

  3. Your proprietary embedded OS only allocates 20K for the stack? Hahahahaha…. ha…. ha.

  4. Have you ever seen a colleague start being really, REALLY nice to everyone a few months before they put in for a promotion to be team lead?

  5. It didn’t fail! We finished, it’s just that management decided to pivot!

  6. or get promoted and start researching the corporate ladder

  7. Sucker! t’s never been tested!

  8. SIGSEGV followed by a CVE a few months later.

  9. And I should be the one to do it! It’ll be GREAT!

  10. Except half of our partners.