菜单
Choosing a technology/framework/dependency and longevity matters. Use the heuristic that for non-perishable things, expected remaining life is proportional to current age — favor the proven.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
Start with means, not goals; co-create with partners; leverage contingencies. Use for startup strategy, innovation projects, and uncertain/novel domains where planning is unreliable.
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true.
Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
| name | thinking-lindy-effect |
| description | Choosing a technology/framework/dependency and longevity matters. Use the heuristic that for non-perishable things, expected remaining life is proportional to current age — favor the proven. |
The Lindy Effect, named after a New York deli where comedians discussed career longevity, states that for non-perishable things (ideas, technologies, books, practices), future life expectancy is proportional to current age. If a technology has survived 20 years, it's likely to survive another 20. If it's survived 2 years, expect another 2.
Core Principle: Time is the ultimate test. Old things that still exist have proven their value; new things are still being tested.
Decision flow:
Choosing between options?
→ Are some options significantly older? → yes → APPLY LINDY HEURISTIC
→ Is longevity important for this choice? → yes → FAVOR OLDER, PROVEN OPTIONS
→ Is the new thing solving a new problem? → yes → NEW MIGHT BE APPROPRIATE
When choosing a technology, framework, or dependency and longevity matters:
Skip for short-lived/experimental work where longevity doesn't matter. "Old" isn't automatically "best" — survival predicts further survival, not optimality for a new requirement.
Expected remaining life ≈ Current age
If survived 10 years → Expected to survive another ~10
If survived 50 years → Expected to survive another ~50
If survived 2 years → Expected to survive another ~2
| Language | Age | Lindy Expectation | Evidence |
|---|---|---|---|
| C | 50+ years | 50+ more years | Powers OS, embedded, will outlive us |
| Java | 30 years | 30+ more years | Enterprise backbone, not going away |
| Python | 30 years | 30+ more years | Scientific computing, ML, scripting |
| Go | 15 years | 15+ more years | Proven for infra, backed by Google |
| Rust | 10 years | 10+ more years | Growing, solving real problems |
| New hotness | 2 years | 2-5 years | Unproven, might disappear |
| Database | Age | Lindy Expectation | Notes |
|---|---|---|---|
| PostgreSQL | 35+ years | 35+ more years | SQL is 50+ years old |
| MySQL | 30 years | 30+ more years | LAMP stack foundation |
| MongoDB | 15 years | 15+ more years | Survived NoSQL hype cycle |
| CockroachDB | 10 years | 10+ more years | NewSQL, still proving itself |
| Latest DB | 2 years | Unknown | High risk for production use |
| Framework | Age | Lindy Expectation | Notes |
|---|---|---|---|
| React | 10+ years | 10+ more years | Dominant, ecosystem mature |
| Rails | 20 years | 20+ more years | Productive, battle-tested |
| Django | 18 years | 18+ more years | Python's Rails, stable |
| Express | 14 years | 14+ more years | Node.js standard |
| Newest framework | 1 year | 1-3 years | Likely to be replaced |
| Practice | Age | Lindy Expectation |
|---|---|---|
| Version control | 50+ years | Permanent |
| Automated testing | 40+ years | Permanent |
| Code review | 40+ years | Permanent |
| Agile (core ideas) | 30+ years | Very long |
| CI/CD | 20+ years | Very long |
| Microservices | 10 years | Moderate |
| Latest methodology | 2 years | Unknown |
For each option, determine how long it's been in significant use:
Options for message queue:
- RabbitMQ: 17 years (2007)
- Kafka: 13 years (2011)
- NATS: 11 years (2013)
- NewQueue: 2 years (2022)
Lindy expectation:
- RabbitMQ: 17+ more years
- Kafka: 13+ more years
- NATS: 11+ more years
- NewQueue: 2-5 more years (high uncertainty)
Lindy is a heuristic, not a law. Consider:
When older is better:
- Long-term production systems
- Core infrastructure
- Skills investment
- Dependencies with many consumers
When newer might be appropriate:
- Solving genuinely new problems
- Performance-critical new workloads
- Specific capability older tools lack
- Temporary/experimental projects
A 5-year-old tool in a 5-year-old ecosystem is "old" for that ecosystem:
Kubernetes ecosystem: ~10 years old
- Helm: 8 years → "Lindy" for K8s
- ArgoCD: 7 years → "Lindy" for K8s
- New tool: 1 year → Not Lindy yet
Node.js ecosystem: 14 years old
- Express: 14 years → Maximally Lindy for Node
- Fastify: 8 years → Moderately Lindy
- New framework: 1 year → Unproven
Lindy predicts future survival given current survival. It doesn't say all old things are good:
Correct: "COBOL has survived 60 years, will survive 60 more"
Incorrect: "COBOL is the best choice for new projects"
(Survival ≠ Optimal for new use cases)
Lindy works within stable paradigms. Paradigm shifts create discontinuities:
- Pre-cloud: On-premise databases were Lindy
- Post-cloud: Managed databases emerged
- But: Core database concepts (SQL, ACID) remained Lindy
Perishable: Specific SaaS vendor → Can be acquired, pivoted, shut down
Non-perishable: The practice the vendor enables → Likely Lindy
E.g., Heroku might change, but "platform-as-a-service" concept is Lindy
## Lindy Analysis: Database for New Product
Requirements: ACID transactions, relational data, long-term stability
Options:
| Option | Age | Lindy Score | Fit for Requirements |
|--------|-----|-------------|---------------------|
| PostgreSQL | 35 years | Excellent | Excellent |
| MySQL | 30 years | Excellent | Good |
| CockroachDB | 10 years | Good | Excellent |
| PlanetScale | 5 years | Moderate | Good |
Decision: PostgreSQL (Lindy + excellent fit)
Consider CockroachDB for scale needs (worth the Lindy tax)
## Lindy Career Analysis
Which skills to invest in?
Lindy skills (high confidence in future value):
- SQL (50+ years)
- Unix/Linux (50+ years)
- Git/version control (40+ years)
- Testing fundamentals (40+ years)
Moderate Lindy (good bet):
- Python (30+ years)
- JavaScript (28 years)
- Docker/containers (12 years)
- Kubernetes (10 years)
Low Lindy (speculative):
- Latest framework (1-3 years)
- Trending language (variable)
Investment strategy: Core in Lindy skills, experiments in new
## Lindy Dependency Audit
For each critical dependency:
| Dependency | Age | Last Update | Contributors | Lindy Risk |
|------------|-----|-------------|--------------|------------|
| lodash | 12 years | Active | Many | Low |
| express | 14 years | Active | Many | Low |
| new-lib | 1 year | Active | 3 | High |
Policy: Critical path requires 5+ year Lindy
Experimental features can use newer dependencies
# Lindy Analysis: [Decision]
## Options with Age
| Option | First Stable | Age | Category |
|--------|--------------|-----|----------|
| | | | Proven/Moderate/New |
## Lindy Expectations
| Option | Expected Longevity | Confidence |
|--------|-------------------|------------|
| | | High/Medium/Low |
## Context Adjustments
- Is this a new problem domain? [Yes/No]
- Is the ecosystem mature? [Yes/No]
- Do newer options solve critical gaps? [Yes/No]
## Lindy-Adjusted Decision
Primary choice: [Option with best Lindy + fit]
Rationale: [Why this balances Lindy with requirements]
## Risk if Lindy is Wrong
[What happens if the non-Lindy option outlasts expectations?]
"If a book has been in print for forty years, I can expect it to be in print for another forty years. But, and that is the main difference, if it survives another decade, then it will be expected to be in print another fifty years."
"Technology is at its best when it is invisible."
The technologies you don't think about—TCP/IP, Unix, SQL—are the most Lindy. The technologies that demand constant attention are still being tested.
"The old is to be respected; the new is to be examined."
Lindy doesn't mean reject the new. It means: the burden of proof is on the new. New must demonstrate value; old has already demonstrated survival.