I'm pretty confident that the web and mobile development that most of HN does today will NOT be big in 2035. Computers will probably have evolved into pretty different forms, and we'll have different ways of interacting with them.

However, the principles of engineering good computing systems will probably be pretty similar. And the higher level skills needed to be a good engineer will almost certainly be the same.

I wouldn't be so quick to dismiss soft skills as easy to pick up - well, maybe you mean soft skills like basic verbal and written communication, in which case, sure, they can be learned pretty easily. But there are a lot of very valuable "soft" skills that fall under the realm of engineering wisdom and experience.

A senior engineer can add a huge amount of value for a team - justifying a huge pay check - by having a good sense for how to design things to allow for greater productivity, when to be extra paranoid about failures, which corners can safely be cut, or how to avoid subtle but devastating pitfalls in a given domain or platform.

I think most professions are a bit pyramid shaped, with lots of people whose career trajectories don't always go up and to the right. Software development probably has a bit more of a plateau than some, but it's not the only one. Architecture, for example, is very cutthroat, with a handful of senior people who do very well, and an awful lot of disappointed later-career professionals. Even at big corporate law firms things are pretty much up or out - not everyone makes partner, and not every partner makes senior partner.

I think across all of these professions, if you want to keep moving up and/or stay highly employable (and that's a big if), then you have to always be thinking about trends in the market for your skills, and how you can stay ahead of them. It's not that different from a company thinking about how their products can continue to stay competitive in a changing market.

I had a six month co-op in college where I worked for a major defense contractor working on software for an embedded system. I really enjoyed the work and had a few offers from defense contractors doing embedded development when I graduated but ultimately decided on going to work for a growing e-commerce company near Boston. My primary reason for not going back into the defense industry despite enjoying the work was because I saw that kind of work as too unstable and career limiting going forward.

I have to say that based on my experience I believe very little meta engineering skills would transfer between these two industries. The way software is written for a full authority digital engine control and the way software is written for an e-commerce website have very little in common other than they are both called "software engineering." The process is immensely different, the technology is immensely different, testing is immensely different, integration is immensely different. It's a different universe. If I went back to work for one of those companies I would be starting from the bottom - if they would even hire me. Yes, if you squint really hard, you can see parallels in the two industries - they both test, for example - but to try to extrapolate beyond that is... well, quite a big pitfall.

The things you mentioned - a good sense for designing things for greater productivity, where to be paranoid about failures, what corners can be safely cut, or where the pitfalls are - are extremely different between the two industries.

The nature of computation opens up a boundless universe of possible ways to both run a software project and build a software project. This sets us apart from other engineering disciplines -- there are a limitless number of ways to architect almost any software project, but there are only so many safe ways to build a bridge.

This allows our industry to fork off into places we can't possibly imagine today. I agree with you that in 2035, our field will be very different.

> It's not just technology stacks - even the methodologies in this industry seem to undergo radical changes every few years (for better or worse).

If this is the case, then when someone entered the workforce has absolutely no relevance. What is relevant is staying current. It is absolutely ageist to assume that a 50 yr old is going to have more trouble staying current than a 30 yr old.

> How confident are we that the web and mobile development that most of HN does today will be big in 2035? I'm not very confident at all. But how do I recognize when to jump ship?

Thankfully, these days we have data scientists who examine trends in framework and methodology assimilation for fun and publicity. We have metrics like GitHub stars, Stackoverflow questions, and Google Trends to clue us in on the popularity and profitability of new ways of doing things.

> It is absolutely ageist to assume that a 50 yr old is going to have more trouble staying current than a 30 yr old.

I don't know if I agree with that. When I was 25, I was all over every new technology that came out. I was the expert in my group. I'm now pushing 50. The latest tech isn't nearly as interesting. And honestly, I'm getting tired of chasing it. My energy level has dropped a bit. Physically I'm not in as good a shape (though still quite healthy). The effects of age are very real.

Another way to put it is that the 25 year old thinks all the shiny new technologies are important. The 50 year old knows better.

I'm 51. Many, maybe most of the tech that's fundamental to my career didn't even exist when my career started. Only Unix and SQL have been constants. http was a lab experiment. The Mosaic browser didn't exist yet. Java? Ruby? NoSQL? Whatever.

If you need to learn a tech to solve a problem, you learn a tech. It's not hard.

What I find interesting isn't new technologies. It's new problems, problems that didn't exist before (often because they're the result of new tech), or problems that could not be addressed before (due to limits of computational power or data access).

I'm your age, and I think a good example of what you're talking about is javascript frameworks. Younger programmers might dissect each one and suss out the details like any of us might have done with CONFIG.SYS, but as an older programmer they all seem essentially similar and as far as professional skills go I can probably either just choose one or wait until the dominant one shakes out. This of course is aided by my sense/prediction/bigotry that JS frameworks are following Hotelling's Law.

You're mostly right, but that means you're missing an extremely important piece of the picture.

Both the browser and Node provide hardly any structure at all compared to Cocoa, WinForms, or even the Java standard library. Experienced developers recoil because it feels like building a house with hand tools, compared to having a team of contractors at your disposal.

This results in JavaScript developers building their own tools. That's why there are so many of them. In iOS no one writes a GUI toolkit, because Apple already provided one and it's pretty good. People have their complaints but they're rarely serious enough to warrant throwing the whole stack away.

In that sense these more robust platforms are superior. But the JavaScript world is like a giant evolutionary system trying all ideas at once, at almost every level of the stack. Lots of repetition, lots of death, but also WAY more ideas floating around.

JavaScript frameworks all look the same to outsiders because they mostly are. But they are different in subtle ways that you simply can't explore on iOS because Apple already decided where the major architectural boundaries will be.

There are painful tradeoffs on the JavaScript side, but I think in the long run the fundamental advantages will become enormous. I believe the web a disruptive (to native) technology in the Innovators Dilemma sense, but we're still very early on the adoption curve. Only a fraction of a percent of people use the web's most powerful feature, which is JavaScript functions.

> Only a fraction of a percent of people use the web's most powerful feature, which is JavaScript functions.

…What!?

Most web users at best write a little html. Very few do any programming.

> And honestly, I'm getting tired of chasing it. My energy level has dropped a bit. Physically I'm not in as good a shape (though still quite healthy). The effects of age are very real.

But that's also experience. There is a sameness both the 'new thing' cycle and the new things themselves that largely becomes apparent as we accumulate experience -- which happens to coincide with years, but I don't think it's the years that are the cause.) From that perspective it seems logical to be less interested in chasing all the new things.

So far I've found (~10 yr. younger than you) that if something comes along that is sufficiently interesting, I dive into it just as deeply as ever -- but I'm a fair bit more discerning about what I find sufficiently interesting.

At 25 everything seems new and exiciting, now in my mid 30's I'm starting to see new tech as just a new spin on old ideas. If you were familiar with smalltalk for instance, you probably wouldn't have found java or .net particularly exciting, you probably wouldn't have as hard a time picking it up either.

You're right, and it's not just the affects of age. As I have gotten older, my responsibilities have become more diverse - Outside of work, I am a husband, parent, and bible study teacher. Much of the time I used to spend playing with new technology are now spent in those roles.

You also mentioned getting tired of the chase. It's hard not to get jaded about the newest javascript framework (for example) when we have been reinventing these wheels in our industry since the 50's. Whenever the next big thing pops up, it will arise out of the oeuvre of a lot of stuff that - taken individually - are a dead ends.

I think every 50 year old is different. A fifty year old who did some regular exercise, is different than a guy who spent the last thirty years sitting at a desk?

When I was younger, I thought most people over 30 were basically worthless. As I've aged, I changed that up a bit.

Young and old have their place.

When I was in my twenties, and thirties; you couldn't pay me to sit in front of a computer--literally.

What was I interested in? Guess? Girls! And then Girls! And then anything other than sitting at a desk all day, especially looking into a screen. Was I entitled? A bit?

Only as I aged, did computer science become palatable. Do I love it? No, but I haven't loved anything besides a few family members, and my pets.

I think where Hiring Managers get it wrong is assuming all young people will be Rock Stars, with great ideas. They will be happy with free food, and lofty promises. I never bought it. I took what I wanted. I smiled, looked promising, but hated my employers. I would not want to hire myself after college. I finished college ready for med school, and looked back, and could count on my hands what courses weren't a waste of time. I was dissalusioned.

I do think the best ideas still come from mainly young people, but separating the the best from the herd is impossible.

Peter Thiel has the money to throw at young people, and wait for the shooting star. He knows that combination of being young, hormones at full throttle, and angst; might just produce another Mark Zuckerburg. (I used Mark, but he might have just stole an idea, and got very lucky? I honestly haven't figured it out.)

And to be perfectly honest; the young guys, I know, who became rich--all had wealthy enabling fathers. The more I think about it, it was their fathers(50 plus) who provided the idea, and capital, but weren't willing to give up their day gig to see their product through.

The ageism won't go away soon.

I think it will take another five to ten years for the industry to realize you don't need to fire programmer at 40, but who knows?

I personally think in a decade, this profession will be talked about in the past tense. Yes, a few will always have a secure job, but most jobs will be contracted out to the lowest bidder.

Hell, I don't think it will be ten years. Once "Let it go whatever", rehashedidea.com, etc. run out of free money; we will have a huge group of dissalusioned 25-35 year olds. Many will be homeless? Many talking about the good ole days when companies treated you like you were a valuable commodity.

"Rember the free stuff?"

Your writing style is really enjoyable to read.

Even at 25 I wasn't interested in the new tech. Uh oh. Oh well. Anybody up for some hacking around with bits?

> If this is the case, then when someone entered the workforce has absolutely no relevance. What is relevant is staying current. It is absolutely ageist to assume that a 50 yr old is going to have more trouble staying current than a 30 yr old.

I might be wrong, but I got the sense that the comment you're responding to is trying to make the exact same point. It even says that one point that the uncle's age was completely irrelevant to his not learning the newer technologies.

> He saw object oriented programming as snake oil and a passing fad

for how long ? I dont blame him for reading about C++ in 1989 and saying "hrmmmf! hogwash!". But in 1995 ? in 2000 ? It sounds like he got set in his ways, and how is that NOT an "age problem" ? I'm also 32, and I'm getting slightly more set in my ways as I get older.

> he begrudgingly learned Java/C#/JavaScript/SQL and took a major pay/prestige cut basically starting over.

well, had he had an open mind and not shunned new things, he might be a Herb Sutter today. Or even in IBM, had he bet on a different "horse", and moved into As/400 or whatever other IBM technologies there are, he could be earning more than a C++ programmer, knowing some obscure proprietary IBM language and having 20+ years experience backing it up. I've heard of guys like that making $100+/hr because only a few people in the world can do it.

I think his story is one of mismanagement of intellectual capital. Maybe it's naive of me, but I dont see how you could be in software engineering for 30 years and not be worth at least a million, especially from his era. Did he invest in IBM or any tech companies at all ? How could you not see everyone making money in the dot-com era and not be a part of it ?

>for how long ? I dont blame him for reading about C++ in 1989 and saying "hrmmmf! hogwash!". But in 1995 ? in 2000 ? It sounds like he got set in his ways, and how is that NOT an "age problem" ? I'm also 32, and I'm getting slightly more set in my ways as I get older.

Christmas of 2002.

>well, had he had an open mind and not shunned new things, he might be a Herb Sutter today. Or even in IBM, had he bet on a different "horse", and moved into As/400 or whatever other IBM technologies there are, he could be earning more than a C++ programmer, knowing some obscure proprietary IBM language and having 20+ years experience backing it up. I've heard of guys like that making $100+/hr because only a few people in the world can do it.

That's actually the big trap. He WAS making good money because of legacy systems and because not many people were familiar with the technology... right up until there were no jobs left. It makes changing fields earlier difficult even though it would have probably been the best long term strategy.

>I think his story is one of mismanagement of intellectual capital. Maybe it's naive of me, but I dont see how you could be in software engineering for 30 years and not be worth at least a million, especially from his era. Did he invest in IBM or any tech companies at all ? How could you not see everyone making money in the dot-com era and not be a part of it ?

I assume he's worth well over a million. It isn't enough to be worth a million when you are 50. When you and your wife will be living for (hopefully) another 30-40 years and social security doesn't kick in until 62-65, you gotta keep working unless you explicitly planned for an early retirement.

As for how to avoid the .com era - well, you miss it by seeing it as a bubble (and feel vindicated when it "pops" in 2001). You also miss it because you are committed to living in a certain geographic area without a significant presence of e-commerce companies.

I've got a year on you and I think I'd agree that OO is snake oil. The worst code bases I've ever seen (and I've seen some horrors) have been from over used inheritance and mixing logic and data. Provided you avoid global state (also a problem with OO) I think a c program would be more understandable than a lot of java/c# ones.

Not to say there aren't useful features, that would go well with a language like c, like interfaces, but I'd love to get rid of inheritance, encapsulation and mixing data and code.

it could very well be snake oil, but I make a living doing it (or at least knowing how to answer C++ questions during interviews. many of my jobs were advertised as SE but really dont require much actual coding (to my frustration)) and I actually enjoy C++.

Personally, I think both java and javascript (yes I know they are entirely separate languages ) are snake oil. But you know, I learned to program in them anyway.

I tried to find a happy medium where I learn about a new technology and see if it sticks. If after 3-5 years its still around, I give it a try. This worked for me for javascript and python. When python first came out (or when I first heard of it ) I said "no way, not learning a new language right now. perl works fine as a scripting language". Then year after year I kept hearing about it, and heard about perl less and less. Then I finally tried it.

But a couple years ago, I kept hearing about "coffee script" and "clojure". I said the same thing, "not touching it". And now, I hardly ever hear about them, and I barely even know what they are.

From what you are saying I guess you have never been in an OO project but you just worked in the "cold hell" of procedOOral code, the worst mix of copy and paste, overblown inheritance and singletons. I experienced a lot of it in my career, nowadays I am more oriented towards the functional world, but saying that OO is completely useless and even dangerous is an outright lie. The most awful codebases on which I worked on would have been quite nice applying the OO best practices. Sadly they where far too big to be changed by the concerted effort of a couple of people. And they were full of anti-patterns. Even loving the type safety of F# and Haskell I can't honestly say that OO is an anti-pattern per se. What it matters is not the size of the hammer but how you use it. But I can rightfully proclaim that the wrong tools used for something that they were never meant for are the worst possible solution. EVER.

I've spent 10+ years of my career working in OO languages, I'm no stranger to it and I've seen it used well. But we'll tends to be a subset of OO, with minimal inheritance and encapsulation with data and logic in seperate places.

You would probably enjoy Go, for the most part.

I've been thinking that. Rust is probably next on my list though.