Ask HN: Developers aged 50, how have you gotten around age discrimination?

When I code these days, I'll take Python.

It would be age discrimination if employers wouldn’t even invite you for an interview, thinking “(s)he’s 50, so (s)he must be wise enough not to fall for the crap story we tell the gullible”.

As long as there are employers where work-life balance is a better match with what you want out of life, I wouldn’t worry about it. And I think there are, certainly in Europe.

Straight from your profile.

You fit the complaining valueless old man profile completely. Thanks for confirming.

I'm not saying that one shouldn't adapt a bit, but dyed hair and "How do you do, fellow kids" clothes overshoot the goal by a good bit.

Describes more than one 20-something developer I know. Being a sloven does not correlate with age.

This seems like a minor thing, but assuming you're not incompetent, someone who knows how to dress themselves will be perceived better by those whose opinions matter.

The key is to match the general attire of the people around you, but do it a bit nicer. If everyone is wearing shorts and jeans, don't wear a suit to work.

Edit: This advice isn't limited to young people, there are plenty of older people that need to learn how to dress themselves. As a general rule, though, the younger generation dresses a lot more casually than I did at their age, and many don't seem to have been taught when an occasion calls for dressing a little nicer.

However when it comes to advice, are we interviewing for a job in an imaginary world, or the real one?

If it's the real world, this is great advice. Just like having a marketing team instead of thinking every product will sell itself is great advice that almost every company in existence learns at some point or another.

Clearly there are some companies more open to more senior people in various roles. At some level, the path of least resistance at least is to accept that.

I’m 45 and have religiously kept my resume “buzzword” compliant.

You can’t learn best practices, frameworks, etc in a few days. Yes things were already invented, but if you don’t know the ecosystem you’ll end up reinventing the wheel badly.

Don't feel underused or misunderstood etc etc even if you blatantly are. You won't be able to change it anyway, just work with what you have, and use your remaining brain cells to do stuff they CAN'T do: for example learning the next big thing quicker than they will...

Ultimately, it's just tech. it comes, it goes... You've likely seem most of it before anyway...

Also, when you DO find the basket case of someone who is interacting with you like an ass and has no clue about your real value, remember that it's THESE GUYS failings that will ultimately keep you employed to make stuff work in the end :-)

Most programming tasks are a variation of the same problem, you realise it, accept it and then realise that the way to write good software is to get decent at the building bit and then work on getting decent at all the other bits around it.

Requirements gathering (aka talking to people and writing down/recoding what they say), testing (hitting things until bits fall off), reliability (making sure things don't break the same way twice), documentation (making sure the poor sod in after you has more to go on than you inherited).

There is a tonne of variation in what the average dev has to do day to day (unless you are a "Here are the requirements, you can change nothing, implement this spec, never question it" dev - in which case I pity you) so the trick is to keep learning in multiple domains when one gets stale rotate to another, variety is as they say the spice of life.

And the marketing bods/management and so on more or less dragged the project off track, up to the point I didn't want to work on it at all, I quit, I left my 'baby' and had a hard 6 months where I didn't really want to do anything... Good thing is that I became a pretty competent landscape photographer along the way...

Nowadays, I work a LOT more like a mercenary. I don't mind working on projects that leads straight to the wall -- NOBODY will listen to you, or trust you've seen that 12 times before.

So as far as I'm concerned, I enjoy the work, the architecture, the TECH challenges, and everything which gives me a quick, and I completely ignore the outcome in the end. Sure, if it's a success, whoohoo whoohoo but I no longer put the same amount of 'care' and 'ownership' in what I do. I just let it go, and do something else just as efficiently.

It might sound cruel, but for the like of us who REALLY get a kick from designing/building/implementing stuff, it's actually quite liberating.

I just smile benignly on at the idiots in the room sometimes, it's quite relaxing :-)

His solution: he became a long-haul truck driver (he asserts that the skill overlap between software engineering and long-haul truck driving is far larger than you'd think). After a couple of years doing that, he reentered the software engineering world, completely revitalized.

But I can't think of a better industry than software development to satisfy the search for novelty. There's always something new and interesting to learn.

Every day is the same. If you want to search for novelty, it's the fact that it is the same problem and it's been broken from the beginning of time. So do something else! But what? That's what drives me.

You can't dally, either. It would be easy to just spend a year logging (and probably get nowhere). But you can't do it in a job. They won't stand for it. So what can you do in your few minutes of leeway? What difference can you make? You aren't going to fix it, so how can you extract just a tiny bit more information so that maybe someday it will all click?

I think most people don't care about this stuff. Programming is inherently boring. You need to care about insignificant details to really get deep into programming, I think. I mean, it doesn't really matter. Global variable, passed parameters. It sucks one way or it sucks the other way. Who cares? Only crazy people, probably. But in my opinion, that's where the fun is.

My guess is that I'd be pretty average or less, given my patience threshold -- I've worked with fantastic managers before, I'm not them. I don't think there's much of a problem of age discrimination in managements, unless it's for places like startups and so on where "people" NEEDS to "look cool and startupy".

I'm a pretty effective mentor tho, and I seriously enjoy that -- I think it's a lot more "my place" than trying to manage/herd cats :-)

Can you elaborate?

I don't know if my answer is good, but here it is...

If I find myself in a position where I'm actually bored and doing the same things over and over, then I move on to a new challenge, be it with my current employer or not. The most important thing for me in a job is that it's interesting to me. If it becomes boring, then it's time for a new job that is interesting -- partly for my own emotional health and partly because that's a strong sign that I've learned all I can learn from my current position.

And there's always a new job that is interesting!

Every large institution has an old COBOL mainframe running some mission-critical software that they can't upgrade away from.

Oh and be fluent in C -- you might not like it, you might despise it, you might think whatever you might think of it, but you will find 10 examples of anything in C for any programming problem you have.

Basically it's like being able to read/write Ancient Egyptian when finding a stone with wierd symbols on in the desert.

Then do a small run on how compiler works (you know some assembly, and you know some C now to match) from then you can infer how an interpreter works, and even infer how a JIT works. You'll get to understand how the Javascript in your browser actually /works/ -- that's more than what 99.9999999999% of the population will ever know :-)

Then feel free to play with other languages, quite frankly, I'd suggest not getting enamoured with one in particular. Ultimately, they are all the same. Make sure you understand how a garbage collector works, how dynamic loading of libraries works, and more generally, how the operating systems works -- no need to get in details.

Just ^^^ THAT makes you more knowledgeable than many people throwing O-n's problems around the place.

For training, i think you should try some easy "security challenge" that exist on the web, especially those based on shell, network and assembly with no stack-protection. They are not usable in the "real world" (well, some shell exploit might still work tbh), but you will learn how to use debugging tools efficiently, as well as reading assembly. If you want to be a devops, those skills are very important imho.

I remember a while back on a guy who was raving about my code setting a (as boolean) flag with "done++;" -- he thought it was such an awesome idea. OH YEAH.

I'm really sorry about that man... I guess young people tend to feel like they own the world. I'm 27 and I believe I have been raised outside this toxic bubble (I got a lot of shit from my parents, I never thought I was somewhat special just for the sake of it, I only felt special after achieving goals, I always felt necessary to them though, regardless of achievements). I believe younger people are raised like they are too special, the promise of a better world, the ultimate legacy of their parents and that tend to go over their heads, specially after a historical period of unprecedented growth in which my parents and I believe their parents lived (60s through 80s) in which they prospered.

Young people tend therefore to believe they inherited their parents achievement and they can only go forward. I feel lucky I don't share that and I would love to be your coworker and learn from you.

Yes, that sounds like the normal "folly of inexperience" -- it comes from people who don't yet have enough experience to know that they don't know as much as they think.

There's a reason that people (in any field) with less experience tend to be more certain of the correctness of their judgement than people with more experience. The more I learn, the more I realize how little I know.

> Sometimes I still get mad or sick thinking about it.

I think back on instances like that as dodging a bullet. Can you imagine the hell that actually working with those people would have been?

Some older people I worked with (I'm 40 now) were well respected by the others, because they prove time and time again that their experience is really valuable on all kinds of stuff, both low level details and high level strategies. To show this in an hour is difficult.

Although I was once able to do it, and was hired. They asked me a typical OO inheritance questions with a base class Animal, and derived classes Dog and Cat, and then let them "bark" and "meow". I knew were it was going, so I said "There will probably come more animals after this, so what I would do is drop the inheritance and move into a data-driven approach, where the specific animal behaviors can be defined in a config file, without needing to go through programmers have to compile a new exe every time". They liked that response, although that was probably not the standard answer that they were looking for when interviewing juniors.

And basically such things are your job as a senior anyway, to look into the future and steer the short sighted solutions that juniors come up with.

And yet, those are still the most popular interview questions :/

Young devs are surprised when I say Git is only okay, look forward to the next SCM tool, they tend to think git will be the tool fir eternity, and surprised when I list if the 6 other tools I’ve gone through in my career ... so far!

* socket listeners

* line drawing

* explicit memory management

* old APIs and libraries

* Perl

* Assembly

And things I rarely use:

* Semaphores & other threading primitives

* XML

* C/C++

Now, knowing these sometimes helps, but the amount of time I spent on them probably doesn't justify the benefit aside from the fact that it was necessary at the time.

And somebody is doing these now — I just find I don't need to, as it's always handled somewhere below the abstraction layers where I work.

An equally interesting list would be the things I use now that didn't exist when I graduated from college in 1996.

I can't recall the specifics but it's something like

  10% deep-diving on long-lived fundamentals
  25% going deep on your core stack you will be using for the foreseeable future
  The rest on the what's in front of you + what's coming next

Ever deploy the same software to multiple servers, and it maddeningly behaves slightly differently on different servers, and you're not quite sure why?

This is the problem docker solves. Install exactly once, when you build the image. Then deploy the exact same code, down to the bit, as many times as you want, to as many servers as you want. Or quickly roll back to the Docker image for the previous version.

So this is how Docker helps you scale quickly and deploy as often as you want, with confidence.

Kubernetes, meh. Just some code for spinning up more or fewer Docker containers in an automated fashion. At least that's my impression, I haven't had to get my hands dirty with it yet.

Any over 50 female developers care to respond to this "look younger" advice?

In other words, you're an interesting person if you're interested in them.

There are more recent studies like https://www.ncbi.nlm.nih.gov/pubmed/22086817, where if you go to the link, it actually points out the value in spending some time in the sun, getting some melanin and vitamin D development, which will fight a specific kind of skin cancer (CMM) that doesn't seem to be stopped by sunscreen, and might have a number of confounding factors.

The basics are that it's complicated, but that if you are spending time in the sun, you should be using sunscreen, but that you also need some sun, or something like that, who really knows.

https://www.nia.nih.gov/health/skin-care-and-aging

That article also suggests the use of sunscreen.