Hacker News Reader

Comment by agrippanux | Hacker News Reader

Age discrimination being rampant in our industry is a fantastic opportunity for an astute hiring manager.

I go out of my way to hire older devs that are eschewed by typical Bay Area startups. I can get a seasoned pro with a solid background in C - and other more trendy languages - for about the same price of a 3-years-working-experience "senior dev" who likely was battlefield commissioned into the role at their last startup.

The typical solid dev can only put in 4, maybe 5-6 hours of actual good coding a day. If you know how to run a tight org - and not a sweatshop of 20-year olds pulling 16 hour days where only maybe 2-3 hours are actual programming time - then older devs are a fantastic bargain. Plus, when it comes time to architect something complex, I have found older devs typically create more simple and elegant solutions just because they have been exposed to more.

Of course, I do run into the occasional stuck-in-the-mud older dev who is very slow to adapt to current trends and wants everyone else to get off their lawn. That has been a rare exception to my overall experience and I don't think it should be used to stereotype the older devs as a group.

View on HN

> The typical solid dev can only put in 4, maybe 5-6 hours of actual good coding a day.

Outside of extremely rare triage situations, this limit is true for all developers, regardless of age or quality of output. Beyond about the 6 hour mark, people can force themselves to sit in a chair and hit keys on a keyboard like the Swedish chef from the muppets, but it's pure management denial to believe those hours count as "productivity" and in fact when the defect rates start to get high and fatigue compounds and morale drops, it's really anti-productive.

Really, younger age is just usually correlated with fewer extracurricular responsibilities, i.e. home repair, health maintenance, domestic responsibilities, marriage, children, etc. These things tend to increase with age, making it a scheduling impossibility for older workers to sit in the chair at 8 pm going "hur duh dur" while slapping keys.

> this limit is true for all developers

Maybe sober, but that's not the limit once you factor in the rampant use of amphetamine.

This is probably a myth, but I've heard Kerouac wrote On the Road practically in a single sitting thanks to the peppy magic of Benzedrine, aka Bennies, a _widely_ available inhalant & pill form of amphetamine.

I think it was 3 weeks and a roll of teletype paper so that once he started he wouldn't have to stop to even change the paper.

edit: https://www.theguardian.com/books/2008/dec/02/jack-kerouac-r... the "scroll"

True but generally not good information to propagate, not for selfish reasons, just because it sets an unreasonably high standard

It’s true you can knock out a 10-20hr session in essentially one sitting, but it’s not a good habit to set for yourself or the industry

I have recently started working remotely and dealing with my own productivity as opposed to have some expectations of work hours has been an interesting challenge.

Since I log my own hours I became full aware of this 6 hours "ceiling" in the long term, for a few days I could work for many more hours, but that would have a big price to pay in future productivity. In the beginning I felt bad, as if I was not able to produce as much as other people leading to a lot of anxiety. As I realized that my actual productivity was going up, compared to my older self and other peers, I embraced it.

Now I work 6 productive hours and to me that's 8 hours of work, my results are better month by month, my quality of life is better and my anxiety is more controlled. Everybody wins.

Please, please, please let everybody come to this conclusion. How much better would the world be as place. I’ve wasted many hours of my time at work, not working, which is so sad

I personally allocate the work day into one 4-hour block as my "big pipe", one 2-hour block as my "little pipe", and let the other 2 hours be "fluff". For limited intervals, I can combine the two pipes into one "mega pipe", to get a "big pipe" task done faster, but it takes a toll over time. The "big pipe" can also theoretically be split into two more temporary "little pipes", but in general, I usually want to have the "big pipe" around to get something important done, and multitasking on three things creates too much organizational overhead, so that also takes a toll.

"Fluff" time is for sitting in meetings or writing reports, as work functions, or for just looking busy. I intentionally avoid doing real work that requires any focus or creativity in the fluff slot. After six hours of real work, any more time spent doing the same thing starts to become counterproductive. So just leave it for tomorrow.

I have been more productive while explicitly dedicating 2 hours a day to getting nothing useful done, than when trying to stay focused on one thing for 8 hours, and ending up goofing off, getting sidetracked, or procrastinating for some amount of time anyway.

That's the theory, anyway. My current employer doesn't keep my pipelines reliably filled. During the dry spells, I have a hard time expanding the fluff slot to more than two hours, and end up doing stuff like coding stupid CLI games, or vectorizing the company logo, or setting up a new vanilla VM that I might not ever use.

That's exactly how I do with my work day. 2-hours / lunch / 4-hours / stop working or anything else less demanding

Don't ever yield to the temptation of working more remotely because you save on commuting time etc. and can be in the flow for longer. Once you do that 4-5 years, you are likely to be long-term burned out. Balance your brain by doing completely different things in your real life, don't work past 8 hours.

Yeah, I always try to keep that in mind.

Based on what I have seen, even 6 productive hours is a high bar even in people that stay in the office 10+ hours a day. Simple things like getting a drink of water or going to the bathroom often take far longer in a cubicle farm than at home. Add having nothing to do, random IT problems, chit chat, checking the phone or other web browsing etc, and the average IT worker might be doing 3-4.

Maybe you also accrue enough wisdom to know that after that 5-6 hours, however productive you might feel, what you write is going to be garbage so the smartest thing to do is stop, unless you want to waste even more time sorting out the mess later.

I can still code for longer than this, from time to time, but only if I already know exactly where I'm going. Even then it's playing with fire.

> I go out of my way to hire older devs that are eschewed by typical Bay Area startups

Going "out of [your] way" to hire older devs sounds like age discrimination. AFAIK, age discrimination in this direction isn't illegal in America, but it seems odd that you would respond to an article decrying age-discrimination by proudly declaring that you discriminate too, in the opposite direction. Maybe you just meant that you almost always find the qualities/compensation-demands you're looking for in older applicants rather than younger ones, but your phrasing doesn't seem to indicate that.

You're right it's not illegal and all you have to do is say you want someone with at least 20 years of professional software development experience...

It's not age discrimination if you accept and do not otherwise discriminate against young/younger candidates. There's a lot that goes into recruiting. Optimizing your job descriptions, creating multiple job descriptions, and targeting your ad spend are all things that can affect the age, race, gender, education level, etc of the people you reach without being discriminatory.

In fact, you should do this to be inclusive. There are a lot of unconscious things hiring managers do that remove themselves from the running of highly qualified candidates.

Want to remove yourself from consideration from young talented female developers? Create a laundry list of "requirements" even though you consider them "nice to haves." Also add plenty of trigger words to make your business seem unattractive.

https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless... https://www.forbes.com/sites/hbsworkingknowledge/2016/12/14/...

Avoiding hurting yourself in the eyes of candidates you'd like to include is far from being discriminatory to other groups.

> There's a lot that goes into recruiting. Optimizing your job descriptions, creating multiple job descriptions, and targeting your ad spend are all things that can affect the age, race, gender, education level, etc of the people you reach without being discriminatory.

Wait...isn't this exactly what the article is talking about?

'Targeting your ad spend' is the thing under fire here, and under a very specific attack.

Before online advertising you kind of had an idea of what the target audience of TV channels, news, and radio was like, but it was very fuzzy and you certainly weren't excluding people not in your target demographic that happened to utilize those media platforms. Women reading male fitness magazines or men reading female lifestyle magazines weren't the primary target of ads in those platforms, but they could certainly utilize what was being advertised if they so desired. The same is not true of online advertising today.

Facebook is more in the position of a newsstand than anything else, and it would be blatant discrimination if a newsstand wasn't allowing older people to buy technology magazines, for example.

AFAIK in USA, age discrimination is forbidden only against people older than 40, it's legal to discriminate against any groups younger than that (including 35-39 year olds) as much as you want.

It sounds more like experience discrimination.

The GP said "older devs" but what they are talking about isn't age, they are talking about skills and experience level.

Everything is discrimination - if you're seeking to hire a software engineer you're probably going to discriminate against people who don't know how to code, people with low IQs, people who can't get along with the team, etc.

The question becomes, is the discrimination legal and/or ethical and based on actual business needs? If the GP noticed they can get a seasoned developer for only slightly above the price of a jr developer (who sees themselves as "senior") , that doesn't really seem like immoral discrimination to me, especially if they are more than willing to also hire jr engineers at jr engineer prices. Most places cant, for business reasons, survive alone solely on senior engineers.

(Interestingly enough, in the US, discrimination based on age because "old people are stupid" is illegal whereas discrimination on age based on "young people are stupid" is not.)

Once upon a time "discrimination" had positive connotations, e.g. "he has discriminating tastes".

Somehow the word has been twisted to be almost exclusively negative.

But show me an organization that doesn't discriminate, and I'll show you an organization of utter incompetence.

The "somehow" is no mystery; discriminatory practice was (and still is) used to stack the deck against people in the United States based on the color of their skin for hundreds of years.

"President" was chosen as the title of the head of the US Executive Branch because it was a title with nearly no prestige; it was the sort of name you'd give to the Robert's Rules enforcer for community meetings. Words take on a connotation history provides them.

Not a complete mystery, but also leaves English without a good substitute.

"Differentiation" is the word I have to use now.

The word "judge" has become like that, too. "How dare you judge people" is a common rage. But having good judgement is critical for your very existence, that is, you must judge everything you come into contact with. Making good judgements can literally mean the difference between life and death. And making judgements about the people you engage with, i.e. judging them, can mean the difference between happiness and misery.

> Somehow the word has been twisted to be almost exclusively negative.

Webster gives pride of place to both the transitive and intransitive definitions that could fit your "once upon a time" definition.[1]

Furthermore, of the six definitions given, five are what I'd consider a trait or ability that is wholly positive to possess. Only the 2nd definition for the intransitive form has a negative connotation.

> But show me an organization that doesn't discriminate, and I'll show you an organization of utter incompetence.

Any organization that isn't utterly incompetent would avoid using the ambiguous word "discriminate" in place of the unambiguous phrase "use good judgment."

Also, HR is just one tiny and narrow domain of human affairs. Music, writing, even dating see way more use of the positive definitions of "discriminate."

[1] https://www.merriam-webster.com/dictionary/discriminate

> Webster gives pride of place

In practice, discrimination has largely negative connotations https://english.stackexchange.com/questions/183093/is-there-...

> "use good judgment."

"The screening exercise _____ aggressively."

* "The screening exercise uses good judgement aggressively." Awkward.

* "The screening exercise filters aggressively." No implication that choice is based on the candidate's characteristics instead of random chance.

* "The screening exercise distinguishes aggressively". Sounds odd, plus has positive rather than neutral connotations.

* "The screening exercise differentiates aggressively " Best one, though it doesn't hint at the pass/fail nature of the distinction.

Going out of your way to recruit and have older applicants apply is not discrimination as long as you treat all applicants equally once they apply.

Is there some kind of asymmetry that prevents this logic from being applied with "older" replaced by other inherent physical attributes like race, or do you think that wouldn't be discrimination either?

Maybe the fact that everyone becomes old, whereas with other protected classes, everyone does not eventually gain membership into that class. So society as a whole is more sympathetic to discrimination that favors the older maybe because we can see ourselves in their shoes.

Age discrimination applies for workers/applicants >= 40.

In this case, it sounds more like moneyball than age discrimination. By "moneyball", I mean that in very intense recruiting environments, you have to get strategic about ways to find talent that may have been overlooked.

https://en.wikipedia.org/wiki/Moneyball

aka recruiting

I think you're confusing age with experience. The sad fact is that experience in important, and there's only way of getting it, letting time go by.

I prefer hiring people in their 30ies. It’s the perfect mix of being old enough to be practical and patient and young enough to still be cheap. The cheap bit comes from being in the Danish public sector where seniority gives automatic pay increases that you can’t legally turn down, so there is that.

I do wonder why people wouldn’t hire older programmers or engineers though. A lot of them are still extremely nerdy about their hobby, they have profound amounts of experience and they’ll typically both be able to follow orders and voice their opinions. Often they’ll have a good grip on work life balancing as well, making them less prone to stress.

I’m not sure ageism is really a big problem though. I haven’t seen any unemployment numbers on old programmers being huge, though I will admit that fear of abuse was one of the reasons I went into management.

That being said, I do think people should plan their staff to be without huge age gaps. It’s one of the few things that has an empirical proven negative effect on teams. But that goes both ways.

Couple points I’ve seen that can knock older (and not wiser) devs -

* fixing the problems they had at their last company, inappropriately so to the point of over-engineering. Sometimes it’s not elegant, but hardened against the wrong things

* insistence on older technologies and patternss that they’re familiar with even if not concise

maybe you mean 'patterns'

My pphones autocorrect might not be working correctly ;)

>I prefer hiring people in their 30ies.

>I’m not sure ageism is really a big problem though.

I'm not sure you can put both those statements together without sounding uninformed.

Its only ageism when other people do it.

I do wonder why people wouldn’t hire older programmers or engineers though

The same reason the military prefers younger over older. Younger developers are easier to manipulate, overwork, and underpay. They are easier to mould and shape in conformance with corporate "culture fit", and they're less likely to question authority. They also don't have the wisdom yet to know when they are being asked to drink the startup Kool-Aid.

Which in a way kind of brings up a point - sometimes you need idealists to see things through, to have a chance. A crusty pessimistic person isn’t necessarily battle-hardened, they may be battle-broken.

Of course, that doesn’t have much to do with age - one can be closed to new ideas at any age.

I think in Scandinavia it is different because we actually have laws saying you cannot force people to work the extreme amounts of overtime that they do in USA or in China. So older devs could be using the time they have more efficiently. My experience is also that older devs are very sought after. It could also have something to do with the shortage of developers here though.

Five of the six people on my team, including me, are over 30; four of us are over 40. I must admit that although devs with that level of experience are "expensive", they start to look a lot cheaper when you realise the additional value they add due to experience. Software development, as with many things in life, often follows the adage that you get what you pay for. (It should go without saying, but it's a sad inevitability that there will be exceptions.)

A part of the higher pay grade is that the majority of the mistakes one must make to gain experience points have been paid for.

Also, maturity often comes with a reduction of the ego-driven drama friction which can make people so much more pleasant to work with.

But many startups are "ship first, debug later". When it's a pump-and-dump fashion contest, younger fingers are probably better: a fast BS-nozzle to get VC attention. If instead you want your infrastructure to last 5 or 10 years and not get hacked, then experience will pay off.

The over 40s I know are also able to produce working crap faster than the young-uns. If you call it a prototype (so the goal is showing functionality that works but later it will be tossed out and redone) then hiring me is probably going to produce a better one (less bugs and will probably last until the startup runs out of money) then it would with a ‘team of young ninjas’. As PR for VCs I can see a bunch of young people might look better (not to many VCs I talk to but I so not live in the US), but if you want ‘faster’, a 35+ who kept up is probably faster and cheaper. In my experience. When the company grows I definitely would not want a CTO under 35/40.

Re: The over 40s I know are also able to produce working [prototypes] faster...

Not necessarily if it has to be built in some stack or language flavor of the month (and VC's check). If you change entire tool-sets every 18 months, I bet the younger folks will be able to re-learn faster. I'm 40+ myself, and am saying this from experience. It's unfortunate our industry is so fad-driven, but I didn't create humans, I just work among them.

I recommend one focus on a domain (insurance IT, healthcare IT, etc.) when they get around 40. Your domain knowledge will have market value. Reformatting your head all the time is not a good career strategy for most. (There is some value to some new IT things, but a good portion is hype and gimmicks.)

It might be different in different regions and different markets. Here VCs definitely don't check (or care). I find that they are generally more interested in buzzword bingo on a more abstract level; AI, ML, Blockchain etc. That said, I'm not building a religion; if the latest tech is a business goal, then it will happen.

And i'm also not sure if it's true that 'we' would be slower to learn these things; I keep on top because, I feel, that as CTO, I need to understand what is out there and if there is something promising that can help us long term, I want to be early to find it. So I do learn every new fad, and, not to sound cocky because I believe it's just experience, there is not much to learn; they are all, in a lot of ways, rehashes. Sometimes you see something really innovative, but that's not the thing that ends up being a fad or even remotely popular. After 30+ years of programming in many different technologies/projects (especially the functional experience helps a lot these days) etc it is easy to recognize the patterns and the goals the programmer was going for when building that new tech. Not that I would want that job as a non-cto at a startup :)

Maybe you are CTO and I'm not because my brain is not fast enough to keep up. Yes, a lot of it is rehashes of old things, but I keep inter-confusing the old incarnations with the new ones when coding. You can't cross-confuse 2 things if you never met one of them. Plus, its hard to keep enthusiasm up for the 500th reinvention of the wheel. Maybe I'll reinvent stronger coffee; call it "Covfefe 2.0", or "Blockchain Covfefe"...

Yeah I see what you mean: I have something like that; I get enthusiastic because I see people apparently solving things that annoy me. So I go and try them and find they made things worse, usually. Sometimes, however, it is really great and then we start using it.

So can our org pay yours to be our guinea-pigs? :-)

I think this depends on the difference of perspective between startup->fledgling-and-profitable company CTO and Fortune 500 CTO.

I feel like in the case of the later, the priorities are much more in the order of 1) manage business risk wrt technology, and 2) manage organizational processes wrt technology.

Tech is only the thing that gets you to the thing and the usefulness of anything new is either a) readily apparent (like from orbit), or b) can only be brought in from outside talent (failure of priority #2) or learned from falling on your ass (failure of priority #1).

My point being, it is of little benefit in this scenario to spend any time actually learning the latest fad tech.

I agree with that; the bigger the company the more business like the CTO is. I consulted the CTO of a large insurance company: he showed me (and told me) I never really want to become that. I like getting people to make great things that benefit the business; I make myself know about the business, budgets etc. I believe some companies are underestimating tech and what it can do, at any scale; I believe I add value to the bottomline there. Learning new tech is not for the direct benefit of the company/business but it is indirect; I need to know how to talk to people in my teams. When they talk about something new and ask ‘why not this’, I am not the manager that said ‘stfu and work on what we pay you for’; I like to discuss it and I cannot do that if I did not try it. If someone convinces me it is a good idea, then we can do a PoC. I could just ask someone else to do that research and, as companies grow that is inevitable, at this moment however, I think I am doing a good thing.

> I recommend one focus on a domain (insurance IT, healthcare IT, etc.)

So that others benefit from my experience: the cheat code to this is to work in marketing tech. You will have domain experience in all of these in a relatively short time because you will have had to deal with partners & clients from these domains.

You also learn very quickly how any company makes its money, what they consider positive contributions to the bottom line and how you can be one of those.

Except for at the fringes of new tech, traditional business is far more personally rewarding than working in the seeking-funding startup snakepit.

> I bet the younger folks will be able to re-learn faster.

This is another place where experience helps. I can definitely learn a new framework faster now that I've had 10+ years experience than I could when I first started.

You might be able to find more younger people who already know the framework of the month.

It is really ironic that an industry focused on engineering can act in such an irrational manner. Long hours in the office chair is only a measurement of management’s failure to pay attention to the metrics that matter.

Strongly preferring less experienced devs because they can work longer (which they need to, partially to compensate for their lack of experience), is both tragic and comical. It’s likely the pay is lower for the younger devs but the very practice of working long hours has been proven as detrimental to quality.

> an industry focused on engineering

I'm not sure that's the whole story, though, especially considering how much of the "industry" is VC-driven and how few VCs are engineers.

You ever play the video game "World of Goo?" That's my image of what shortsighted engineering can get you.

Trailer: https://www.youtube.com/watch?v=-A_JfkzPwww

I understand your intent and I'm not suggesting you oughta do anything differently, but I am not sure how net good it is that older devs' labor is being sold at a discount.

My understanding is that silicon valley hasn't cured aging yet, so until that happens, this seems like yet another market distortion that favors employers at the expense of labor (or 'YAMDTFEAEL' for short)

I like to think of it as hiring people with actual years of experience. I don't care what their age is or their title. Are they a senior developer only because they have 6 more months than the other guy at the startup or are they senior because they've had 6 jobs over twice as many years? Those years add add experience in doing things the wrong way and in ways that work.

Are you hiring?

Why would you go out of your way?

You could actually read the comment and have your confusion resolved.

Are you sure? I hired these seasoned pros you talk about. I have a team of 12 developers and 3 of these seasoned pros that are about 60+ yrs old. C/C++ devs. They are the worst performing on the team. The 22/23yrs old are running circles around them. They are slow, taking 2-5x times as long to finish their task. It's no better in quality. They are seriously struggling to pick up new technologies. I'm a minority so I'm pretty open minded and built a diverse team race, gender, age, sexuality, whatever. Oh yeah, they are also very well paid due to the past experience! Sometimes as much as twice as the new grads. The one quality that scares the crap out of me for the future is ... Please do note that I'm not talking about 10hr shifts, work on weekends kinda environment. Just the typical come in at 9ish leave at 6 environment. I'm getting older myself too so I understand.

What are your quality metrics and over what timescale are you measuring?

Are you treating everyone in your organization as equivalent resources or are you allocating people based on strengths/specialties?

Having a heterogeneous team with breadth of experience across the stack helps to isolate you from the real business risks of group-think and "not knowing what you don't know". It's a hedge and a pillar of a resilient, long-term-oriented organization.

If you just want to have a get-shit-done culture, move fast and pivot/abort when things get bad, you probably want all 20 year olds. However, if you look at the organizational structure of banks, who are literally in the business of managing business risk, you will see diversity and redundancy in hiring.

Side note: Every single time I've seen a complaint about X group doesn't work as effectively as Y group, it's almost always a management misallocation of (human) resource. Not calling you out specifically, just wondering how much thought was put into team/work structure.

Reply on news.ycombinator.com