
Why You Should Hire an Old Programmer - joshmarinacci
https://joshondesign.com/2017/07/02/hire_old_programmer
======
pleasecalllater
When talking with young programmers I too often think "well, you are doing
that wrong, been there, done that". They don't want to listen. A couple of
months later they notice that the gray beard ones were right. From a company
perspective, that's just too late, as the money loss is not recoverable.

There is nothing wrong with being a young one with no experience. There is so
much wrong when a company has only a bunch of young programmers and no
experienced one who lead them.

~~~
ruffel
Conversely I find that a number of the old(er) programmers I've worked with
are incredibly stubborn and bigoted. They refuse to see anything from another
persons perspective _especially_ if that person is young. As well refusing to
keep up with 'modern' technologies and paradigms because "that's not how I'm
used to doing it". It's a lot of the "I've been round the block a few times I
know what I'm doing" bullshit attitude.

But obviously that's a generalisation. Just like your comment is.

~~~
Mouse47
Yup. I've seen 55+ year old programmers write what was essentially a message
queue persisted in a database table, processed by a cron job. We frequently
had problems with duplicate processing of messages, due to multiple cron jobs
running at once.

I've personally argued against a key-value store schema in SQL Server and was
in favor of a flat-table design. In our case, there were records of different
'types', and each type may have a number of fields always be null. Looking
back, I'd probably do something like this:

    
    
       Entity
           common attribute 1
           common attribute 2
           etc
    
       Entity_Type1
           entity_id fk references Entity,
           type1_attribute 1,
           etc
    

He was certain that the flat-table design would take up more space since it
would 'have to store every attribute every time'. Most of these were varchars,
so (looking back) that was straight up false. Not only that, but in a key-
value schema you have to store the name of the 'column' (key)... every time. I
was unable to articulate the harms of key-value schemas when it comes to
queryability...even though our existing system was filled to the brim with
'unions' due to a key-value schema. I lost this argument.

Each of these developers refused to use git, in favor of visual source safe. I
know.

All of the business logic was in stored procedures. I've seen a stored
procedure with triple nested cursors spanning 2000 lines. Our 'senior'
developer would take weeks to make changes to this thing.

I've lost count of the times I've been steamrolled in discussions. I'm not
sure if it's my age or if I'm just lacking that much socially. When you lose
an argument over key-value schemas of all things it makes you really question
if you know what you're doing...

~~~
Clubber
>All of the business logic was in stored procedures. I've seen a stored
procedure with triple nested cursors spanning 2000 lines. Our 'senior'
developer would take weeks to make changes to this thing.

I'm and old programmer and I've been arguing against business logic in SPs
since SQL Server 6.5 and have been losing ever since. That's not an old/young
argument.

It's because vendors (in this case MS) recommend putting code in SPs. I
suspect it has to do with lock-in. I use the database for what it was made
for, and only what it was made for: to persist and retrieve data. Anything
else should be in the code.

Also, key/value schemas are terrible and slow, but sometimes they're the only
way to get the dynamic nature of what you are doing. The best compromise I've
seen of that is to have the values you _know_ are going to be used a lot by
groups/customers flat, then have the key/value schema for anything oddball.

I guess the moral of the story is old/young doesn't really matter. It's know /
don't know what you are doing. I guess it boils down to thinking about what
you are doing. Key value is very dynamic but I'll bet it's slow. Do we need
fast more than dynamic? Is there a compromise that will satisfy both
requirements? Many people don't think that deeply and just want to get it
finished.

When I was young, the dot bomb was the "great filter." After that, there were
a lot more people who knew what they were doing because they survived. It
sucked though, I don't recommend it.

~~~
vpeters25
> I'm and old programmer and I've been arguing against business logic in SPs
> since SQL Server 6.5 and have been losing ever since. That's not an
> old/young argument.

> It's because vendors (in this case MS) recommend putting code in SPs. I
> suspect it has to do with lock-in.

If i recall correctly, back in the dark ages of Classic ASP and SQL Server
6.5, database stored procedures was the only feasible way of implementing a
reasonably performing web application.

~~~
Clubber
No, we had middleware back then. It was ugly text over sockets, or worse,
DCOM, but it worked. That was more ISAPI than classic ASP. If nothing else, we
could create a queue table in a database and have a Windows Service pick it
up.

~~~
vpeters25
Ah DCOM, fun times.

Back in SQL 6.5 days (and all the MS SQL versions up to, i believe, 2005),
"precompiling" queries in stored procedures was recommended for performance
reasons. It was even asked on hiring interviews, at least to me.

------
js8
I think programmers should reframe the problem. If cognitive decline is real,
why would anyone hire anybody over 40? Yet there are plenty managers,
politicians, doctors, lawyers, salespeople, engineers, etc. who are over 40.

If you want a culture where people retire at 40, go for it. But please don't
pretend that programmers are "special" in that the decline in their skills is
worse than decline in skills of anybody else.

~~~
timwaagh
programmers actually need to think sometimes. the jobs mentioned are more
routine and rely on soft skills and experience a lot. I do not mean any
disrespect by that. mathematicians are also best when they are young, but
unlike programmers work in academia and get to teach until retirement, whereas
programmers get replaced.

~~~
js8
> mathematicians are also best when they are young

This guy springs to mind:
[https://en.wikipedia.org/wiki/Laszlo_Babai](https://en.wikipedia.org/wiki/Laszlo_Babai)

Because, yeah, programmers and mathematicians don't actually need any
experience, they can just think everything up on the spot!

I also wonder how you imagine that other professions gain their experience, if
they don't need to think.

~~~
timwaagh
it is a historical fact that most of the best mathematicians make their famous
discoveries when they are younger than 30. if you have studied the subject,
you'd know this, so i assume you just dislike these facts and argue for the
sake of it.

~~~
pathsjs
I would question whether this is actually true. Stats on Field medalists have
to be taken with a grain of salt, given that it is awarded at 40 years top in
the first place

~~~
timwaagh
That is pretty limited information. Talk to a good professor. he will gladly
admit that his mind is not as nimble as it was once. maybe he will say things
like hes glad he can still keep up and do research. mine told me this in front
of an entire class just to drive the point home that 'the time is now'.

~~~
pathsjs
I have been doing mathematics up until a couple of postdocs - and based on
first hand experience I think that the story of young mathematicians is mostly
a myth.

Maybe people in their 60s were not at the center of research, but I would say
that the field was dominated by people in their 40s (certainly not by
20-something).

I cited the Fields medal, because their artificial limitation on age is one of
the first things that comes to mind when talking about the subject

------
gozur88
The most frustrating thing about being an older programmer is watching
organizations make the same mistakes over and over again. Yeah, sure, you
might want to hire an older guy because he has experience with the intangible
project stuff. But only if you're planning to _listen_ to him. I feel like
Bill Murray's character in _Groundhog Day_ :

Me: We need to create our security architecture in the beginning. It's always
harder to add when we have a bunch of functionality to work around.

Management: But we don't have time. We promised these features by January 1st.
Don't worry about security yet - the initial version won't have critical
business or customer data.

Me: We'll never have time. Once the users get ahold of this we'll be buried
under requests for new features and critical bug fixes. Particularly since the
only way we have to test it is to have people poke at it in a browser.

Management: Adding automated testing would take too much time.

Me: ...

~~~
sean2
I'm in my early 30s, so frequently called an older programmer and I've heard a
lot of, "we don't have time".

What I've been waking up to is that projects that estimate realistic budgets
and time scales don't get funded. Everyone underbids knowing that the
company/customer will continue to fund and extend deadlines for project after
sinking so much effort into a buggy prototype, until the realistic estimate is
reached and the product actually reflects all the "hidden"/"discovered"
requirements (i.e. foreseen but not in the bid) including security,
integration and test efforts.

What's weird is that everyone, customers included, seems to be in on this.

~~~
imhoguy
What you describe is often the scenario of do-everything consulting sweat shop
building tailored or customized solution from scratch based on a single
customer requirements. Management often lacks business vision and
technological path. Front sales and techical people are randomly assigned and
switched between ad-hoc projects with varying industry domains and poor
communication chanels.

I think only debt slave or masochist stay in such places for longer. Age
doesn't matter.

I would rather look for more focused software product companies with stable
teams.

------
autokad
How do older programmers deal with coding interviews from companies like
facebook / google? i feel like those advantage people who just finished their
algorithms class, or have time to practice specifically for it.

~~~
dagw
_How do older programmers deal with coding interviews from companies like
facebook / google?_

Badly. The unfortunate truth is that if you've hit 40+ without having built up
enough expertise and contacts to bypass those types of interviews then finding
a programming job is going to be really hard.

~~~
ryandrake
> bypass those types of interviews

Can you elaborate a bit? I hear this all the time (get the job through
contacts and _networking_ not by applying and interviewing) but nobody will go
into step-by-step detail about how one actually can manage to "bypass" a
company's interview process.

Company: "Thanks for your interest in working here. Your resume and
application are impressive, and you have great references! Obviously you are
skilled, so forget about having to interview. How's $180K plus benefits sound,
and can you start in a week?"

I've been in tech for close to 20 years and that scenario just sounds absurd
to me.

~~~
dagw
_step-by-step detail about how one actually can manage to "bypass" a company's
interview process._

Networks and reputation. Get a former boss/colleague that knows you (and who
has ideally ended up in a position some of trust/responsibility) to recommend
you to his boss. If someone the boss trust tells him that you have the exact
combination of expertise they're looking for and that you're the person they
need then everything goes a lot smoother.

That's how I got my current job. A former colleague (who'd ended up in a
management position) called me out of the blue, invited me out to lunch and
straight up asked me if I'd be interested in a new job. I still had to
interview, but it felt like much more of a formality.

You can also just ask people. Keep a list of people you've work with that you
trust/respect and that you believe trust and respect your skills and just keep
in touch with them once every 6 month or so. Let them know that you are open
to switching jobs if something interesting comes along and ask them to keep
you mind.

Another way is to become a 'name' in your field. If yours is one of a handful
of names that always comes up when people are talking about who in town is
really good at X then chances are people will start seeking you out.

~~~
ryandrake
Not sure that counts as "bypassing the interview" but thank you for your
thoughts! This seems like normal networking 101, get your foot in the door by
knowing someone there.

However, I've seen people claim, here on HN and in other forums, that they
have received offers (not just opportunities to interview), sight otherwise
unseen, from companies based purely on their own reputation and/or references.
That's what seems unbelievable to me.

~~~
dagw
It's not bypassing the whole interview, but it is bypassing the "coding
interview" gauntlet which is what seems causes the most anguish. If you're
there on a strong recommendation from a trusted colleague then the interview
becomes as much the company trying to convince you to work there as it is you
trying to convince them to hire you.

------
polote
This guy assumes that old programmers are not super enthusiast and hard worker
but they have experience, while young ones are enthusiast, hard worker and
motivated but they know nothing, that's not a very rigorous way to prove
something ...

All that is just nonsense !

------
evolvedlight
I would _never_ hire this candidate, based on seeing this.

So - the author says that he has "developed some good communication skills".
Great! Moving on, let's look at his linkedin page. Quotes from past jobs:
"even after our idiot (now ex) CEO canceled the platform.", "wonky JavaEE
stuff.".

So, as a hiring manager, from this post + linkedin, I now know that this guy:
1) can reach large audiences, 2) trashes past jobs and colleagues publicly.
And thus, I would be terrified of hiring the author, as there seems a 50%
chance that this will end with my employers being trashed in the same way.
That's just not worth it.

OP: Come on, give yourself the chance to be hired by removing that from
linkedin.

~~~
stingraycharles
This is indeed basic psychology [1]: talking bad about other people reflects
poorly on _you_, not just the people you're talking about.

[https://en.wikipedia.org/wiki/Emotional_contagion](https://en.wikipedia.org/wiki/Emotional_contagion)

------
theycallhimtom
I've worked with old programmers who are great and old programmers who suck.
Most of the points in the article are obviously wrong.

"Anyone who is still a programmer in their 40s has to have developed some good
communication skills." "Old programmers are dabblers." "Old programmers have
judgement." "We can pick up any new language because we’ve used so many over
the years."

I've met old programmers who are counter examples to all these points.

A steelmanned version of the article would argue why older coders are more
likely to have these skills than young coders. It also needs to talk about the
average difference in ability relative to the variance in each group. If old
coders are on average 0.1 standard deviations better than young coders you
should focus on hiring the good old or young coders. If old coders are on
average 1.5 standard deviations better than young coders you should just focus
on hiring the good old coders and exceptional young coders.

------
twii
What a ridiculous assumption. It is not about age! I've seen both young and
old horrible coders. Of course you can have a slight advantage from experience
if your'e older, but the quality of that experience remains relative to the
person in question. You might have 10 years of experience doing things the
wrong way!

Growing older doesn't make you a 10x dev, just as it won't make an average
musician a superstar.

------
bengale
If age is not a good indicator of someone being a bad hire, then it can't be a
good indicator of someone being a good hire either.

------
DrNuke
To be honest, as a middle aged folk I find it impossible to relate with ping
pong culture and open space offices. On the other hand, cubicles here are too
often signal of brick & mortar ways to intend business, which ultimately means
losing value. That's why I think older folks like me should really get into
contracting or external consulting. As an alternative, do with finding a job
at utilities or other non-cyclic ventures, they always seem eager to listen to
juvenile-but-not-disruptive folks to innovate just a bit, not too much, not
too fast.

------
1ba9115454
I know more this year than I did a year ago.

I will know more next year than I do today.

This will never stop.

~~~
sokoloff
My grandmother knows less today than she did ten years ago.

~~~
david-gpu
We are talking of ordinary folks in their forties and fifties, not senescent
folks in nursing homes.

~~~
adrianN
Then we shouldn't say "never".

------
thehardsphere
I don't disagree with anything stated here, but how much of this actually is a
function of age?

I feel like a young programmer could aquire all of these traits also, because
they're less about age and more about being able to learn from experiences.
You can choose to have more experiences to become the kind of person the
article talks about.

Or is this a survivorship bias thing? The old programmers are more likely to
be this way because the people who would be old programmers who are not this
way aren't programmers anymore?

~~~
chefandy
Well I'm not sure if you're young or just playing devil's advocate, but a
young person often feels that way.

The whole knowledge * intellect idea that someone else here mentioned is far
too reductive. You can be a ridiculously smart person who has read white
papers and coding books, learned all about discrete math and project
management, worked on as many projects as you could, and still not touch the
maturity of an older software developer. Why?

Experience doesn't begin and end with topics directly surrounding your
vocation; your whole life contributes to it.

As you age, you get to know yourself better. Old people have made far more
decisions in their life than a young person has: lots of good ones, and lots
of bad ones. You know your decision making process and its flaws. You remember
what it feels like to reap the rewards of a good decision, and even more
intensely, you remember the sting of a bad decision. You know, from
experience, what decisions you should make, what ones you shouldn't make, and
any confounding variables.

You also start to understand those same patterns in the human and
organizational behavior of people you live and work with. You start to get an
intuitive understanding of the kinds of mistakes various kinds of people make
in various kinds of situations. There's a reason that older people– often ones
without a ton of domain knowledge– are generally the ones making big decisions
in a mature company, while the younger people are working out the details.

For example, the couple decades that I spent as a bouncer in clubs might not
help me see if I'm making a bad coding choice per se, but it vastly increased
my understanding of group dynamics, ego, negotiation, how to mitigate the
damage of having to make snap decisions with a whole lot of consequences, how
to respond when someone tries to intimidate me or make me feel uncomfortable,
deescalating pointless arguments, and even starting a fight when one really
needs to be started. (the worn-smooth restraint and fighting techniques have
much less utility in the office... so far) Before I gained that experience,
I'd have no way to have known it would proved useful in a software development
career. I'm sure many parents, people who have coached sports teams, people
who have experienced the death of an industry, or even people that have gone
through messy divorces can all point to things they've taken away from those
experiences which have vastly improved their judgement and maturity.

And it's not just the soft skills which are improved by this understanding.
Being more mature means you write more mature code. I look at code I wrote 15
years ago and shudder. It's not that I have a better understanding of the
mechanics of Perl or C now than I did then, but my sense of logic has been
refined, I'm more patient, and I have a better sense of where to put in extra
effort and where to cut corners.

When you're young, you're still mostly figuring out what you're capable of,
but you don't have a very good sense of what your limitations are. When you
get older, you've got a pretty good sense of what you can do, and a much
better sense of how to keep yourself and everybody else out of trouble by
avoiding what you can't do. The problem is, lack of experience is generally
pretty opaque to the people who lack it.

¯\\_(ツ)_/¯

~~~
tonecluster
"lack of experience is generally pretty opaque to the people who lack it"

Agree! this is a succinct description of a eng management problem. However, it
can be mitigated by hiring coachable, trainable (and mature) people.
Interestingly, we've had great luck hiring from programming bootcamps;
programmers who lack programming experience but have other work experience &
who are eager and able to learn quickly, & usually come with some level of
intellectual curiosity (as opposed to entitlement).

~~~
chefandy
Totally. I've also had good luck with people coming out of programming boot
camps. _In my current line of dev work,_ I'll take someone who's really eager
to learn new things and jump on tasks over someone who can confidently invert
a binary tree on a whiteboard.

------
davidhbolton
I'm 58, live in the country (UK) and found a programming job almost exactly
suited to my skill set (Pascal mainly-i.e. Delphi along with C# plus a few
years of C, C++). Add in 5 years of 6502/Z80 assembly (games in the 80s), two
years of Ada. The last three years was creating a mobile app in C#/Xamarin.
Plus lots of php, html, SQL.

To stand out from other candidates I prepared a 7 minute screen cast (using
Camtasia which I bought a couple of years back) showing off programs I'd
written and briefly mentioning programming aspects that made each program
different. I uploaded it to Dropbox, emailed the link to the recruitment agent
who forwarded it on. I got the job after two interviews and have just
completed my first week. I was lucky, round here there aren't that many
programmers and most jobs are for C#/ASP.NET MVC websites. It's just a 30
minute drive away.

The job interviews included an online IQ test (not a problem), a logic test
which was not my finest hour (4PM on a Friday is the worst time for me!) and a
10 minute stand up presentation on the subject of my choice. "A trip to an
Arctic Isle."

------
jaclaz
I will risk a quote by C.S.Lewis:

“Experience: that most brutal of teachers. But you learn, my God do you
learn.”

------
rsoto
Hiring is more than the job tasks: there's work culture, politics and external
factors. At least here in Mexico, the people usually are very political (we
call them 'grillos'): they tend to form groups, brain wash other employees and
use the law to their advantage, because in Mexico, the employer has to prove
almost everything in case there's a work dispute.

And that's another reason to consider: yes, there are young people that has
these traits, but mostly it comes from experience (or as we say here,
'colmillo').

The other big factor is the old saying that old dogs don't learn new tricks,
so it's difficult to guide them towards the company vision, and it's worse
when they have a boss that could be their son.

Those are my experiences based on Mexico, I know there are better places in
the world with different mindsets, I just wanted to include my thoughts on
this topic.

------
jacquesm
If you're trying to get hired please always include your location in your
communications so that you don't get rejected out of hand for not appearing to
be 'close' and/or waste peoples time.

------
eloycoto
Be old dev doesn't mean that you know how to write code. I worked with devs
with twenty years of experience, and I love it, and I learnt A LOT from them.

On the other hand, I worked with old devs too, and they did a lot of spaghetti
code, they didn't make a module and a lot of things are weird for them. Like
async/await/yield.

I think that it's not an old programmer, it's about the attitude that they had
during his professional career and the attitude that they have now. With a lot
of experience and the right attitude, I agree, it's a perk in the team!

------
bryanrasmussen
as an old programmer I think it would be better if the author said 'I know
this, because I hired one.'

~~~
1ba9115454
Even better. 'I tried to hire one but someone else made a more compeitive
offer.'

------
bsvalley
2 reasons why you will OR won't be hired as an old programmer:

1- "programmer" is the entry level in a software/hardware company. Rising
stars move up in the ranks over the years and take more responsibilities.
Manager, sr. manager, director, VP, etc. still a programmer at 40?

2- If you're still programmer at 40, you might really like it! We're looking
for programmers and need age/exp diversity in our group. You are rare my
friend and valuable.

~~~
pc86
A programmer with 20 years of experience is definitely worth more than a
programmer with 2 years of experience. But not that much more. A skilled
architect with 8-10 years of experience will beat a programmer with 25 or 30
years experience every day in terms of ongoing business value, and will
command a much higher salary (15-20% or more).

So yes, you can absolutely have a professionally rewarding, lucrative career
as a 40-50 year old programmer, but you'll earn more money by moving over to
the business side, simply because you can more easily show a direct line
between your actions and business revenue.

~~~
Clubber
Job titles are meaningless. When I say 20 year programmer, it's what you would
call an architect, senior engineer, whatever. The programmer being someone who
doesn't do any design is a foreign concept to me and should find another
career. Any architect that doesn't write at least the skeleton code is the
same. All levels of that career needs to involve design and implementation of
that design.

~~~
pc86
Every company I've worked at with 2 or more developers has acknowledged a
difference between a developer responsible for high level architecture and
technical ownership of a system(s) who happens to program some of that system
as well, and a developer responsible for programming parts of that system who
happens to architect smaller self-contained pieces of it.

Architecting a class or small single-use library is a subset of the skill
required to architect a distributed system, a large multi-tenant application,
or some other non-closed system.

Whether you want them to have the same job title or not is I think orthogonal
to the fact that they are very different jobs.

~~~
Clubber
I think you are trying to differentiate between a programmer with 20 years
experience and what you call an architect by using titles. Like I said titles
are meaningless. A programmer with 20 years experience who can't design a
large system isn't a very good programmer. An architect who can't design a
large system isn't a very good programmer either.

I think we are arguing the same thing, we're just stuck on the semantics of
titles. I guess let me put it this way, do you know people who have the title
of programmer who are way better at building systems than a guy with the title
of architect? Of course. Some companies don't even use the title of architect.
That certainly doesn't mean no one in the shop can design a large system. It's
not the title, it's the ability, and titles are a horrible way to discern
ability.

>A programmer with 20 years of experience is definitely worth more than a
programmer with 2 years of experience. But not that much more.

This is what I took issue with. A (good) programmer with 20 years experience
is capable of designing large scale systems, which is much more valuable than
a programmer with 2 years experience. Maybe it's just my bias.

When I first heard the term "architect," I asked, "what is that?" and the
reply was, "someone who designs large systems but doesn't code." I thought to
myself "well that's dumb." FWIW, I've had the title of "architect" at various
companies since 2008 and I've always coded at least the skeleton of my
designs. I mean how else do you know if you're right? When I switched
companies in 2010, the new company didn't have the title "architect," so I was
just a "senior engineer," until we got acquired. I regained the title
"architect" because I made X amount of money. Like I said, meaningless. As a
side note, I think coders calling themselves engineers is also incorrect.
Engineering is a specific discipline that actually has meaning. It's like Dr.
Dre. It sounds good, but I sure ain't going to see him for a rash.

------
chandler
Consider smartness as "what you can do with what you know," while experience
is "what you know"\--then, what follows is that having more experience makes
up for not being as clever.

    
    
        Able to make good choices = Intellect * Experience
    

Moreover, employers can _try_ to assess intelligence with whiteboard
interviews...but the easier factor to evaluate is experience. It's right there
on the resume!

~~~
hardwaresofton
Yeah, except 10 years at certain companies could teach you less than 6months
to 1 year at one company that's actually doing it right.

I hesitate to try and prescribe an answer for the "how employers should find
good employees" question, because it's so difficult, but I imagine the ideal
hiring process would:

\- Allow candidates a choice on how they want to be tested (take home thing,
online code test, whiteboard, whatever else)

\- Ask better questions at the abstraction level that would show experience.
For example, if you want to know whether someone has experience, give them an
architectural diagram (or process diagram) of your current
project/workflow/whatever, and ask them how they would improve it (and if
they've ever been through the steps they suggest themselves/how they would
roll it out).

There was an excellent post on HN a while back detailing what a specific
company (whose job is doing interviews, I can't for the life of me remember
what company it was), learned from doing thousands and thousands of
interviews.

Also I'm not super good at math, but in the equation you posted wouldn't the
intellect variable be pretty much equal to experience, and you could make up
for one with the other? Or maybe you're implying that the scales for each
multiplier are different (like intelligence might only go 1 to 10 but
experience might go 1-100?)? I agree with what you're getting at, basically
that someone who has seen lot but isn't as clever will often make better
choices than someone that's very clever, but completely green.

~~~
chandler
> Yeah, except 10 years at certain companies could teach you less than 6months
> to 1 year at one company that's actually doing it right.

Is it common for programmers that have been on a job to not realize the ways
in which their software sucks? Knowing what to avoid and the consequences of
doing things wrong is an important factor of experience; additionally,
maintaining a bad system gives insight into mitigating problems.

That said, I do agree that experience isn't just a passive function of time
(as in "interest earned"). Instead, it's more like a landscape that needs to
be explored (and to your point, some companies will allow a programmer to
explore more productive areas).

> ...the equation you posted wouldn't the intellect variable be pretty much
> equal to experience, and you could make up for one with the other?

I suppose the answer to your question would depend on just how much variance
you place on intellect. Is it:

\- 0.0 (rock) to 1.0 (cleverest human on earth)

\- 0.0 (rock) to 1.0 (cleverest intelligence across time and space)

Either way, I wouldn't take the equation too seriously--it was just a model to
show a trend :/

------
gcatalfamo
Somewhat related: is oldgeekjobs.com still going? I can't tell from looking at
the posts if it's really active.

------
hashkb
Time does not translate directly to experience, not all experience is equal,
and one thing old programmers should know about more than anything else is
their personal biases.

I agree with the point- I'm getting older, too- but the reasoning is not
strong.

------
wmu
In Polish the title "senior developer" is usually translated into "starszy
programista"; the adjective "starszy" means literally "older". So, I ask
everybody to call me "old programmer". :)

------
gregjor
Thank you. 56 years old, still writing code. I enjoy working with young
programmers, they bring energy and ideas to my projects and keep me from
getting stale and stuck.

------
mmjaa
Oh shit, I may have just committed a truly heinous sin, as a "senior
developer", by posting this to the company channel.

Ah well, lesson learned. Don't do it, youngsters!

------
calafrax
You might want to add to the list that you are required to by law if they are
equally qualified.

------
spodek
Is this post not promoting age discrimination?

Isn't age discrimination illegal?

Why would discriminating against younger people be any more fair or legal than
against against older?

I expect discriminating by amount of relevant experience is fair, but that's
not the same as age.

~~~
Doradus
> I expect discriminating by amount of relevant experience is fair, but that's
> not the same as age.

As someone who started coding at age 9, I agree. :-)

It's not about hiring someone in their 40s per se, but rather about
recognizing the value of 20 years' experience. Age alone doesn't impart
wisdom.

------
RickJWagner
I like it. Of course, I'm an older programmer. But still.

~~~
pc86
"I am in favor of discrimination as long as I am not the one discriminated
against."

------
rdtsc
Reason to hire a young programmer based on the confession from CTO: we like
college grads because we can drive them hard and pay them minimal salaries.
The only thing is they burn out pretty quickly. And yes they also lamented the
quality of their software and how releases were buggy and delayed. Not sure
they saw a connection there...

To attract the candidates they optimized non-salary benefits they thought
college kids would like such sports tickets, beer nights etc.

The bottom line is companies know exactly what they are doing and just
officially​ claim some culture fit thing.

Same with hiring women, minorities,etc.

Even with open space offices. They say it's because they want people to
collaborate but more often than not they want to save money and monitor people
to see if the are "working".

~~~
dwc
> Not sure they saw a connection there...

In my experience, they try not to see the connection. If you try to show it,
they'll listen for a bit and then rationalize. If you keep at it you'll begin
to see irritation and even aggression.

That a fair number of CTOs have a decent technical background doesn't seem to
help much, somehow. I've had this confirmed personally when I got together
with a coworker from almost 20 ago who had moved into management. He struggled
to keep experienced people because they moved for more money, because they
were paying below market value. If I suggest something like paying more, he
considers it and then some weeks later I find he's still struggling to figure
out a way to keep people, having changed nothing of consequence.

It's my pet theory that (almost all) management _wants_ programming/IT to be a
commodity and are willing to pretend that it is, to their detriment. They
_demand_ that it be a commodity.

~~~
vim_user
I also have that theory, and it's not a stretch since the act of business is
to commoditize everything. I especially saw it in the IT consulting business.

------
whalesalad
s/old/experienced

------
andreasgonewild
Being sweet-talked into raping the world for other peoples awesome profits
comes easier when you're 20. The real problem is the messed up priorities of
most companies these days; older coders are more likely to call bullshit and
demand a fair share of the cake.

------
throwawaymanbot
The problem with Old Programmers, is not their work. Thats solid. Its the fact
that they have mortgages, pensions, health issues, etc. This costs employers
money. And employers HATE giving money because they feel like since you are
getting a meager salary they are already doing you a giant favor.

Its a management cultural issue, not an older programmer issue really.

------
throwawaymanbot
I think, outside of Hollywood. The Tech industry in general is one of the most
ageist.

------
cortexio
didn't read the article, clearly just self promotion.

------
lozzo
the article is interesting yet based. Most notably, it's clearly written by an
old programmer.

~~~
salvar
So clearly that the author explicitly states that he is one: "I know this,
because I am one."

------
tvaughan
For hire:
[https://www.linkedin.com/in/tvaughan](https://www.linkedin.com/in/tvaughan)

------
Bahamut
To add a dissenting view, ideally I want more seasoned developers, so older is
better. However, I still want to hire the right developers. I have worked with
some older/experienced developers who were deficient in various ways,
including one who had no concept of separation of concerns or testing code.

I think this goes to the mindset that it is always important to try to prove
your skills by example.

------
eganist
If an attorney were building an age discrimination case against a person (or
entity, per jacquesm below) involved in the rejection of a younger candidate,
posts like this are among the evidence I suspect would be used to point to a
discriminatory mindset. That said, I'm not a lawyer.

If someone were to be making hiring decisions, posts like this discovered
during the course of casual googling would oblige the person with a robust
basis not to hire. Heck, at least one firm on my CV has instructed me to
regard discriminatory language involving suspect classification, age included,
as grounds to reject.

~~~
jacquesm
(1) You don't make legal cases against people involved in a hiring rejection,
you make a case against a company.

(2) If you are making hiring decisions the appearance of random blog posts
should not and will not give you any legal basis not to hire. Legality is
encoded in the law, not in blogposts, especially not in blogposts by random
passers by. If you were using this as a reason not to hire the person writing
the blog post then you _might_ get some mileage out of it but it could also
easily backfire.

~~~
eganist
> (1) You don't make legal cases against people involved in a hiring
> rejection, you make a case against a company.

Entirely true. In my defense, I'm not a lawyer. Technically also in my
defense: the United States has a bad habit of calling corporations people.

> (2) If you are making hiring decisions the appearance of random blog posts
> should not and will not give you any legal basis not to hire. Legality is
> encoded in the law, not in blogposts, especially not in blogposts by random
> passers by. If you were using this as a reason not to hire the person
> writing the blog post then you might get some mileage out of it but it could
> also easily backfire.

This may be true in the Netherlands, but in many states in the US, quite a
number of things can be used as grounds to not hire, _with the notable
exception of_ anything involving suspect classification
([https://en.wikipedia.org/wiki/Suspect_classification](https://en.wikipedia.org/wiki/Suspect_classification)).
_My understanding_ is that if someone is likely to cause the firm to be
responsible for illegal conduct e.g. age discrimination, for many firms,
that's a sufficient basis not to hire.

I'd love to be corrected, though.

~~~
jacquesm
> if someone is likely to cause the firm to be responsible for illegal conduct

HR policies are what takes care of that, if an individual is able to make the
company engage in illegal behavior you have bigger problems in the oversight
department. Hiring comes with a bunch of rules, this person should not be able
to transcend those rules by their lonesome.

~~~
eganist
We're not at all in disagreement, but even after an enforcement action is
taken within the firm, if the illegal act has already taken place, you'll
still find lawyers willing to go after the firm.

Policies don't physically prohibit certain conduct; they merely provide a
framework of consequences to discourage it. That's also why policies exist on
when not to hire someone: to minimize the risk of the new hire acting in
violation of policies.

