Live data from Hacker News

The diminishing half-life of knowledge

rednafi.com

51–60 of 84 posts

Re: The diminishing half-life of knowledge

#51

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…

Once you understand that inexperienced is an HR-approved euphemism for young, and experienced is an HR-approved euphemism for old, then the discussion they’re having falls into focus:

If large companies need to train someone (typically on a company-specific toolkit) they want to train someone with more room for optimism in their workplace expectations, fewer points of comparison for the quality or utility of the toolset, and who will have less of an ability to exit post-training.

Re: The diminishing half-life of knowledge

#52
In response to the spirit of the article and ignoring the specificity of content, a great way of retaining knowledge over time is Sean Whitelys Memletics courses. His frameworks and practices for studying, learning and retaining any subject matter are very practical. While his “Learn” tool can get a bit verbose, the concepts of reviewing notes in an irregular patterned method over time are extremely effective. I recommend using the Learn tool on a simple subject just to observe the effect the process has on your own experience of retaining knowledge over a few weeks, months and years. I don’t know where this guy Sean ended up - but if you get your hands on his materials, hold on to em! Hopefully that helps.

Re: The diminishing half-life of knowledge

#53
post #46
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…

> 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 Umm, you are just picking survivorship bias tech things. Focusing on html was a good choice. Focusing on xhtml2 or vrml would be a bad choice. HTTP will serve you well. FTP or Gopher not so much. TCP is a better choice than IPX or SCTP, etc. Ult…

Lindy Principle

Re: The diminishing half-life of knowledge

#54
It is important to recognize that even if knowledge becomes untrue because some assumption or fundamental has changed, knowing the history of these changes and why they occurred is still extraordinarily valuable knowledge.

Too many software developers just know the "current thing" without knowing why it is the current thing and the specific issues that caused us to move on from the old thing. This ignorance of the past frequently encourages developers to reinvent an old thing poorly without understanding that not only is it not new but that we stopped doing it in many contexts for good and nuanced reasons.

I think this sense of history is one of the most important aspects of "experience" when hiring. It is easy to train someone on an arbitrary tech stack but difficult to train someone on the history and path dependencies. Many developers are not interested in that history because it doesn't feel relevant to doing a job now. We tend to gain this sense of history by being in the industry long enough that we were part of that history.

Re: The diminishing half-life of knowledge

#55

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…

I think they're about different contexts.

The first paragraph is about training inexperienced computer programmers to do things their way. It's a point frequently made that more experienced programmers don't just need to be trained in the new company's ways, but often need to be untrained from their previous ways -- yet they still cost more. So this isn't about "industry-wide" training, it's more about how company-specific training.

While the second paragraph is more about training relating to transferrable skills. Companies don't want to teach people to become data scientists or ML experts -- they'd rather hire people with those skills already.

Perhaps it helps to think of the first bucket as "generic" programmers, the ones writing CRUD apps or websites or similar. While the second bucket is about "domain-specific" engineers.

Re: The diminishing half-life of knowledge

#56

It's not so much the knowledge itself that has a half-life (unless it is front-end tech knowledge), but the ability to monetize knowledge. You used to be able to make a career out of some niche bit of knowledge but those days are over. You need to work hard just to stay current, in almost every field and that is as much a trend driven by technology as it is driven by the fact that there are so many people of working…

This is an excellent point. The frontier moves quickly, leaving a wake of commoditized skills behind it, but there used to be identifiable, well-paid skills that people chose precisely because the frontier moved slowly. While my instinct is to say that the frontier moves more quickly now, I have a suspicion that this less true than I think it is and what has really changed is that everything has a fast-moving frontier now.

For example, the evolution and development of the Internet technology in the 1990s occurred at an incredible pace that is as fast as anything I've seen since, but back then you could switch to being e.g. an Oracle DBA if you wanted to avoid the chaos, and many people did. Those safe harbors have become rare in tech and the relative pay for them declines every year.

Re: The diminishing half-life of knowledge

#57
You get used to it. Just approach it every time as “learning a new stack” and those old muscle memories will come back automagically.

Knowing how you got to Z from A is valuable knowledge too. Not just in changes to the old stack that is now new again, but to your own knowledge and journey.

It’s ok to not be the smartest person in the room. It’s ok to admit that you need ramp up. What’s not ok is to go around claiming to be an expert and spout inaccurate facts so you’re already one step closer to being awesome in stack A again.

Re: The diminishing half-life of knowledge

#59

It is important to recognize that even if knowledge becomes untrue because some assumption or fundamental has changed, knowing the history of these changes and why they occurred is still extraordinarily valuable knowledge. Too many software developers just know the "current thing" without knowing why it is the current thing and the specific issues that caused us to move on from the old thing. This ignorance of the pa…

> It is important to recognize that even if knowledge becomes untrue because some assumption or fundamental has changed, knowing the history of these changes and why they occurred is still extraordinarily valuable knowledge. [...] I think this sense of history is one of the most important aspects of "experience" when hiring.

I can tell you that in my experience employers do not value this kind of knowledge a lot. Quite the opposite: quite some employers hate such employees who ask "too many inconvenient questions" instead of surfing the hype of the "current/next big thing".

Re: The diminishing half-life of knowledge

#60
post #46

Earlier quoted context omitted.

> 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 Umm, you are just picking survivorship bias tech things. Focusing on html was a good choice. Focusing on xhtml2 or vrml would be a bad choice. HTTP will serve you well. FTP or Gopher not so much. TCP is a better choice than IPX or SCTP, etc. Ult…

Lindy Principle

For those curious

> The Lindy effect (also known as Lindy's Law) is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age. Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy.

https://en.wikipedia.org/wiki/Lindy_effect

Post reply on HN