--- title: The diminishing half-life of knowledge | daily.dev description: Technical skills decay faster than ever in software engineering — a phenomenon known as the 'half-life of knowledge,' coined by economist Fritz Machlup in... canonical: https://daily.dev/posts/the-diminishing-half-life-of-knowledge-o8566flex twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The diminishing half-life of knowledge | daily.dev og:description: Technical skills decay faster than ever in software engineering — a phenomenon known as the 'half-life of knowledge,' coined by economist Fritz Machlup in... og:url: https://daily.dev/posts/the-diminishing-half-life-of-knowledge-o8566flex og:image: https://api.daily.dev/og/posts/O8566FlEX.png og:image:alt: The diminishing half-life of knowledge og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The diminishing half-life of knowledge **[Lobsters](https://daily.dev/sources/lobsters)** · 3 min read · 0 upvotes · 0 comments ## Summary Technical skills decay faster than ever in software engineering — a phenomenon known as the 'half-life of knowledge,' coined by economist Fritz Machlup in 1962. As developers switch stacks and roles, previously mastered skills atrophy and become partially obsolete. The author shares a personal journey across data science and backend engineering, noting the struggle to re-enter data science after years away. Strategies that have helped include engaging with the OSS community, taking notes, tracking learning progress, adopting stable technologies, and writing about what you learn. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the half-life of knowledge concept and who coined it? The half-life of knowledge is the amount of time that must elapse before half the knowledge in a particular area is superseded or shown to be untrue. The term was coined in 1962 by economist Fritz Machlup, borrowing the metaphor from radioactive decay. An IEEE Spectrum article further explores how the half-life of engineering knowledge is shrinking faster than ever, with continuous learning as the primary countermeasure. _Engineers navigating stack transitions and skill decay track discussions like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 13 comments across lobsters, hackernews (as of 2026-08-07). **TL;DR:** Commenters broadly agree that chasing fast-moving tech stacks is exhausting and counterproductive, and advocate for building on stable, long-lived technologies; there's also a nuanced view that deep, transferable principles age far better than surface-level framework knowledge. **Sentiment:** 25% positive · 50% mixed · 25% skeptical **The case for** - Stable, established technologies (C, Java, Go, SQL, Unix) offer durable career value and resist rapid obsolescence. - Deep conceptual knowledge — concurrency, memory management, data processing patterns — transfers well across ecosystems even when specific APIs change. - Vanilla/plain approaches (e.g., plain JS, shell scripting) can be surprisingly productive and avoid the churn of framework ecosystems. - The Lindy effect suggests that knowledge that has already lasted a long time is likely to remain useful far into the future. **The pushback** - Rapidly shifting frontend and framework ecosystems burn developers out and make genuine mastery nearly impossible. - Websites and software quality have arguably gotten worse despite (or because of) constant stack churn. - Developers who choose volatile tech stacks bear some responsibility for their own knowledge decay, since the choice of technology domain heavily influences how quickly skills become obsolete. **By community** - lobsters (mixed): Discussion is lively and substantive, with strong agreement that stable technologies are preferable, tempered by a nuanced point that core principles transfer well even when surface details change. - hackernews (mixed): No comments were available to assess sentiment. **Hottest debate:** Whether React's dominance has actually stabilized the frontend ecosystem or whether meaningful paradigm shifts still occur within it. **Open questions** - How should developers balance learning timeless fundamentals versus staying current enough to remain employable in fast-moving markets? - Will C become a highly paid niche skill the way COBOL did, given how few younger developers know it? - Does the Lindy effect reliably predict which technologies are worth investing in deeply? **Highlights** > I think it's burning out people left and right that are trying to chase all the technological trends and fads in highly active fields of our trade. This is most prominently seen with web developers, who change their preferred software stack every 6-12 months. Have websites become better over the years given the amount of time poured into this technological tumbler? No, they have become worse, e.g. more bloated, less accessible, slower, more energy-consuming, etc.. This is why I think it makes more sense to build a career on top of established technologies and more stable departments. One department to avoid is probably frontend development, which sees many shifts of core technologies over the years and is usually not well-paid, because it is almost impossible to mature in this field and given the frequent technology shifts companies are literally unable to accumulate technical debt in a specific technology that warrants paying experts to fix and maintain their stuff. Backend development on the other hand, with some exceptions, tends to be conservative in terms of employed technologies. With just PHP, MySQL, Java, C/C++, Go (and others) making up the majority of the software stack, you could have lived under a rock since 2020 and still be probably good to go with a very flat learning curve. Companies will have invested into a much smaller and stable set of technologies, and they will have accumulated technical debt motivating them to pay you good money to take care of their software for you. Just look at the job listings: Most are looking for C#, Java, C/C++ developers; the few web development gigs are usually not well-paid, but backend can still keep you afloat. I recently noticed how few developers in my age group (late 20's) actually know how to program in C (not C++). Considering how much software is still written in this language (often for good reasons), this niché could become very profitable in the future, just like COBOL turned into a well-paid niché after the 80's. So yeah, to briefly reflect on the article's topic: It's your choice how quickly your knowledge diminishes, and your own fault if you choose a profession that does not value your significant time investments to master a given technology. True mastery is not an end in itself, as it heavily depends on the context it is formed and used in. > — [FRIGN on lobsters · 8 points, 2 comments](https://lobste.rs/s/bx9ss7/diminishing_half_life_knowledge#c_rdtnbv) > Yeah I also don't have too much patience for learning slightly different versions of the same thing, over and over again. I call it "motion without progress" This kind of thing is the motivation of for Oils, e.g. - Narrow waists and O(MxN) vs O(M+N) is an **economic** argument about how much software there is, and how much you would have to understand - e.g. https://www.oilshell.org/blog/2022/03/backlog-arch.html - The *Lindy effect* is maybe a good contrast to the "half-life" idea - Knowledge that's been around for a long time is likelier to last longer into the future. If you learned HTML or SQL or shell in 1999, that knowledge is still useful, and will continue to be for decades. - mentioned here - https://www.oilshell.org/blog/2021/01/philosophy-design.html It's maybe surprising but I would put "Unix" along with basic computer science knowledge. I used to think of Unix as a separate bunch of implementation details, sorta like Windows, but then I came to understand that the basic ideas are fundamental. It's how the "world works" for fundamental (economic) reasons, not accidental ones. --- More concretely, I was genuinely surprised that I would get so much done with shell at my job -- e.g. with respect to - testing (which IMO is a bigger bottleneck than writing code. LLMs create a testing bottleneck.) - benchmarking - also a key to high quality software - whipping up data science and machine learning pipelines. Bridging clusters and single machines, which is super useful and necessary As a concrete example, I did a side project which was basically "shell scripts," that led to a paper with >5000 citations now (with the author of the deep learning textbook) https://arxiv.org/abs/1607.00133 https://scholar.google.com/scholar?cluster=11431158613977668861&hl=en&as_sdt=0,39&as_vis=1 (The citation count is an obvious sign of bubble, and not a good metric. But if you care about your career, then it's something employers care about. I of course don't care, because I decided to work on a shell instead of deep learning :-P ) --- To elaborate, I'd say I try to think about the timeless concepts of code and data when programming. Processes and files aka protocols. I try to think less about specific languages, specific frameworks, or specific design patterns. I try to build up a vocabulary that I can use in multiple contexts, and remember less. I'd say the fundamental code/data approach works for everything from writing a blog, creating web services, distributed systems, and data science/machine learning. It scales up and down and it's applicable to many problems. > — [andyc on lobsters · 4 points, 2 comments](https://lobste.rs/s/bx9ss7/diminishing_half_life_knowledge#c_lozqh3) > There's a bunch of ways to think about this. One is that there are different levels of knowledge, from "knowing it exists" to "knowing when to use it" to "hands-on usage" to "full-on expertise". The first two levels are _much_ less work to achieve, just reading articles here is sufficient... and this limited knowledge is often all you need for interviews. E.g. years ago I was asked during a job interview about what NoSQL databases are and why one would use them. I'd never used any of them, but I knew enough to give a good answer. If asked I would have certainly explained I didn't have personal experience, but they didn't ask that. At the same time, while there's a lot of superficial churn, a lot of core principles don't change, so expert-level understanding transfers quite well: 1. The experience I have writing an event-driven networking framework 20 years ago still applies today. The specific libraries people use are different, and I'm often thinking of different use cases (scientific computing instead of IRC bots), but a strong understanding of concurrency and parallelism and the implications of blocking APIs is still very helpful. 2. [The basic techniques for reducing memory usage in data processing](https://pythonspeed.com/articles/data-doesnt-fit-in-memory/) apply in a large number of contexts. So whether it's a array-processing library or an database, to reduce memory you need to ask "how do I index, how do I do processing in batches, how do I represent data in a more compact format". The specific APIs will vary, but they'll be the solution in some form or another. > — [itamarst on lobsters · 5 points, 1 comments](https://lobste.rs/s/bx9ss7/diminishing_half_life_knowledge#c_cptyyv) > I think "web developers swap out their entire stacks every 6-12 months" was somewhat true for a while but has kind of stopped these days. React won. > — [koreth on lobsters · 5 points, 1 comments](https://lobste.rs/s/bx9ss7/diminishing_half_life_knowledge#c_lslkr2) **Source threads** - [lobsters](https://lobste.rs/s/bx9ss7/diminishing_half_life_knowledge) · 13 points · 13 comments - [hackernews](https://news.ycombinator.com/item?id=38238121) · 5 points · 0 comments ## Similar posts on daily.dev - [How to avoid knowledge decay in software engineering](https://daily.dev/posts/how-to-avoid-knowledge-decay-in-software-engineering-dqdaql9bm) · LeadDev · 2 upvotes · 0 comments - [Software engineering may no longer be a lifetime career](https://daily.dev/posts/software-engineering-may-no-longer-be-a-lifetime-career-uszacmbn5) · sean goedecke · 321 upvotes · 85 comments - [The West Forgot How to Build. Now It's Forgetting Code](https://daily.dev/posts/the-west-forgot-how-to-build-now-it-s-forgetting-code-hw1fbcw1c) · Hacker News · 1 upvotes · 0 comments --- Tags: [#career](https://daily.dev/tags/career) [View this post on daily.dev](https://daily.dev/posts/the-diminishing-half-life-of-knowledge-o8566flex) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The diminishing half-life of knowledge","url":"https://daily.dev/posts/the-diminishing-half-life-of-knowledge-o8566flex","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-diminishing-half-life-of-knowledge-o8566flex"},"datePublished":"2026-08-07T08:02:11.297Z","dateModified":"2026-08-07T08:02:52.056Z","description":"Technical skills decay faster than ever in software engineering — a phenomenon known as the 'half-life of knowledge,' coined by economist Fritz Machlup in...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d48ac3f8b4c3185e9406151bde7819fb?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d48ac3f8b4c3185e9406151bde7819fb?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-diminishing-half-life-of-knowledge-o8566flex","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"career","timeRequired":"PT3M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"The diminishing half-life of knowledge"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-diminishing-half-life-of-knowledge-o8566flex#faq","mainEntity":[{"@type":"Question","name":"What is the half-life of knowledge concept and who coined it?","acceptedAnswer":{"@type":"Answer","text":"The half-life of knowledge is the amount of time that must elapse before half the knowledge in a particular area is superseded or shown to be untrue. The term was coined in 1962 by economist Fritz Machlup, borrowing the metaphor from radioactive decay. An IEEE Spectrum article further explores how the half-life of engineering knowledge is shrinking faster than ever, with continuous learning as the primary countermeasure. Engineers navigating stack transitions and skill decay track discussions like this on daily.dev."}}]} ```