@MinLiBuilds: I wish I had read such an excellent article during my undergraduate and graduate studies; my career would have turned out completely differently. This is her research methodology, very smart and solid, with compounding returns. Translation: vivek @itsreallyvivek how to be good at r…

I wish I had read such an excellent article during my undergraduate and graduate studies; my career would have turned out completely differently. This is her research methodology, very smart and solid, with compounding returns. Translation: vivek @itsreallyvivek how to be good at research Nobody has actually taught you how to do research. You get a desk, a problem picked by someone else, and a vague instruction to "make something new." So most people reverse-engineer the job through what they can observe (papers, posts, announcements) and end up learning how to *look* like a researcher, not how to *be* one. Real research ability is a stack of small skills, and almost every one of them can be cultivated through deliberate practice. **Pick your own problems** Richard Hamming had a habit at Bell Labs that made him unpopular at lunch. He'd ask the person next to him what the important problems were in their field, then ask why they weren't working on them. People started eating at other tables. The question stings because most of us don't have a good answer. We don't choose problems — we absorb them: from advisors, from announcements made by some big lab last quarter, from papers everyone is forwarding and citing this week. The trouble with absorbed problems is that you only have the conclusion, not the reasoning behind it. You know some famous lab cares about a certain direction, but you don't know why, what they expect to find, or what would make them drop it. When they pivot, you'll notice a year later. And on a problem that's already popular, you're racing against a thousand people who started earlier and have more compute. John Schulman's guide to machine learning research divides the work into two modes. The first: read the literature and find things to improve. The second: **choose an outcome you genuinely want to achieve, then work backward to design experiments.** He advocates for the second, and the hidden reason is that it forces originality. A goal you actually care about will drag you into territory no survey paper has ever covered. As for "taste," people often talk about it as if it were a talent. But it behaves more like a muscle. Before running each experiment, predict its outcome; cover the results section of a paper and guess the data just from its method; note down which results published this month will still matter in two years and later verify your hit rate. One prediction plus one correction, repeated hundreds of times — that's how every good model is trained, including the one inside your head. **Upgrade your inputs** Shared reading lists produce shared ideas. If your information diet is just the arXiv trending list plus whatever survives your group chat filter, you will inevitably reach the same conclusions as everyone else at the same time, which makes those conclusions nearly worthless. Old material is severely underrated. This field is always replaying its own past with a delay: mixture of experts (MoE) dates back to 1991, LSTMs to 1997, backpropagation became mainstream in 1986. Rich Sutton wrote "The Bitter Lesson" in 2019 in just over a thousand words, and it predicted the field's trajectory better than surveys ten times its length. Claude Shannon gave a talk on creative thinking in 1952, and his first trick was to shrink the problem until it was almost trivial, crack that shrunken version, and then gradually add difficulty back. That single trick will break through more walls than any modern productivity advice. **Breadth is as important as depth.** Interpretability research unashamedly borrows from neuroscience; eval design is mechanism design in a white coat; a practical understanding of how GPUs actually move memory lets you predict which architecture papers are doomed before the benchmark results come out; and honest statistics is arguably the rarest skill in machine learning, where much of what gets published as "rigor" is just "gut feeling" with error bars. One more thing. **Read the paper itself, not posts summarizing it.** The appendix is where secrets are buried, and the "Limitations" section is often the most honest part of the entire document. **Write everything down** Paul Graham points out that an idea always feels fully formed before you try to put it into words. But writing it down exposes the gaps your brain has glossed over: assumptions you never tested, steps that don't actually connect, two claims that quietly contradict each other. Feynman's principle was that the first person you must not fool is yourself, because you are the easiest one to fool. **Writing is the cheapest defense mechanism ever invented.** Darwin went further and formalized it: any fact that contradicted his theory was written down immediately, because he found his memory was much faster at deleting inconvenient evidence than favorable evidence. Your memory does the same to your failed runs. Keep a log: hypotheses, setup, expectations, results, updated beliefs. Re-reading last month's entries will humble you in a way no reviewer ever can.