Hacker News Reader

Comment by freyir | Hacker News Reader

> "why there are such a few percentage of older folks in engineering"

No, there's a small percentage of older folks in software engineering. In almost any other engineering discipline, you'll find many older engineers who enjoy long careers, and whose perceived value often grows with age. That's because actual engineering principles change very slowly.

Most software jobs do not involve much engineering in the traditional sense; most of the effort is keeping up with the constant churn of flavor-of-the-week libraries and frameworks, information that will be often be outdated and useless in a few years.

View on HN

>will be often be outdated and useless in a few years.

Often it's "useless now and outdated in a few years". It's amazing how much software today justifies its existence through a weird self-referential loop that isn't connected to solving any problems outside of itself. Complex tools to manage complexity and so on.

The usual pattern is that the generation N - 1 of a tool didn't solve for some dimension D_n of the problem, so generation N is created that handles D_n.

The usual defect is that generation N isn't very good at D_n-x where x is greater than the mean experience of the implementing engineer(s), and often isn't even very good at D_n-1.

I see you’ve worked with Angular before.

If I see one more blog post that has step 1 as "install composer/bower/npm", I might vomit.

When you need a finicky "dependency manager" just to get started writing something, you've already lost.

I opted for a recent webgl driven app to use no framework for our frontend code and it was lovely. It really makes me wonder why they get pushed so hard. There are no 'indications for use', just 'its HOT right now'.

MSBuild... cough

Msbuild, MSdeploy, and SqlPackage are those kinds of techs where I profoundly resent the man-hours I've spent learning to work around their quirks.

I have no doubt there is some age discrimination, though I haven't experienced it personally. What I want to point out here is that there were a lot fewer of us in total when I first started (I'm 58 now). I find very few peers my own age now, but I also found very few peers my own age when I was 25. So just going by percentages may be misleading for a relatively young discipline.

I wonder about that, too, although I'm "only" 45. I still have tons of people pinging me with new job offers, and they don't look like the sort of job offers that they're going to offer a 25-year-old. Regardless, I put a lot of effort into making sure that they need me more than I need them.

> information that will be often be outdated and useless in a few years

but this is was HR believes, not the actual reality of software engineering nor of software development.

the concepts between persistence, object model mapping, handling user events, propagating user intent to business logic, share data between heterogeneous systems and present everything coherently to the user are not going to change so all the solutions are going to look and feel the same since stems from the same problems.

I mean for example chaining template for code reuse isn't something that only react ever did, I remember turbogear doing something very similar conceptually with how nesting widgets and widget having each their own template and dictionary of inputs that took from the model state directly and the lesson you learn on problem solving and code reuse do stay with you a long time, longer than any single framework.

I'm always unsure about how to judge whether the lower percentages of older engineers I see is due to age discrimination or just a low percentage of older engineers period. Software developers are young in general. And interestingly the United States has the highest average age [1]. At my workplace I can count at least one "greybeard" on most teams. I don't get the sense that they are discriminated against because of their age. I've always enjoyed talking with them about how software development used to be back in the day. I remember talking to one guy that worked on a text editor back in the 80s that was backed by a mainframe. The terminal didn't have enough computing power to manage the whole document, so it only stored a few pages locally and swapped them in from the mainframe as the user scrolled to them. Things like bulk find-replace were done via an RPC. It's interesting how many parallels this has to modern client-server web-apps. I especially like to hear from people that programmed on punch cards - that's kind of stuff is fascinating to me.

I also wonder how much of the perceived age discrimination is due to expectations of an ever-increasing salary. I remember one older co-worker that interviewed for a job, liked the company, and got an offer that he dismissed as "not much higher than entry level" and even called the offer insulting. My line of reasoning was that if he didn't have relevant domain experience why wouldn't get paid not much more than a new grad? It was still well into the 100-200k range - in the Bay Area but in a cheaper city (San Bruno I think). More than enough to save and live a comfortable life. I wonder how much of the perceived age discrimination is more about being realistic about the fact that years of experience don't automatically translate into higher productivity, paying younger folk commensurate with their contribution - as opposed to other industries where it's entrenched that young people get paid less and older people get paid more.

Not saying age discrimination doesn't exist. I've seen job adverts that explicitly specified an age cap of 40 (despite this being blatantly illegal).

1. https://www.businessinsider.com/silicon-valley-age-programme...

It's worth noting that surveying from Stack Overflow can mean significant selecting bias.

I think you hit the nail on the head. Absolutely age discrimination exists but there are also other factors at play in some situations. Without specific domain knowledge or management experience there is a ceiling to how much experience helps the company.

For a software developer working on standard CRUD database-backed applications, the difference in productivity and usefulness to the company at 5-10 years is really not that different at 20 years.

This effect is also compounded by the fact that the less experienced developer now looks a lot better if he is essentially doing the exact same job that a 20 year experience developer is doing.

Note that what I'm talking about has very little to do with "keeping up with the latest frontend frameworks" or stuff like that. Software engineering in this sense is like a trade - if your sink is broken and you need it fixed, would you hire pay $15 / hour for a plumber with 5 years experience or pay $30 / hour for a plumber with 10 years experience? You know that the sink can be easily fixed by most decent plumbers so the amount of experience they have really doesn't matter beyond a certain point.

If your broken sink is connected to a broken pipe under the street in front of your house on your property, and you find that you need to hire a Master Plumber with a team of juniors to fix it, you may find that the same price/years of experience equation exists.

The hierarchy of the trade union is what sustains this service model in the marketplace.

"hire a Master Plumber with a team of juniors to fix it"

In that situation I would consider the "Master Plumber" akin to a lead developer or project manager. Which goes back to my main point - in software development you eventually need to either move to a management/leadership role or specialise in domain specific fields like security, computer graphics, systems architecture etc.

Wouldn't that be the responsibility of the water company which is civil engineering

Every house has a connection to the water main - what happens after that connection point is not their responsibility to repair.

But they will shut it off if you don’t fix it in, say, 10 days...

"You know that the sink can be easily fixed by most decent plumbers"

Find a decent plumber who isn't so busy that they will do a small job like fixing a sink - now that is the real problem.

And bad plumbers can create chaos in ways that would make lawyers jealous - we had to call the police on a plumber once....

>I also wonder how much of the perceived age discrimination is due to expectations of an ever-increasing salary.

Expectations on whose part? Based on what I read here on HN, many employers don't want to even interview older applicants because they are just so sure that any older person is going to demand too much money.

Granted, the reaction of my older co-worker has demonstrated (albeit in only one instance) that this assumption does hold true.

> My line of reasoning was that if he didn't have relevant > domain experience why wouldn't get paid not much more than > a new grad?

Presumably because you're paying him for his ability to apply his broader knowledge and experience to this domain; he is not coming to the table with the same limited set of tools as the new graduate. He will be up to speed more quickly, and his solutions will tend to be more comprehensive because of his wider perspective.

If the interviewing company isn't looking for that, then the offer reflects their present needs -- not the candidate's capabilities. I could see how that's insulting, since that's a whole lot of wasted time.

> I've always enjoyed talking with them about how software development used to be back in the day. From your words I see that you value their knowledge of things past, but I don't see anything about enjoying the discussion of current/future development with them. Is that not something that you value as much, or that you find in some way lacking? Or something that you haven't explored because of age?

How much more productive is a developer with 20 years experience working on something [s]he has no direct domain knowledge about vs. one with 2-3 years? Probably not enough to justify a very substantial salary difference.

Re: enjoying talking about current development. I do enjoy that as well, but that's not specifix to age or experience. The sane discussions can be had with less experienced people. Older developers uniquely offer those experiences.

Yea. As a traditional engineer (non software) I shudder in horror at what y'all go through. My industry is all about what you know and there seems to be nearly infinite things to know. That knowledge takes years to accumulate, so a Senior Engineer with 10 years of experience almost always has an order of magnitude more value than a novice engineer. Although there are some seniors that I have no idea how they got promoted, it is generally rare.

Successful companies don't have this sort of framework churn. You see it in the startup world because companies are always starting up right when some new framework came out. But anything out of the MVP stage doesn't churn on frameworks, unless something went horribly wrong - like passing on experienced engineers.

>Successful companies don't have this sort of framework churn.

Sure they do. They're just slower at it. I've seen plenty of established companies jump on React bandwagon right after jumping off Angular, for example. One year and the "new" framework is thrown out of the window. (But all the software written in it remains and creates maintenance liability.)

Funny thing is, more often than not they don't even need SPAs in the first place.

It happens, but usually for some decent reason.

Some companies for instance have a very stable business and keep a stable stack, but then hit a wall when trying to hire. They'll see average people coming to them, but those are not as efficient as their current staff who is now super experienced and want people who can match them.

Or they'll try to find graduate level people to train forward, but newcomers have no interest in the old stack, as it won't pimp their resume that much to their eyes.

Solution: keep using trendy frameworks.

Veterans will be happy to see shiny things, recruiting becomes that much easier, buzzword capacity increases all other the map. And all of these have a real benefit, in people retention, hiring cost, marketing opportunities that can cover the man/hour cost of moving frameworks.

True not everything is like the crazy front-end JS world but when it comes to age we're talking about a very long timescale. Say ~40yrs in the business (20+40=60).

How many companies maintain a framework/stack from 20-30yrs ago? The average new company will die after ~7yrs from start date. Only a few major monopoly-style companies survive like IBM and Microsoft. Which is basically the only software that runs forever on that type of scale. That's only a percentage of available jobs.

And even within IBM and Microsoft there are countless sub-projects within the company...beyond say the classic Windows OS, Word, etc from the 90s there are tons of other programming work going on (for ex: VSCode is JS or IBM's cloud + consulting work). Very few of those newer projects are going to look much like the 20yr old one you cut your teeth on early in your careerr.

I don't think no one is saying age discrimination doesn't exist. But this is a unique problem in our industry rarely found in other fields.

    Very few of those newer projects are going to 
    look much like the 20yr old one you cut your 
    teeth on early in your careerr.

Maybe I'm too young to comment, but my first job as a developer was almost 18 years ago now & even tho I'm no longer using the same language & tools a lot of the challenges of software engineering are the same now as it was then (and you learn using new stuff incrementally anyway).

Overall the experience of developing a comparable-scale project in java on tomcat in 2001 is not that different from a modern one in ES6 on node.js in 2019.

I've been doing this about the same amount of time, and yes, everything is the same as it was 20 years ago. Frameworks come and go, but they aren't that different. And you are hopefully mostly writing application code not framework glue. So the framework doesn't matter.

All the popular languages are sadly still descendants of C, just with variations on the strongly/weakly typed spectrum, and if functions are first or second class.

The hard stuff is still identifying requirements, managing expectations, and writing code that can adapt to changing requirements overtime. None of the hard stuff has anything to do with the language or framework you are using.

That's even worse then: You are honing obsolete skills and will have a hard time finding a new job if you want or have to.

So you are an expert in Java service oriented architecture? Sorry, but we are now looking for developers with Spring Boot 2.x Microservice experience.

Well, software folklore seems to say that COBOL graybeards get paid A LOT.

Does this hold for everything? Do we have any other examples besides the fabled COBOL developer?

Are application server / Java XML SOA graybeards also paid a lot?

My current technological focus are Spring Boot applications, seasoned with everything that comes with that: SQL, devops basics, etc. If Spring Boot is still a thing in 10 - 20 years I'd be extremely surprised.

  most of the effort is keeping up with the constant churn of flavor-of-the-week

But that only applies to new and recent code bases.

The age purge is ongoing even for long-established, mature code bases and projects, e.g. IBM, HCL, etc.

It's been awhile, but I interviewed at LinkedIn some years ago and it sounded very much like an anything-goes ethic. It was based on feature ownership, so if you had an idea you could implement it however you wanted as long as you also supported it. I was left to think that flavor-of-the-week is very much a part of life there if a programmer wants it.

Citations needed. You're basically saying "old people don't learn new things."

My experience has been very different from what you're suggesting. All the "older folks" I've worked with know everything about your favorite framework...they just don't care. After you've been through the cycle for 10 years or so you cease to be impressed.

> Most software jobs do not involve much engineering in the traditional sense; most of the effort is keeping up with the constant churn of flavor-of-the-week libraries and frameworks[...]

I'm not so sure about that. Yes, keeping up with the latest tech is a lot of effort, but the majority of software development is using those tools to actually solve problems. And the principles used to solve those problems don't change all that much. Patterns of Enterprise Application Architecture came out almost 20 years ago but is still useful today.

But companies are not hiring for software architecture and enterprise patterns. They are hiring for flavor-of-the-week.

Is that just Silicon Valley though? I'd wager there are just as many companies out there trying to support a legacy code base or just doing straight up SharePoint work than worrying about the latest and greatest flavour of the month.

Exactly. The flip side of the constant churn is the majority of companies have code bases that are not the flavour of the month that they need to support. Given enough time, most companies will end up with multiple generations of flavours of the month that require attention.

Are the people who are old now part of the flavor of the week framework frenzy? Or were they before AJAX was a hot term?

Software engineering is a new field, and therefore has fewer oldies.

It's really not. There were people long retired before I hit the workplace and I'm fast approaching 50.

There is a combination of seemingly relentless growth in demand and people deciding they've had enough and hitting the management track however. At least in London/finance. The number of people I started with that are still coding on a daily basis is very small.

Yes

Reply on news.ycombinator.com