Hacker News Reader

Comment by C4stor | Hacker News Reader

I'm not sure I'm buying that. The JVM ? Still rocking it 20 years after. Memory allocations pattern ? Still there. The network stack ? Well, doesn't seem to have changed a lot.

The older guys, they seem like they had the time to correctly learn the unix network tools, the jvm debugging ones, the memory inspection ones. I've known older devs for which I have the utmost respect because I felt like they can just debug the shit out of anything happening on a computer, with tools I don't even know of but have been there for decades.

And here I am, needing to google how use tcpdump or jstack, and scrambling to correctly understand the result.

I agree that new tech is always stacking, but I feel like it's pretty damn hard to catch up on the in fact still very relevant and important old one, because it's no longer taught, no longer a meetup topic, no longer hype. And the new one is really easy to learn when you realize that it's 90% rehashing of old concepts (Observables are all the hype in javascript ? Well, great, I've learnt that pattern 15 years ago...)

Admittedly, I have no clue if the management realizes that !

But the impact of this knowledge, from what I observed, is really huge on productivity, and is especially a boon when the production is on fire or generally when tricky stuff happens.

So, respect for the elders, and please come and teach in conferences and meetups, we need more wisdom and less hype !

View on HN

Yeah, you hear all these horror stories about how developers have a "shelf life."

In the meantime, though, every single older developer I've met has been extremely knowledgeable and frankly much better at the craft than myself.

Look at any hobby -- say, guitar playing. The difference between someone who's been doing it for 4 years and someone who's been doing it 20 years is ridiculous. They're so much better. I feel software dev isn't that different.

The only problem is if you're older you do need to follow new technologies. Older devs I've talked to who were pushed out of the field are the types who worked on, say, mainframe technology well into the mid-aughts and never thought about learning anything new.

As long as you get off the sinking ship of technologies that are obviously waning (and you should have at least a decade of warning in advance, I think), I don't think it's honestly that hard to stay current. You don't have to follow every fad, but make sure people will continue to use your main programming language.

Also, startups discriminate on age because they need people that can work until 2 AM and drink their Kool Aide. But there's a lot of stable, non-startup jobs out there. People who have never left the scene probably think of it as death, but there's actually some really nice enterprise shops out there with great developers.

> every single older developer I've met has been extremely knowledgeable

To be fair, this observation could be massively influenced by survivorship bias - more talented devs tend to be the ones still programming in older age.

That argument applies in the other direction as well: it's a very relatively young industry full of big industry-wide disruptions at least once a decade since it has been its own industry. Companies with young median and mean ages may have been more likely to survive (or evolve out of) some of those big early disruptions, but that may not be a long term equilibrium for the industry.

Keep in mind, too, how much the 80s, 90s, and 00s median/mean ages were impacted by "flash flood" millionaires that could retire early simply by how much money was thrown around in the various "software revolution" and "Dot Com" booms.

I seriously doubt the number of instant millionaires is significant enough to impact the total numbers. 25% of programmers did not become rich enough to retire, and if so, I'm doing everything wrong.

It was always a matter of luck. If there were ways to predict such a lottery ahead of time, I think the industry would look quite different today.

As with flash floods of rivers, the coverage of such events was complex. It probably affected some companies a lot more than others.

Anecdotally, it used to be an aphorism at Microsoft that if you hadn't made your first million by 30 (or was it 25?) you were doing something wrong. Certainly the demographics at Microsoft showed several clear waves of early retirements from stock booms and bonuses, and for a ~forty year old company the median age is still staggeringly young today, even accounting for industry ageism.

If it wasn't clear, I don't expect those flash floods to happen again, they definitely seem to have been flukes of luck. But I think it shouldn't be ignored that it had an impact on the industry demographics.

> I don't expect those flash floods to happen again

Google, Amazon, Facebook, Netflix... It already happened again multiple times after Microsoft.

At the same time though the industry has an age distribution that reflects the arc of the industry more than the selection of the workers.

I entered the field in the mid-90s and saw the industry hugely explode at the end of that decade. So as all of those nascent developers look around they noticed how few older developers there were and said "boy, this really is a young person's profession!". I remember all of the "before you turn 30, get a plan B" articles then, everyone fearfully looking into management or dubious project management paths.

And as that cadre aged, of course most new workers are younger, so proportionally they drop from a majority to a minority, but there are a massive number of very gainfully employed, successful older developers, and it certainly has been normalized far more than then.

To go with the guitar playing analogy, there's plenty of people that have played the guitar for 20 years and always play the same 4 chords.

Indeed. My previous job was very Java-focused but wanted a more senior man on the team. So management hired a developer with 20 years of experience in C and Fortran.

Now in my country, when you hire someone, a probation period of two months is very common. In that period, you can be fired and/or leave without cause.

Unfortunately, he was not able to pick up object-oriented programming in those two months and left before the probation period expired.

> As long as you get off the sinking ship of technologies that are obviously waning

But then you would have to compete with young people starting out in the same technologies. And they are more naive, more easily manipulated and exploited, corporations love that and prefer that to 20 year experience in the field they can't even understand could be important to all the new technologies.

That's sometimes the plan. But as always, you get what you pay for. Some management teams are savvier than others.

> As long as you get off the sinking ship of technologies that are obviously waning (and you should have at least a decade of warning in advance, I think)

You also don't need to get on the ground floor. Every technology boom creates next years legacy apps, there will be React work for years after the next tool gets popular for one example. The article touches on it, but you can make a good living out of consulting work for older technologies.

Another angle is moving into non-tech domain specialization. Becoming an eCommerce consultant, your value proposition isn't knowing React/Shopify/Demandware etc, it's knowing the eCommerce ecosystem and domain. I know devs who specialize in agribusiness, automotive software, construction, energy infrastructure and such. They build solutions to problems in those spaces that happen to be software. But they get hired based on their time in those industries not their current tech stack.

One thing I've noticed is that there seem to be a lot more older developers and engineers at hardware-oriented companies.

I currently work at Wing Aviation, the Alphabet drone delivery company. We were originally located in the Google X building, which is the old Mayfield Mall in Mountain View. I used to shop at that mall in the 1970s!

X is full of hardware startups, and when I started there I noticed one thing right away: for the first time in a while, I was not the oldest person in the building.

Now that we've moved to our own smaller building, I may be the oldest again, but not by a wide margin. There is a lot of gray hair in our teams.

I'm 67 and have been programming for 50 years.

That's probably not by coincidence. The cost required to fix a hardware/firmware defect vs a software defect is much more. I'd definitely want to put my best engineers on the product that can't be easily fixed once it's shipped vs software than can always be patched.

> I'm 67 and have been programming for 50 years.

Also, that's really impressive. You've probably forgotten more than I've ever learned!

Personally, I find it slightly weird that I've been in the industry longer than some of my co-workers have been alive.

Related experience in the opposite direction: I'm a relatively new software engineer that works on a 13 year old product. It's fun to see a particular commit and think about what I was doing in middle school, high school, or college at the time it was committed.

I mean, I feel like more programmers were working closer to the metal back in the day.

In the 80s you needed to understand computer hardware much better and there was a bigger fraction of C++ developers. Now all those people have migrated to hardware (or have kept doing it) because that's where their skills are needed.

My experience has been that many younger engineers don't want to work closer to the metal as much. They want to work on the bleeding edge, sexier technologies.

I would enjoy working close to the metal in some capacity, it's just not really what the majority of modern tech businesses require, and moving in that direction is likely not worth the sort of career reset it would require.

I've noticed that most dev work is "full-stack developer". This usually means that you'll be bouncing between back-end (python, rails, node, go, w/e), front-end (react, css), and possible devops.

I'm not sure how satisfying this is. You probably don't get much chance to dig deep and solve tough problems, or craft as you would in a hardware-oriented job.

I've never worked in hardware though, so I'm quite possibly complete wrong about their day-in-the-life. Just rampant speculation.

> "mainframe technology well into the mid-aughts and never thought about learning anything new" - today this is called the cloud

What is the new ship we should all be jumping to?

> In the meantime, though, every single older developer I've met has been extremely knowledgeable and frankly much better at the craft than myself.

That just means the field isn't totally corrupt with fashion or nepotism or whatever. Survivor Bias is a perfectly plausible explanation, too.

Every single older guitarist I've met has been a fantastically successful rock musician.

I went "full software" back at the age of 36. I did this because I saw the writing on the wall for systems/devops and being a half-developer, essentially from writing scripts to full OOP.

I put a ton of time and thought, and effort into the change. It wasn't easy to complete the transition and get hired, but I settled on C#. Chosen because C# and Java are similar enough (my only formal education in programming was in Java), and I could move between the two, if I had to. I also saw MS driving the future of .Net really hard, even after about 10 years before it looked like there was no future and MS was going back to unmanaged code. I also wanted as stable of a development platform as possible, an attempt at avoiding churn with all the kiddos in the web space. I'm still working fulltime as a C# dev and enjoy it. But if anything ever happens, I'll jump ship to the Java space. Both the city I live in and less-populated state that I'm from have copious amount of C# and Java jobs available, so I'm not on something so cutting edge that I have to live somewhere specific. It's my opinion that the best balance for most software projects was nailed with Java (and then it's descendent, C#). There's a reason it's so popular and they're not bad reasons.

My dream job is to come full circle and be "the IT guy" at a small company, handling software and systems as a one-man operation. That can be done in the MS space, as less expertise is necessary in general on the systems side to manage the entire stack. Even less so with Azure.

Will I be pushed out? I'm sure. I'm expecting less of a shelf life than the old hats because so many more people are raising their children to be ready for this field. Also, outsourcing/visa migration was fully implemented to diminish the industry for workers, since about 2000. The industry that was supposed to be the next buoy of the American middle class has been successfully undermined by American hypercapitalism. Greatly reducing prospects and the future for even my generation, the golden generation of children that grew up on a Commodore. A special time of astute technologists raised when we had personal computers at home, but before iOS collapsed the barrier of entry and nullified the mystery & effort required to get to entertainment.

Also, most languages are not sinking ships. Certain uses of them are of course. But even languages this site hates, such as C, C++, C#, and Java have very long lives ahead of them for certain uses. Obviously C++ vs Rails... well, you're going to be out of a job. But if you were using C++ for the sorts of things you would have used Rails in 2009 you were already a decade or so behind the curve.

I doubt it. C++ has come a long way in the past decade and still has a lot of momentum.

As for rails? Admittedly I'm in an anti-ruby bubble... but the Ruby developers I do know definitely don't use Rails anymore. Ruby seems to have matured into basically just Chef/Vagrant in my bubble and any Rails apps are being deprecated in favor of the bubble-biased languages.

Rails developer here. It's still quite easy to get a Rails job; maybe not for Google, but easy. There's much less hype but also less competition over jobs (many young developers come with Python/Nodejs backgrounds nowadays, many senior Rubyists left for greener fields).

> But even languages this site hates, such as C, C++, C#, and Java

What makes you think this? I have been on here for years and have never really got this impression.

See:

- Any thread about rust

- Any thread about an exploit in a c variant

I think you miss the point about 'shelf life'

The shelf life is due to a business decision, where the knowledge the older person has is deemed insufficient to justify the compensation they've grown used to.

Sure, you love working with them and it's better for engineering, but the business wants college grads they can pay less, even if they don't do the same quality work.

Importantly, this doesn't have to be logical or good for the business. It just has to make sense in the context of quarterly targets.

It's not just quality, it's capability.

As I'm fond of saying, I may cost twice as much as an entry level engineer, but I can do things that two entry level engineers can't do.

I have a similar expression. My daily price might be higher, but they will cost you more.

More significantly, you can probably do things that no amount of entry-level engineers could do. The question is usually whether your (prospective) employer benefits from any of those things, whether they realise it or not.

As a former software guy, life long computer hacker, who moved to desktop support for years, I ran into new people hired as programmers who had to be coached to hit Ctrl-Alt-Del properly to log into their newly deployed laptop.

I'm working on hiring back into software roles now... I figure if the bar is that low, I can rock it out if I can just convince anyone that I can still code.

Interviews have been interesting.

I keep hearing this but sometimes you just need hands on keyboard to push things out fast. Yes I can do a passable job at front end, middleware, databases, and I'm pretty adept at cloud infrastructure and devops. Does that mean I'm as valuable as 5 people? I can only do one of those at the same time.

It depends entirely on how much autonomy and motivation you have. I have to do all of that for my own modest product, but it's only viable because I have complete autonomy to decide what the most efficient approach would be... and I enjoy it.

This isn't typically how it plays out when you start a new job for someone else. Which means they won't reap the rewards of your experience until enough trust has been built to give you the autonomy to make it happen (this may never happen). So it takes time, and not everyone wants to take that time or can see the benefit, and arguably in the startup space there may not be enough runway for it either.

It’s not about autonomy. I work for a small company where I have a reasonable amount of control of how I implement anything. But, I can only do one thing at a time. At a certain point, you need more people to get anything done in a reasonable amount of time.

This may be true, but your company always wants the most business value, not the best/most elegant/most maintainable code. If you can deliver your boss's business interests at even 1.5x, I think you will have a long career.

I am at a startup just now and they are complaining about frontend devs as - they don't hang around - they don't want to touch the old frontend written in Dojo, just the React stuff.

I'll do whatever (I am officially a 80% backend dev who can do enough frontend when needed). The Dojo way of writing things actually seems a lot nicer than React, but it ain't cool.

I don't care about it being "cool", but I'm not going anywhere near a company doing Dojo because it isn't marketable.

The guitar playing is a good analogy here. Say you've played classical for years and dabbled in rock and some jazz. Like any musician you've played around a little but probably focus on one style. You're best friend asks you to play flemanco for them at their wedding.

Sure, you won't be as good as someone that's played flemanco all their life. But if flemanco was invented 5 years ago you're sure going to pick it up fast and probably be better than someone who has only been playing it for the past few years.

Skills translate. Transfer learning is unsurprisingly a real thing. The funny thing is that a guitar player will pick up a brand new instrument and quickly gain and surpass someone who has only been playing that instrument for a few years. Even though each instrument is a different "language" per say, there are common patterns in the language tree of music. I don't think any programmer worth their salt would disagree that this is also true for programming.

No matter the language you use, there are common patterns. Someone who has been programing for years generally picks up a new language quickly (because of this). Certain languages will make you a better programmer in general too (low level languages help you understand what's going on behind the curtain).

So should a programmer with 30 years of experience in C and 1 year in rust be paid more than the programmer with 5 years of rust experience? Absolutely. Those 30 years they were learning to program, to debug, to solve problems. The skills translate. And I say this as someone under 30. I've seen the wizards solve problems in languages they've never used because they just understand programming.

>No matter the language you use, there are common patterns. Someone who has been programming for years generally picks up a new language quickly (because of this). So should a programmer with 30 years of experience in C and 1 year in rust be paid more than the programmer with 5 years of rust experience? Absolutely. Those 30 years they were learning to program, to debug, to solve problems. The skills translate.

Tell this to HR/recruiting departments.

I'm a highly experienced C developer with some python and JavaScript experience on the side yet can't get any jobs on those as HR/recruiters will just filter my resume out every time due to "insufficient python/JS experience".

HR has no idea how programming skills and experience translate across languages, they're just trained to filter out people based on buzzwords.

On the other side, everybody is looking for people already versed in the languages they need right NOW and aren't gonna take the chance on someone proficient in other languages hoping they'll master the new ones soon enough. Too risky for business.

I don't think many employers are interested in training anyone at any age anymore. Margins are often too lean to dedicate productive resources to training. When switching jobs, I always emphasize the aspects of previous jobs and accomplishments that would be most relevant to the employer (eg, delivering on time, under budget, reduction in reported defects). Having projects in GitHub or a portfolio also speaks volumes.

I think that's much more true of large companies than small ones. At a small company, the engineers are more likely to be involved in the hiring process, and (unless they're very inexperienced themselves) they'll have a better sense for how skills translate.

For example, on my team, we're writing most of our new code in Kotlin. But even though the language has now been around for the better part of a decade, we regard prior Kotlin experience as only a very slight nice-to-have when we're evaluating someone. If you've programmed in Java or Scala or C# or C++ or pretty much any other statically-typed language, you'll pick it up quickly enough that the time to get productive in Kotlin will be dwarfed by the time to get familiar with our code base.

What we do usually filter out, though, is monoglots. If you have 10 years of experience and have only ever done, say, Ruby on Rails development, you will probably not have the breadth of engineering perspective to succeed on our team. But if you've done RoR as well as something else that's dramatically different, that's fine. We would probably even filter out a Kotlin monoglot in the unlikely event we ever came across one.

You would definitely pass a resume screen at my (large-ish) company. We don't screen people out for lacking specific experience in our tech stack. Don't get me wrong, we like experience in our tech stack, but with 30 years of C, we wouldn't care what else is on your resume.

Maybe you just picked the wrong companies.

30 years of experience in C? Would you mind dropping a resume to my username AT google dot com to give me a chance to get referral bonus? :D

I like this analogy for a separate reason. Many musicians can relate to hitting a ceiling in terms of ability. You might have X years playing any instrument, but depending on talent, you may have plateaued for some period of time. It is highly likely for anyone that has stayed in one role (in a mature industry) that has not actively sought extra-curricular technology to experience this.

But plateaus are local. Usually they happen because you don't know how to progress anymore. Once you figure that out you jump ahead again. I think with age it is easier to become complacent and just say "this is enough". Which there's nothing wrong with that. But I think it is different than hitting a real ceiling. You're not at peak.

The myth of developers not being able to keep up as they age seems to be mostly propagated by two types of people. 1) Managers who want to keep wages low and 2) Young developers who try to hard too prove themselves and don't want to listen to/or work with older developers. [0]

[0] Note, I'm not saying all young developers or all managers. Only a small subset of each.

Also, startups discriminate on age because they need people that can work until 2 AM and drink their Kool Aide.

There may well be a correlation there, but which is the cause and which is the effect is less clear.

> In the meantime, though, every single older developer I've met has been extremely knowledgeable and frankly much better at the craft than myself.

While this is true for you, there is a lot of selection bias and survivor bias involved in this.

For These older developers you need to also consider their comrades they were working with 20 years ago. For every older dev you work with today, there are 10 of their former buddies that decided long ago they didn’t need to advance beyond VB 6, or IVM mainframe assembler or RPG/3.

Or they hit the stock lottery jackpot and have retired, or moved into management, or marketing, or started a sandwich shop.

But I do think there's a bit of generational shift that the stereotype of outdated engineers haven't caught up with. When I started out in the mid-90s, anyone more than a little older than me didn't have a CS degree and had come up in a world without source control, continuous integration, automated testing, iterative development processes, open source libraries, etc, etc. So in some ways they were from a different planet than the next generation. Although the tech du jour still changes quickly, programmers in their 40s these days still have a comparatively small gap when it comes to education and development process.

I was using source code control and open source software in the mid-80s.

I think a lot of the age-ism has more to do with cost than skill. Older developers ask for more pay, negotiate more, and are less willing to put in uncompensated overtime.

The way to get past this is to make sure you develop skills that are exotic and high-end and hard to find so you can't easily be replaced by a cheaper college grad.

>> In the meantime, though, every single older developer I've met has been extremely knowledgeable and frankly much better at the craft than myself.

This may seems strange from where you sit but trust me. If you stay in the field that length of time, you will probably become that guy. You don't need to set out to be him. The only thing it requires is time and a refusal to stagnate.

Amen to all that.

OA> Herein is the source of the problem. The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes…

No, the source of the problem is the idea that 10 years of “C++ experience” is “irrelevant” to a project using Rails, as if development experience is somehow locked to the language you happened to do the development in.

Being a valuable senior developer is about 10% what technology you know and about 90% how good you are at working in a team to solve a business problem with a machine, and those fundamental skills haven’t changed much since 1960.

As you point out, the more experience you have, the more you realize that all these “different” technologies are mostly the same wine in different bottles. Or, as I like to say, “it’s all just software”.

I worry the real problem is not that managers are looking for someone who can do the job, but someone they can exploit.

The gleeful exuberance over 'new' things is something you can use against a younger programmer.

The older one who knows the vintages doesn't get as excited, because it's really not that exciting. You haven't discovered Shangri La. We've kinda already done 90% of this before, just maybe not all at the same time.

But there's good exciting and bad exciting, and it takes a while to learn the difference (I work with a bunch of people who apparently have not).

What's bad excitement look like? War rooms, for one. But they are the same dopamine hit as Stockholm Syndrome and so the battlescarred have bonded while the rest of us are doing everything we can to stay out of war rooms (I haven't been in one in well over a year).

I've started calling these people BASE jumpers, because they're adrenaline junkies. There are not so many older BASE jumpers (I hope it's not because they're all dead). I think you learn to value other things besides adrenaline. Like teamwork.

Maybe the problem is the big tech producers that introduce new technologies over and over, that don't raise productivity but create churn, force software rewrites, etc.

Tech history looked at from 40yr perspective, really seems like reinventing wheels over and over. I'm not sure if there is another industry with so much churn yet with a lot of rehashing of old ideas.

"It used to be the case that people were admonished to "not re-invent the wheel". We now live in an age that spends a lot of time "reinventing the flat tire!""

Alan Kay AMA: https://news.ycombinator.com/item?id=11941199

That's just the startup world. There are a million chill software jobs out there. If you get sick of it, save up a bunch of money and move to Dallas or Atlanta or any other large-ish city and find a quality enterprise shop.

I think a lot of problems some older developers have is that the culture has shifted. Maybe I'm off the mark, but I feel like older devs come from a world where programming was all about programming and it was less a formal career than it is now.

To succeed in programming, you have to work well in a business. You can't be Linus Torvalds, walking around with a big ego, unless you're so important it's hard to get rid of you.

You have to work with people well, and some of the older people I've worked with seem to understand this less.

Again, not an insult to older devs. Plenty of them are wonderful. And I could be completely wrong. Just an observation.

There's a big difference between being a developer and a programmer. Wrote about it here:

http://www.mooreds.com/wordpress/archives/871

In companies that I've worked in, the traits listed would (very roughly) distinguish a junior from senior developer.

There's various ways of describing these levels, but I think programmer/developer is less clear, and seems to suggest programmer almost as a pejorative.

I agree with your premise but not your reasons. personally I'm a programmer - I know enough about business to know I don't have good insight.

everyone I talk to doesn't want* a programmer in the older sense. they want people to integrate external large packages. they don't want to to test, they want to prop something up and see if it makes money. they don't want to talk about architecture and features and make plans - they just want to respond on a dime to what the market is saying.

without any value judgement - I personally don't have a lot to offer in that environment. and to varying degrees I think the hiring managers understand that (sadly, quite a number don't)

I agree with you.

I recently started working on a project in which the company had outsourced it to a wordpress shop, despite it not being a wordpress site.

fast forward a few years and no one fully trusts the software so everything it does gets checked/verified by a human, and they're actually hiring people because the workload is too much.

So they brought it in-house, which is where I come in.

And let me tell you, this codebase is horrific. To give you an idea, they needed a progress bar and ended up writing a FSM with the transition between nodes being http redirects. Now, the developers who worked on this wouldn't know what a FSM is if it bit them in the ass, but that's what they built. And the data for detecting if the background processing was still running was duplicated in 3 or 4 places, which means you would get states in this FSM that disagreed with each other about whether or not processing was finished. These pages would literally "argue" with each other over it by redirecting back and forth until the browser threw a too many redirects error.

I came across some code yesterday in which the developers had created a string of multiple insert statements. They then split on the string "INSERT INTO". Said split removes the INSERT INTO from the string. They then looped over the resulting array, prepended "INSERT INTO" back onto the sql and called the DB 1 at a time. I don't think these guys realized you could separate MySQL statements by semicolon.

My point is that the codebase is horrific, written by someone who was used to the style of development you're referring to, and they made an absolute mess.

BUT

To your point. The company realizes how bad the software is and I get a surprising amount of respect when talking about what needs to happen. The result is that we're making great strides towards making improvements, and despite how horrific the code is I find myself enjoying the work because it allows me to have an aspect of my skill set respected that can sometimes get ignored by people because it's not forward facing. Good software dev is boring as shit, so when you're doing it well no one notices.

Also, this post got me to thinking. I should submit that SQL code snippet to the daily wtf.

Ah, speaking of code snippet of the day. Found someone’s code trying to check if a promo-code is already used, and if not to apply it:

    $codes = $db->exec(‘SELECT code from promocode’);
    if (!in_array($myCode, $codes)){
        // use it
    }

Well, that's the thing. Most jobs are 80% stuff you don't want to do and 20% stuff you do. You're not being paid to do your hobby, you're paid to make money for the business and do what your bosses say.

There are many places though that understand writing good code, even if it's boring, is important, and any decent programmer can go fish until they find a workplace like that.

Having a solid older developer around is important even if most of the work is boring. You're there to help the younger folk from making costly mistakes.

> To succeed in programming, you have to work well in a business. You can't be Linus Torvalds, walking around with a big ego, unless you're so important it's hard to get rid of you.

I keep running into the inverse of that at companies. People who put on a smile and a nice demeanor, but then fail to do any actual work and subsequently lie and politic to cover that up, leaving the rest of the group to play cleanup and cover. I've always loved working with the Torvalds, you do your work and all is well.

That’s true. But if you haven’t learned that in 10-15 years - there is something wrong. That means the difference between someone with 15 years and 30 years would be marginal.

Unless working in some subfields of SE which have such depth.

The most popular nowadays don't though... mobile & web have a short half life.

I'm going to disagree. For every year I've spend doing something, I've got better at it. While there are definitely people with "1 year of experience repeated 30 times", I can't believe that you hit a point in software engineering where there is nothing material left to learn and/or where everything left to learn has marginal benefit.

There are things left to learn, but how many of those things are valuable to an employer who is just wanting yet another software as a service CRUD app, mobile app, or bespoke internal app that will never be seen outside of the company?

It’s practically a trope that every time this subject comes up, the top-rated comment is a skeptical response...from a junior developer.

As someone who actually has worked as a programmer on the far side of 40, let me assure you that yes, older programmers have value. Your perceptions are not wrong. But that said, the article is right. The people who do the hiring and firing do not care about what you care about.

As the article noted clearly, the marginal benefit of an older engineer has to exceed the marginal costs. And if we’re being honest, the fact that a graybeard can use tcpdump without reading the docs carries little marginal benefit. Guess what, kid? You’ll figure it out, and you’ll do it quickly enough that the total cost of your learning won’t really compare to the cost of hiring me.

That’s why you see lots of anecdotes about the value of older engineers, but lots of articles from older engineers who know that the discrimination is real. And this is coming from someone who has managed to “stay relevant” a lot longer than most software devs.

I litterally wrote that I don't how management values what I value.

I also never wrote that the article is wrong, I wrote that I didn't find it convincing.

I'm simply observing that after more than ten years developing and learning the craft, I still find myself not able to correctly know the old tools, and instead I merely have an idea of some that exist, and I'm sometimes able to google the correct one.

As so, I'm stating that when I see a graybeard with actual knowledge of fundamentals that I still totally lack, well, I respect that, and I _hope_ that he's not unemployable because if it is the case, I fear that our industry is doomed to produced always more buggy software due to a lack of basic understanding.

And I think than faced with no evidence from the article or you, it's well within my rights to be skeptical.

So, thank you for the unwarranted condescendance.

I honestly wasn’t trying to be condescending to you. I even said, right at the very beginning of my comment, that you’re right about many of your observations. My word choice may have been poor in some places, but overall I defend the content.

You’re (self-admittedly) missing some of the life and business experience that comes with being an older programmer, and then expressing skepticism about direct advice communicated by older programmers. This is also so common as to be a meme:

Person A: “I experienced $something_rare at work”

Person B: “I have never experienced such things. I am skeptical of your claims.”

So sure, you can call it whatever you like - skepticsm, disagreement or debate - but when people tell you about their experiences, and then you reject those experiences because you don’t have “evidence”...well, eventually you’re just confirming your own biases.

Again, it’s not that you’re wrong - I actually agree with your perceptions of older devs. I just think you’re missing critical life experiences that connect your observations with the arguments being made in the article.

Well, what you wrote was :

> It’s practically a trope that every time this subject comes up, the top-rated comment is a skeptical response...from a junior developer.

I looked at the top rated comment for the other times this exact same article was posted on hacker news. For none of those, the top rated comment "is a skeptical response...from a junior developer". Actually, it's more often (https://news.ycombinator.com/item?id=16934500, https://news.ycombinator.com/item?id=9361580) from a self declared senior developer. And none of those top comments really collaborate the article. Talk about confirming one's biases...

But taking into account all the anecdote from senior devs available just on hackernews, there's no consensus emerging whether the article makes sense or not.

So, at this point, I don't really feel the need for a plan B, even if being 40 years old is not really this far away for me. And it seems from the shared stories that whether this is needed or not is really based on personal experience, and is not a generally needed advice. I certainly hope to be in a path where I'm honing my skills well enough to be able to continue beind paid to engineer software after I'm 40.

Well, sure: you disagree, and you’re seeking out arguments that confirm your existing beliefs.

In any case, I’ve said what I have to say on the subject. I can’t make you listen to my direct experience, but I’m not going to spend time arguing with you about it.

The thing is as startups mature and become enterprise level shops, they need people who know how to work with enterprise software. Guess who has all the experience with that? Yep, the people with 10+ years experience. My company is hiring very senior devs like crazy right now for exactly this reason.

I think there are some orgs that definitely benefit, but it’s an 80/20 thing: 80% of software shops are more than content to hire junior devs and live with the costs of their mistakes. (Especially because most of those costs never really get experienced by the people who make the decisions.)

I had a recent conversation with someone who was into electronics & programming 40+ years ago as a youth. He has had successful careers in other non-related fields. He recently was messing around with a Raspberry Pi & remarked how little things have changed & how easy it was to jump pack in.

I strongly believe an employer is very short sighted if they are more concerned in a specific framework than knowledge as a whole. I agree, learning a framework doesn't take much time. They all borrow their patterns & ideas.

If your needs are urgent for a person to hit the ground running on a specific framework you should probably hire a contractor. If you want an employee you should care more about people & project skills, plus overall programming/IT knowledge.

I’m always mirin’ my current boss when he opens midnight commander and figures out the answer to his question by looking at the hex of the binary.

I needed to change a string in a compiled binary and as I pulled the project down to change and compile from sources, he suggested we just patch the binary and we did in 1 minute with hexedit.

I really don’t buy that skills don’t transfer. Where this is actually the case must be people getting too locked into abstractions and never really understanding the essence

"Mirin is a common staple used in Japanese cooking. It's a type of rice wine, similar to sake, but with a lower alcohol and higher sugar content."

Unlikely this is what you meant. Admiring?

It is 100% a colloquialism..

Meaning what?

Urban Dictionary is useful for looking up suggested meanings of colloquialisms. https://www.urbandictionary.com/define.php?term=mirin

What's funny is that it's already getting dated. I remember it was ubiquitous online in the forums I frequented in 2010 just like Urban Dictionary's graph shows. And that is already a decade ago (yikes)!

I think it's short for "admiring": admiring -> admirin' -> mirin'

I find it unlikely that someone referring to himself as mixmastamyk (mix master mike?) isn’t familiar with millennial slang.

> I'm not sure I'm buying that. The JVM? Still rocking it 20 years after.

Java may not be my favorite language, but I respect how the language has both progressed and maintained its heritage. It allows the developer to build upon their skills rather than relearning nearly identical skills every time a new technology comes out.

The problem is that this 70 year old industry still behaves in very immature ways. While this may be acceptable when it comes down to attitudes towards technology, the unfortunate side-effect seems to be the adoption of similar attitudes towards people.

Every time someone says something like, "young people are more in tune with the current state of technology," or, "old people are more capable because they have more experience," they are legitimizing prejudice. That's true even when the statement is being made in an attempt to combat prejudice since it is applying generalizations to individuals.

Granted, it is very difficult to shed generalizations. Just look at my comment about the immaturity of the industry. That isn't universally true. Some companies are going to have a younger workforce, some older, some heterogeneous. Some companies are going to have old people working with old technologies, some are going to have young people working with young technologies, but some are going to have the young with old technologies and vice versa. Yet the generalization comes about because of how we frame the industry, which is one where the new replaces the old.

Which brings me back to why I respect Java: it looks both towards the future and back at the past. It is language of growth, rather than a language of revolution. Perhaps this inanimate technology has something to teach us about how we regard people: we should be encouraging growth and advancement rather than treating people as disposable.

This is the bottom section of TFA:

> You’ve got a cash cow, milk that sucker!

> I know you love programming because you like technology, so this may go against your very nature, but no one says you’ve got to jump every time some snot-nosed kid invents a new way to run byte-code. You have invested a lot of time and energy mastering the technology you use, and your experience differentiates you. Money follows scarcity, and snow-birding on an older technology, if you can stomach it, may just be the way to protect your earning potential. The industry turns on a dime, but is slow to retire proven technology. It is highly likely that you will still be able to earn some decent coin in the technology you know and love even after a few decades.

The article mentions this:

Yes. But as the article said, there is a diminishing amount of value after every year of true experience after a number of years. I would say around 10.

I definitely don’t believe in the “10x Engineer” (individual contributor) - yes they do exist but are so rare they aren’t worth talking about. I do believe in being a force multiplier as a team lead/mentor.

On the one hand, sure, percentage-wise you learn less in year 20 than in year 10, because you already know a lot more in year 19. But that is no more true of this field than any other field. Is a doctor, architect, civil engineer, or auto mechanic with 20 years experience more valuable than one with 10 years experience? Heck yes.

20 years ago,much of what I used today didn't existed there was no AWS, no C# (but C++ was close enough I guess), mobile where you had to worry about semi-connected networks and syncing, etc. There is no part of the human body that exists today that didn't exist 20 years ago.

All of which is just details, which are much less important than the fundamental skills of building systems with whatever people and tools are available. (And I'm sorry, are you implying no significant changes have occurred in the tools and practice of medicine in 20 years?)

Thinking that moving from on prem to AWS for instance is now you end up with “AWS Architect” who were old school net ops guys who only know how to do a “lift and shift” and end up costing clients more. Because they pattern matched thought AWS was just an implementation detail and they could just set up everything like they would on prem.

You could argue the opposite is true: 20 years ago, there were dangerous misconceptions about how some body parts work. Many chemical pathways were completely unknown. Medicine and biology both evolved a lot in the 20 years.

The big picture however is still valid. Concepts and paradigms hold for decades. We still use TCP/IP. Computers still use the Von Neumann Architecture.

Looking at the details however, AWS is just a fancy GUI over time sharing on a mainframe. C# is just new syntax for concepts that are older than I am. While mobile brings new challenges, you now don't have to deal with the challenge of customers connected through a 330 baud modem.

In 1986 I had to not only know 65C02 assembly language to get any performance out of my 1Mhz Apple //e, I had to know that I could get 50% more performance for every access I did to memory on the first page as opposed to any other page. If I spent time doing that type of micro optimization today, I would be fired. I couldn’t imagine doing the types of things I could do today with modern technology.

In 1995, when I wrote my first paid for application in college, Internet was a thing for most colleges where I did some work on a HyperCard based Gopher server (long story), that wouldn’t have been possible in 10 years earlier.

In 2006, I was writing field service software for ruggedized Windows Mobile devices, architecting for semi connected smart devices is a completely different mindset than terminal programming or desktop programming. That wasn’t feasible before hardware became cheap and at least 2G was ubiquitous.

Even then what we could do, pales in comparison to the type of field service implementation I did in 2016 when mobile computing was much more capable, much cheaper and you could get a cheap Android devices and 3G/4G was common place.

But people thinking cloud computing is just “sharing mainframes” and don’t rearchirect either their systems or their processes is how we end up with “lift and shifters” and organizations spending way too much money on infrastructure and staff.

Also anyone who equates managing AWS to a “GUI” kind of makes my point, if you’re managing your AWS infrastructure from a GUI - you’re doing it wrong. 10-15 years ago you didn’t set up your entire data center by running a CloudFormation template or any other type of infrastructure as code.

How has medicine evolved in the last 20 years? I don’t doubt your statement, but you make it sound like common knowledge, and from my point of view (average non-medical person) not much has changed.

> But as the article said, there is a diminishing amount of value after every year of true experience after a number of years. I would say around 10.

I don't buy it. 10 years is about when you start moving into the actual expert category. Note I said start.

At 35, I finally had real, full control over multiple languages, could pick up CLR and understand and implement any algorithm in it, finally understood exactly why concurrency was so damn hard and how to mitigate that, and would pass practically every interview with flying colors. I could finally drive my tools with some facility and started to realize gdb was my friend.

At 45, I can predict the errors I and others are likely to make and take steps to mitigate them up front--although I still get irritated that I when I make the mistake anyway. My comments are now psychic--my team often remarks how "I just thought that I could really use a comment explaining this-and, behold, there it was". I can reduce interviewers to tears and can surprise all but the most knowledgeable experts in their own domains. I reach for gdb far more often, but am still frustrated at how much I don't know about it.

I still only consider myself an "expert" in very few subdomains--none of them involving programming languages.

One of my heavy hitter software guys once said: "Your code is the most straightforward code I have ever read." I apologized for being so simple. His laughing response: "Don't apologize. That was a compliment, dumbass."

At 35, I finally had real, full control over multiple languages, could pick up CLR and understand and implement any algorithm in it, finally understood exactly why concurrency was so damn hard and how to mitigate that, and would pass practically every interview with flying colors. I could finally drive my tools with some facility and started to realize gdb was my friend.

You may be an expert in multiple languages but as the article said, if the company is looking for Ruby developers to write a CRUD app, they no more care that I spent years doing C than they do the years I spent doing 65C02 assembly in the 80s.

No matter how many subdomains you are an expert in, if the company doesn’t need that experience, it doesn’t matter.

But some things translate much better than others: Django and Rails aren't that different (I'd also put Laravel in there). So I think the real problem is moving from a senior Django role to a senior Rails role and vice versa, but I see no reason why a 10 years Django developer can't get a mid-level Rails job (other than blatant age discrimination that is).

Isn’t that the point? That if you have 10 years worth of experience as Django developer, you aren’t as attractive to someone looking for a Rails developer as someone with 5 years of Rails development.

Simplicity is definitely a virtue. When I maintain large codebase of 10+ year project, it is easy to spot where someone tried to be very clever, and it is rarely benefit for codebase maintainability and extendability in the long term. Things rarely get reused that much to take advantage of overcomplicated abstract solution. Most of the times developers do not predict future business requirements correctly and simple solution would be the better one.

Just one note about 10x, because I often see people ho don't believe it have the definition wrong. 10x programmers are not ten times better than the average programmer, they are ten times better than the worse programmers. This is based on an actual study and, by the metrics the study chose, this disparity does exist. Of course, measuring programming performance is notoriously intractable.

Seeing someone fire up wireshark, sniff some traffic and solve a complex production issue in five minutes by looking at the raw packets never gets old.

I worked a consulting gig with a 60yo who had just learned Objective-C so he could do mobile work. This was in 2013.

I guess if it’s a seed round company with a 22yo founder they might have some bias. But the rest of the world absolutely needs devs of any age.

> Admittedly, I have no clue if the management realises that ! Well, that's the key thing in many places: it's management that decides whether to hire and how much to offer, not you :)

The first instinct would be to put 'resources' that costs little into a project, and that usually means people with less experience that requires less pay and are easier to drag around. Imagine the difficulty they will be having trying to grok your line of reasoning for respecting and going after these older devs.

The javascript ecosystem however...

The entire stack literally (for the actual meaning of literally) change completely every year. Frameworks, language, package manager, libraries, etc.

I'm pretty sure you have misused the word literally.

Try to update a one year old npm project and you will find that literally 75% of the code in node_modules changes, and also that the app no longer works.

And then it was yarn. And then npm again.

Ecosystem, sure, but I am still using the JavaScript I learned x years ago when I need to see how something is implemented in Angular or React under the hood, etc.

Sure. But learning a new framework is like 100th on the list of hard parts of being an engineer. Its new incantations but ultimately the loop of solving business problems with automation is precisely the same.

100% of my team had basically zero C++ experience before joining. Our application is developed entirely in C++. I didn't care one bit because learning the programming idioms is so trivial compared to the actually hard stuff.

That’s basically how I find work. I’ve been in Unix admin since the 90s.

Do I know the latest coding pattern some adjunct professor is teaching after copying it from a math book into code, like the college grads I often encounter?

No.

Do they know much about operating at scale? How USE their tools?

They know what ideas are important to computer science. They often don’t know how to make anything work that isn’t an insecure mess.

I think that’s the important take here: I program less these days because I’m teaching people how to make shit that’s more complex than their reduced to a few talking points homework assignments.

Well, TCP is a hot mess that should and will be phased out in favor of more congestion friendly protocols.

We barely could get IPV6 to get adopted. Replacing the whole TCP ? Most probably not. The successor to TCP if it ever gets adopted, will look more like TCP than a new protocol.

Agreed. Entire industries are based off the distinction of the stack and it's interoperability(sp?).

What are those alternatives?

QUIC (https://en.wikipedia.org/wiki/QUIC) is one alternative.

doesn't quic use bbr, a cc scheme developed by and supported in tcp?

> Observables are all the hype in javascript ? Well, great, I've learnt that pattern 15 years ago...

Well, the listener/observer pattern is used to explain observables in order to make them familiar, but no, it's not the same thing.

Observables are streams and you work with them the via composition of streams. When viewed from that high level, the underlying protocol (the observer) becomes irrelevant and in fact, if you're often finding yourself working with that protocol, you're doing it wrong.

People familiar with functional programming will be very familiar with this style, because composition is very natural to an FP developer and the composition of all kinds of streams is in the repertoire of FP developers.

But I've seen plenty of colleagues, who are otherwise very capable people, really struggle with the concepts involved. The mentality shift from the imperative programming that people have been taught, to describing actions via function composition and then doing evaluation "at the end of the world" is a mind fuck.

Interestingly, functional programming has been with us for some time, being older than Java.

However people are not interested in actual functional programming and more recently there's this trend to classify junk as FP, just because you've got a shitty API that takes functions (often doing side effects) as arguments to other functions, but that's not FP.

So going back to Observables, as a piece of advice, don't mention that in an interview ;-)

Well, it was my obvservation reading typescript code (never wrote a line in this language) with a background from java and then c# and then scala. The observables part felt really easy even without knowing the language syntax, but I suppose that the past 4 years of scala made me instantly translate the code in functional fashion and it was all smooth.

On the other, while it's wrapped differently, the whole idea of "this object will start emitting events, and we will be having functions as callback on them defined in various objects" really feels a lot like good old java observables/listeners, even if it's applied with a different paradigm. The stream part really feels like an implementation detail to me, it's just less boilerplate than before.

Then again, it was just an anecdote based on reading code in a language I don't use ^^ javascript and typescript aren't even mentioned on my resume, for good reasons, so I should be safe in interviews !

Reply on news.ycombinator.com