research workflow
how to approach research problems. the process i've refined through various technical projects.
the process
- read a lot — "literally read more" appears so often in my reflections it should be instinctual. before you can find an interesting problem, you need to know the landscape.
- find an interesting technical problem — something that excites you, not just something that sounds impressive. excitement sustains perseverance.
- start reading hella — once you have a direction, go deep. papers, implementations, discussions.
- build understanding — "start with good understanding & foundation." the investment in understanding pays compound returns.
- prototype and iterate — "prototyping is so great." test your ideas early.
the reading imperative
"literally read more" keeps showing up because i keep not doing it enough. there's a resistance to reading — it feels passive, it's not as immediately rewarding as building. but every time i invest in reading, the building goes 10x faster.
this connects to the CEO's observation that "knowledge is super useful" (see startup-workflow). aggressive learning, whether through reading or LLMs, compounds over time.
the hype trap
"it is so easy to get fooled by hype." in research, some ideas sound amazing but don't hold up. a collaborator who is "very much a hype machine" taught me this — excitement about an idea and validity of an idea are different things. zooming-out helps distinguish between the two.
connecting to mentors
"talking with a mentor was very good, moving away from crazy big big is important." mentors help you scope research problems down to something tractable. left unchecked, i tend to pick problems that are way too ambitious. see team-dynamics for more on learning from others.
foundation → flow
"not spending much effort and still going great because just have great understanding." when you invest in understanding upfront, the implementation phase becomes almost effortless. this is the same principle as software-workflow — think first, build second.