224 Matching Annotations
  1. Aug 2025
    1. Research = uncertainty. Unlike building a house, you don’t know all the materials or obstacles ahead.

      Can I apply this framework for my research workflow to accommodate both "structure" and "flexibility"? I guess the Heilmeier Catechnism will stand on the "structure" part. Iteration, "fail fast" will stand on the "flexibility" part. Can I formulate this sweet combination of "structure" and "flexibility" in research practice? Is there anyone before me who adapt this strategy? How to balance between planning, execution and replanning?

      The right question frame might be: "How to navigate uncertainty efficiently?"

    2. Visible progress tracker Have a simple Kanban board (Notion/Trello) with columns: Month → Week → Day → Done. This makes milestones not just a plan, but a visual progress bar.

      this is like from Duolingo's streak

    3. Define Minimum Viable Output (MVO) Ask: What’s the smallest version of this milestone that proves progress? Example: For Collect → don’t wait until you’ve read 50 blog posts. Ten high-quality ones may be enough to proceed.

      Parento 80/20 Need lots of elaboration since it's important

    1. A milestone introduces artificial scarcity: “I only have 2 weeks to gather advice → better prioritize the most important sources.”

      Okay so I guess the right question to consider is: now I only give myself 2 weeks for this task, then how to make the most out of it. This is the right problem frame! Now we proceed to tackling it. I believe the Parento 20/80 law is one of the correct answer. Any others?

    2. “Keep reading until I know enough” → “By end of Week 2, I’ll have 20 summarized advices.” “Keep synthesizing until it feels right” → “By end of Week 4, I’ll have a draft, even if messy.”

      "until I know enough" or "until I feel right" are so dangerous; my mind is really bad at time realization. It will push things to infinite.

    3. Creates time pressure → reduces endless wandering. Builds momentum by giving you small wins. Forces trade-offs: if time is almost up, you’ll cut distractions more aggressively.

      These are important

    4. Exploration Log → Any recurring themes worth folding into (1) later?

      What is this? It's might be a very important idea to overcome the problem of evolving tree structure!

    5. Example: Friday afternoons = serendipity time.

      so what should be the optimal frequency? one per week seems too sparse. And btw I read somewhere that allocate a "mind wandering" slot in everyday also improves concentration when we're in the main task

    6. Step 1: Define a Sharp Focus Box Write down your main goal in one crisp sentence: “Collect and synthesize research advice on problem-driven research to develop my own meta research style.” Break this into milestones (e.g. “Collect 20 pieces of advice → Cluster key themes → Draft my meta approach”). Keep this Focus Box visible in your workspace (sticky note, Notion top bar). This serves as your anchor whenever FOMO tries to pull you away.

      I guess this help anchor our workflow and also to filter noises

    1. A good “bit to flip” has 3 properties: Universality: shared by many current methods. Constraining: it actually limits progress toward capabilities. Replaceability: you can imagine an alternative (not just removing, but replacing with something better). Bad flips: assumptions that were helpful approximations without being real bottlenecks → flipping them just adds complexity.

      need elaboration

    2. 3. Build Trust in Your Evaluation Harness If you never rerun baselines, how do you know: your code, logging, and evaluation are sound? improvements aren’t due to hidden differences in implementation? By reproducing others’ results in your own harness, you ensure a fair playing field for comparing your new method. 👉 Otherwise, reviewers (and yourself) can’t be sure whether gains are real or artifacts.

      Donggyun used to mention with me about this. It's possible that the improvement in performance is just due to noise/artifact (e.g randomness in seed), but might not be real improvement.

    3. Papers tend to report best-case or average numbers, not the messy reality: instability across seeds, catastrophic drops mid-training, reproducibility quirks. By rerunning, you see the variance, fragility, and edge cases that are invisible in benchmark tables. 👉 Schulman’s insight about instability in policy gradients (leading to TRPO) only came from seeing the failures himself, not from reported scores.

      this is gold

    4. Different methods break in different ways. Running several gives you a menu of failure patterns: instability, sample inefficiency, poor generalization, etc. These failures help surface the real subproblems you need to tackle.

      Yes different methods break in different ways but they might share some failure modes (e.g sample inefficiency). We want to find a big bit to flip, i.e the one that is shared by as much existing methods as possible.

    5. 5. De-Risk Your Research Jumping straight into your own method is high-risk — it may fail for reasons you could’ve predicted by simply running known baselines. Testing others first is a low-risk learning stage that grounds your work in reality before you spend months on a new algorithm. 👉 It’s like scouting the terrain before building your own path.

      need elaboration

    6. Running others’ methods forces you to internalize their assumptions, strengths, and weaknesses. Often, you notice small tweaks that make a huge difference, or you realize why a method doesn’t scale to your problem. Schulman explicitly said: testing many methods was a way of discovering what properties mattered most (stability, variance reduction, etc.). 👉 This hands-on process sharpens your taste and informs your own design choices.

      need elaboration