Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The diminishing half-life of knowledge

rednafi.com

Post reply on HN
Print view View original

31–40 of 84 posts

Re: The diminishing half-life of knowledge

#31

Post by a_c »

Some angles for me to see this phenomenon

- focus on the fundamentals rather than the particular brand of tools. HTTP, tcp, HTML, OS, CPU, filesystem, etc will almost certainly out last a language, framework and SaaS

- See beyond the assumptions. Solutions are based on assumptions of current problem. Solutions come and go but the fundamental problem of, for example, go from a place to another, rarely change. Try to distill THE problem.

- focus on outcome rather than action. Ask ourselves why such and such actions matter. Do we know why are we implementing a thing, or if a thing we implemented 6 months ago matter at all.

All of these demands consideration beyond do you know "dewalts" or "bosch"

Re: The diminishing half-life of knowledge

#32

Post by jasode »

joshuaissac wrote: post #26

The article references the following IEEE Spectrum article: https://spectrum.ieee.org/an-engineering-career-only-a-young... > Given a choice, many employers would rather hire a couple of inexperienced computer programmer and spend a few months training them than hiring (or retaining) a more experienced but expensive programmer. In the very next paragraph: > In addition, many employers aren’t interested in providing t…

>>, many employers would rather hire a couple of inexperienced computer programmer and spend a few months training them [...] In addition, many employers aren’t interested in providing training to engineers or programmers

>That directly contradicts the preceding paragraph,

The "many employers" can be 2 different subsets of employers and/or 2 different tech stack situations. Examples...

Subset (1) FAANG or "tech" companies will train on specific in-house technology stacks for younger new hires. The "inexperienced" was in referencing "young". E.g. Apple hires fresh young college graduates that only did Scheme and Python in school but will train them on Objective-C and Swift so they can work on macOS and iOS. However, Apple typically doesn't hire older experienced COBOL programmers to re-train them in Swift.

Subset (2) companies that don't train new hires (many non-tech companies where IT/dev is a cost center). They usually don't recruit from college campuses and prefer the job candidates to have existing skills that already match the job listing. E.g. a hospital IT's department has a job listing for a Java programmer to help maintain their billing system. The hospital is not interested in a candidate who's skillset is only Turbo Pascal and Macromedia ColdFusion and retraining them on Java.

Re: The diminishing half-life of knowledge

#33

Post by smitty1e »

joshuaissac wrote: post #26

The article references the following IEEE Spectrum article: https://spectrum.ieee.org/an-engineering-career-only-a-young... > Given a choice, many employers would rather hire a couple of inexperienced computer programmer and spend a few months training them than hiring (or retaining) a more experienced but expensive programmer. In the very next paragraph: > In addition, many employers aren’t interested in providing t…

There is some "loyal autodidact" unicorn who would be an ideal hire.

People tend to fall somewhere on a robot/ninja spectrum.

The observation that employers have multiple motives that are in tension is simply human.

Re: The diminishing half-life of knowledge

#34

Post by spencerchubb »

joshuaissac wrote: post #26

The article references the following IEEE Spectrum article: https://spectrum.ieee.org/an-engineering-career-only-a-young... > Given a choice, many employers would rather hire a couple of inexperienced computer programmer and spend a few months training them than hiring (or retaining) a more experienced but expensive programmer. In the very next paragraph: > In addition, many employers aren’t interested in providing t…

If you read closely, the former is saying they want to train INEXPERIENCED programmers. The latter is saying they don't want to train EXPERIENCED programmers who are becoming obsolete.

Maybe they were trying to make a different point, but that's how I interpret it.

Re: The diminishing half-life of knowledge

#35

Post by abc_lisper »

DeathArrow wrote: post #10
zer00eyz wrote: post #5

I often watch a pair of YouTubers who cover china, and they used to reside there. The one thing that they lamented often was a lack of maintenance, from historic buildings to lightbulbs in elevators. They tried to posit it as something more cultural, and I dont know if that is true or not for china. I do feel like the culture of tech has become one of maintenance not being part of what we do. When was the last time y…

>To make a point: do we need docker? No, but writing installable software is hard Writing installable software doesn't help with isolation, self healing and scalability. In a microservice world you kind of need Docker/Kubernetes.

Um. VMs were doing the thing you said before there was Docker

Re: The diminishing half-life of knowledge

#36

Post by epgui »

Obviously I don't have a solution to offer anyone, but this is one of my motivations for wanting to learn more about things like category theory, type theory, functional programming...

It's not directly about getting skills that will land me a high paying job (via... marketable resume keywords?), it's more about trying to understand the fundamentals that no PL or framework trend, or social current, can obviate.

Re: The diminishing half-life of knowledge

#37

Post by marcosdumay »

a_c wrote: post #31

Some angles for me to see this phenomenon - focus on the fundamentals rather than the particular brand of tools. HTTP, tcp, HTML, OS, CPU, filesystem, etc will almost certainly out last a language, framework and SaaS - See beyond the assumptions. Solutions are based on assumptions of current problem. Solutions come and go but the fundamental problem of, for example, go from a place to another, rarely change. Try to d…

One really important issue with your first point is that everybody hiring is filtering by experience in SaaS, framework, and as a last resort, language. Nobody is searching for knowledge of the fundamentals.

But anyway, my take is that the problem the article is describing is caused by the existence of way too many fundamentals that can't all be practiced.

Re: The diminishing half-life of knowledge

#38

Post by marcosdumay »

DeathArrow wrote: post #10
zer00eyz wrote: post #5

I often watch a pair of YouTubers who cover china, and they used to reside there. The one thing that they lamented often was a lack of maintenance, from historic buildings to lightbulbs in elevators. They tried to posit it as something more cultural, and I dont know if that is true or not for china. I do feel like the culture of tech has become one of maintenance not being part of what we do. When was the last time y…

>To make a point: do we need docker? No, but writing installable software is hard Writing installable software doesn't help with isolation, self healing and scalability. In a microservice world you kind of need Docker/Kubernetes.

Hum... Docker isn't a great solution for isolation (it can do some of it, it promises way more than it can do).

Your system's scalability is completely defined by how you architect it, and Docker changes nothing.

And WTF is self healing? Docker can't fix any ops problem that it didn't create.

Re: The diminishing half-life of knowledge

#39

Post by idkdotcom »

As the author highlights, this is not a new thing. What is definitely a more recent thing is that half-life is much shorter than before. Now it is fair to say that even the knowledge that's most staying power has at most a 2-3 year half life.

My own solution to this problem has been to work in startups for 2-3 years and then move on rather than try to seek a well paid job at a large, prestigious company.

Why? I started my career at one of these brand name, "everybody wants to get in" kind of companies that hadn't made institutional layoffs ever. When time came to do their first mass layoff, I saw people who had spent their entire careers at the company lose their jobs unemployable because thy had essentially become bureaucrats.

Startups offer you the possibility of "on the job training" for the most recent technical stack. And precisely because there are too many people with golden handcuffs at the large companies, good startups are a bit easier to get into (not "easy", but "easier").

The downside is that 90% of startups fail, and you need to live with that. At the same time, if you happen to work at one that succeeds spectacularly, you won't have to worry about making a living until you die.

Re: The diminishing half-life of knowledge

#40

Post by jasode »

marcosdumay wrote: post #38
DeathArrow wrote: post #10

Earlier quoted context omitted.

>To make a point: do we need docker? No, but writing installable software is hard Writing installable software doesn't help with isolation, self healing and scalability. In a microservice world you kind of need Docker/Kubernetes.

Hum... Docker isn't a great solution for isolation (it can do some of it, it promises way more than it can do). Your system's scalability is completely defined by how you architect it, and Docker changes nothing. And WTF is self healing? Docker can't fix any ops problem that it didn't create.

>And WTF is self healing? Docker can't fix any ops problem that it didn't create.

The gp you replied to mentioned both "Docker/Kubernetes"

It's the Kubernetes management layer of Docker-style containers (in pods) that helps with monitoring and restarts: https://www.google.com/search?q=kubernetes+self-healing

Post reply on HN