Comment by ak_111 | Hacker News Reader

Comment by ak_111 | Hacker News Reader

Parent Full thread

You are sort of ignoring the bias in your own AI extremist prediction.

People who have decided to go all in in learning an interpreted language like Perl or even PHP, had to continuously also learn react, js, ruby,... and gazillions of other languages and frameworks to remain in business over the last two decades.

While people who invested in learning C, Java or SQL have as much healthy opportunities to pursue today with almost the same amount of knowledge that they had accumulated three decades ago. Their life has been much less stressful, pretty much on auto-pilot, while those who were pursuing the latest technology are constantly living on the edge having to continuously relearn entire new framework on average every 3-5 years to remain relevant.

So yes all these glitzy languages have "won" but it wasn't by these "ancient" languages losing.

If I had to bet I would say a decade from now, based on the last 50 years history of computing, I can easily imagine the same amount of jobs for C programmers as we have today but there will be as many Ruby jobs as we have perl jobs today.

Reskilling has its upsides, you are exposed to many more paradigms and communities that do things completely differently which allows for a lot of cross pollination. living life on autopilot isn’t usually a source of great insights.

Reskilling is much more productive and fun when you are doing it for the intellectual journey and insight, rather than because you need to do it to find a job.

Indeed being able to auto-pilot your job allows you an amazing amount of time and freedom to learn new things deeply. See also the detrimental effects of "publish or perish" mindset in academia.

You don't need to kill a chasing bear to survive, you just need to run faster than your friend.

With those new interpreted language that are easy to pick and have a low-barrier of entry you are constantly having to run faster than an influx of fresh energetic high school dropouts and boot camp graduates.

With less fashionable language that require significant expertise and experience in picking them up like C (understanding the hardware level) and Java (understanding the JVM and OOP concepts) the barriers of entry are much higher and this will mean you have to outrun fewer people in the long run to survive.

"Java (understanding the JVM and OOP concepts)"

I am pretty sure that you can programm java without knowing details about the JVM and I would think, that most java programmers do exactly this. I think only in high performance scenarios knowing more is beneficial?

But I have not touched java in a long time .. as I have indeed choosen the web as plattform.

But I don't feel threatened by the high school kids coming from boot camps.

Edit:

I know what a pointer is, so I can work closely with wasm libaries. I know algorithms and how to structure data and why I am structuring data this way in this case, so I can adopt in another case. I know how to achieve performant simple code. I know how to debug layers of code with sideeffects over sideeffects. Raceconditions, memory leaks, etc. (All a thing in js, too). Using and understanding the profiler etc.

Someone coming from a coding bootcamp, does not know this. He or she might learn it after years of practice, which is allright by me - but they are no direct threat to me, despite that I don't even really know react for example.

not feeling threatened doesn't mean you're not under threat.

It's entirely possible that between your skill level and those boot campers is a few(dozen) percents of workforce. But at the same time it's entirely possible that if you are not as quickly progressing as the growth of the industry, you could become a part of the same percentile as bootcampers in no time.

Just like it's entirely possible you could be hit by a meteorite.

Focus on what you can control and let go of that which you cannot.

A lot of the Java programmers I know professionally know fuck all about JVM internals, etc. Its largely unnecessary unless you have to chase down some extremely subtle bug most of the time.

A lot of them are senior or principal product engineers at companies you will have heard of.

Whereas with C, its extremely necessary to get into the weeds - otherwise your code just crashes or suffers some memory corruption issue, race condition, etc etc.

It's not only about performance, it's also about maintainability. Codebases written by inexperienced programmers are extremely convoluted, nothing is decoupled and functions are extremely long and do multiple things. Extremely hard code to maintain or add features to.

> I am pretty sure that you can programm java without knowing details about the JVM

yeah that was the whole point of object oriented programming and Java to begin with. You don't need to know the details of the underlying implementation, focus on the problem you're trying to solve.

Which pretty much sums up today's work culture. I was just talking about this same exact thing, yesterday.

That's absolutely heartbreaking.

In the old days, we would have a team, that would compete, as a team, against other corporations. Our team would stick together, work together, and, quite often, function as a unit; leveraging each others' strengths, and compensating for each others' weaknesses.

Nowadays, we look at our team members as "the competition." In fact, we may actually be making plans to move to the other team.

But I have written programs in C, that were still in use, 25 years later. I have written programs in PHP, that were still (are still) in use, 15 years later.

There'll always be room for the classics.

That said, I'm quite looking forward to seeing what I can do with the new AI stuff.

The idea that nobody saw their coworkers as competition for a promotion, or bonus, or face-time with the boss in the past, and that there are no teams that stick together and work together today, is fanciful at best.

These are "Because I can find an exception, your position is invalid." arguments. Not sure I can recall the exact fallacy title, but it's a fairly typical debating tactic.

I disagree that there's a fallacy at play here. The GP (GGP) should support their bold claim that "times have changed" and "people/teams aren't the same as they used to be." If anything, that's an extremely common fallacy and is not to be believed without sufficient evidence.

Actually, that's a fairly typical thing to say to someone that's older, and has lived through those times.

And I am sorry. Things definitely used to be better than they are now, in some ways, and definitely used to be worse, in other ways (for example, it used to be a very white, very male demographic). It's not my fault that things went the way they did. Folks liked money, so folks built a culture that maximized profit, and eschewed humanity.

I am quite sorry about that, but it doesn't change the fact that it was not always so.

It's not in my personal interest to go about creating a slideshow on "how things used to be." I know what I know. I lived it. I ran teams, exactly like I described, and I was a proud member of very large, high-functioning teams that stuck together for decades without stabbing each other in the back.

Let's just agree to disagree, then, eh?

> I know what I know. I lived it.

I don't disbelieve you, but I'm saying your experience can't be generalized in that way. Only aggregate data can tell us these things. Your experience may well have followed the exact trajectory you've described, but maybe 90% of people see the opposite.

Given how quickly income inequality is rising, can you blame people for taking any advantage possible to try to stay ahead of the curve? If it means throwing your teammates under the bus to get more money, that's unfortunate but it's going to happen.

I never publish or react to individual velocity as a manager. It's all about what the dev and QA team gets across as a whole to the Done pile each week, and I use a rolling ten week average. I know what each person is doing still but if they spend four hours collaborating on something nobody loses points.

You're a good manager. But not everyone/company is like this.

Well my team wins more than most others and we've replaced teams and fixed many failed projects so that helps too. And if the company is dense there's others that aren't and lots that will follow where I go to next.

Yes this is the social-rot that is everywhere

Everyone is at best a temporary ally, friends and community groups are just atrophying daily as we continue to not invest in people and community and invest in more alienation.

While maybe it does sum up our work culture it shouldn't influence how you work. Rarely have I seen someone who "runs faster" be more valued (monetarily or among senior peers) than someone who churns out quality and runs "a little slower".

Team is still very much a thing and if your team members are looking at each other as competition then that sounds like a culture thing, maybe the norm, still not acceptable.

The collateral damage of careerism is objectifying your coworkers as either enemies or things to manipulate in order to advance yourself. It's the belief that all software devs are temporarily embarrassed FAANG devs.

This mindset will damage you over the long run, and the resulting career success may or may not be able to offset it. A zero sum mindset will lock you into this view along with the accompanying anxiety.

If your friend is faster, you just wack them in the knee before you start running from the bear.

This zero sum rhetoric is ridiculous. You are not being chased by a bear.

"You don't need to kill a chasing bear to survive, you just need to run faster than your friend."

Problem with this approach is you run out of friends quick. People in bear country cary bear spray, have dogs to scare off bears and electric fences to keep them out.

We have tools and culture to not have to deal with/rely on survival of the fittest if we don't let fear control us - whether at work or in nature.

I find it hard to believe people who learned Java don't have to learn new things every now and then. Yeah maybe they stuck to Java but the whole backend ecosystem looks way different than even 10 years ago. Even C is debatable.

Of course, everyone is always learning, you can't remain static. But you could afford to become more and more of a specialist in Java and growing your job opportunities that you can apply to.

If you became more and more of a specialist in Perl on the other hand you would have had to completely relearn something new by now to find as many opportunities as you used to in the late 90s.

I don't think it made a huge difference in most of these guys careers. I'm sure Perl "specialists" were able to move stacks if they wanted to...and you learn most of it on the job anyway so its not like you had to take a year off to catch up learning Java. So yeah it was a time investment for people but I don't think its as dramatic as you're making it seem.

I'm saying this based on the fact the job market was amazing for software developers in the last decade or more. Things now might be different.

There are no perl jobs.

Exactly my point. You had proportionally as many perl jobs in the late 90s as you have Ruby jobs today. It even had early mover advantage in the scripting space and insanely good ecosystem of libraries.

I almost took one a little more than a year ago, and I wasn't even looking for one...

There are a considerable number of Perl jobs out there - just not many "greenfield" perl jobs.

Most of them are maintaining existing codebases (not a fun job), and some are "help port this legacy codebase to not perl".

I'd not discount Perl. Its incredibly fast to develop services in, stable as fuck, runs anywhere, performant (relatively), flexible, and if you were a startup looking to get a product out the door, just offer decent TC to a couple of old hands you can ship something viable fast.

Perl is a great tool for when you want to scale that text mangling file wrangling bash script to do more stuff, and pretty much in no other case.

A horrifying amount of applications out there that I've seen are basically just that - wrassling some text around, but with a billion layers of unnecessary abstraction.

I get to see a lot of peoples code in my job. Most of it is ridiculous levels of over engineering

Dice lists 10 times more Perl jobs than Rust jobs and almost 3 times more than Kotlin.

Reply on news.ycombinator.com