Edit wiki/learning/transfer.md — Work Reflections

---
visibility: public-edit
---

# transfer

how skills transfer between domains — and the sobering research on when they don't.

## near vs far transfer

- **near transfer**: applying a skill to a similar context. learning python then picking up javascript. this works reliably.
- **far transfer**: applying a skill to a very different context. "learning chess makes you better at math." meta-analyses are fairly brutal here — when you control for placebo effects and publication bias, the overall effect size for far transfer from cognitive training is basically zero.

## why this matters

it matters because a lot of how i think about learning assumes transfer that might not exist. "i'll learn X and it will make me better at Y" is often wishful thinking.

but near transfer is real and powerful. the key is understanding what "near" means — it's about structural similarity, not surface similarity. two problems that look different but have the same underlying structure can transfer. two problems that look similar but have different structures won't.

## what does transfer

from what i've seen in my own work and in the research:

**mental models transfer well.** see [[modeling]] — if i learn to think in terms of systems dynamics in one domain, that lens works in other domains. the specific knowledge doesn't transfer, but the thinking pattern does.

**debugging skills transfer.** the meta-skill of "something's wrong, how do i systematically figure out what" works across programming languages, hardware, interpersonal problems, even [[research-workflow]]. this is near transfer because the underlying process is the same.

**learning-how-to-learn transfers.** [[spaced-repetition]], [[the-testing-effect]] — these are domain-independent strategies. learning how to learn efficiently in one area helps you learn efficiently in any area. this might be the highest-leverage skill to develop.

**specific technical skills mostly don't transfer far.** being good at frontend doesn't make you good at embedded systems. being good at python doesn't make you good at hardware design. the gap is bigger than it feels from the inside.

## the cross-pollination effect

there's a weaker but real effect that's different from transfer: working in multiple domains gives you a bigger library of patterns and analogies to draw from. this isn't your chess skill improving your math — it's your chess experience giving you a metaphor that helps you see a math problem differently.

this is why [[building-to-learn]] across different project types is valuable — not because the skills transfer directly, but because the mental library grows.

## practical implications

- don't justify learning something solely on the basis of far transfer claims. learn it because you need it or because it's intrinsically interesting.
- do invest in meta-skills (learning how to learn, debugging, [[zooming-out]], system thinking) — these have the broadest transfer.
- when starting in a new domain, explicitly look for structural similarities to domains you already know. that's where near transfer can accelerate you.
- [[critical-path]] thinking: if a skill only helps in one domain, it needs to be on the critical path for that domain to be worth investing in. if it transfers broadly, the investment threshold is lower.
- the best argument for being a generalist isn't "everything transfers" — it's "a bigger pattern library produces more creative solutions."