08c140a9f1628acf88124b07b641ed96125168e3
new file mode 100644
index 0000000..fe5539f
@@ -0,0 +1,173 @@
+---
+visibility: public-edit
+---
+
+# work reflections
+
+distilled from real experiences — anonymized notes from a neurotech startup internship, hackathons, math competitions, coding sessions, and a lot of honest self-reflection. not polished advice. real patterns that worked, failed, or taught something.
+
+76 pages across 13 sections. heavily interconnected — browse from any entry point.
+
+## sources & methodology
+
+[[sources-and-methodology]] — where this content came from (IdeaFlow, Apple Notes, Obsidian, mentor conversations), how to search those sources, and what was useful.
+
+---
+
+## core strategies
+
+- [[zooming-out]] — stepping back from work. walks, scenery changes, thinking time.
+- [[resyncing]] — communication patterns. sync meetings, high-bandwidth comms, "short circuit."
+- [[critical-path]] — "is this critical path?" as the core prioritization question.
+- [[intentionality]] — the meta-skill applied to work, relationships, growth.
+
+## work patterns
+
+- [[startup-workflow]] — weekly cadence, re-entry format, growth numbers, 80-15-5.
+- [[electronics-workflow]] — breadboarding → wiring → UX.
+- [[software-workflow]] — think first, types, iterate, then implement.
+- [[vibe-coding]] — AI coding reflections. rotting, context switching, trusting agents.
+- [[modeling]] — "all models are wrong but some are useful."
+- [[research-workflow]] — approaching research problems.
+
+## mentality & inner game
+
+- [[impostor-syndrome]] — from "everyone is cooking me" to "acceleration > position."
+- [[perseverance]] — staying when things are cooked.
+- [[narratives]] — how framing affects motivation.
+- [[resets]] — reset options by emotional/physical state.
+- [[gratitude-and-appreciation]] — gratitude as a tool.
+
+## team & relationships
+
+- [[team-dynamics]] — bandwidth in comms, "assume no ill will."
+- [[relationship-repair]] — deliberate walks to fix friction.
+- [[feedback-and-honesty]] — "tell them how im feeling, dont ask for anything, keep working."
+
+## meta
+
+- [[operation-optimization]] — periodically optimizing how you operate.
+
+---
+
+## mentorship
+
+lessons from 30+ mentor conversations, anonymized.
+
+- [[agency-talk]] — the pivotal "take agency" conversation
+- [[pattern-recognition]] — how mentors spot what you cant see
+- [[asking-good-questions]] — extracting value from conversations
+- [[the-stocks-metaphor]] — acceleration > position, growth compounds
+- [[disagreeing-productively]] — "disagree and commit", being forceful
+
+## things that worked
+
+positive patterns extracted from weekly reflections. not evolution — just wins.
+
+- [[morning-routines]] — morning patterns that produced good days
+- [[energy-hacks]] — specific boosts for energy and focus
+- [[social-wins]] — relationship strategies that worked
+- [[work-sessions]] — patterns of productive sessions
+- [[mindset-shifts]] — moments where mindset change unlocked performance
+
+## research notes
+
+technical workflows from a neurotech internship.
+
+- [[signal-processing-workflow]] — EEG pipeline
+- [[debugging-hardware]] — binary search debugging hardware
+- [[reading-papers]] — extracting value from academic papers
+- [[experiment-design]] — designing tests, iterating, ensuring robustness
+- [[emotions-and-work]] — when emotions cloud work
+
+## strategies
+
+distilled from 100+ IdeaFlow entries.
+
+- [[prioritization]] — raise or fold, the yes-brain mistake
+- [[habit-formation]] — identity approach, trigger-response
+- [[learning-from-experience]] — the reflection engine
+- [[framing-and-narrative]] — reframes, the articulation effect
+- [[social-strategy]] — graph search, mutual growth model
+
+## inner work
+
+Joe Hudson / Art of Accomplishment influenced.
+
+
+## learning science
+
+how learning actually works.
+
+- [[spaced-repetition]] — Ebbinghaus, Mochi, natural spacing
+- [[the-testing-effect]] — retrieval practice > re-reading
+- [[building-to-learn]] — learn by building, not studying
+- [[transfer]] — how skills transfer between domains
+
+## flow & deep work
+
+getting into and maintaining focus.
+
+- [[monotony-and-creativity]] — 80-15-5 rule
+- [[distraction-management]] — AI rotting, escape ladders
+- [[energy-cycles]] — ultradian rhythms, 90-min blocks
+
+## decision-making
+
+frameworks for choosing what to do.
+
+- [[reversible-vs-irreversible]] — type 1 vs type 2 decisions
+- [[regret-minimization]] — 80-year-old self test
+- [[fomo-trap]] — FOMO is position, not growth
+- [[sunk-cost-and-quitting]] — when to keep going vs quit
+- [[information-gathering]] — how much research before deciding
+
+## sleep & energy
+
+managing the physical substrate.
+
+- [[circadian-rhythm]] — light, meals, temperature
+- [[food-and-focus]] — food comas, the ~7pm cutoff
+- [[exercise-as-reset]] — exercise as most reliable reset
+- [[napping-and-recovery]] — strategic napping, breathwork
+
+## math problem-solving
+
+from math modeling competitions and physics.
+
+- [[problem-framing]] — choosing the right abstraction level
+- [[monte-carlo-and-simulation]] — when to simulate vs solve
+- [[estimation-and-sanity-checks]] — Fermi estimation
+- [[competition-strategy]] — time management, problem selection
+- [[mathematical-writing]] — writing modeling papers
+
+## debugging
+
+the meta-skill. harrison's favorite topic.
+
+- [[the-30-hour-bug]] — one line fix after 30 hours
+- [[binary-search-your-life]] — debugging as life meta-skill
+- [[hardware-vs-software]] — can't printf a circuit
+- [[rubber-duck-and-zoom-out]] — explaining reveals answers
+- [[assumptions-kill]] — every long session has a wrong assumption
+
+## writing as thinking
+
+writing discovers what you think.
+
+- [[writing-to-understand]] — writing as debugging for thought
+- [[the-reflection-gap]] — insight without action
+- [[articulation-as-memory]] — naming patterns makes them usable
+- [[public-vs-private]] — honesty vs clarity tradeoff
+- [[journaling-systems]] — what works and what doesn't
+
+## from obsidian
+
+older reflections that still resonate.
+
+- [[before-the-awakening]] — pre-startup self-reflection
+- [[compiled-advice]] — accumulated wisdom
+
+---
+
+*published notes on [moonflowers.xyz](https://www.moonflowers.xyz/notes) — especially [on modeling](https://www.moonflowers.xyz/notes/mDl1nG_N0t3-on-modeling), [operation big items](https://www.moonflowers.xyz/notes/YWtzu4HKbA-operation-big-items), [reset options](https://www.moonflowers.xyz/notes/reset_options), and [on optimized learning](https://www.moonflowers.xyz/notes/mWCmDjrZH--a-note-on-optimized-learning).*
\ No newline at end of file
new file mode 100644
index 0000000..e73ef06
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# log
+
+## [2026-04-11] ingest | Initial wiki population
+
+ingested content from 6 source categories:
+- neurotech startup internship reflections (Apple Notes, summer 2025)
+- IdeaFlow reflections (100 #reflection + 47 #operation entries, feb-apr 2026)
+- other Apple Notes reflections (math competitions, vibe coding, projects)
+- moonflowers.xyz published notes
+- reset strategies (direct experience)
+- Joe Hudson / Art of Accomplishment concepts (web research)
+
+created 21 wiki pages across 5 categories: core strategies (4), work patterns (6), mentality & inner game (6), team & relationships (3), meta (2). all pages cross-linked with wikilinks.
\ No newline at end of file
new file mode 100644
index 0000000..3ca7deb
@@ -0,0 +1,33 @@
+---
+visibility: public-edit
+---
+
+# confidence
+
+where confidence comes from, the validation trap, and the shift toward self-acceptance.
+
+## the achievement treadmill
+
+for a long time, i thought confidence came from achievements. ship something → feel confident → confidence fades → need another achievement. the cycle never ends because no achievement is ever "enough" to permanently satisfy the need.
+
+this is the core of [[impostor-syndrome]]: measuring yourself by position (what you've done) instead of acceleration (how fast you're growing).
+
+## the validation trap
+
+"working on referral.bike was pretty short sighted and approval seeking." when confidence depends on external validation, you optimize for easy wins and other people's opinions. see [[critical-path]] — approval-seeking pulls you off the critical path.
+
+## confidence from self-acceptance
+
+Joe Hudson (Art of Accomplishment) teaches that confidence comes from self-acceptance, not from achievement. this isn't "just believe in yourself" platitude — it's a practice of noticing the patterns of self-judgment and letting them pass instead of building on them.
+
+## purpose and confidence
+
+"there is an ease in unfocus that is unsettling — want purpose ↔ confidence." these are linked. when i have clear purpose (see [[intentionality]]), confidence follows naturally. when i'm drifting, confidence drops and the inner critic gets louder.
+
+## the acceleration reframe
+
+from the [[impostor-syndrome]] breakthrough: "acceleration is much better than position." this gives confidence a new foundation — not "what have i done?" but "how fast am i learning?" the stocks metaphor: skills and mentality go up, cost to do things goes down.
+
+## building evidence
+
+"things have worked — i spent good effort to make things work." keeping a record of things that worked — not grand achievements, but moments where effort paid off — builds evidence against the inner critic. see [[gratitude-and-appreciation]].
\ No newline at end of file
new file mode 100644
index 0000000..5eae9dc
@@ -0,0 +1,37 @@
+---
+visibility: public-edit
+---
+
+# critical path
+
+"is this critical path?" — the core prioritization question. simple to ask, hard to follow.
+
+## the question
+
+before starting any task, ask: is this on the critical path to the thing that actually matters? if not, why am i doing it?
+
+## why it gets ignored
+
+the honest answer is usually pleasure. something is fun, or it's easy, or it feels productive. working on a side project was "pretty short sighted and approval seeking; took the easiest thing on the list." the critical path question gets overridden by whatever feels good in the moment.
+
+this connects directly to [[narratives]] — with an excited narrative, i *want* to work on the critical path. without one, i drift to whatever is most gratifying.
+
+## the efficiency trap
+
+a CEO i worked with put it well: "productivity is output / time. not how productive you feel." and even sharper: "efficiency is |output|/time. most of the time |output| is in a direction nobody cares about."
+
+you can be incredibly efficient at something that doesn't matter. the critical path question catches this — it's not about how fast you're going, it's about whether you're going in the right direction.
+
+## wasted setup time
+
+"wasted a lot of time on setup that didn't matter — ditching them feels so good." sometimes the critical path means abandoning work you already invested in. sunk cost is real.
+
+## too fixated vs. too scattered
+
+there's a tension: "too fixated on doing a single thing — can start 1-3 things and have fun." critical path thinking can make you too rigid. the 80-15-5 rule from [[startup-workflow]] addresses this — 80% mission-focused, 15% slightly tangential, 5% something completely whacky.
+
+monotony is the death of creativity and [[intentionality]]. the solution isn't to abandon critical path thinking but to build in structured space for exploration.
+
+## applying it
+
+periodic check-ins with yourself (see [[operation-optimization]]). stop, ask: is what i'm doing right now the most important thing? if not, why? sometimes the answer is "because i need a break" and that's fine — see [[resets]]. sometimes the answer reveals drift.
\ No newline at end of file
new file mode 100644
index 0000000..c6f20fd
@@ -0,0 +1,82 @@
+---
+visibility: public-edit
+---
+
+# assumptions kill
+
+every long debug session, without exception, traces back to a wrong assumption. the bug was always findable — you just weren't looking where it was because you "knew" it couldn't be there.
+
+## the pattern
+
+here's how it always goes:
+
+1. something breaks
+2. you form a mental model of what's wrong
+3. you debug based on that model
+4. hours pass
+5. you discover the actual cause was in a part of the system you never questioned
+6. you realize you had an unexamined assumption that ruled out the correct hypothesis from the start
+
+the [[the-30-hour-bug|30-hour bug]]: i assumed the HTTP library faithfully forwarded my POST body through redirects. it didn't. that assumption meant i spent 30 hours looking at everything except the one thing that was broken.
+
+hardware debugging is the same. i'll assume a component is working because it's new, or because "i just tested that." but "new" doesn't mean functional, and "just tested" might mean i tested under different conditions. [[hardware-vs-software|dead components are invisible]] precisely because you assume they're alive.
+
+## types of hidden assumptions
+
+### "this part works"
+
+the most common and most dangerous. you've tested a component, it passed, so you mentally mark it as "known good" and never revisit it. but "works" is context-dependent. something that works in isolation might fail in combination. something that worked yesterday might not work after a dependency update.
+
+### "this library does what the docs say"
+
+libraries have bugs. docs have gaps. undocumented behaviors are everywhere. the assumption that third-party code is correct is reasonable — until it isn't. and when it isn't, you can waste enormous time because you're looking at your code while the bug is in theirs.
+
+### "the environment is the same"
+
+"it works on my machine." different OS, different compiler version, different network configuration, different timezone, different locale. the assumption that your environment matches production (or matches your teammate's machine) is wrong more often than you'd think.
+
+### "i understand the system"
+
+maybe the deepest one. you think you know how the system works, so you debug based on that understanding. but your [[modeling|mental model]] is always an approximation. the gap between your model and reality is where bugs hide.
+
+## how to systematically challenge assumptions
+
+### the assumption audit
+
+when you're stuck, stop debugging and start listing assumptions. literally write them down:
+
+- i assume the request is reaching the server
+- i assume the database connection is live
+- i assume this function returns what i think it returns
+- i assume this config file is being read
+- i assume the data is in the format i expect
+
+then go through the list and verify each one. not "i'm pretty sure" — actually verify. print it, log it, test it directly. the one you're most confident about is often the one that's wrong, because high confidence is what prevents testing.
+
+### "what if the opposite were true?"
+
+for each assumption, ask: what if this were wrong? what would the symptoms look like? do the symptoms match what i'm seeing? this is essentially hypothesis inversion — instead of trying to prove your theory right, try to prove it wrong. this is basic scientific method, but it's remarkably hard to do when you're emotionally invested in your current theory.
+
+### fresh eyes
+
+someone who doesn't share your assumptions will question things you'd never think to question. this is why [[rubber-duck-and-zoom-out|rubber duck debugging]] works — explaining to someone (or something) that doesn't have your context forces you to make your assumptions explicit. and explicit assumptions are testable.
+
+it's also why pair debugging is often more effective than solo debugging. not because two people are smarter than one — they're not, necessarily — but because they have different assumptions.
+
+### the "proven wrong" log
+
+i've started keeping a rough mental list of assumptions that turned out to be wrong. "HTTP redirects preserve the request body" is on that list now. "new components always work" is on it. "the docs are accurate" is on it. every entry on that list makes me slightly better at questioning similar assumptions in the future.
+
+this is experience. this is what separates a senior debugger from a junior one — not intelligence, not speed, but a longer list of things they know not to assume.
+
+## beyond code
+
+this applies directly to [[feedback-and-honesty]]. in relationships, the things you "know" about what someone else thinks or feels are assumptions. "they're upset because of X" — maybe. or maybe your model of them is wrong, and the real cause is something you'd never guess because you filtered it out before considering it.
+
+it applies to [[confidence]]. sometimes the reason something isn't working in your life is that you're operating under an assumption about yourself that's wrong — "i'm not good at this," "this isn't for me," "this always fails." those are unexamined assumptions, and they're just as capable of sending you on a 30-hour detour as a bad HTTP redirect.
+
+## the uncomfortable truth
+
+you can't eliminate assumptions. you need them to function — you can't verify every single thing from first principles every time you write a line of code. the skill isn't being assumption-free; it's knowing that your assumptions exist, knowing which ones are load-bearing, and being willing to [[zooming-out|zoom out]] and question them when things aren't working.
+
+the best debuggers aren't the ones with no assumptions. they're the ones who hold their assumptions lightly.
\ No newline at end of file
new file mode 100644
index 0000000..b54a981
@@ -0,0 +1,52 @@
+---
+visibility: public-edit
+---
+
+# binary search your life
+
+debugging is not a programming skill. it's a thinking skill. isolate variables, bisect the problem space, converge on the cause.
+
+## the technique
+
+in software, binary search debugging means: if something is broken and you have 100 possible causes, don't test them one by one. cut the space in half. disable half the system, see if the bug persists. if yes, the bug is in the remaining half. repeat. you go from 100 possibilities to 1 in about 7 steps instead of 100.
+
+andreas zeller formalized this as "delta debugging" — algorithmically minimizing the conditions needed to reproduce a failure. in a famous case study, a browser crash that required 95 user actions was reduced to 3 relevant ones. 896 lines of HTML narrowed to a single line.
+
+the principle isn't about code. it's about systematic isolation.
+
+## applying it to everything
+
+### work problems
+
+when a project is failing, there are usually multiple things wrong simultaneously. bad communication, unclear spec, wrong technical approach, team friction. if you try to fix everything at once, you fix nothing. isolate. which one factor, if fixed, would change the outcome most? that's your [[critical-path]]. change that variable, hold everything else constant, observe.
+
+### energy problems
+
+feeling drained and don't know why? binary search it. is it sleep? hold everything else constant, fix sleep for a week, observe. still drained? it's not sleep. is it social? isolate that variable. this is slower than code debugging because the feedback loops are days, not milliseconds — but the logic is identical.
+
+### relationship problems
+
+"when nothing is working, backtrack like crazy." this is the debugging instinct applied to people. something broke in a relationship. when did it start? what changed? what assumptions am i making about what the other person thinks? (see [[assumptions-kill]]). you can't printf a friendship, but you can isolate variables.
+
+## the meta-skill
+
+what makes debugging transferable is that it teaches a specific cognitive pattern:
+
+1. **observe** — something is wrong. define what "wrong" means precisely. what did you expect? what happened instead?
+2. **hypothesize** — form a theory about the cause. crucially, form it as something *testable* and *falsifiable*. "i think it's X" is useless. "if i change X, the behavior should change in Y way" is a hypothesis.
+3. **test** — change one variable. observe.
+4. **update** — did the test confirm or reject your hypothesis? if rejected, good — you've eliminated a possibility. if confirmed, test again to be sure it's not coincidence.
+
+this is just the scientific method, applied to problems. zeller literally calls it "scientific debugging." but knowing it's the scientific method doesn't mean you default to it. under stress, the instinct is to change everything at once, panic-google, try random things. the discipline of isolating one variable at a time is hard and counterintuitive.
+
+## the half-split instinct
+
+the most valuable version of this skill is when it becomes instinctive. you're facing a mess — code, life, whatever — and instead of feeling overwhelmed, your first thought is: "where's the halfway point? what can i cut to narrow this down?"
+
+that instinct doesn't come from reading about it. it comes from [[perseverance|persevering]] through enough debug sessions that your brain rewires. every [[the-30-hour-bug|30-hour bug]] builds the reflex.
+
+## the trap
+
+binary search only works when the problem is deterministic and you can actually isolate variables. some problems are emergent — they only appear when multiple things interact. for those, you need [[rubber-duck-and-zoom-out|different tools]]. knowing which type of problem you're facing is its own skill.
+
+also: binary search assumes you've correctly defined the search space. if the bug is in a layer you're not even considering, bisecting the wrong space just wastes time. this is why [[assumptions-kill|challenging assumptions]] matters so much — it's about making sure you're searching the right space before you start searching efficiently.
\ No newline at end of file
new file mode 100644
index 0000000..9ce1d8d
@@ -0,0 +1,58 @@
+---
+visibility: public-edit
+---
+
+# hardware vs. software
+
+you can't printf a circuit. a dead component looks identical to a working one. hardware debugging is software debugging with the safety rails removed.
+
+## the fundamental difference
+
+in software, you can inspect everything. add a log line, set a breakpoint, print every variable at every step. the system is transparent if you choose to look. the iteration cycle is seconds — change, compile, run, observe.
+
+in hardware, the system is opaque by default. a dead transistor looks the same as a live one. a cold solder joint might work when you press on it and fail when you don't. a capacitor might be within spec on a multimeter but fail under load. you're debugging with limited observability and the iteration cycle is minutes to hours — desolder, replace, test, realize it was something else.
+
+## what hardware teaches you
+
+### patience is not optional
+
+i spent six hours debugging a mug warmer circuit once. the symptom: no heat. the cause, eventually: a dead transistor. but before finding that, i checked the power supply, the control circuit, the heating element, the wiring, the solder joints. i replaced a capacitor that looked suspicious (it wasn't the problem). i replaced an LED that wasn't lighting up (also not the problem — the LED was fine, it just wasn't getting signal because of the dead transistor upstream).
+
+six hours for a component that costs three cents. in software, this would've been a 20-minute debug session with a debugger. hardware forces you to be patient in a way software rarely does. and that patience transfers back — when you've spent 6 hours on a dead transistor, a [[the-30-hour-bug|30-hour software bug]] feels survivable.
+
+### dead things are invisible
+
+this is the hardest part of hardware debugging. in software, a null pointer throws an exception. a dead component just... doesn't do anything. no error message. no stack trace. the absence of function is the only signal, and absence is hard to spot when you're not sure what the function should look like.
+
+i've had the experience of staring at a circuit for an hour, checking everything, and the problem was a component i didn't even think to check because "that one is definitely fine." it's [[assumptions-kill|assumptions]] again — always assumptions.
+
+### the multimeter is your debugger, and it's terrible
+
+a multimeter can tell you voltage, current, resistance. that's like having a debugger that can only print three variables. an oscilloscope helps more — it's like being able to see execution over time instead of at a single point. but even then, you're seeing electrical signals, not logical behavior. you still have to map voltage waveforms back to "is this component doing what it should" in your head.
+
+this teaches you to build better mental models (see [[modeling]]). when your observability tools are weak, your internal model of the system has to be strong.
+
+### working with EEG signals
+
+at a neurotech startup, i spent weeks debugging noisy brain signals. dead electrode channels that looked active. frequency artifacts from power lines. signal drift from temperature changes. the signals we were trying to detect — visual evoked potentials — were microvolts buried in millivolts of noise. the signal-to-noise ratio was terrible.
+
+this was a different kind of hardware debugging. the components weren't dead — they were noisy. the skill wasn't finding a broken thing; it was distinguishing signal from noise when the noise was orders of magnitude louder. which is honestly a pretty good metaphor for a lot of non-hardware problems too (see [[research-workflow]]).
+
+## the 10x iteration penalty
+
+software: change a line, run, see result in seconds.
+hardware: desolder a component, find replacement, solder it in, power up, test — minutes at minimum, hours if you need to order parts.
+
+this 10x (or 100x) penalty on iteration speed changes your debugging strategy. in software, you can afford to try things. in hardware, you can't — every attempt is expensive. so you think more before you act. you form better hypotheses. you test more carefully.
+
+this is a discipline that software could use more of. the ease of iteration in software encourages sloppy debugging — just try stuff until it works. hardware forces the [[binary-search-your-life|systematic approach]] because the cost of random attempts is too high.
+
+## the crossover
+
+embedded systems are where hardware and software debugging collide. a microcontroller sending data over a wire — is the bug in the code or the circuit? is the signal not arriving because the code isn't sending it, or because the wire has a bad connection? you need both skill sets, and you need to know when to switch between them.
+
+my [[the-30-hour-bug|longest debug session]] was exactly this kind of problem — it looked like a hardware issue, then a software issue, and turned out to be a library behavior at the intersection of both.
+
+## the meta-lesson
+
+hardware debugging builds a kind of resilience and rigor that transfers everywhere. when you've debugged systems where you can't see inside, you get better at debugging systems where you can. the constraints force better thinking, and better thinking has no domain boundary.
\ No newline at end of file
new file mode 100644
index 0000000..1b101a3
@@ -0,0 +1,55 @@
+---
+visibility: public-edit
+---
+
+# rubber duck and zoom out
+
+explaining the problem reveals the answer. stepping away lets the answer surface. both work, and neither is a waste of time.
+
+## the rubber duck
+
+the technique comes from *The Pragmatic Programmer* — a developer carried a rubber duck and explained their code to it line by line. the act of articulating what the code should do, step by step, forces you to confront what it actually does. the gap between those two things is the bug.
+
+this works because of metacognition — thinking about your own thinking. when you debug silently, your brain skips over things it "knows" (see [[assumptions-kill]]). when you explain out loud, you can't skip. you have to justify every step, and the step you can't justify is usually where the bug lives.
+
+i've had this happen dozens of times. i'll be explaining a problem to someone — a friend, a coworker, sometimes literally to nobody — and halfway through the explanation i'll stop and say "wait." the act of translating internal knowledge to external language catches errors that internal review misses.
+
+this connects to [[articulation-as-memory|articulation as memory]] — putting something into words changes your relationship with it. debugging by explanation isn't just a trick; it's the same fundamental mechanism that makes [[writing-to-understand|writing a thinking tool]].
+
+## the zoom out
+
+[[zooming-out]] is the complementary move. where the rubber duck forces you closer — line by line, step by step — zooming out pulls you back. am i even solving the right problem? am i looking at the right layer? is this the [[critical-path]]?
+
+the instinct when stuck is to go deeper. more logging, more breakpoints, finer granularity. sometimes that's right. but often, the problem isn't at the level you're looking at. the [[the-30-hour-bug|30-hour bug]] was at the HTTP library level, not the application level. no amount of application-level debugging would've found it. zooming out — asking "what if the problem isn't in my code?" — is what eventually led to the fix.
+
+## walks
+
+walks have yet to not be worth it. every time i've been stuck on a hard bug and gone for a walk, i've either come back with a new idea or come back with enough mental distance to abandon a dead-end hypothesis. the diffuse mode of thinking that happens during walks — when your brain is processing without actively trying — surfaces connections that focused debugging misses.
+
+the hard part is actually going. when you're deep in a debug session, walking away feels like giving up. it's not. it's [[resyncing]] — letting your brain catch up to the information you've gathered.
+
+## sleep on it
+
+even more powerful than walks, and even harder to do. when you've been debugging for hours and it's midnight, the rational move is to sleep and come back fresh. the emotional pull to "just try one more thing" is enormous. but sleep restructures information. i've woken up knowing what the bug is, without any new data — my brain just needed time to reorganize what it already had.
+
+this is a form of [[resets|resetting]], applied specifically to debugging.
+
+## the pattern
+
+there's a rhythm to effective debugging that alternates between these modes:
+
+1. **focus** — dig in, gather data, form hypotheses, test them
+2. **explain** — rubber duck it, force yourself to articulate what you think is happening
+3. **zoom out** — am i even looking at the right thing? challenge the frame, not just the details
+4. **step away** — walk, break, sleep. let diffuse thinking work
+5. **return fresh** — come back and re-examine with new eyes
+
+most people only do step 1 and wonder why they get stuck. the full cycle is what separates [[perseverance|persistent]] debugging from stubborn debugging.
+
+## when to use which
+
+- stuck for minutes → rubber duck first. explain what you think is happening.
+- stuck for an hour → zoom out. question whether you're looking at the right layer.
+- stuck for hours → step away. walk, eat, sleep. your focused mind has hit its limit.
+- stuck for a day → [[binary-search-your-life|binary search]]. systematically eliminate possibilities instead of following intuition.
+- stuck for days → question everything. your fundamental [[assumptions-kill|assumption]] about the system is probably wrong.
\ No newline at end of file
new file mode 100644
index 0000000..c7089a6
@@ -0,0 +1,55 @@
+---
+visibility: public-edit
+---
+
+# the 30-hour bug
+
+one line. thirty hours. the bug is never where you think it is.
+
+## the setup
+
+i was building a system that needed to send audio data from a microcontroller to a cloud service. the microcontroller would record a chunk of audio, then POST it to an endpoint for processing. straightforward pipeline, or so i thought.
+
+it worked perfectly in testing. local server, direct connection, clean 200 responses. then i pointed it at the real endpoint and everything broke. 400 errors. every single time.
+
+## the spiral
+
+i spent the first few hours doing what anyone would do — checking the obvious stuff. was the payload formatted correctly? yes. were the headers right? yes. was the endpoint actually up? yes, i could hit it from curl no problem. the microcontroller was the problem. except it wasn't.
+
+i rebuilt the HTTP request from scratch. twice. i rewrote the audio encoding pipeline. i added logging at every step. i tried different audio formats, different chunk sizes, different content types. i questioned whether the microcontroller's HTTP library was even spec-compliant. i read the library source code. i started wondering if the cloud service had some undocumented requirement.
+
+this is the thing about long debug sessions — somewhere around hour 10, you've tested every hypothesis you can think of, and you start testing increasingly desperate ones. you start changing things at random. you start questioning reality.
+
+i took walks. i slept on it. i came back fresh and still couldn't see it.
+
+## the fix
+
+the cloud endpoint was behind a redirect. when you hit the URL, it 301'd you to a slightly different URL. my HTTP client had `setFollowRedirects` enabled — but the library's implementation silently dropped the POST body when following redirects. it would follow the redirect, but convert the POST to a GET. the body was gone. the cloud service got an empty request and returned 400.
+
+one line fix: set the correct endpoint URL that didn't redirect. or alternatively, don't follow redirects and handle them manually.
+
+thirty hours for one line.
+
+## what this taught me
+
+### the bug is in the layer you're not looking at
+
+i was looking at my code. the bug was in a library behavior i'd never questioned. this pattern repeats constantly — the bug lives in your [[assumptions-kill|assumptions]], in the code you trust implicitly, in the layer between your code and the thing it talks to.
+
+### logging is necessary but not sufficient
+
+i had extensive logging. it told me the request was being sent correctly. what it didn't tell me was that the library was silently mutating my request after my logging code ran. you can't log what you don't know to look for.
+
+### the time investment distorts thinking
+
+after 20 hours, i was so invested in certain hypotheses that i couldn't let them go. sunk cost applies to debugging. the willingness to throw away your current theory and start from scratch — genuinely start from scratch, not just say you are — is maybe the single most important debugging skill. see [[zooming-out]].
+
+### there's a moment of rage and relief
+
+when you finally find it, you feel both simultaneously. rage that it was this stupid, this simple, this hidden. relief that you're not insane. and then a strange gratitude, because you learned something about the system that you'd never have learned otherwise.
+
+## the real lesson
+
+every long debug session has a story like this. one line. one wrong assumption. hours or days of work. the skill isn't avoiding these sessions — it's building the [[perseverance]] to survive them, the [[zooming-out]] instinct to step back when you're stuck, and the systematic habits that shorten them over time (see [[binary-search-your-life]]).
+
+the best debuggers i've met aren't the ones who never get stuck. they're the ones who've been stuck enough times to know what being stuck feels like, and what to do about it.
\ No newline at end of file
new file mode 100644
index 0000000..c423a58
@@ -0,0 +1,43 @@
+---
+visibility: public-edit
+---
+
+# the fomo trap
+
+FOMO masquerades as ambition, but it's actually about position — where you stand relative to others — not about growth.
+
+## the distinction
+
+- **growth-driven decisions** — "i want to learn this because it'll make me better at what i care about"
+- **position-driven decisions** — "i need to do this because everyone else is and i'll fall behind if i don't"
+
+the feeling is similar — urgency, excitement, a pull toward action. but the source is completely different. growth comes from within; FOMO comes from comparison.
+
+## how i spot it
+
+the test i use: "would i still want this if i were the only person in the world?" if the answer is no, the desire is positional. that doesn't automatically make it wrong, but it means i should be suspicious of it.
+
+another signal: FOMO decisions tend to be reactive. something shows up in my feed, someone mentions an opportunity, and suddenly it feels urgent. but nothing about my actual situation changed — only my awareness of what others are doing.
+
+## common FOMO traps
+
+- **shiny new technology** — every new framework, tool, AI model. the fear isn't that it's useful; it's that everyone else will know it and you won't. connect this to [[vibe-coding]] — the temptation to jump on every new tool.
+- **competitions and programs** — applying to everything because "what if i miss out." sometimes the right move is to focus on what you're already building.
+- **social events** — saying yes to everything because you might miss the one conversation that changes everything. diminishing returns hit hard here.
+
+## FOMO vs genuine opportunity cost
+
+real opportunity cost exists. sometimes not doing something IS a mistake. the difference:
+
+- genuine opportunity cost: you've thought it through, it aligns with your [[critical-path]], and skipping it has concrete consequences
+- FOMO: you feel a vague anxiety about missing out, driven by seeing others do it
+
+## the antidote
+
+[[intentionality]]. having a clear sense of what you're optimizing for makes FOMO decisions obvious — they don't fit the plan. without intentionality, every opportunity looks equally important, and FOMO wins by default.
+
+also: [[zooming-out]] helps. when you're zoomed in, every opportunity feels urgent. when you zoom out, you see that most of them don't matter for your actual trajectory.
+
+## the meta-trap
+
+the biggest FOMO trap is FOMO about FOMO — being so afraid of falling into FOMO that you dismiss every new opportunity as "just FOMO." some things genuinely are worth pivoting toward. the framework isn't "never react to new information." it's "react from a place of intention, not anxiety."
\ No newline at end of file
new file mode 100644
index 0000000..f4dd310
@@ -0,0 +1,45 @@
+---
+visibility: public-edit
+---
+
+# information gathering
+
+how much research should you do before making a decision? the answer is almost never "all of it."
+
+## the diminishing returns curve
+
+information gathering follows a steep diminishing returns curve. the first 30 minutes of research on a topic often gives you 70% of the useful information. the next 3 hours might give you another 20%. the remaining 10% could take days.
+
+the question isn't "do i have enough information?" — you never will. the question is "will more information change my decision?"
+
+## the 70% rule
+
+i aim to make decisions at roughly 70% information. that's enough to be directionally right without burning time on diminishing returns. for [[reversible-vs-irreversible|type 2 decisions]], even 50% might be fine — just try it and course-correct.
+
+for type 1 decisions, push closer to 85-90%. but never 100%. 100% is a fantasy, and waiting for it is its own form of risk.
+
+## failure modes
+
+- **asking too many people** — every new opinion adds noise. after 3-4 informed perspectives, more opinions usually just create confusion.
+- **not distinguishing signal from noise** — some information sources are much more valuable than others. one conversation with someone who's done the thing is worth 20 blog posts about the thing.
+
+## the best information sources
+
+ranked by signal density:
+
+1. **doing the thing** — nothing beats direct experience. often faster than research. if you can prototype or test cheaply, do that instead of researching. see [[vibe-coding]] for how this applies to software.
+2. **talking to someone who's done it** — high bandwidth, can ask follow-up questions, they know what actually mattered vs what seemed important
+3. **case studies / postmortems** — real outcomes, not theory
+4. **structured frameworks** — models that help you think, not answers that tell you what to do
+5. **general advice** — often too generic to be actionable. "it depends" is usually the honest answer.
+
+## when to stop gathering
+
+signs you have enough information:
+
+- your decision hasn't changed with the last few inputs
+- you can articulate the key tradeoffs clearly
+- you know what you don't know, and you've decided it's acceptable not to know it
+- the cost of waiting is starting to exceed the cost of being slightly wrong
+
+this connects to [[operation-optimization]] — information gathering is itself a process that can be optimized. don't just research the decision; optimize how you research.
\ No newline at end of file
new file mode 100644
index 0000000..d63124d
@@ -0,0 +1,35 @@
+---
+visibility: public-edit
+---
+
+# regret minimization
+
+the 80-year-old self test. project yourself to the end of your life and ask: "will i regret not doing this?"
+
+## the framework
+
+Bezos used this when deciding to leave a hedge fund to start Amazon — imagining himself at 80 and realizing he'd regret the inaction far more than a failed attempt. the core move: reframe the decision from "what's the safe choice?" to "what will i regret not trying?"
+
+## when this works well
+
+- big life decisions where the downside is bounded but the upside is unbounded
+- decisions where fear of failure is the main thing holding you back
+- situations where the "safe" path has its own hidden risks — like never learning what could have been
+
+this connects to [[confidence]] — a lot of the time, the thing stopping me isn't a rational assessment of risk. it's [[impostor-syndrome]] whispering that i'm not ready, not good enough, not the kind of person who does that thing.
+
+## when this breaks down
+
+- **recency bias** — you imagine future regret based on what excites you *now*, but your values will shift. the 80-year-old you might care about things current-you doesn't.
+- **survivorship bias** — Bezos's story worked out. plenty of people left good jobs for startups and regret it. the framework doesn't account for the actual probability of success.
+- **overweighting action regret** — research shows people regret inaction more than action in the long run, which means this framework is biased toward "go for it." that's sometimes right, but not always.
+
+## my version
+
+i use a lighter version: "if i don't do this, will it bother me in 5 years?" not 80 years — that's too abstract. 5 years is concrete enough to feel real. if the answer is yes, the bar for doing it drops significantly.
+
+the key: this is a filter for big [[reversible-vs-irreversible]] type 1 decisions. for type 2 decisions, just try it — you don't need to invoke your future self.
+
+## the trap
+
+regret minimization can become a justification engine. "i'd regret not doing X" can be used to rationalize anything that feels exciting in the moment. the check: would you still want this if nobody knew about it? if the regret is about missing a status marker, that's [[fomo-trap]], not genuine regret minimization.
\ No newline at end of file
new file mode 100644
index 0000000..75c71e6
@@ -0,0 +1,36 @@
+---
+visibility: public-edit
+---
+
+# reversible vs irreversible decisions
+
+the single most useful filter i've found for decision-making speed. comes from Bezos's type 1 / type 2 framework, but i use it constantly outside of business.
+
+## the framework
+
+- **type 1 (one-way doors)** — irreversible or nearly irreversible. once you walk through, you can't come back. these deserve slow, careful thinking.
+- **type 2 (two-way doors)** — reversible. if it doesn't work, you walk back through. these should be made fast.
+
+the key insight: most decisions are type 2, but we treat them like type 1. we agonize over things we could easily undo.
+
+## how i actually use this
+
+when i'm stuck on a decision, i ask: "what happens if i'm wrong?" if the answer is "i waste a few hours" or "i can change it next week," it's type 2 — just pick and go. the cost of deliberating often exceeds the cost of being wrong.
+
+type 1 decisions are rarer than you'd think. choosing a college, taking on a cofounder, signing a long contract — these are genuinely hard to reverse. they deserve the full [[information-gathering]] process, maybe even [[regret-minimization]].
+
+## the startup connection
+
+in [[startup-workflow]], this comes up constantly. product decisions are almost always type 2 — ship it, see what happens, iterate. but hiring decisions or choosing your core technology stack lean type 1. the mistake i see (and make) is treating every product call like a type 1 and moving too slowly.
+
+## common failure modes
+
+- **treating type 2 as type 1** — the most common one. spending days deciding something you could just try. analysis paralysis lives here.
+- **treating type 1 as type 2** — rarer but more dangerous. rushing into something you can't undo because you're in a bias toward action.
+- **not noticing when a type 2 becomes type 1** — some decisions start reversible but lock in over time. a "temporary" architecture choice that everything gets built on top of. see [[critical-path]].
+
+## connection to speed
+
+the reason this matters: speed is a competitive advantage, but only on type 2 decisions. on type 1 decisions, speed is a liability. knowing which is which lets you be fast where it counts and careful where it matters.
+
+this connects to [[intentionality]] — being deliberate about *how* you decide, not just *what* you decide.
\ No newline at end of file
new file mode 100644
index 0000000..05668b8
@@ -0,0 +1,49 @@
+---
+visibility: public-edit
+---
+
+# sunk cost and quitting
+
+the hardest decision skill: knowing when to keep going versus when to walk away.
+
+## the sunk cost fallacy
+
+"i've already put so much time into this" is never a reason to continue. the only question that matters: is the *next* unit of effort worth it? everything you've already spent is gone regardless.
+
+this is obvious in theory and brutally hard in practice. identity gets tangled up in commitments. quitting something you've invested in feels like admitting the investment was a mistake. but sometimes the investment *was* the right call at the time — and quitting is the right call now.
+
+## Annie Duke's kill criteria
+
+the most useful framework i've found: set kill criteria *before* you start. decide in advance what signals would tell you to quit.
+
+- "if we don't have X users by Y date, we stop"
+- "if i'm still not enjoying this after 3 months, i move on"
+- "if this approach doesn't produce results after Z iterations, we try something else"
+
+the reason this works: deciding in a calm state is better than deciding in a state of sunk-cost-induced stubbornness. your past self was more rational about this than your current self will be.
+
+## the tension with perseverance
+
+this page exists in direct tension with [[perseverance]]. that page says keep going when it's hard. this page says sometimes you should quit. how do you reconcile them?
+
+my filter: **is the difficulty coming from the problem being genuinely hard, or from this being the wrong problem?**
+
+- hard problem, right direction → push through ([[perseverance]])
+- hard problem, wrong direction → quit and redirect
+- easy problem, no progress → something is structurally wrong. zoom out (see [[zooming-out]])
+
+## the "monkeys and pedestals" test
+
+from Annie Duke: if your goal is to train a monkey to juggle while standing on a pedestal, build the pedestal last. the pedestal is easy — anyone can build a pedestal. the hard part is training the monkey. if you start with the pedestal, you'll feel like you're making progress, but you haven't de-risked anything.
+
+applied: tackle the hardest, most uncertain part first. if that part fails, quit early. don't build elaborate infrastructure around an unvalidated core assumption.
+
+## quitting projects vs quitting approaches
+
+important distinction: quitting a *project* is different from quitting an *approach*. most of the time, you don't need to abandon the goal — you need to abandon the method. see [[critical-path]] for thinking about which parts are load-bearing.
+
+## identity and quitting
+
+the deepest trap: when something becomes part of your identity, quitting feels like losing yourself. "i'm a person who does X" makes it nearly impossible to stop doing X, even when X isn't serving you anymore. this connects to [[narratives]] — your story about yourself can trap you in commitments that no longer make sense.
+
+the reframe: you're not quitting who you are. you're updating your model of yourself with better information.
\ No newline at end of file
new file mode 100644
index 0000000..70c4f69
@@ -0,0 +1,31 @@
+---
+visibility: public-edit
+---
+
+# electronics workflow
+
+the practical process for building electronics projects, learned at a neurotech startup.
+
+## the build sequence
+
+1. **breadboard** — get the circuit working at all. ugly is fine.
+2. **get it to work** — functional prototype, doesn't matter how messy
+3. **make wiring nice** — clean up connections, organize
+4. **make UX nice** — put it in a box, hot glue, add controls
+
+this mirrors the general principle from [[software-workflow]]: make it work, then make it good. resist the urge to make it pretty before it's functional.
+
+## fundamentals
+
+- power sources: DC, understanding volts
+- signals: what's being sent where
+- PWM for control: pulse width modulation to manage output
+- program microcontroller → flash code
+
+## practical lessons
+
+jumper cables are worthless — use proper breadboard connections. this sounds minor but bad connections cause hours of debugging phantom issues. always ensure robustness (see [[intentionality]]).
+
+## the demo matters
+
+having a pretty cool thing to show off and demo is very powerful. even a rough breadboard prototype gets people excited and provides feedback. see [[critical-path]] — the demo is often on the critical path even when polish isn't.
\ No newline at end of file
new file mode 100644
index 0000000..7b1ed77
@@ -0,0 +1,32 @@
+---
+visibility: public-edit
+---
+
+# circadian rhythm
+
+the 24-hour internal clock that governs when you're alert, when you're sleepy, and how well everything from digestion to cognition works.
+
+## the key signals
+
+three main signals ("zeitgebers") tell your body what time it is:
+
+**light** is the primary one. morning light exposure (10-15 min of bright outdoor light within an hour of waking) anchors the whole cycle. evening light — especially blue wavelengths — pushes the clock later.
+
+**meal timing** entrains peripheral clocks in the liver and gut. eating at inconsistent times creates internal desynchrony: your brain thinks it's one time, your gut thinks it's another. see [[food-and-focus]] for how this affects cognitive performance.
+
+**temperature** follows a circadian rhythm — lowest around 4-5am, highest in late afternoon. hot showers before bed paradoxically help by dropping core temperature via vasodilation. sleeping cool (65-68F) aligns with the body's natural temperature drop.
+
+## my experiments
+
+i've gone through phases of trying to shift my circadian rhythm earlier. the things that actually worked:
+
+1. morning light — non-negotiable. this is the foundation.
+2. consistent wake time — even on weekends. the body hates schedule variance.
+3. no food close to bedtime — eating late shifts peripheral clocks later and makes sleep quality worse.
+4. wind-down routine — same sequence of actions each night signals the transition. not about "relaxing" so much as about consistency.
+
+what didn't work: trying to force an earlier bedtime without changing the morning anchor. you can't push the clock from the sleep end — you have to pull it from the wake end.
+
+## the connection to work
+
+understanding circadian rhythm reframes energy management. it's not about willpower — it's about alignment. working during your biological peak (usually mid-morning for most people) and resting during your biological trough (early afternoon) isn't laziness; it's [[operation-optimization]].
\ No newline at end of file
new file mode 100644
index 0000000..308dd8b
@@ -0,0 +1,42 @@
+---
+visibility: public-edit
+---
+
+# exercise as reset
+
+of all the tools in my [[resets]] toolkit, sustained exercise is the most reliable. it's also the one i resist the most.
+
+## why it works
+
+the mechanism isn't mysterious: exercise floods the brain with BDNF, endorphins, norepinephrine, and serotonin. it clears cortisol. it forces deep breathing that activates the parasympathetic nervous system. it raises core body temperature, which then drops afterward, creating a natural relaxation response.
+
+but the real reason it works as a *reset* specifically: it forces a context switch. you can't be stuck in a coding problem while running. the physical demand hijacks your attention, and when you come back, you see the problem fresh. this is [[zooming-out]] with a physical forcing function.
+
+## the 10-minute threshold
+
+i've noticed exercise only works as a reset if it's sustained — at least 10 minutes of elevated heart rate. a quick set of pushups doesn't cut it. a 5-minute walk helps but doesn't fully reset. 10+ minutes of real effort is where the state change happens.
+
+this matters for planning. if i only have 5 minutes, i'm better off with breathwork or cold water (see [[resets]]). if i have 15-20 minutes, exercise is the play.
+
+## the resistance paradox
+
+the times i most need to exercise are the times i least want to. when i'm tired, stressed, or stuck, the last thing that sounds appealing is physical effort. this is the resistance paradox — the reset that would help most is the one that feels hardest to start.
+
+the fix i've found: don't negotiate with yourself about whether to do it. just start. the first 2 minutes are the worst. by minute 5, you're glad you started. by minute 15, you can't believe you almost didn't.
+
+## types that work best for resets
+
+- **running / fast walking** — best for general energy resets and when i need [[zooming-out]] time. the rhythmic motion is meditative.
+- **high-intensity intervals** — best when i'm agitated or anxious. burn off the cortisol fast.
+- **swimming** — total sensory reset. the water blocks out everything. probably the most complete reset but requires access and time.
+- **bodyweight stuff (pushups, pull-ups)** — quick, no equipment, but usually not sustained enough for a full reset unless i'm doing a circuit.
+
+## exercise as sleep insurance
+
+regular exercise improves sleep quality — you get more deep sleep, fall asleep faster, and sleep more efficiently. so exercise during the day pays dividends at night. it's one of the few interventions that compounds across systems.
+
+## the trap
+
+don't use exercise to avoid work. there's a fine line between "i need a reset" and "i don't want to face the hard thing." the test: if you're dreading a specific task, exercise might be avoidance. if your whole state is degraded regardless of the task, it's a legitimate reset.
+
+also: overtraining degrades everything. exercise as a reset works because it's a break from cognitive work. if exercise itself becomes another source of stress and optimization pressure, you've lost the benefit. see [[operation-optimization]] for the general principle of not over-optimizing.
\ No newline at end of file
new file mode 100644
index 0000000..02d27b6
@@ -0,0 +1,37 @@
+---
+visibility: public-edit
+---
+
+# food and focus
+
+what and when you eat has an outsized effect on cognitive performance. this took me embarrassingly long to figure out.
+
+## the food coma problem
+
+large meals — especially carb-heavy ones — trigger a parasympathetic response. blood diverts to digestion, insulin spikes, and you get the classic post-lunch crash. this isn't a character flaw; it's physiology.
+
+the worst combo: a big meal + sedentary work immediately after. your body is trying to digest and your brain is trying to think, and neither wins.
+
+## the no-eating block
+
+i've settled on not eating past ~7pm. the reasons stack up:
+
+- **sleep quality** — eating close to bedtime forces your body to digest when it should be cooling down and preparing for sleep. late meals shift the peripheral clocks later (see [[circadian-rhythm]]), creating internal desynchrony.
+- **morning energy** — sleeping without a full stomach means waking up actually hungry, which is a natural alertness signal.
+- **evening wind-down** — not eating creates a natural boundary between "productive hours" and "wind-down hours."
+
+## caffeine timing
+
+caffeine blocks adenosine receptors but doesn't clear adenosine. when it wears off, all the accumulated adenosine hits at once (the crash). the fix: don't use caffeine to mask tiredness — use it strategically when you're already alert and want a boost. and never after ~2pm if you value sleep.
+
+## the fasting question
+
+i've experimented with intermittent fasting (16:8 window). the morning focus is genuinely better — no digestion overhead, elevated cortisol and adrenaline from mild fasting state. but it's a tradeoff: afternoon energy can crash hard if you're not adapted to it.
+
+my current approach: light breakfast or skip it, moderate lunch, done eating by 7pm. this gives me the morning focus benefit without the afternoon collapse.
+
+## connection to resets
+
+when energy is low, eating fruit is on my [[resets]] list. it's fast-acting sugar without the heavy digestion overhead. the key is that this is a *reset*, not a meal — small, quick, targeted.
+
+also: the physical state of hunger vs. satiation affects decision-making. don't make important decisions (see [[reversible-vs-irreversible]]) when you're either starving or in a food coma. your cognitive resources are compromised in both states.
\ No newline at end of file
new file mode 100644
index 0000000..f682685
@@ -0,0 +1,40 @@
+---
+visibility: public-edit
+---
+
+# napping and recovery
+
+strategic napping as a performance tool, not a sign of weakness. plus breathwork alternatives when napping isn't possible.
+
+## the science
+
+NASA found that a ~26-minute nap improved alertness by 54% and performance by 34%. the key is length — too short and you don't get enough benefit, too long and you drop into deep sleep and wake up with inertia worse than the tiredness you started with.
+
+## nap timing
+
+- **ideal window: 1-3pm** — aligns with the natural post-lunch circadian dip. your body already wants to rest here.
+- **never after 3-4pm** — late naps push back sleep onset at night, wrecking your [[circadian-rhythm]]. the short-term energy boost isn't worth the long-term cycle disruption.
+- **duration caps** — 20-30 minutes for a power nap. if you need more, go for a full 90 minutes (one complete sleep cycle) to avoid waking during deep sleep. anything in between (40-60 minutes) is the danger zone.
+
+## the caffeine nap
+
+drink coffee immediately before a 20-minute nap. caffeine takes ~20 minutes to kick in, so you wake up right as it hits. the nap clears some adenosine, then the caffeine blocks the receptors so the remaining adenosine can't dock.
+
+## when napping isn't possible
+
+sometimes you can't nap — you're in a competition, a meeting marathon, or just can't find a quiet spot. alternatives from my [[resets]] toolkit:
+
+- **cyclic hyperventilation** — 25-30 deep, fast breaths followed by a breath hold. this is a deliberate stress response that floods the system with adrenaline and norepinephrine. not subtle, not relaxing, but extremely effective at clearing tiredness for 1-2 hours.
+- **box breathing** — 4 seconds in, 4 hold, 4 out, 4 hold. calmer than hyperventilation. good when you're tired AND anxious.
+- **cold water on the face/wrists** — triggers the dive reflex, drops heart rate, increases alertness. the quick version of a cold shower.
+- **10-minute walk outside** — combines light exposure, mild exercise, and fresh air. see [[exercise-as-reset]].
+
+## recovery sleep
+
+after a bad night, recovery looks different than you'd think. you can't "make up" lost sleep hour-for-hour. the body prioritizes deep sleep on recovery nights, compressing more N3 into the first few cycles. so one good night after a bad one recovers more than you'd expect, but it doesn't fully restore what was lost.
+
+the implication: don't try to sleep 12 hours to compensate. go to bed at your normal time, maybe 30-60 minutes early, and let the body's built-in recovery prioritization do its thing.
+
+## the cultural problem
+
+napping gets treated as laziness in most work/school cultures. this is pure irrationality. a 20-minute nap makes the next 4 hours dramatically more productive. skipping it doesn't demonstrate discipline; it demonstrates poor [[operation-optimization]].
\ No newline at end of file
new file mode 100644
index 0000000..5f1e6d8
@@ -0,0 +1,49 @@
+---
+visibility: public-edit
+---
+
+# feedback and honesty
+
+"best path is to just tell them how i'm feeling, don't ask for anything, and just keep working."
+
+## the core practice
+
+when something feels off with a teammate, the instinct is to either:
+1. say nothing and let resentment build
+2. make demands ("you need to change X")
+
+both are bad. the third option: express exactly what you feel and why it matters. don't ask for anything. then keep working.
+
+this works because:
+- you've released the pressure (it's not building inside you)
+- the other person has information they didn't have before
+- there's no defensiveness trigger (you didn't demand anything)
+- the relationship stays intact because you're still working, still present
+
+## argue without getting personal
+
+from the [[startup-workflow]] communication patterns: effective teams argue about ideas, not about people. present findings, discuss next steps, disagree about approaches — all fine. "you always do X" — that's personal, and it kills productive conflict.
+
+## being forceful
+
+a CEO i worked with realized that "in pursuit of open-mindedness, was too passive in arguments." the fix: be forceful in exchanging ideas, trust the other party not to collapse.
+
+this is the opposite of the typical advice to "be gentle." forceful isn't aggressive — it's confident. you believe something, you say it with conviction, and you trust that the other person can handle disagreement. see [[confidence]].
+
+the failure mode: being so open-minded that you have no position. real openness is holding a strong position while being genuinely willing to update it.
+
+## the perception problem
+
+"these are all just my perceptions, many times wrong or exaggerated." before giving feedback, check: is this a real problem, or is this my perception filtered through insecurity, tiredness, or bias? see [[team-dynamics]].
+
+this doesn't mean dismissing your feelings — they're real data. but feelings about *why* someone did something are often wrong. "they don't care" is usually "they're overwhelmed" or "they have different priorities."
+
+## high-bandwidth communication
+
+from the same CEO: articulating every piece of meta-data you observe from the other person. this sounds like over-communication, but it surfaces misinterpretations early. "i noticed you seemed frustrated when i said X — is that right?" this is feedback about the feedback process itself.
+
+see [[resyncing]] for the full communication toolkit.
+
+## "short circuit"
+
+sometimes the most honest thing is: "i don't know what you mean" or "discussing this doesn't matter right now." the "short circuit" tool (see [[resyncing]]) is feedback at its most compressed.
\ No newline at end of file
new file mode 100644
index 0000000..40381e1
@@ -0,0 +1,59 @@
+---
+visibility: public-edit
+---
+
+# distraction management
+
+AI rot, youtube, discord as escape — understanding why i reach for distractions and what to do about it.
+
+## distractions as symptoms
+
+the biggest reframe: distractions aren't the problem. they're the symptom. every time i reach for my phone, open youtube, check discord — there's something i'm avoiding. sometimes it's an emotion you haven't processed. sometimes it's an unclear task (unclear goals prevent flow). sometimes it's just that i'm depleted (see [[energy-cycles]]).
+
+treating the symptom (blocking sites, hiding phone) helps a little. treating the cause (figuring out why you're escaping) helps a lot.
+
+## the AI rot phenomenon
+
+this is a newer pattern: endlessly chatting with AI instead of doing the actual work. it feels productive — you're "exploring ideas" and "doing research." but often it's a sophisticated form of procrastination. you get the feeling of intellectual engagement without the discomfort of actually building something.
+
+the test: "am i using this tool to accomplish a specific task, or am i using it to avoid a specific task?" see [[vibe-coding]] — AI is most valuable when pointed at concrete problems, least valuable when it's a substitute for your own thinking.
+
+this connects to [[building-to-learn]] — reading and discussing is comfortable. building is uncomfortable. the discomfort is where the learning happens.
+
+## the escape ladder
+
+my typical distraction escalation:
+
+1. **mild**: checking email, slack, notifications. low-grade context switch.
+2. **moderate**: youtube, reddit, twitter. active content consumption that fills the attention space.
+3. **deep**: discord conversations, AI rabbit holes, research tangents that feel productive but aren't on the [[critical-path]].
+4. **full escape**: gaming, binge-watching, anything that completely numbs. this usually means i've been ignoring an emotion for too long.
+
+each level is a stronger numbing agent. the further down the ladder, the stronger the thing i'm avoiding. level 4 means something real needs to be addressed — usually an unprocessed emotion or a decision i'm scared to make.
+
+## why willpower doesn't work
+
+"just don't get distracted" is terrible advice. willpower is a finite resource, and it depletes throughout the day. by afternoon, there's nothing left to resist with.
+
+what works better:
+
+- **environment design**: remove the option. phone in another room. site blockers. working in a place where distractions aren't available. time-blocking creates environmental structure.
+- **clear next actions**: when i know exactly what to do next, distractions lose their pull. when i'm vague about the task, my brain seeks clarity elsewhere. [[intentionality]] before each work block.
+- **emotional check-in**: before starting work, quick scan — what am i feeling? is there something i need to process before i can focus? 30 seconds of this prevents hours of unfocused distraction.
+- **energy matching**: doing demanding focused work when energy is high, shallow work when it's low. see [[energy-cycles]] — trying to do demanding work in a low-energy state guarantees distraction.
+
+## the content consumption trap
+
+youtube, podcasts, articles, newsletters — passive content consumption feels like learning but mostly isn't. see [[the-testing-effect]] — without retrieval, consumption produces very little durable knowledge.
+
+the honest question: "am i consuming this because it's on my [[critical-path]], or because it's more comfortable than doing the actual work?" ninety percent of the time, it's the latter.
+
+this doesn't mean all consumption is bad — [[research-workflow]] reading is valuable when targeted. the difference is intentional consumption (reading something specific for a specific purpose) vs escape consumption (browsing until something catches your attention).
+
+## the role of rest
+
+sometimes "distraction" is actually your body's way of demanding rest. if you've been in deep focus mode for hours and your brain keeps reaching for your phone, maybe the answer isn't more discipline — it's a break.
+
+the key is the quality of the break. scrolling twitter is not rest — it's stimulation without recovery. actual rest is: a walk, a nap, a conversation, food, staring out a window. the things that feel "boring" are often the most restorative.
+
+see [[resets]] — macro-level breaks serve the same function as micro-level breaks, just at a larger scale.
\ No newline at end of file
new file mode 100644
index 0000000..ce44532
@@ -0,0 +1,51 @@
+---
+visibility: public-edit
+---
+
+# energy cycles
+
+ultradian rhythms, 90-minute focus cycles, and working with your biology instead of against it.
+
+## the 90-minute rhythm
+
+nathaniel kleitman (the same researcher who mapped sleep cycles) proposed the basic rest-activity cycle (BRAC): a roughly 90-minute oscillation between higher and lower alertness that runs throughout the day, not just during sleep.
+
+the pattern: ~70 minutes of rising alertness and focus, followed by ~20 minutes of lower alertness where the body wants rest.
+
+the research is mixed — some studies find the 90-minute cycle clearly, others don't. but the underlying principle is solid: attention and cognitive capacity fluctuate in cycles throughout the day. you are not a machine that runs at constant output.
+
+## working with cycles, not against them
+
+- **peak phases are for demanding work**: complex coding, architecture decisions, hard writing, [[research-workflow]] that requires deep comprehension.
+- **trough phases are for shallow work**: email, admin, reviews, routine tasks, [[spaced-repetition]] reviews in mochi. fighting the trough with willpower is inefficient — you'll produce worse work while burning more energy.
+- **transitions need breaks**: the shift between peak and trough is the natural break point. trying to power through without a break extends the trough and delays the next peak.
+
+## my energy map
+
+through tracking (inconsistently, honestly), i've noticed rough patterns:
+
+- **first peak (morning)**: strongest focus window. this is where the most important [[critical-path]] work should go. protecting this window from meetings and messages is the highest-leverage scheduling decision i can make.
+- **post-lunch dip**: the most reliable low-energy period. perfect for admin, reviews, or a walk.
+- **second peak (afternoon)**: smaller than the morning peak but real. good for a second focus block if the morning block was protected.
+- **evening**: variable. sometimes good creative energy, sometimes nothing. not reliable enough to plan around.
+
+## energy management vs time management
+
+this is maybe the biggest practical insight from all of this: time management is necessary but not sufficient. an hour of high-energy focus produces more than three hours of low-energy grinding. see [[operation-optimization]] — optimizing when you work matters as much as optimizing how you work.
+
+the implication: a shorter workday with well-timed focus blocks often produces more than a long day of constant low-grade effort. this is counterintuitive when the culture values hours worked, but the output doesn't lie.
+
+## energy and emotions
+
+there's a bidirectional relationship between energy and emotional state:
+
+- low energy amplifies the inner critic. when i'm depleted, self-judgment gets louder and harder to notice.
+- unprocessed emotions drain energy. something i'm avoiding acts like a background process consuming CPU.
+
+this is why [[resets]] aren't optional luxuries. they're maintenance. running on empty doesn't just reduce output — it degrades the quality of your thinking, your relationships, and your relationship with yourself.
+
+## sleep as the foundation
+
+all of this is moot without adequate sleep. ultradian rhythms assume a well-rested baseline. sleep-deprived, the peaks are lower, the troughs are deeper, and the cycles are harder to detect. no amount of time-blocking or environment design compensates for insufficient sleep.
+
+this is probably the most boring and most important insight in this entire wiki: sleep more. everything else works better when you do.
\ No newline at end of file
new file mode 100644
index 0000000..1022d50
@@ -0,0 +1,48 @@
+---
+visibility: public-edit
+---
+
+# monotony and creativity
+
+"monotony is the death of creativity." the 80-15-5 rule for balancing routine, exploration, and chaos.
+
+## the problem with pure routine
+
+there's a tension in all the productivity advice: routines, systems — all of it optimizes for consistency. and consistency is powerful. but pure consistency produces monotony, and monotony kills the creative impulse.
+
+i've experienced this directly. some of my best [[startup-workflow]] periods had rigid routines that produced incredible output for weeks... and then creativity just died. i was producing, but producing the same thing with diminishing quality. the work became mechanical. novelty is a flow trigger — remove novelty entirely and you remove the fuel for creative flow.
+
+## the 80-15-5 rule
+
+a framework for balancing structure and novelty:
+
+- **80% routine work**: the core work. the deep focus blocks, the shipping, the [[critical-path]] execution. this is where consistency matters and where routines pay off.
+- **15% exploration**: related but different. reading outside your domain ([[research-workflow]]), trying new tools, learning adjacent skills ([[building-to-learn]]), having conversations that challenge your assumptions. this is where cross-pollination happens (see [[transfer]]).
+- **5% chaos**: deliberately unstructured time. no plan, no goal, just follow curiosity wherever it goes. a lot of this will be "wasted" time by any productivity metric, but it's where genuine insight and creative breakthroughs tend to emerge.
+
+the percentages aren't sacred — the principle is. pure routine (100-0-0) kills creativity. pure chaos (0-0-100) kills execution. you need all three.
+
+## why this matters for engineering
+
+in [[vibe-coding]] and technical work, monotony shows up as:
+
+- using the same patterns for every problem, even when a different approach would be better
+- solving problems the way you've always solved them, never questioning the assumptions
+- diminishing interest in work that used to be exciting
+- going through the motions — shipping features without caring about them
+
+the fix isn't motivation or discipline. it's novelty. a new problem, a new tool, a new constraint — anything that breaks the pattern enough to re-engage creative attention.
+
+## monotony and the inner work
+
+monotony also shows up emotionally. when work becomes routine, it's easy to numb out — not processing emotions because there aren't strong ones to process. this low-grade emotional flatness is a signal that something needs to change.
+
+[[resets]] are partly about breaking monotony. a change of environment, a different project, a walk outside — these work because they inject enough novelty to restart the creative engine.
+
+## the fear of chaos
+
+the 5% chaos allocation feels dangerous, especially when there's a lot to do. "i can't just... wander around. there's work to ship." but the cost of eliminating all unstructured exploration is higher than the cost of 5% "wasted" time.
+
+some of my best ideas have come from completely unrelated rabbit holes. a biology article that gave me an architecture idea. a game mechanic that suggested a UX pattern. you can't plan serendipity — but you can create conditions for it.
+
+[[zooming-out]] helps distinguish between "i'm being lazy" and "i'm creatively depleted." they feel similar but have very different solutions.
\ No newline at end of file
new file mode 100644
index 0000000..8842114
@@ -0,0 +1,39 @@
+---
+visibility: public-edit
+---
+
+# gratitude and appreciation
+
+gratitude as a practical tool, not a platitude. appreciation as a reset mechanism and confidence builder.
+
+## appreciation in the reset sequence
+
+when i'm anxious, sad, jealous, or unconfident, the reset sequence goes: process the feeling → appreciation → look at achievements → confidence (see [[resets]]). appreciation is the bridge between processing a difficult emotion and rebuilding confidence.
+
+this isn't "just be grateful" — it's a deliberate practice of looking at what's actually going well. after processing the negative feeling, there's space to see clearly. that's when appreciation works.
+
+## Joe Hudson's welcoming practice
+
+Joe Hudson (Art of Accomplishment) teaches something deeper than gratitude: the practice of *welcoming* difficult emotions. instead of trying to replace negative feelings with gratitude, you welcome the negative feelings fully. feel them, don't fight them.
+
+the insight: emotions that are welcomed move through faster than emotions that are resisted. a feeling of inadequacy that you sit with for two minutes passes. the same feeling resisted for two weeks festers.
+
+this connects to the anxious/sad reset — the first step is "go through what's making you feel that way." that's welcoming. then appreciation can happen authentically, not as a way to suppress the original feeling.
+
+## gratitude shifts perception
+
+Joe Hudson teaches that gratitude practiced consistently shifts how you perceive everything — not just what you're grateful for. it trains the brain to notice what's working, which makes [[confidence]] feel more natural and [[impostor-syndrome]] less convincing.
+
+## evidence building
+
+"things have worked — i spent good effort to make things work." looking back at past notes, past successes, past moments where effort paid off. this is appreciation directed at your own track record. it's not bragging — it's building evidence against the inner critic.
+
+looking back at old notes is listed as a general reset for a reason — it reconnects you to past versions of yourself that were capable and growing. see [[resets]].
+
+## make people feel good
+
+appreciation isn't just self-directed. "make people feel good" — noticed the contrast between scary-attacking leadership and comforting leadership.
+
+## the gap between reflection and action
+
+"for reflection, always amazing. sometimes though i reflect and then that's it, don't do anything about it." gratitude and appreciation can become a warm feeling that doesn't lead to change. the practice needs to connect to action — see [[operation-optimization]].
\ No newline at end of file
new file mode 100644
index 0000000..7c6dd8b
@@ -0,0 +1,45 @@
+---
+visibility: public-edit
+---
+
+# impostor syndrome
+
+the arc from "everyone is cooking me" to "acceleration > position." one of the most important shifts i've experienced.
+
+## the setup
+
+i arrived at a neurotech startup as the youngest intern. everyone seemed a lot more experienced, more structured than i expected. my initial work (visual evoked potentials) wasn't working, which meant no approval from the team. i didn't like doing work that wasn't getting results.
+
+## the cope spiral
+
+"lots of cope: people are older than me, different work style, others cooking me." i was rationalizing my insecurity instead of addressing it. the excuses were partly true (they *were* older, they *did* have different styles) but they were functioning as shields, not insights.
+
+## the breakthrough
+
+a cofounder gave a mentality talk that reframed everything:
+
+**"acceleration is much better than position."**
+
+the stocks metaphor: your skills and mentality go up and the cost to do things goes down. it doesn't matter where you are right now — it matters how fast you're learning.
+
+this hit different because it was exactly my situation. i was comparing my *position* (output, knowledge, experience) to people with years more of it. but my *acceleration* (learning rate) was high. i was still very young compared to them. maybe i learn a bit less fast, but i still learn very fast.
+
+## the deeper lesson
+
+"you should take agency and care about your growth, and if any org says you shouldn't, you should probably leave." impostor syndrome often comes from environments that measure position, not acceleration. the right environment celebrates growth.
+
+this connects to [[startup-workflow]] — the "growth number" literally measures acceleration. how much faster could you have gained the same position with what you now know?
+
+## who gets it
+
+"many times amazed by exactly WHO has impostor syndrome — which points to: it's dumb that you are having it." the people i'd least expect to feel like impostors still do. this doesn't mean it's not real — it means the feeling doesn't track reality.
+
+## the self-acceptance angle
+
+impostor syndrome is fundamentally a confidence problem. the fix isn't more achievements (they never feel like enough) — it's changing your relationship with yourself. see [[confidence]] and [[gratitude-and-appreciation]].
+
+Joe Hudson (Art of Accomplishment) teaches that confidence comes from self-acceptance, not from achievement. the achievement treadmill fuels impostor syndrome; self-acceptance breaks the cycle.
+
+## resolution
+
+i'm not "cured" of impostor syndrome. but i now have a framework: when the feeling hits, ask whether i'm comparing position or acceleration. usually it's position. and that comparison is almost always unfair.
\ No newline at end of file
new file mode 100644
index 0000000..a42b754
@@ -0,0 +1,33 @@
+---
+visibility: public-edit
+---
+
+# intentionality
+
+the meta-skill. "be intentional" applied to work selection, relationships, growth — everything.
+
+## the core question
+
+"what are we even trying to do here?"
+
+this question cuts through drift, scope creep, and the feeling of being busy without being productive. when things aren't working, often the problem isn't execution — it's that you forgot to be intentional about what you're executing on.
+
+## intentionality in relationships
+
+"connect intentionally — talk to people you can learn from, but also chat with people you're not closest with." at the neurotech startup, i deliberately repaired relationships with two teammates through intentional one-on-one walks (see [[relationship-repair]]).
+
+"make people feel good" — the intentional choice to build people up rather than tear them down. there's a contrast between scary-attacking leadership and comforting leadership. both can work, but the intentional choice matters.
+
+## intentionality in growth
+
+"what i want to be doing is learning and implementing and growing." when i check in on this, the drift becomes obvious. see [[critical-path]].
+
+## the first-principles version
+
+get values → values are hard so get fuzzy values → do things that roughly fit. this is the most stripped-down version of intentional living. you don't need perfect clarity — fuzzy values still create direction.
+
+## intentionality vs. ease
+
+"there is an ease in unfocus that is unsettling — want purpose ↔ confidence." being intentional takes energy. [[resets]] and [[zooming-out]] help restore the capacity for intentionality when it's drained.
+
+monotony kills intentionality. the fix: structure the first hour robustly, make the next hour unstructured. spend 10% on crazy ideas. see [[startup-workflow]] for the 80-15-5 rule.
\ No newline at end of file
new file mode 100644
index 0000000..d104763
@@ -0,0 +1,51 @@
+---
+visibility: public-edit
+---
+
+# building to learn
+
+learning by building, not by studying. why making things teaches faster than reading about things.
+
+## the core principle
+
+the best way to learn something is to build something with it. not read about it, not watch a tutorial, not take a course — build a real thing that forces you to confront the actual complexity.
+
+this isn't just my opinion. it's what the learning science supports: [[the-testing-effect]] shows that retrieval and application beat passive review. building does both simultaneously.
+
+## why tutorials fail
+
+following a tutorial is not building. it's copying. the tutorial author already solved every problem, and you're just retracing their steps. you feel like you're learning because it's novel, but there's no struggle, no failed retrieval, no debugging, no "wait, why doesn't this work."
+
+the moment the tutorial ends and you try to build something on your own, you discover how little you actually retained. the gap between "followed along successfully" and "can build from scratch" is enormous.
+
+## the learning-by-building loop
+
+what actually works:
+
+1. have a thing you want to build
+2. start building it with whatever you currently know
+3. hit a wall — you don't know how to do the next thing
+4. look up specifically what you need (not a full course, just the answer to your question)
+5. implement it, probably badly
+6. iterate until it works
+7. now you actually know that thing, because you fought for it
+
+the key insight: steps 3-6 are where all the learning happens. the struggle is the signal. see [[perseverance]] — the temptation to give up at step 3 and go back to comfortable studying is strong.
+
+## how this applies to my work
+
+[[vibe-coding]] with AI is an interesting case. AI lets you skip steps 3-6 by generating code for you. this is great for productivity but potentially terrible for learning. the friction that AI removes is exactly the friction that produces understanding.
+
+my current approach: use AI for things i already understand (speed boost) and build manually for things i'm trying to learn (learning boost). the danger is using AI for everything and ending up as a manager of code i don't understand.
+
+this connects to [[critical-path]] — sometimes the critical path is building fast (use AI). sometimes the critical path is building understanding (do it yourself). knowing which one you're on matters.
+
+## the prototyping advantage
+
+building something bad quickly teaches more than planning something perfect slowly. the prototype reveals what you actually don't know, which you can't discover by thinking about it. see [[startup-workflow]] — the lean methodology is basically building-to-learn applied to business.
+
+## the role of documentation
+
+writing about what you built — like these wiki pages — is a second pass of learning. the [[testing-effect|the-testing-effect]] again: retrieving what you learned and organizing it in writing consolidates the knowledge. building is the first pass (learning through doing), writing is the second pass (learning through explaining).
+
+this is why i use [[research-workflow]] as a complement to building, not a replacement. reading and research fill in the theoretical gaps that pure building misses — the "why" behind the "how."
\ No newline at end of file
new file mode 100644
index 0000000..2274868
@@ -0,0 +1,50 @@
+---
+visibility: public-edit
+---
+
+# spaced repetition
+
+the forgetting curve and how i use mochi to actually retain what i learn.
+
+## the forgetting curve
+
+ebbinghaus discovered in 1885 that you forget most of what you learn within 24-48 hours, following an exponential decay — but each review flattens the curve, and by the fourth or fifth spaced review the memory is basically permanent.
+
+this is not controversial in cognitive science — meta-analyses of 250+ studies confirm that spaced practice produces 10-30% better retention than massed practice (cramming).
+
+## why cramming feels effective
+
+the cruel trick of memory: rereading material creates a feeling of familiarity that gets mistaken for learning. you read your notes, everything looks familiar, you think you know it. then you close the notes and can't reproduce any of it.
+
+this connects to [[the-testing-effect]] — retrieval practice (actually pulling information from memory) is what builds durable memory, not re-exposure.
+
+## how i use mochi
+
+mochi is a spaced repetition app — basically anki but with better design. the system works by scheduling cards at increasing intervals based on how well you recall them.
+
+what i make cards for:
+- key concepts from [[research-workflow]] reading
+- api patterns and syntax i use occasionally but not daily
+- mental models and frameworks (the kind of thing from [[modeling]])
+- definitions and distinctions that are easy to confuse
+
+what doesn't work well as cards:
+- anything too complex for a single recall prompt
+- things i use daily anyway (no card needed — natural spacing)
+- opinions or judgments — cards are for facts and frameworks, not takes
+
+## the deeper principle
+
+spaced repetition is an instance of a broader principle: learning happens at the edge of forgetting. you need to almost-forget something before reviewing it — that's what makes the review effortful and therefore effective.
+
+## connection to building things
+
+the best spaced repetition system isn't mochi — it's using what you learn in real projects. see [[building-to-learn]]. if i learn a concept and then use it in code the next week and again in a different project the following month, that's natural spaced repetition with the added benefit of contextual practice.
+
+mochi fills the gap for things i need to remember but don't naturally encounter at spaced intervals.
+
+## practical notes
+
+- i do mochi reviews in the morning — it's low-energy work that gets the brain moving
+- card quality matters more than card quantity. a bad card wastes time forever. see [[operation-optimization]] — small improvements to card writing pay compound dividends
+- the habit of making cards is harder to maintain than the habit of reviewing them. mochi's scheduling handles reviews automatically; the bottleneck is creating good cards from new learning
\ No newline at end of file
new file mode 100644
index 0000000..1e8ff89
@@ -0,0 +1,44 @@
+---
+visibility: public-edit
+---
+
+# the testing effect
+
+retrieval practice beats re-reading every time. the counterintuitive finding that testing yourself is a learning tool, not just an assessment tool.
+
+## the research
+
+roediger and karpicke (2006) showed that students who tested themselves retained 50-80% more than students who re-read, even without feedback — an effect replicated across hundreds of studies.
+
+## the illusion of knowing
+
+this connects to why [[spaced-repetition]] works and why cramming doesn't. re-reading creates fluency — the material feels familiar, so you think you know it. this is an illusion. recognition ("oh yeah, i remember seeing this") is completely different from recall ("let me reconstruct this from memory").
+
+i fall for this constantly. i'll read a technical article, feel like i understand it, and then three days later can't explain the core concept to someone. the understanding felt real in the moment. it wasn't.
+
+## why retrieval works
+
+pulling information from memory — even unsuccessfully — strengthens the memory trace in a way that re-exposure doesn't. the effort of trying to recall is the learning signal. failed retrieval attempts are almost as valuable as successful ones, because the effort itself builds the neural pathway.
+
+## practical applications
+
+how this changes my learning workflow:
+
+- **after reading something important**: close it and try to write down the key points from memory before re-reading. this single habit has probably 10x'd my retention from [[research-workflow]] reading.
+- **mochi cards**: the whole point of [[spaced-repetition]] flashcards is forced retrieval. each review is a mini-test.
+- **explaining to others**: teaching or explaining a concept is retrieval practice plus elaboration. this is why writing wiki pages like this one actually helps me learn — i'm retrieving and organizing, not just copying.
+- **coding from memory**: when learning a new api or pattern, trying to implement it from memory before looking at the docs. the struggle is the point.
+
+## the testing effect and building
+
+[[building-to-learn]] is basically the testing effect applied to skills instead of knowledge. building something with a concept forces you to retrieve and apply it, which is far more effective than reading about it.
+
+this is why tutorials that just have you copy code don't work — there's no retrieval involved. the moment you deviate from the tutorial and have to figure something out yourself, that's when learning actually happens.
+
+## implications for how i work
+
+the meta-lesson: passive consumption is almost worthless for learning. reading articles, watching videos, attending talks — these feel productive but produce very little durable knowledge unless paired with active retrieval.
+
+this has changed my relationship with content consumption. instead of reading five articles on a topic, i'm better off reading one and spending the rest of the time testing myself on it. quality of engagement over quantity of exposure.
+
+see [[distraction-management]] — part of the pull of passive content is that it feels like learning without the discomfort of actual learning.
\ No newline at end of file
new file mode 100644
index 0000000..d3ad321
@@ -0,0 +1,44 @@
+---
+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."
\ No newline at end of file
new file mode 100644
index 0000000..6cdf5cf
@@ -0,0 +1,57 @@
+---
+visibility: public-edit
+---
+
+# competition strategy
+
+time management, problem selection, and team dynamics for math modeling competitions. distilled from HiMCM, MCM/ICM (Meritorious, top 10%), M3, MTFC, and USAYPT (2nd nationally).
+
+## the meta-game
+
+modeling competitions aren't just about math. they're about project management under extreme time pressure. MCM/ICM gives you 4 days. HiMCM gives you ~2 weeks but the effective work window is much shorter. the teams that win aren't always the most mathematically sophisticated — they're the ones that manage their time, divide work effectively, and produce a polished paper.
+
+## time allocation
+
+for a 4-day competition like MCM/ICM, my rough allocation:
+
+- **day 1 (first 8-12 hours):** problem selection, research, [[problem-framing]], initial model design. this is the most important day. a bad framing wastes the entire competition.
+- **day 2:** core model development. get the math working, get code running, generate initial results.
+- **day 3:** refinement, sensitivity analysis, additional models or extensions. start the paper structure.
+- **day 4:** paper writing, polishing, proofreading. no new math on this day — if it's not done, it doesn't go in.
+
+the biggest mistake teams make: spending too long on the model and not enough on the paper. judges read the paper, not your code. see [[mathematical-writing]].
+
+## problem selection
+
+when given multiple problems (MCM/ICM offers 6):
+
+- **pick the problem your team can model, not the one that sounds coolest.** FOMO ([[fomo-trap]]) applies here — the "exciting" problem might be outside your team's strengths.
+- **prefer problems where you can validate.** if there's real-world data to compare against, your paper is stronger.
+- **avoid problems that require domain expertise you don't have** unless you can learn it fast. you can't become a climate scientist in 4 days.
+- **read all problems before choosing.** obvious but teams often anchor on the first one that catches their eye ([[information-gathering]]).
+
+## team dynamics
+
+for a 3-person team (standard MCM/ICM):
+
+- **one person owns the paper.** always. writing by committee produces garbage. one person writes, others contribute sections and review.
+- **parallelize where possible.** one person on the main model, one on a secondary approach or sensitivity analysis, one on research and paper structure.
+- **sync frequently but briefly.** 15-minute check-ins every few hours beat hour-long status meetings.
+- **disagree early, commit fast.** the worst outcome is spending day 3 debating something that should have been settled on day 1. see [[reversible-vs-irreversible]] — most modeling choices are type 2.
+
+## the summary page
+
+in MCM/ICM, the summary page is the most important page of the paper. first-round judging often only reads the summary. it needs to:
+
+- state the problem clearly (as you interpreted it)
+- describe your approach concisely
+- present key results with actual numbers
+- highlight what makes your approach novel or strong
+
+don't create suspense. don't narrate your process. state your conclusions upfront. this is not a mystery novel; it's a technical report.
+
+## when things go wrong
+
+they will. models fail, code has bugs, team members disagree. the [[perseverance]] page is relevant here, but so is knowing when to pivot. if your approach isn't working by the end of day 2, pivot. don't spend day 3 trying to save a broken model ([[sunk-cost-and-quitting]]).
+
+the teams that do well aren't the ones that never hit problems — they're the ones that recover fast.
\ No newline at end of file
new file mode 100644
index 0000000..85934ec
@@ -0,0 +1,42 @@
+---
+visibility: public-edit
+---
+
+# estimation and sanity checks
+
+Fermi estimation, order-of-magnitude thinking, and the discipline of checking whether your answer makes sense.
+
+## Fermi estimation
+
+named after Enrico Fermi, who was famous for estimating quantities with almost no data. the method: break a hard question into sub-questions you can roughly answer, multiply the estimates together, and get within an order of magnitude (factor of 10) of the real answer.
+
+the point isn't precision — it's getting close enough to be useful with minimal data.
+
+## why this matters for modeling
+
+every mathematical model should pass a Fermi sanity check before you trust its output. if your model says a city of 100k people needs 50,000 hospital beds, something is broken. if your optimization says the answer is negative when it should be positive, something is broken.
+
+this sounds obvious but i've seen it fail — including in my own work. you get deep into the math, the equations look right, the code runs, and you accept the output without asking "does this number make sense in the real world?"
+
+## the sanity check habit
+
+after getting any result — analytical, simulated, or estimated — i try to check:
+
+1. **order of magnitude** — is the number roughly the right size? if you're modeling the weight of a car and get 50 kg, stop.
+2. **sign and direction** — does it go the right way? if increasing price decreases demand in your model, good. if it increases demand, probably a bug.
+3. **limiting cases** — what happens at extremes? if you set a parameter to 0 or infinity, does the model behave sensibly?
+4. **dimensional analysis** — do the units work out? this catches a surprising number of errors.
+5. **comparison to known values** — is there a real-world benchmark you can compare to?
+
+## estimation as a competition skill
+
+in [[competition-strategy]], estimation serves two purposes:
+
+- **guiding model development** — before building a complex model, estimate the answer. this tells you what order of magnitude to expect and helps catch errors early.
+- **validating results** — after your model produces numbers, check them against Fermi estimates. if they're wildly different, either your model or your estimate has a problem — figure out which.
+
+in timed competitions, Fermi estimation is also a time management tool. if a quick estimate tells you the answer, you might not need the complex model at all.
+
+## connection to other thinking
+
+Fermi estimation is decomposition — breaking a hard question into easier sub-questions. this is the same skill as identifying [[critical-path]] in a project, or [[problem-framing]] in modeling. the meta-skill is always: "what simpler questions can i answer that combine to answer the hard question?"
\ No newline at end of file
new file mode 100644
index 0000000..931e174
@@ -0,0 +1,55 @@
+---
+visibility: public-edit
+---
+
+# mathematical writing
+
+how to write modeling papers that judges and reviewers actually want to read. the math matters, but the writing is what gets it across.
+
+## the core principle
+
+a modeling paper isn't a record of what you did. it's an argument for why your approach works. every section should advance that argument.
+
+the number one mistake in competition papers: narrating your process chronologically. "first we tried X, then we tried Y, then we realized Z." nobody cares about your journey. present the final approach as if you knew the answer all along, with the reasoning laid out logically, not temporally.
+
+## paper structure
+
+for MCM/ICM and similar competitions:
+
+1. **summary/abstract** — the most important page. see [[competition-strategy]]. state the problem, your approach, and your key results. include actual numbers.
+2. **problem restatement** — restate the problem as you interpret it. this is where you show the judges you understood what was being asked. your interpretation IS part of the solution.
+3. **assumptions** — list them explicitly with justifications. don't hide assumptions in the text. a well-justified assumption demonstrates [[problem-framing]] skill.
+4. **model development** — the core. explain your approach, the math, and why you chose this formulation. connect back to your assumptions.
+5. **results and analysis** — present results with visualizations. sensitivity analysis goes here — how do results change when assumptions change?
+6. **strengths and weaknesses** — judges love honest self-assessment. it shows maturity. a paper that acknowledges its limitations is stronger than one that pretends to be perfect.
+7. **conclusions** — brief. what did you find? what would you do with more time?
+
+## writing quality signals
+
+things that make a paper look stronger, independent of the actual math:
+
+- **clear variable definitions** — define every variable when it first appears. use consistent notation throughout.
+- **figures that speak for themselves** — every figure should have a descriptive caption. a reader skimming the paper should understand the story from the figures alone.
+- **transitions between sections** — each section should flow into the next. the reader should never wonder "why am i reading this now?"
+- **quantitative claims** — "the model performs well" is weak. "the model achieves 94% accuracy on validation data" is strong. numbers beat adjectives.
+
+## the equation-to-explanation ratio
+
+equations without explanation are useless. explanation without equations is vague. the sweet spot: every equation should be preceded by intuition ("we want to minimize the total cost, which depends on...") and followed by interpretation ("this tells us that as X increases, Y decreases quadratically").
+
+don't dump a wall of equations and expect the reader to parse them. guide the reader through your reasoning. this is fundamentally about [[modeling]] — presenting the model in a way that builds understanding, not just demonstrating mathematical ability.
+
+## the visualization principle
+
+a good figure is worth 500 words of text. invest time in visualizations:
+
+- **heatmaps** for sensitivity analysis
+- **time series** for dynamic models
+- **flow diagrams** for model architecture
+- **comparison plots** for validation against real data
+
+the mistake: making figures an afterthought. in competition papers especially, judges flip through and look at figures first. make those figures tell the story.
+
+## connection to other skills
+
+mathematical writing is a specific case of [[research-workflow]] communication. the same principles apply to research papers, technical documentation, and even [[startup-workflow]] pitch decks: know your audience, lead with results, be honest about limitations, and make the structure carry the argument.
\ No newline at end of file
new file mode 100644
index 0000000..2595df5
@@ -0,0 +1,57 @@
+---
+visibility: public-edit
+---
+
+# monte carlo and simulation
+
+when to simulate versus when to solve analytically, and why simulation is underrated as a modeling tool.
+
+## the case for simulation
+
+analytical solutions are elegant but they require the problem to be tractable. most real-world problems aren't. the moment you have nonlinear interactions, stochastic elements, or enough variables, closed-form solutions disappear.
+
+simulation doesn't care. throw random numbers at the problem 10,000 times and see what happens. you trade mathematical elegance for computational brute force, and in practice that trade is almost always worth it.
+
+## monte carlo basics
+
+the core idea: use random sampling to estimate quantities that are hard to compute directly.
+
+1. define the system and its random inputs
+2. sample those inputs from their distributions
+3. run the model for each sample
+4. aggregate the results — mean, variance, percentiles, whatever you need
+
+the power: as sample size grows, your estimate converges on the true value. the error shrinks as 1/sqrt(n), which means 100x more samples gives 10x more precision. diminishing returns, but predictable diminishing returns.
+
+## when to simulate vs solve analytically
+
+**solve analytically when:**
+- the problem is tractable (linear, well-behaved)
+- you need to understand *why* the result is what it is, not just *what* it is
+- the analytical solution reveals structure (sensitivities, critical thresholds)
+- judges/reviewers expect it (in competitions, an analytical result carries more weight)
+
+**simulate when:**
+- the problem has too many interacting variables for closed-form
+- you need distributions, not just point estimates — "what's the range of outcomes?"
+- the system has feedback loops or emergent behavior
+- you want to stress-test your analytical solution (see [[estimation-and-sanity-checks]])
+- time pressure makes deriving a closed-form impractical (see [[competition-strategy]])
+
+## in competitions
+
+in MCM/ICM, i've found the strongest papers often combine both: an analytical model that captures the core dynamics, validated and extended by simulation. the analytical model shows you understand the structure. the simulation shows it actually works under realistic conditions.
+
+the trap: using simulation as a black box. judges want to see that you understand what your simulation is doing, not just that it produces numbers. always pair simulation results with sensitivity analysis and sanity checks.
+
+## practical simulation tips
+
+- **start with a tiny simulation** — 100 runs, simple model. get the code working and the output format right. then scale up.
+- **validate against known cases** — if your problem has a special case with a known answer, simulate that case first. if the simulation doesn't match, you have a bug.
+- **vary one thing at a time** — understand the effect of each parameter before varying everything at once.
+- **visualize intermediate results** — don't just look at final numbers. plot distributions, time series, spatial patterns. the shape of the distribution often tells you more than the mean.
+- **seed your random number generator** — for reproducibility. nothing worse than "it worked yesterday but not today" because of random variation.
+
+## connection to [[modeling]]
+
+simulation is a form of [[modeling]] where the model is expressed as code rather than equations. the same principles apply: all simulations are wrong, but some are useful. the question is still "does this capture the dynamics that matter for my question?"
\ No newline at end of file
new file mode 100644
index 0000000..3468e18
@@ -0,0 +1,39 @@
+---
+visibility: public-edit
+---
+
+# problem framing
+
+the most important part of mathematical problem-solving happens before any math. choosing *what* to model and *what to ignore* determines everything downstream.
+
+## "all models are wrong, but some are useful"
+
+this idea from George Box (see [[modeling]]) is the foundation of problem framing. the goal isn't to capture reality perfectly — it's to build a representation that's useful for answering your specific question.
+
+the framing move: "given this messy real-world situation, what's the simplest mathematical structure that captures the dynamics i care about?"
+
+## the framing process
+
+how i actually approach it, refined through HiMCM, MCM/ICM, and other competitions:
+
+1. **read the problem 3 times.** first for the gist. second for the constraints. third for what's NOT said — the degrees of freedom.
+2. **identify the core tension.** every interesting problem has a tradeoff or a conflict. find it. the model should capture this tension.
+3. **list your assumptions explicitly.** what are you ignoring? what are you simplifying? writing these down isn't busywork — it's the intellectual honesty that judges (and reviewers) respect. it also prevents you from accidentally building on an assumption you forgot you made.
+4. **choose the level of abstraction.** this is the hardest step. too detailed and the model is intractable. too abstract and it's useless. the art is finding the level where the key dynamics survive but the noise drops out.
+
+## common framing mistakes
+
+- **modeling everything** — trying to include every variable. the model becomes a worse version of reality instead of a useful simplification.
+- **wrong abstraction level** — modeling individual agents when you should be modeling aggregate behavior, or vice versa. the question determines the right level.
+- **forgetting what question you're answering** — the model drifts as you build it, and you end up with something technically interesting but irrelevant to the original problem. this connects to [[intentionality]].
+- **not checking if a simpler model works first** — always start simple. add complexity only when the simple model fails at something the problem requires. see [[estimation-and-sanity-checks]].
+
+## framing in competition vs research
+
+in competition ([[competition-strategy]]), framing speed matters. you have limited time and need to commit to a framing quickly. the 70% rule from [[information-gathering]] applies — frame at 70% confidence and iterate.
+
+in [[research-workflow]], you can afford to explore multiple framings before committing. often the insight IS the framing — finding the right way to look at the problem is the paper.
+
+## connection to the rest of the work
+
+problem framing isn't just a math skill. it's the same skill as identifying the [[critical-path]] in a project, or choosing what to focus on when [[zooming-out]]. the underlying move is always: "what's the simplest representation that captures what matters?"
\ No newline at end of file
new file mode 100644
index 0000000..23f8dd6
@@ -0,0 +1,41 @@
+---
+visibility: public-edit
+---
+
+# the pivotal conversation about taking agency
+
+there was one conversation that changed everything. my mentor at a [[neurotech startup|signal-processing-workflow]] sat me down and asked me how my day was. i said 70%. productive? yeah probs. and then he dropped it:
+
+"it should be up to you. i feel intuitively that taking agency would be much better."
+
+i didn't fully get it. i'd been doing things because people told me to do them. not really thinking that critically, just acting. the whole day felt weird — like i was operating on autopilot while someone else drove.
+
+his response was basically: that's the point. "i make you do things, and you think about agency, and you understand your agency through experience." the discomfort of being directed was supposed to wake me up to the fact that i wasn't directing myself.
+
+## the core idea
+
+"you should take agency and care about your growth, and if any org says you shouldn't, then you should probably leave."
+
+when i asked why he cared about my acceleration so much, the answer wasn't what i expected. it wasn't pure altruism — though he did say he has a personal philosophy that there should be more good people in the world. it was also practical: the hiring bar was so high that even slightly increasing the chance of finding exceptional people was a worthwhile investment. i might be a potential deep hire, or i might pull in other potential deep hires.
+
+but the real insight was about [[acceleration vs position|the-stocks-metaphor]]:
+
+> "acceleration is much better than position. we have grown so much. if we started over with nothing, we could get back to this in 2-3 months."
+
+## what changed
+
+after this conversation, things shifted. i started dropping stuff from my todo list that wasn't important. for the first time, i was really prioritizing. before, i thought [[intentionality|prioritization]] just meant getting rid of actions caused by fear and pleasure. but actually there was much more — especially the question of "great, i'll do work the entire day; what kind of work?"
+
+if i care about growth so much, why was i reflecting on a math camp that was mediocre compared to this? why was i going to some finance essentials program? why was i working on my own stuff while at a once-in-a-lifetime opportunity?
+
+the agency talk wasn't just about doing things proactively. it was about understanding that i was the one who should be deciding what mattered. nobody else could do that for me — and the discomfort of having someone else direct me was the proof.
+
+## the aftermath
+
+all the new ideas felt overwhelming at first. two senior people were setting the tone with words like "exceptional" — but they didn't really care about exceptional work, just exceptional activity. exceptional engagement with growth.
+
+the place was a growth machine. and this conversation was when i started understanding that the machine only works if you grab the wheel yourself.
+
+---
+
+*see also: [[the stocks metaphor|the-stocks-metaphor]], [[intentionality for selecting work|prioritization]], [[disagreeing productively|disagreeing-productively]]*
\ No newline at end of file
new file mode 100644
index 0000000..5ef661a
@@ -0,0 +1,70 @@
+---
+visibility: public-edit
+---
+
+# how to extract value from mentor conversations
+
+over a summer at a [[neurotech startup|signal-processing-workflow]], i had probably 30+ structured conversations with mentors, cofounders, peers, and visitors. some were incredible. some were mediocre. the difference was almost always in the questions.
+
+## what worked
+
+### ask about their experience, not their advice
+
+instead of "what should i do?", the better question is always about what they actually experienced. "how has your experience of running [the company] been? tiring? easy to maintain motivation?" gets real answers. "what should i do with my life" gets platitudes.
+
+### probe the disagreements
+
+the most valuable moments came when i found contradictions between what different mentors told me:
+- one cofounder said he cared deeply about intern growth; another called that altruism
+- one person said a former colleague was a mistake; the other said they missed them
+- everyone had different opinions on each other
+
+"be very careful of what other people tell you about" — this was itself great advice. mentors have biases. the skill is triangulating across multiple perspectives.
+
+### ask the meta question
+
+"what do you think of me?" sounds needy but it's incredibly high-signal. one CEO answered: "cool, fun person. don't know what you want." that single sentence told me more about my blind spot than weeks of self-reflection.
+
+"what can be better about [the org]?" is the same move in reverse — showing the mentor you're thinking critically, not just absorbing.
+
+### use walks
+
+"one of the biggest ways i can get feedback is walks." walks strip away the formality. no screen to hide behind, no agenda pressure. the best conversations happened walking around the city at night or during breaks between work sessions.
+
+## what didn't work
+
+### asking for validation
+
+"you're not just lying to me to not make me feel sad, right?" — i asked this early on and it reveals insecurity more than it generates useful info. the answer is always going to be "no" regardless.
+
+### pre-filtering your questions
+
+i had a habit of crossing out questions before meetings because they seemed too basic or already answered. bad move. the "dumb" questions often led to the most surprising answers.
+
+### not pushing back
+
+"push back more. you're too soft with people you think are better than you." i had a filter coefficient problem — i was setting it too low (accepting everything) for people with more experience, when actually those people have a higher chance of being tunneled in their own perspective.
+
+the fix: "do you understand it well enough to explain it back to your sibling? if not, ask more questions."
+
+### arguing to be right instead of for the idea
+
+"many times it feels that you are arguing to be right instead of for the benefit of pursuing the idea." — this feedback hit hard because it was true. the goal of a question should be to advance understanding, not to win.
+
+## the agenda principle
+
+"whenever you talk to anyone, state one sentence of what you are doing and why." basically: have an agenda. not in a manipulative way — in a clarity way. know what you want from the conversation before it starts.
+
+but also: be open to the conversation going somewhere unexpected. the best insight i got all summer (the [[agency talk|agency-talk]]) came from a question about how my day went, not from my prepared list.
+
+## recording vs not recording
+
+i went back and forth on this. the CEO's take was decisive:
+
+"don't record. there is a single moment to learn, and it is now. it increases focus."
+
+my counter was that recording makes me relaxed and lets me converse better. i ended up taking notes right after instead — trying to capture the emotional texture, not just the content.
+
+---
+
+*see also: [[pattern recognition|pattern-recognition]], [[disagreeing productively|disagreeing-productively]], [[social wins|social-wins]]*
\ No newline at end of file
new file mode 100644
index 0000000..ad0c638
@@ -0,0 +1,69 @@
+---
+visibility: public-edit
+---
+
+# disagree and commit: being forceful in idea exchange
+
+this was one of the hardest lessons from working at a startup. i came in soft — deferring to anyone i thought was smarter than me, which was basically everyone. by the end, i understood that productive disagreement is a skill, not a character trait.
+
+## the feedback loop
+
+the feedback kept coming from multiple directions:
+
+- a cofounder: "push back more. when people say things, push back more."
+- another cofounder: "many times it feels that you are arguing to be right instead of for the benefit of pursuing the idea."
+- my own reflection: "push back more. too soft with people i think are better than me."
+
+these seem contradictory — push back more, but also stop arguing to win? the resolution is that there are two different failure modes:
+
+1. **not pushing back at all** — accepting everything because the other person has more experience
+2. **pushing back for ego** — arguing to prove you're smart rather than to improve the idea
+
+i was doing both at different times, often in the same conversation.
+
+## the filter coefficient
+
+the best framing came from a cofounder's concept of a "filter coefficient":
+
+- for people with a lot of experience, the coefficient should be *higher* (more skepticism), not lower
+- they have a much higher chance of being tunneled in their own perspective
+- definitely don't make it 0 for anyone — that means you're a pushover
+- the test: "do you understand it well enough to explain it back to your sibling? if not, ask questions."
+
+this was counterintuitive. i thought experienced people should be trusted more. but the filter coefficient idea says the opposite: the more someone knows, the more likely they are to have blind spots in their expertise. they need your naive questions more, not less.
+
+## what good disagreement looks like
+
+### think before speaking
+
+"when saying things, think about them more. many times you say something and it's logically beat by someone. you could have gotten to that same conclusion yourself."
+
+this stung because it was true. i was throwing out half-baked ideas and getting shot down, then feeling defeated. the fix wasn't to stop sharing ideas — it was to stress-test them internally first. know your own weaknesses and loopholes in thinking.
+
+### disagree about the idea, not the person
+
+i noticed inconsistencies everywhere at the startup. one person said the org cared about intern growth; another dismissed that as altruism. one said a former colleague was a mistake; another missed them. these contradictions were everywhere.
+
+the skill wasn't calling people out on contradictions. it was using the contradictions to form better questions: "i've heard different perspectives on X. what's your take and why?"
+
+### the "giving negative feedback is really good" principle
+
+from writing up improvement notes for the org, i learned that you can be brutally honest if you frame it right. i literally wrote: "disclaimer — suggestions, not personal at all. for growth." and then gave pointed feedback to each founder about their blind spots.
+
+the fact that they received it well taught me something: people at the top often have fewer people willing to be honest with them. your willingness to disagree is itself valuable.
+
+### decrease the latency
+
+"decrease the latency on the honesty. just say stuff more often." don't wait for the perfect moment or the right framing. the thing you're sitting on for days could have been said in a sentence yesterday.
+
+## the org-level pattern
+
+emotions matter a lot in how disagreements land. "org is run by humans; emotions matter a lot." you can be right about everything and still damage the relationship if the delivery is wrong.
+
+but also: "gripe night" (a dedicated time for grievances) was tried and found to be risky. structured disagreement has its place, but it can backfire when grievances get personal.
+
+the best pattern i found was walks. informal, low-stakes, one-on-one. the disagreement flows naturally when you're walking side by side instead of sitting across a table.
+
+---
+
+*see also: [[asking good questions|asking-good-questions]], [[pattern recognition|pattern-recognition]], [[social strategy|social-strategy]]*
\ No newline at end of file
new file mode 100644
index 0000000..208411f
@@ -0,0 +1,59 @@
+---
+visibility: public-edit
+---
+
+# how mentors spot what you can't see about yourself
+
+one of the most unsettling things about good mentors is they can read you before you can read yourself. during my time at a [[neurotech startup|signal-processing-workflow]], i got to see this from multiple angles — being read, learning to read others, and watching the founders read each other.
+
+## the read on me
+
+when i asked a cofounder what the read on me was during hiring, the answer was blunt:
+
+- "just woke up a couple of months ago, now is half awake"
+- "lots of potential"
+- "kinda like a young version of [another person there]"
+- "either fully wake you up or set you on a good path"
+
+less than 1% of people they talked to got invited for even a week. the fact that they saw something in me that i couldn't yet see in myself was both flattering and destabilizing. i didn't know what "half awake" meant until i experienced what "awake" felt like.
+
+## the failure mode stack
+
+when i brought up a bunch of ideas for improving the org (honesty culture, feedback systems, guided reflections), one mentor responded with something i think about a lot:
+
+coping can be classified into a stack:
+- first order: make mistakes and grow
+- second order: make mistakes and grow while under crazy pressure to perform
+- third order: understand how to make mistakes while under pressure for the most growth
+
+he was seeing that i was at first order, trying to jump to third. the insight was that i needed to experience the pressure first before i could optimize around it.
+
+## reading people as a skill
+
+"reading people is a really good skill. you can also refine it by just telling your read of them to them."
+
+i tried this. i gave my reads on coworkers:
+- one person: crazy hard worker, slightly less active in certain ways
+- another: very active, sometimes too active in pushing ideas
+- a third: not very active, sometimes so inactive it felt off-brand
+
+the response was "good reads." and then: "what about on me and the other cofounder?" so i said it — one was an unbeatable force, the other a bit arrogant and spread thin.
+
+the fact that he didn't flinch at the feedback was the lesson. [[disagreeing productively|disagreeing-productively]] means being honest about what you see, even upward.
+
+## what mentors see that you can't
+
+- **tunneling.** you get stuck in a local optimum and can't see the bigger picture. the easy solution is to talk to people and have them ground you.
+- **vague fears vs clear fears.** clear fears are good to act on. vague and murky fears are often irrational. mentors help you figure out which is which.
+- **the gap between wanting and doing.** i thought i was being intentional. they could see i wasn't — that i was doing unimportant tasks while important ones sat there.
+- **inconsistencies.** i found many inconsistencies between what different people at the org told me. that itself was a pattern-recognition lesson: people's stated beliefs and actual behaviors diverge, and spotting that is a critical skill.
+
+## the uncomfortable truth
+
+the CEO once said: "i dont know what you want." that stung because i thought i was projecting clarity. the truth was i was projecting activity, not direction.
+
+a mentor asking "what do you want?" repeatedly isn't small talk. it's the most important diagnostic question. if your answer keeps changing or stays vague, that's the pattern they're spotting.
+
+---
+
+*see also: [[the agency talk|agency-talk]], [[asking good questions|asking-good-questions]], [[emotions and work|emotions-and-work]]*
\ No newline at end of file
new file mode 100644
index 0000000..77fe838
@@ -0,0 +1,63 @@
+---
+visibility: public-edit
+---
+
+# acceleration > position: growth compounds like investments
+
+this metaphor came out of the [[agency talk|agency-talk]] and it stuck with me harder than almost anything else.
+
+## the original framing
+
+a cofounder at the startup explained the org's mentality like this:
+
+> "think about it like stocks: money grows up and up and cost to buy things goes down and down. skills + mentality goes up and up and cost to do things goes down and down."
+
+the point: acceleration matters more than position. where you are right now is less important than how fast you're moving and in what direction.
+
+he backed it up: "we have grown so much. if we started over with nothing, we could get back to this in 2-3 months." the assets weren't the code, the hardware, the office. the assets were the people and their rate of improvement.
+
+## why this reframes everything
+
+before hearing this, i was obsessed with position. what have i done? what can i show? what's on my resume? the stocks metaphor flips that:
+
+- a person who's mediocre but accelerating is worth more than a person who's great but plateaued
+- the "stuff that the interns are doing, we could probably do in 1/20 of the time" — the interns' output wasn't the point. their growth rate was.
+- when the cofounder first joined, he was doing wiring work that the electrical engineers could have done faster. he didn't care. he was there to compound.
+
+## how i applied it
+
+### dropping todo items
+
+once i internalized this, i started [[prioritizing differently|prioritization]]. the question became: "does this accelerate me?" not "is this productive?"
+
+- reflecting on a mediocre math camp vs reflecting on the startup experience — obvious choice
+- going to a finance essentials program vs going deeper on the work right in front of me — obvious choice
+- working on personal projects during a once-in-a-lifetime immersive experience — obvious mistake
+
+### evaluating people
+
+the stocks metaphor also changed how i think about who to spend time with. "once you find a node, don't let go. good nodes bring you in flows of people." the question isn't whether someone is impressive right now — it's whether they're on a steep curve.
+
+### compounding skills
+
+"to increase output over time, do skills that compound." the CEO put it bluntly: "people think growth is dumb — no way people are growing 20% per week. but actually look at pioneers, they output insane amounts."
+
+the meta-skills that compound fastest:
+- navigating new environments
+- leading a team
+- learning new things
+- reading people and situations
+
+these aren't domain skills. they're multipliers on everything else.
+
+## the dark side
+
+this framing can be addictive. when everything is about acceleration, it's easy to devalue rest, relationships, and anything that doesn't obviously compound. i've had to learn that [[energy management|energy-hacks]] and [[social connection|social-wins]] are themselves compounding investments, not distractions from the real work.
+
+also: the metaphor can breed arrogance. "the world is pretty shit, most of the people are pretty shit" — that's the elitist version of this idea, and while there's a kernel of truth in setting high standards, it's easy to lose empathy along the way.
+
+a friend put it well: "friends ground you." the same people who taught me about acceleration also needed others to keep them from flying off the rails.
+
+---
+
+*see also: [[agency talk|agency-talk]], [[prioritization|prioritization]], [[mindset shifts|mindset-shifts]]*
\ No newline at end of file
new file mode 100644
index 0000000..4fb1393
@@ -0,0 +1,33 @@
+---
+visibility: public-edit
+---
+
+# modeling
+
+notes on mathematical and conceptual modeling. [published on moonflowers.xyz](https://www.moonflowers.xyz/notes/mDl1nG_N0t3-on-modeling).
+
+## the core idea
+
+"all models are wrong, but some are useful." — George Box
+
+models aren't truth. they're tools. the question isn't "is this model right?" but "is this model useful for what i'm trying to do?"
+
+## examples across domains
+
+- **anesthetics EEG model** — a simplified representation of brain activity that's useful for monitoring patients, even though it doesn't capture everything happening in the brain
+- **data center environmental impact** — models that estimate carbon footprint, useful for decision-making even if imprecise
+- **linear regression** — the simplest useful model. often good enough.
+- **firefighting strategy** — models of fire spread that guide resource allocation
+- **Maxwell's equations** — near the ground-truth end of the spectrum. physics-grade models that are both useful AND highly accurate.
+
+## the spectrum
+
+there's a spectrum from rough useful models to physics-grade ground truth. most real-world models sit closer to the rough end, and that's fine. the mistake is expecting ground truth from a rough model, or refusing to use a rough model because it's not ground truth.
+
+## connection to narratives
+
+a narrative is a model of your own story. and like all models, narratives are wrong but some are useful. choosing a better narrative (see [[confidence]]) is choosing a more useful model of yourself.
+
+## modeling in research
+
+when doing [[research-workflow]], modeling is often the core skill — taking a complex system and finding a representation that's simple enough to work with but accurate enough to be useful.
\ No newline at end of file
new file mode 100644
index 0000000..c6d3956
@@ -0,0 +1,39 @@
+---
+visibility: public-edit
+---
+
+# narratives
+
+how the story you tell yourself about your work determines how you feel about your work.
+
+## the core observation
+
+"narratives very clearly impact how i feel about work — with a more excited narrative i could have been more interested."
+
+this is one of the most practical insights i've had. the same work, the same project, the same timeline — but framed differently, it becomes either exciting or draining. the narrative isn't just how you describe your work to others; it's how you describe it to yourself, moment to moment.
+
+## language shapes behavior
+
+"if something is articulated better, i remember it and its importance more." the way you name things changes how you relate to them. a well-articulated goal sticks. a vague one drifts.
+
+this is why the [[startup-workflow]] rituals work — re-entry slides, growth numbers, weekly reflections. they force you to articulate what you're doing and why. the articulation itself creates motivation.
+
+## the hype trap
+
+"it is so easy to get fooled by hype." a collaborator was "very much a hype machine." exciting narratives can be false narratives. the fix isn't to distrust excitement — it's to check: does this narrative match reality? is the excitement based on substance or hype?
+
+connect this to [[modeling]] — a narrative is a model of your story. "all models are wrong but some are useful." choose a narrative that's useful (motivating, clarifying) without being so wrong that it leads you astray.
+
+## startups hard
+
+"startups hard — growth as exceptional work framing is so strong." reframing startup struggle as "exceptional work" and personal growth changes the experience of difficulty. this is narrative engineering.
+
+## the danger of approval narratives
+
+"working on referral.bike was pretty short sighted and approval seeking; took the easiest thing on the list." when your narrative is about getting approval from others, you optimize for easy wins, not important work. see [[critical-path]].
+
+## narrative and confidence
+
+narrative and [[confidence]] are deeply linked. an impostor narrative ("i'm behind, everyone is better") creates a specific emotional reality that feels true but isn't — see [[impostor-syndrome]]. switching to an acceleration narrative ("i'm learning fast, position doesn't matter yet") changes everything.
+
+Joe Hudson's work (Art of Accomplishment) explores how the inner critic creates narratives that feel like truth but are actually just one perspective. the practice of noticing narratives — without immediately believing them — is a form of [[zooming-out]] applied to your inner experience.
\ No newline at end of file
new file mode 100644
index 0000000..7e68dac
@@ -0,0 +1,54 @@
+---
+visibility: public-edit
+---
+
+# before the awakening: who i was in may 2025
+
+this is a snapshot from a school reflection exercise, about two months before the [[startup internship|signal-processing-workflow]] that changed everything. reading it now is like reading someone else's writing.
+
+## the answers
+
+**who are you?** "i am a student that is passionate about learning."
+
+**what do you want out of your life?** "happiness, and to feel a lot of pleasure through interactions with others, achievement, and completeness."
+
+**long term goals?** "to continuously learn about the world and its functions, and use my knowledge to make change."
+
+**where do you see yourself in ten years?** "after college, looking for a job (or already with a job)."
+
+**what do you know for sure about yourself?** [blank]
+
+## what's striking in retrospect
+
+the person writing these answers had just discovered that change was possible. the big insight at the time: "change came with effort, and if you put in effort, it was easy." the evidence was small things — helping friends win tennis matches, breaking a youtube addiction, independent study of math.
+
+the beliefs: "working hard is the biggest cause of success. people can change. the meaning of life is pleasure."
+
+all of these would get complicated by the summer. the meaning of life shifted from pleasure to something closer to "growth" and "beauty" after conversations about humanism and rationalism. the simplistic view of hard work got nuanced by ideas about [[intentionality|prioritization]] and [[acceleration vs position|the-stocks-metaphor]]. the confidence about change got stress-tested by actually trying to change fast under pressure.
+
+## the pre-awakening strengths
+
+what i listed: fast learner, very analytical, likes to optimize, controlled and calm, athletic.
+
+what i should have listed: curiosity, willingness to change, social energy, pattern recognition.
+
+the things i wanted to change: "being more controlled, sometimes feel like i am out of control. sometimes probably too pushy on others." — both of these would become features, not bugs, at the startup.
+
+## the goals
+
+- short term: sustain social relationships
+- 1 year: learn STEM skills
+- 2 years: figure out what i want to do
+- long term: build cool things
+
+the 2-year goal ("figure out what i want to do") is the one that actually mattered. and it took about 2 months, not 2 years — because someone at a startup sat me down and had the [[agency conversation|agency-talk]] with me.
+
+## why this matters
+
+keeping this snapshot is important because it's easy to retroactively think i was always like this. i wasn't. two months before the internship, i was writing "the meaning of life is pleasure" and imagining myself "looking for a job after college." the transformation was real but it needed a catalyst.
+
+a cofounder would later describe me as having "just woke up a couple of months ago, now is half awake." this document is what "before waking up" looked like.
+
+---
+
+*see also: [[the agency talk|agency-talk]], [[mindset shifts|mindset-shifts]], [[learning from experience|learning-from-experience]]*
\ No newline at end of file
new file mode 100644
index 0000000..dea2937
@@ -0,0 +1,51 @@
+---
+visibility: public-edit
+---
+
+# compiled advice to my past self
+
+this started as a note to younger me. it grew into a general document of things i've learned that i keep coming back to. not all of this is original — some came from [[mentors|pattern-recognition]], some from experience, some from friends.
+
+## general
+
+- lots of life is about optimization: have a goal and achieve it, have a metric and maximize it
+- always variance. just keep working / trying / whatever
+- no idea what you can achieve — that's the exciting part
+- first draft is always bad. iteration is the game
+- first step is removing distractions; second step is being intentional with time
+- there's infinite stuff and finite time — the constraint is always time, never options
+- be crazy. the people i admire most were all a little unhinged in their ambition
+
+## social
+
+- unless you really know a person, they are probably less cool and less smart than you think
+- you are cooler and smarter in comparison than you think
+- super famous/successful people are often very privileged/lucky. they aren't automatically cool people
+- to make friends: literally just talk (and be cool)
+- balance between breadth and depth — gotta know people well AND know lots of people
+- just reach out. lots of people are very cool. ignore the not cool ones
+
+## school
+
+- definitely talk to upperclassmen. super cool, more mature, have all the wisdom
+- definitely get to know teachers. even cooler than upperclassmen
+- go to social events: networking, direct happiness, people to talk to about hard stuff
+- spend time at school socializing, spend time at home working (unless hyper locked in)
+- dating: it's chill to not date. don't feel behind
+- don't need to always fill time during summers and breaks
+
+## technical
+
+- low level CS stuff not that important. syntax super easy. what's important is algorithmic thinking and experience
+- for math: not at all important to get super ahead. if you really like it, you can spend 1 month and catch up. most important: get a very solid base
+- math competitions are fun and only a bit useful
+
+## the meta-advice
+
+most advice is about what to do. the real skill is knowing whose advice to take. my [[filter coefficient|disagreeing-productively]] evolved from "accept everything from smart people" to "weight advice by how well the person knows my specific situation."
+
+and the most useful advice i ever got wasn't advice at all — it was a question: "what do you want?" asked repeatedly until i had a real answer.
+
+---
+
+*see also: [[the stocks metaphor|the-stocks-metaphor]], [[social wins|social-wins]], [[social strategy|social-strategy]]*
\ No newline at end of file
new file mode 100644
index 0000000..00572ca
@@ -0,0 +1,40 @@
+---
+visibility: public-edit
+---
+
+# operation optimization
+
+the practice of periodically optimizing how you operate. meta-work on your work.
+
+## the reflection → action gap
+
+"for reflection, always amazing. sometimes though i reflect and then that's it, don't do anything about it."
+
+this is the central problem. reflection feels productive. you have insights, you write them down, you feel good. then nothing changes. the gap between knowing and doing is where most self-improvement dies.
+
+## periodic check-ins
+
+"the solution to a lot of gratification seeking" — periodic check-ins with yourself. stop, ask:
+- is what i'm doing right now the most important thing? (see [[critical-path]])
+- am i on autopilot or am i being intentional? (see [[intentionality]])
+- is my current [[narratives|narrative]] serving me or draining me?
+- do i need a [[resets|reset]]?
+
+these check-ins are the operational version of [[zooming-out]] — applied to yourself instead of your work.
+
+## self-improvement experiments
+
+things i've tried:
+- structured first hour, unstructured second hour
+- 10% of time on crazy ideas (from [[startup-workflow]]'s 80-15-5 rule)
+- voice to text for coding (see [[vibe-coding]])
+
+some of these stuck, some didn't. the meta-lesson: run experiments, but don't expect all of them to work. and don't keep running experiments that aren't working just because you spent time setting them up.
+
+## wasted setup time
+
+"wasted a lot of time on setup that didn't matter — ditching them feels so good." operation optimization sometimes means undoing previous optimization attempts. if a system isn't serving you, kill it. don't maintain complexity out of sunk cost.
+
+## the re-entry format
+
+the best operation optimization tool i've encountered: the [[startup-workflow]] re-entry format. 30 minutes solo reflection with pen and paper, then group report. the structure forces reflection AND action — you have to articulate what you'll do differently.
\ No newline at end of file
new file mode 100644
index 0000000..2409818
@@ -0,0 +1,29 @@
+---
+visibility: public-edit
+---
+
+# perseverance
+
+"monkey wants us to run away, but clear thinking knows it's a skill to refine."
+
+## the instinct to flee
+
+when things are cooked — when the project is broken, the deadline is tight, the team is frustrated — every instinct says to bail. switch projects, take a long break, find something easier. the monkey brain optimized for survival, not for pushing through hard technical problems.
+
+but clear thinking knows: the ability to stay when things are hard is a skill. and like any skill, it gets better with practice.
+
+## when to persevere vs. when to pivot
+
+this is the hard distinction. sometimes the right move IS to backtrack — "when nothing is working, backtrack like crazy" (see [[zooming-out]]). perseverance doesn't mean stubbornly pushing in the wrong direction.
+
+the test: am i persevering on the right thing, or am i just afraid to admit this approach is wrong? [[critical-path]] helps here — if you're on the critical path, push through. if you're grinding on something that doesn't matter, zooming out is the better move.
+
+## optimism as fuel
+
+"always think of things that could work, never fear that stuff won't work out." optimism isn't naivety — it's a practical stance. pessimism drains energy and makes giving up easier. optimism keeps you looking for solutions.
+
+this connects to [[narratives]] — an optimistic narrative sustains perseverance. a defeated narrative undermines it.
+
+## energy expenditure
+
+"expending more energy frequently works." from the CEO of a startup i worked at. evolution optimized us to save energy, but in knowledge work there's no reason to conserve. see [[startup-workflow]].
\ No newline at end of file
new file mode 100644
index 0000000..f3559b8
@@ -0,0 +1,33 @@
+---
+visibility: public-edit
+---
+
+# relationship repair
+
+deliberate strategies for fixing friction with teammates. not avoiding conflict — resolving it.
+
+## the one-on-one walk
+
+at a neurotech startup, i deliberately repaired relationships with two teammates who initially seemed annoying. the strategy: intentional one-on-one walks.
+
+walks work because:
+- you're side-by-side, not face-to-face (less confrontational)
+- the change of scenery lowers defenses (see [[zooming-out]])
+- walking pace creates natural pauses — no pressure to fill silence
+- it signals investment — you're spending time specifically on this person
+
+the key word is *deliberate*. these weren't accidental encounters. i identified friction, decided to address it, and created opportunities for connection.
+
+## express, don't demand
+
+from a team experience: "best path is to just tell them how i'm feeling, don't ask for anything, and just keep working" (see [[feedback-and-honesty]]).
+
+the instinct is to demand change: "you need to do X differently." but that creates defensiveness. the alternative: share your experience without asking for anything. "i felt X when Y happened." then keep working. often, the other person adjusts on their own.
+
+## suspicion is poison
+
+suspicion makes team dynamics cooked. once you start assuming ill will, every action confirms your bias. the fix: "assume no ill will, assume fighting own battle" (see [[team-dynamics]]).
+
+## when repair isn't possible
+
+"picking the right people is very important, working with people you don't vibe with is tiring." sometimes the issue isn't fixable through repair — it's a fundamental mismatch. recognizing when to invest in repair vs. when to move on is its own skill.
\ No newline at end of file
new file mode 100644
index 0000000..0e84186
@@ -0,0 +1,88 @@
+---
+visibility: public-edit
+---
+
+# debugging hardware systems
+
+debugging software is annoying. debugging hardware is a completely different kind of pain. at the [[neurotech startup|signal-processing-workflow]], i learned this the hard way across multiple EEG headsets, sensor arrays, and experimental setups.
+
+## the headset saga
+
+we went through two EEG headsets over the summer. both had problems. the first one:
+- random packet loss (probably wifi interference)
+- some channels were dead or railed
+- accelerometer always reading something even when stationary
+- important channels railed even with conductive gel
+
+the second one:
+- getting alpha waves to work well was "really hard"
+- heartbeat was definitely being picked up
+- sensitivity to everything: movement, environmental noise, electrical interference
+
+"things are breaking down — channels are being railed, packets are being lost."
+
+## the debugging process
+
+### binary search
+
+"binary search for finding issues in hardware — literally do whatever." the most transferable debugging concept: isolate variables. when everything is broken, start cutting things in half until you find the problem.
+
+concretely:
+- test each channel independently
+- swap out the board (we tried a new cyton board)
+- move to different rooms to isolate electrical noise
+- test on different people
+- test with and without gel
+- check if the problem exists in the raw data or only after processing
+
+### the environment matters
+
+problems with current testing: "extremely sensitive. movement. environmental noise."
+
+things that affected signal quality:
+- wifi and bluetooth interference ("pretty chilling, have done it before" — meaning it could be worked around)
+- footsteps from other people in the room
+- electrical devices nearby
+- brightness of the room
+- how well the electrodes were seated
+
+fixing the environment often fixed the "hardware problem."
+
+### validate before trusting
+
+the most important lesson: validate your setup before running real experiments.
+
+- alpha band: close your eyes, you should see 8-13Hz activity. if you can't, something is wrong.
+- flash test: flash yourself and look for VEPs in the data. if you can't see them on yourself, you won't see them on anyone.
+- known signal: send a known electrical signal through the system and verify it comes out the other side correctly.
+
+"does have good alpha band testing" vs "does not have good alpha band testing" was the difference between a functional and a broken headset.
+
+### ask the symptoms, not the fix
+
+"ways to fix: ask LLM the symptoms, recheck wiring, common issues with EEG headsets, ask LLM for more ways to fix."
+
+the instinct is to google the fix. the better approach is to describe exactly what you're seeing (symptoms) and work backward to causes. "the accelerometer reads non-zero when stationary" is more useful than "EEG headset not working."
+
+## the multi-sensor setup problem
+
+for one experiment, we needed to put EEG, heart rate, pupilometry, temperature, and other sensors on a person simultaneously. new debugging challenges:
+
+- how do all the sensors fit on the person?
+- how to make them stable on the person?
+- how to put them all on quickly?
+- data sync: each device has its own clock. getting timestamps aligned is its own project.
+
+"can't get the data — whoop not connected, oura only nighttime, empatica not connected for some reason." consumer wearables are especially frustrating because you can't control their firmware or data export.
+
+## transferable lessons
+
+1. **hardware problems are usually environment problems.** the device is fine; the setup is wrong.
+2. **binary search everything.** when in doubt, cut the problem space in half.
+3. **validate the simple case first.** if you can't measure a strong, well-known signal, you definitely can't measure a subtle one.
+4. **patience is a technical skill.** software iteration takes seconds. hardware iteration takes hours (set up, run, wait, analyze, tear down, modify, repeat).
+5. **document obsessively.** which channels, which settings, which room, which time. when you finally get it working, you need to know what changed.
+
+---
+
+*see also: [[signal processing workflow|signal-processing-workflow]], [[experiment design|experiment-design]], [[work sessions|work-sessions]]*
\ No newline at end of file
new file mode 100644
index 0000000..5d58429
@@ -0,0 +1,95 @@
+---
+visibility: public-edit
+---
+
+# how emotions cloud work and how to manage them
+
+this might be the most honest page in the wiki. across months of daily reflections, a clear pattern emerged: emotions were the primary bottleneck to productive work. not skills, not time, not resources — emotions.
+
+## the annoyance/unworthy pattern
+
+"annoyance + unworthy emotions clouding work."
+
+concrete examples from the startup:
+- a coworker trying to control my workflow → annoyance → couldn't focus
+- another coworker suggesting paths i disagreed with → defensiveness → lost an hour
+- feeling devalued after a bad day → fear → overcorrecting and trying too hard
+
+"kinda dumb, especially dumb in the perspective of work. should not let them control me."
+
+the breakthrough: "great that i'm catching them. articulating a lot of the feelings." just naming the emotion was often enough to defuse it. "low energy so will go reset" — simple, no drama.
+
+## the fear cycle
+
+fear was the most destructive emotion for work quality:
+
+- fear of being seen as incompetent → overworking on unimportant tasks to look busy
+- fear of losing position → comparing to others instead of focusing on growth
+- fear of being fired → desperately trying to prove myself instead of doing good work
+
+"have feelings of wanting to prove myself. felt that i quickly devalued in your eyes → very afraid."
+
+the CEO's response was clarifying: "fears can be vague and murky or clear. clear is good to act on. vague and murky is often irrational, thus bad to act on."
+
+rational version of the fear: "if they don't think i am capable, they won't let me do important things." solution: do good work. irrational version: "i'll fail and get really fucked up." solution: notice it's irrational and let it go.
+
+## the overwhelm problem
+
+"all the new ideas feel a bit overwhelming." at the startup, i was getting bombarded with new frameworks, feedback, philosophical ideas, and work tasks simultaneously. the response was often paralysis or unfocused activity.
+
+"not reflecting enough. clearly important things that are important to think about. spent like 30s reflecting and generated two really important insights... really cooked on things that feel good recently and not at all focused on the important stuff."
+
+the fix: mandatory extended reflection time (45 minutes, spread throughout the day). structured questions:
+- how intentional was i?
+- what could i have done better?
+- generalizations / lessons learned?
+
+without this structure, reflection defaulted to rumination, which is worse than no reflection.
+
+## emotions that helped
+
+not all emotions were obstacles. some were fuel:
+
+### the "life is beautiful" state
+
+"fundamental truth: life is beautiful." the CEO would say this and it wasn't new-age fluff — it was a genuine emotional state that produced better work. when i was in gratitude and appreciation mode, focus came naturally.
+
+### the urgency spark
+
+"being more aggressive and urgent usually yields more output." urgency — not anxiety, but genuine wanting-to-build energy — was the best emotional state for deep work. the trick was generating it without the fear that usually accompanies it.
+
+"at the ends [of the internship] i was very excited about doing stuff. it can be good because it makes people reflect and have urgency to act."
+
+### the learning high
+
+"learning was also fun. bro i could do this all day every day." genuine curiosity and the pleasure of understanding something new was the most sustainable emotional fuel. better than caffeine, better than pressure, better than deadlines.
+
+## managing the emotional layer
+
+### emotional fluidity
+
+for a period, my daily focus was "emotional fluidity" — the ability to move through emotions rather than getting stuck in them. "tackle head-on undesired emotions. be authentic."
+
+practically: "more meditation in the moment to figure out what we really want, instead of just for relaxing. e.g. went outside and did nothing for a bit, realized my mouth was sour and i wanted water." sometimes the emotion is just a signal for a simple physical need.
+
+### the separation of work and feelings
+
+"why is thinking about working and actually working so disconnected?" this question from a reflection captures the core problem. i could think about work all day and feel productive without doing anything. conversely, i could do great work while feeling terrible.
+
+the insight: feelings about work and the quality of work are separate variables. both matter, but confusing them is dangerous. feeling productive is not being productive. feeling unproductive is not being unproductive.
+
+### the reset toolkit
+
+when emotions are clouding work, the hierarchy of resets:
+1. name the emotion (30 seconds)
+2. go outside, walk, cold water on face (5 minutes)
+3. cold shower (15 minutes)
+4. exercise or physical activity (30 minutes)
+5. talk to someone about something unrelated (flexible)
+6. sleep on it (last resort but often the best)
+
+"chilling out and thinking about something different can help get rid of the persistent emotion. overload into certain activities due to certain stressful events; can help see the bright side of things as well."
+
+---
+
+*see also: [[mindset shifts|mindset-shifts]], [[energy hacks|energy-hacks]], [[pattern recognition|pattern-recognition]]*
\ No newline at end of file
new file mode 100644
index 0000000..d53f88b
@@ -0,0 +1,97 @@
+---
+visibility: public-edit
+---
+
+# how to design tests, iterate, and ensure robustness
+
+from running dozens of experiments at a [[neurotech startup|signal-processing-workflow]] — on brains, on hardware, on signals — i developed a sense for what separates experiments that produce useful data from experiments that produce noise.
+
+## the experiment design framework
+
+### define what you're measuring before you start
+
+the most common failure: "not insanely intentional with testing. could do much better with understanding what is going on and for what reason."
+
+concretely, before any test:
+- what signal am i looking for?
+- what would success look like in the data?
+- what would failure look like?
+- what are the confounds?
+
+for our visual evoked potential tests, the checklist was:
+- one eye (monocular)
+- fixate on central target
+- dark room
+- 70-100cm from screen
+- consider contrast
+- which test type (pattern reversal at 2Hz, onset/offset, flash)
+
+### control one variable at a time
+
+we made the mistake of changing multiple things between tests — new stimulus pattern AND new filtering AND new electrode placement. when results changed, we couldn't tell why.
+
+the better approach: "do something to get a VEP on myself first." test the simplest possible case. if that doesn't work, the problem is fundamental. if it does work, add complexity one variable at a time.
+
+### the validation ladder
+
+from simplest to most complex:
+1. can you see alpha waves with eyes closed? (if no, hardware is broken)
+2. can you see a response to a flash on yourself? (if no, timing or processing is broken)
+3. can you see a response on another person? (if no, setup or parameters might be off)
+4. can you reproduce results on a second trial? (if no, noise is too high)
+5. can you see differences between conditions? (this is the actual experiment)
+
+skipping to step 5 without passing steps 1-4 was a mistake i made repeatedly.
+
+## iteration patterns
+
+### the research → test → analyze loop
+
+"lots of iteration. lots of failure." the actual workflow:
+1. research: read standards, look at what parameters others use
+2. set up: configure hardware, write stimulus script, prepare environment
+3. run: execute the test, usually 15-45 minutes
+4. analyze: process data, plot, look at results
+5. interpret: is this real signal or noise? compare to expected results.
+6. adjust: change one parameter and go back to step 3
+
+steps 3-6 repeat dozens of times. "tested checkerboard on myself, tried flash on myself, tried checkerboard on another person, old stuff was all noise."
+
+### when to pivot vs persist
+
+"just check differences and try to maximize it" vs "maybe they are just good, we are reasonably satisfied." the tension between perfectionism and pragmatism.
+
+heuristic: if you've tried 5 different parameter combinations and none work, the problem is probably not the parameters. step back and question the approach.
+
+"tried many training things, didn't do much" — knowing when to pivot to a completely different method rather than tweaking the current one.
+
+## the timing problem
+
+timestamp synchronization was a recurring nightmare. each device (EEG headset, stimulus presentation, sensors) has its own clock. getting them aligned:
+
+- tried using a wire to send sync pulses — "doesn't work because it sends a pulse that is picked up by the headset in a huge spike"
+- tried software timestamps — "current script might not be using some settings that are important"
+- tried logging approach — eventually worked but required careful validation
+
+"need to get correct times" — without precise timing, epoch-averaging is meaningless. this is an unsexy but critical part of [[experiment design|experiment-design]] that textbooks don't emphasize enough.
+
+## designing for robustness
+
+### the subject experience
+
+"if want longer tests, distraction — brain not focusing." for human experiments, the subject's experience matters:
+- boredom causes attention drift
+- watching videos might confound the signal (occipital lobe activation, pupil changes from brightness)
+- need to balance test duration with data quality
+
+"how to have them not be bored? video? inscapes might not be bad — could confound occipital lobe, could affect pupils due to brightness."
+
+### the engineering gamble
+
+sometimes you have to make a call with incomplete information. "data analysis stuff: hard because big data, for robustness can't really use LLMs that much."
+
+the meta-skill: knowing when you have enough data to make a decision vs when you're just pattern-matching on noise. "interpreting graphs — sometimes good but looks bad, sometimes bad but looks good. need to balance time scrutinizing graph and writing script."
+
+---
+
+*see also: [[signal processing workflow|signal-processing-workflow]], [[debugging hardware|debugging-hardware]], [[reading papers|reading-papers]]*
\ No newline at end of file
new file mode 100644
index 0000000..a4e7003
@@ -0,0 +1,83 @@
+---
+visibility: public-edit
+---
+
+# how to read and extract value from papers
+
+this is maybe the most repeated lesson in my notes across both the startup internship and later research work: read more. "literally read more — so repeated it should be instinctual at this point."
+
+## the pattern of not reading enough
+
+"for [two different research projects], both did not do enough reading." the failure mode was always the same:
+1. get excited about a problem
+2. start building/coding immediately
+3. hit a wall because i didn't understand the fundamentals
+4. realize i should have spent 2 days reading before writing a line of code
+5. go back and read
+6. realize the approach was wrong from the start
+
+"the way to do research and also learn is to spend 1-2 months reading up on a topic and become an expert, then go do the thing."
+
+## what to read for
+
+when entering a new research area, the questions to answer before doing anything:
+
+- what are each of the things that experienced people in this area are talking about?
+- what are the things that people have done already?
+- what is the state of the art?
+- what are the big weaknesses of current approaches?
+- how do the fundamental methods even work?
+- what have other people tried? did it work? why or why not?
+- is the problem even that important? sometimes the thing you think is the hard part has already been solved.
+
+from working on signal processing: i could have saved weeks if i'd spent 3 days reading ISCEV standards and MNE documentation before trying to hand-code everything.
+
+## how to actually read
+
+### the standard approach
+
+for VEP research, the useful reading order was:
+1. the clinical standard (ISCEV standard for VEPs)
+2. a textbook chapter or review paper
+3. 3-5 recent papers using the method
+4. documentation for the tools (MNE, scipy signal processing)
+
+the standard gave me the parameters. the textbook gave me the theory. the papers gave me the gotchas. the docs gave me the implementation.
+
+### reading vs doing
+
+there's a tension. "valuable to in these days be able to learn" vs the pressure to produce results. the resolution: reading IS doing. it's the highest-leverage work early in a project.
+
+"generally when hitting a thing, read / research. bias towards learning. will do it so much better." — the bias should be toward understanding before acting, especially early on.
+
+### active reading
+
+passive reading (skimming papers while eating) doesn't count. the useful reading was:
+- taking notes on key findings
+- connecting to what i already knew
+- questioning whether the conclusions applied to my specific setup
+- trying to reproduce key results before building on them
+
+## the LLM problem with reading
+
+"every time you use LLMs a lot you fall into a pitfall." LLMs are great for getting a quick overview but dangerous for deep understanding. they'll give you a plausible summary that's subtly wrong in ways that only matter when you're actually implementing.
+
+the failure mode: ask chatgpt what parameters to use for EEG filtering, get a reasonable answer, use it, get bad results, not understand why because i never read the actual standard that explains the reasoning behind the parameters.
+
+LLMs for research reading: good for "explain this concept simply" and "what are related topics." bad for "what parameters should i use" and "is this result good."
+
+## the research → implementation bridge
+
+"read then implement → become crazy good. stay centered."
+
+the bridge between reading and doing:
+1. read until you can explain the approach to someone who doesn't know the field
+2. implement the simplest version first
+3. validate against known results
+4. iterate and extend
+
+skipping step 1 was my most common mistake. skipping step 3 was my most expensive mistake.
+
+---
+
+*see also: [[signal processing workflow|signal-processing-workflow]], [[experiment design|experiment-design]], [[learning from experience|learning-from-experience]]*
\ No newline at end of file
new file mode 100644
index 0000000..896db79
@@ -0,0 +1,69 @@
+---
+visibility: public-edit
+---
+
+# EEG/signal processing approach at a neurotech startup
+
+over a summer internship at a neurotech startup, i went from knowing nothing about EEG to running signal processing pipelines, debugging hardware, and designing experiments. this is the workflow that emerged — not textbook-clean, but real.
+
+## the problem space
+
+we were trying to detect and measure brain responses to stimuli — visual evoked potentials (VEPs), event-related potentials (ERPs), and various other signals. the core challenge: EEG data is incredibly noisy, and the signals we cared about are tiny.
+
+key signal types:
+- **VEPs**: brain response to visual stimuli (checkerboard patterns, flashes). key peaks at N75, P100, N145.
+- **ERPs**: brain response to any stimulus (visual, audio, motor). P300 was the easiest to detect.
+- **alpha waves**: oscillations in the 8-13Hz range, measurable with eyes closed.
+- **frontal alpha asymmetry**: difference in alpha power between left and right frontal regions.
+
+## the processing pipeline
+
+### filtering
+- bandpass filter: 1-100Hz (sometimes 0.1-10Hz or 0.8-100Hz depending on what we were looking for)
+- notch filter at 60Hz for electrical noise
+- tried both hand-coded and library implementations (MNE)
+
+### artifact handling
+- blinks and movements were the biggest contaminants
+- MNE had artifact rejection tools but getting them working was non-trivial
+- environmental noise: footsteps, electrical devices, even heartbeats were picked up
+- "others' movements — it picks up on footsteps. your movements — move your head slightly and it messes up the data"
+
+### epoch averaging
+- average over 100-200 trials per stimulus to improve signal-to-noise
+- "if our data were perfect we wouldn't have to do this but it's chill"
+- considered z-score averaging to preserve relative magnitude in spiking
+
+### plotting and analysis
+- filtered data overlaid with stimulus timestamps
+- FFT / power spectral density
+- averaged responses over epochs
+- peak detection (automated and manual)
+
+## what i actually learned
+
+### implementation approaches (ranked by usefulness)
+1. **library + vibe coded (MNE)**: most robust, best artifact handling
+2. **hand coded**: bin average, rolling average — good for understanding what's happening
+3. **fully vibe coded**: interpolation lines, rolling averages — sometimes produced plausible but wrong results
+
+### the LLM trap
+"data analysis is hard because: big data, for robustness can't really use LLMs that much, every time you use them a lot you fall into a pitfall that makes you cooked."
+
+this was a hard lesson. LLMs are great for boilerplate code but terrible for signal processing decisions. they'll confidently suggest parameters that produce clean-looking but meaningless results. had to learn to [[read papers|reading-papers]] and understand the actual science.
+
+### the iteration loop
+"lots of iteration. lots of failure. graphs that don't look right, code that doesn't work. need to get correct times. interpreting graphs — sometimes good but looks bad, sometimes bad but looks good."
+
+the workflow was: write script → run → look at output → realize something is wrong → research → fix → repeat. "writing script robustly actually takes time" — couldn't just hack something together and move on.
+
+## the current testing procedure (by the end)
+
+- conditions: one eye, fixate at center, dark room
+- data processing: bandpass from [0.1, 0.8]Hz to [10, 100]Hz, notch at 60Hz
+- plot: filtered data with stimuli, FFT, averaged over epochs
+- validation: alpha band testing, self-testing with flashing
+
+---
+
+*see also: [[debugging hardware|debugging-hardware]], [[experiment design|experiment-design]], [[reading papers|reading-papers]]*
\ No newline at end of file
new file mode 100644
index 0000000..db61baf
@@ -0,0 +1,33 @@
+---
+visibility: public-edit
+---
+
+# research workflow
+
+how to approach research problems. the process i've refined through various technical projects.
+
+## the process
+
+1. **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.
+2. **find an interesting technical problem** — something that excites you, not just something that sounds impressive. excitement sustains [[perseverance]].
+3. **start reading hella** — once you have a direction, go deep. papers, implementations, discussions.
+4. **build understanding** — "start with good understanding & foundation." the investment in understanding pays compound returns.
+5. **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.
\ No newline at end of file
new file mode 100644
index 0000000..ca1ad93
@@ -0,0 +1,55 @@
+---
+visibility: public-edit
+---
+
+# resets
+
+the full toolbox for getting back to baseline, organized by state.
+
+## anxious / sad / jealous / unconfident
+
+1. go through what's making you feel that way — name it specifically
+2. appreciation — look at what you have, what's going well (see [[gratitude-and-appreciation]])
+3. look at your own achievements — not for validation, but for evidence that you're capable
+4. → confidence
+
+the sequence matters. you can't skip to "just be confident" — you have to process the feeling first, then build back up. this maps to Joe Hudson's welcoming practice: feel the emotion fully before trying to move past it. see [[confidence]].
+
+## tired
+
+- cyclic hyperventilation (box breathing variant — intense)
+- sustained exercise (10+ minutes — needs to be sustained, not just a quick stretch)
+- breathwork
+- bathroom / wash hands (the physical reset — cold water, change of sensation)
+- nap
+- hang upside down (bloodflow to the brain — sounds weird, works)
+- talk with people
+- reflecting — staring into space (different from [[zooming-out]] — this is more passive, letting your mind wander)
+- reflecting — looking at past notes
+
+## itchy / hot / physically uncomfortable
+
+- shower — drench head in cold water specifically
+- change or remove clothes
+- take off glasses / earbuds (remove sensory input)
+- go outside and breathe
+
+## general (works for most states)
+
+- eat fruit
+- blast music in ears
+- look back at old notes
+
+## the meta-lesson
+
+most of these resets are physical. when your mental state is cooked, changing your physical state is usually faster and more reliable than trying to think your way out. the body leads the mind.
+
+the exception is the anxious/sad category, where the reset IS mental — processing the emotion, [[gratitude-and-appreciation|appreciating]], building [[confidence|evidence for confidence]].
+
+## when to reset vs. when to push through
+
+see [[perseverance]]. sometimes the right move is to reset. sometimes it's to push through the discomfort. the test: is the discomfort from the work being hard (push through) or from your state being degraded (reset)?
+
+## in the moment
+
+"in the moment, do what is right, and have the willpower to do what is right." resets aren't about running from work — they're about restoring your capacity to do the work well.
\ No newline at end of file
new file mode 100644
index 0000000..d0923c1
@@ -0,0 +1,30 @@
+---
+visibility: public-edit
+---
+
+# resyncing
+
+communication patterns for staying aligned with teammates.
+
+## core principle
+
+meet often, be as synced as possible. many times everyone's instinct is to split things up equally — feels bad because sum of parts equals whole, just multiprocessing but worse. the alternative: resync often so you're actually building on each other's work.
+
+## tools
+
+### sync meetings
+structured check-ins where you present findings, discuss next steps, argue without getting personal. at the neurotech startup, we had Tuesday morning "takeoff" meetings to sync on state. see [[startup-workflow]].
+
+### high-bandwidth communication
+articulating every piece of meta-data you observe from the other person. this sounds exhausting but it's the CEO's concept — most misinterpretations come from not sharing enough of what you're seeing. often we're wrong about what we think the other person is thinking, and only by articulating it do we find out.
+
+### "short circuit"
+a communication tool that means either:
+- "i don't know what you mean" — stop, rewind, explain differently
+- "discussing this doesn't matter right now; let's just do the thing"
+
+this is incredibly useful for cutting through circular arguments or confusion. instead of nodding along or getting frustrated, you just say "short circuit" and the conversation resets.
+
+## the split-up problem
+
+at school, sometimes i look down on people and try to do a lot of work myself. at the neurotech startup i saw how this backfired — the best output came from high-bandwidth collaboration, not from siloing off and grinding alone. the better move is to invest in [[team-dynamics]] and work together, not to silo.
\ No newline at end of file
new file mode 100644
index 0000000..8f24d64
@@ -0,0 +1,35 @@
+---
+visibility: public-edit
+---
+
+# software workflow
+
+think first, types first, then implement. learned from a teammate at a neurotech startup.
+
+## the process
+
+1. do a LOT of thinking and iterating on a base idea
+2. work through types and function types
+3. design UX and frontend-backend connections
+4. use flowchart tools and whiteboards for planning
+5. *then* implement
+
+the key is step 1 — spending serious time on the idea before writing any code. this feels slow but saves enormous time. "start with good understanding & foundation — right now not spending much effort and still going great because just have great understanding."
+
+## thinking before building
+
+this connects to [[zooming-out]] — spending time thinking about a problem gets insights you miss while tunneled. the software workflow makes this structural: you can't start coding until you've thought through the types.
+
+types are the skeleton. once you have the types right, the implementation almost writes itself. function signatures, data shapes, API contracts — get these right and the rest follows.
+
+## prototyping
+
+"prototyping is so great." but prototyping and the think-first workflow aren't contradictory — you prototype the *idea*, not the code. sketch it out, iterate on paper or whiteboard, then prototype in code with a clear picture of what you're building.
+
+## presenting your work
+
+"presenting went not the best because didn't prep." even great software needs to be communicated well. prep for demos. "having a pretty cool thing to show off and demo is very powerful" — invest in making your work presentable.
+
+## MVPs
+
+"bouncing ideas off people is such a good experience." show, don't tell. an MVP beats a pitch deck. this connects to the [[electronics-workflow]] breadboard-first approach — get something working, then show people.
\ No newline at end of file
new file mode 100644
index 0000000..64a9245
@@ -0,0 +1,43 @@
+---
+visibility: public-edit
+---
+
+# sources and methodology
+
+where this wiki's content came from and how to find more.
+
+## sources
+
+### neurotech startup internship (summer 2025)
+Apple Notes reflections from a summer interning at a neurotech startup. the richest source — covers workflow, mentality, team dynamics, impostor syndrome, and the operational patterns that became [[startup-workflow]].
+
+these notes were raw and unstructured. the best insights came from re-entry reflections (see [[startup-workflow]]) and personal processing notes written late at night.
+
+### IdeaFlow reflections (feb-apr 2026)
+100+ #reflection entries and 47 #operation entries from IdeaFlow. these cover the period after the internship — applying lessons learned, finding new ones, and dealing with the meta-problem of [[operation-optimization]].
+
+most useful: the #operation entries, which capture real-time observations about how i'm working. #reflection entries are more polished but sometimes less honest.
+
+### other Apple Notes
+scattered reflections from math competitions ([[team-dynamics]]), vibe coding sessions ([[vibe-coding]]), and general life processing. less structured than the other sources but contain some of the rawest insights.
+
+### moonflowers.xyz
+published notes on [moonflowers.xyz](https://www.moonflowers.xyz/notes). the [[modeling]] page draws directly from [a published note on modeling](https://www.moonflowers.xyz/notes/mDl1nG_N0t3-on-modeling). other relevant published pieces include [a note on optimized learning](https://www.moonflowers.xyz/notes/mWCmDjrZH--a-note-on-optimized-learning), poorly vibe coded apps, [operation big items](https://www.moonflowers.xyz/notes/YWtzu4HKbA-operation-big-items), rejection & connection, [reset options](https://www.moonflowers.xyz/notes/reset_options), and quotes.
+
+### Joe Hudson / Art of Accomplishment
+concepts from [Joe Hudson's work](https://www.artofaccomplishment.com/) — the welcoming practice, inner critic vs. inner mentor, confidence from self-acceptance. these influenced [[confidence]], [[gratitude-and-appreciation]], and [[impostor-syndrome]].
+
+### direct experience
+some content (like [[resets]]) comes from strategies developed through direct experience and refined over time, not from any single source.
+
+## how to search these sources
+
+- **Apple Notes**: search by keyword, but also browse by date — context matters
+- **IdeaFlow**: search #reflection and #operation tags. chronological browsing is useful.
+- **moonflowers.xyz**: browse [the notes section](https://www.moonflowers.xyz/notes)
+
+## what was most useful
+
+the startup internship notes were by far the richest source. the combination of structured reflection (re-entry format) and unstructured processing (late-night notes) produced the deepest insights. the IdeaFlow entries are useful for the post-internship evolution of these ideas.
+
+the CEO's reflections (shared with the team) were surprisingly valuable — they provided frameworks (efficiency vs. productivity, energy expenditure, being forceful) that reframed my own experience.
\ No newline at end of file
new file mode 100644
index 0000000..d355d57
@@ -0,0 +1,58 @@
+---
+visibility: public-edit
+---
+
+# startup workflow
+
+the operational patterns from a neurotech startup i interned at. a "perpetual state of hackathon."
+
+## weekly cadence
+
+### tuesday morning — takeoff
+sync on state. everyone gets aligned on what's happening, what needs to happen. this is [[resyncing]] made structural.
+
+### monday night — re-entry
+the most structured ritual. format:
+1. conclude work at 6:30pm
+2. 30 minutes solo reflection with pen and paper
+3. group report: context → what you set out to do → how you performed → what each member could've done better
+
+the solo reflection before group reporting is key — you need to process your own week before you can communicate it. slides required. always have a growth number.
+
+## the growth number
+
+"if we didn't have any of the position we gained this week, how much faster could we have gained it with all the skills we learned?"
+
+this measures learning velocity, not output. a week where you shipped nothing but learned a lot still gets a high growth number. this connects to [[impostor-syndrome]] — "acceleration is much better than position."
+
+## subteams
+
+- **science** — research, testing
+- **engineering** — products
+- **growth** — people development, habits, zoom outs (see [[zooming-out]])
+
+the fact that "growth" is a dedicated subteam, not an afterthought, says a lot about this startup's culture.
+
+## 80-15-5 rule
+
+- 80% mission-focused work
+- 15% slightly tangential exploration
+- 5% something completely whacky
+
+this prevents the monotony that kills creativity and [[intentionality]]. it also means the [[critical-path]] question doesn't strangle serendipity.
+
+## speed of decision-making
+
+"anything under $500 don't ask me." this removes friction and empowers people. the cost of slow decisions often exceeds the cost of wrong ones at this scale.
+
+## energy philosophy
+
+"expending more energy frequently works." evolution optimized us to save energy — there's no reason to conserve it anymore. this is counterintuitive but matches my experience: the times i've pushed harder than felt natural, i've gotten more than proportionally more out.
+
+## knowledge stacking
+
+the CEO envied friends who just knew more. started aggressively learning via LLMs. "knowledge is super useful" — not a groundbreaking insight on its own, but the action (aggressive learning) is what matters.
+
+## being forceful
+
+"in pursuit of open-mindedness, was too passive in arguments." fix: be forceful in exchanging ideas, trust the other party not to collapse. this connects to [[feedback-and-honesty]] — honest friction is productive.
\ No newline at end of file
new file mode 100644
index 0000000..f31a8ef
@@ -0,0 +1,64 @@
+---
+visibility: public-edit
+---
+
+# framing and narrative: how you describe things changes what they are
+
+this kept coming up across conversations, reflections, and ideaflow notes. the way you frame something — to others and to yourself — isn't just marketing. it changes the actual experience and outcomes.
+
+## the reframe discovery
+
+"perspective switch for optimism is so real. always look for it."
+
+the startup founders modeled this constantly. hardware broke? "now we know what not to do." bad test result? "we learned something." intern struggling? "making mistakes and growing."
+
+at first this felt like cope. then i realized it was a genuine cognitive skill.
+
+## branding yourself
+
+"branding really important. write about projects, speak about projects, make videos about projects. good way to attract attention: talk about coolest projects."
+
+how you introduce yourself matters. the evolution:
+- bad: "i'm a high school student"
+- better: "student, experience in X, testing out some ideas related to Y"
+- best: just have something impressive to show. "having a pretty fucking cool thing to show off and demo is very powerful. go make that thing."
+
+a mentor's advice: "be accurate. right now 'high school student' is chill. don't introduce yourself as high school though — it's reasonable that people don't want to talk to you." the framing isn't lying — it's choosing which true things to emphasize.
+
+"being technical is crazy good. effortlessly impress." the best brand is just being genuinely capable and letting it show naturally.
+
+## the narrative trap
+
+"in one framing, dropping out and doing a startup is crazy good — have the skills, success, learn, meet people. in another it's hella scary — dropping out of school, leaving everything behind, uncertain trajectory."
+
+both framings are equally true. the one you adopt determines your actions. this isn't self-deception — it's recognizing that reality is complex enough to support multiple honest narratives, and you get to choose which one drives your behavior.
+
+but: "it is so easy to get fooled by hype." framing can also be a trap when someone else is doing it. a mentor calling something "revolutionary" doesn't make it revolutionary. "ai assistant is only good in theory but in practice many things suck."
+
+the skill is deploying good framing for yourself while maintaining skepticism about others' framing.
+
+## framing for communication
+
+"need to frame feedback / thoughts well. important to say them but also need to deliver them humanly and accurately."
+
+from navigating a difficult team situation: "many instincts for things to say (to be logical) but tried empathy & validation and that seemed to work well." the strategy:
+1. state my needs
+2. frame it as "we are working together"
+3. expand the state of possible outcomes
+4. find framings that aren't hurtful — "hurtful framings exist but they are never the only framing"
+
+## the articulation effect
+
+"if something is articulated better, i remember it and its importance more, and then i think about it more." this is the most practical insight about framing: writing something down well literally makes it more real in your brain.
+
+"whenever i get inspiration for something being good i should articulate it well to remember it." the act of finding the right words for an experience doesn't just describe it — it solidifies it.
+
+this is why the [[daily reflections|learning-from-experience]] worked: not because reviewing notes was useful (though it was), but because the act of articulating what happened forced me to actually understand it.
+
+## framing for motivation
+
+more nuanced version from the startup CEO: "greatest thing that can happen to someone is alignment of pleasure and goals. spend more time trying to align them." the ultimate framing challenge isn't making bad things seem good — it's restructuring your actual values so that what you want to do and what you should do converge.
+
+---
+
+*see also: [[mindset shifts|mindset-shifts]], [[social strategy|social-strategy]], [[disagreeing productively|disagreeing-productively]]*
\ No newline at end of file
new file mode 100644
index 0000000..3fcc6a7
@@ -0,0 +1,84 @@
+---
+visibility: public-edit
+---
+
+# habit formation: what actually stuck
+
+over the course of many months, i ran dozens of habit experiments. daily themes ("no swearing," "raise or fold," "emotional fluidity," "agenticism"), habit tracking apps, morning checklists, pause reminders. most failed. some stuck. here's what i learned about why.
+
+## the identity approach wins
+
+"i heard about the guy who was 'religious about his oral care' and now i kinda wanna be that person." the atomic habits insight that actually worked: habits stick when they're identity-based, not outcome-based.
+
+the habits that worked:
+- no video games (identity: "i'm someone who doesn't play video games")
+- no nail biting (identity: "i'm someone with good hands")
+- intentional reflection (identity: "i'm someone who reflects")
+
+the habits that didn't work:
+- "eat until not hungry" (outcome-based, no identity anchor)
+- "sleep early" (constantly failed because the identity — someone who sleeps early — didn't feel true)
+- "no youtube" (worked for a while, relapsed repeatedly)
+
+## the trigger-response pattern
+
+"how did 'keep health' work? understood more deeply that it is something i want. whenever that comes up, do it — kinda like the nail biting / scratching thing: whenever it comes up and you realize, don't do it. have faith in yourself that you will remember."
+
+the pattern: you don't need perfect compliance. you need a reliable response to the trigger. when you notice yourself reaching for the phone, that's the trigger. the habit is the response — put it down, not because of willpower, but because you've practiced the response enough times.
+
+"when doing habits, definitely don't be like 'yeah imma do it' and then wait to start or something. just do it right away to reinforce it and prove you actually care."
+
+## the daily theme experiment
+
+for months, each day had a theme printed at the top of my daily reflection:
+- "no swearing"
+- "raise or fold"
+- "emotional fluidity"
+- "agenticism"
+- "focus! control attention"
+- "learning objectives"
+- "reset & balance"
+- "discipline"
+- "mindfulness"
+
+results were mixed. the pattern: "basically just no planning, barely any checkins, and no conscious understanding of 'the thing to work on.'" the themes were set the night before with good intentions, then forgotten by 10am.
+
+the deeper problem: "with a lot of these kinds of things, i'm doing it just because it feels good. e.g. the night before i'll be like 'yo we should really lock in' and then go to sleep feeling satisfied, even though the job isn't done yet."
+
+## what made habits visible
+
+"visible — THIS IS THE HARD ONE. attractive — tell myself: there are so many lessons you've learned and noted down! ... often for perpetual things like these, visible is so hard because i focus so hard on things it's hard to just remember things."
+
+things that helped visibility:
+- phone lock screen messages
+- watch alarms at specific times
+- physical reminders (laptop stand = work mode)
+- morning checklists
+
+things that didn't help:
+- long lists of habits (overwhelming, ignored)
+- vague reminders ("be intentional" — too abstract)
+- apps (checked once, forgotten)
+
+## the system that emerged
+
+"new system for implementing mindsets: ok so we really care about this thing. small reminders — e.g. only trying to hit visibility, and don't even need that much. pretty simple lol."
+
+the final system was simpler than any of the previous attempts:
+1. pick ONE thing to work on
+2. make it visible (one line at the top of the daily note)
+3. check in at least once midday
+4. reflect on it at night
+5. keep the same thing for at least a week before changing
+
+the key insight: "should learn how to deal with [constant interruptions]. can't just rely on whole days to do things." habits need to work in the margins of a busy day, not require a perfect environment.
+
+## the relapse pattern
+
+"wow yt is crazy. now i've slept 2.5h past what i wanted to and i have a headache. work & life is pretty in control though! crazy how that happens."
+
+relapse is normal and doesn't erase progress. the habit of recovering from relapse is itself a habit worth training. "a principle is [try your best, not try to be perfect]. whenever catch myself doing the thing, do the right thing." the forgiveness is part of the system.
+
+---
+
+*see also: [[mindset shifts|mindset-shifts]], [[morning routines|morning-routines]], [[prioritization|prioritization]]*
\ No newline at end of file
new file mode 100644
index 0000000..a1b3d02
@@ -0,0 +1,70 @@
+---
+visibility: public-edit
+---
+
+# learning from experience: the reflection engine
+
+the single biggest meta-skill i developed was learning how to learn from what i was already doing. not from books or courses — from my own experience, reflected on systematically.
+
+## the reflection system
+
+at the startup, reflection was built into the culture. daily check-ins, weekly meetings, guided reflections. but the real system emerged after i left, when no one was making me reflect anymore.
+
+the daily reflection structure:
+- how intentional was i?
+- what could i have done better?
+- generalizations / lessons learned?
+
+the weekly reflection added:
+- review each day's notes
+- identify patterns across the week
+- extract 2-3 actionable changes for next week
+- track what i actually did vs what i planned
+
+"reviewing on weekly reflection is super good." the review step was the most important and most often skipped.
+
+## the experience-describing exercise
+
+"imagine someone else is telling me about a thing, or i am describing a thing from a bit ago that i don't remember. what would i want to know?"
+
+this reframe turned reflection from navel-gazing into information extraction. instead of "how did i feel about today?" the question became "if i were advising someone who just had this exact day, what would i tell them?"
+
+## what blocks learning from experience
+
+### the info-loss fear
+
+"i'm very sad if i can't know what happened in my past / what i did with my time. very much inner critic: 'bro you just wasted those x minutes.'"
+
+this fear led to over-documenting (writing down every little thing) and under-processing (never reviewing what was written). the fix: shorter notes, more review. quality of reflection beats quantity of recording.
+
+### the "feeling productive" trap
+
+"with a lot of these kinds of things, i'm doing it just because it feels good. sending someone an email is basically equivalent to finishing the task. start training models overnight = done for the day."
+
+the feeling of having done something productive — planning, sending a message, starting a process — often replaced actually learning from the experience. the reflection became a checkbox rather than a learning moment.
+
+### not enough reading
+
+"for both projects, did not do enough reading." experience alone isn't enough. learning from experience works best when combined with learning from others' experience (papers, books, conversations). the synthesis is where the real insights live.
+
+## what accelerated learning
+
+### talking as reflection
+
+"talking to others as a form of reflection" — explaining what i was working on to someone who wasn't involved often surfaced insights i couldn't get alone. "bouncing ideas off people is such a good experience."
+
+the act of translating internal experience into language forces clarity. things that seem clear in your head reveal their contradictions when you try to say them out loud.
+
+### the pattern: work hard, put it down, come back
+
+"very much a pattern where i work really hard on something, put it down, come back, have so many ideas/insights." the subconscious processing during breaks was real and reliable. the mistake was trying to force insights during the work session instead of trusting that they'd come during the walk home.
+
+### doing random things and possibly failing
+
+"doing random things and possibly failing is very good because you have potential for crazy good." the explore/exploit tradeoff in practice. structured learning has diminishing returns. sometimes the best learning comes from trying something completely new without a plan.
+
+a friend at a startup: "spend 2 weeks grinding some bio problem, then pivot to EE, then pivot to physics. learn to learn. connections between random stuff makes learning much faster and better."
+
+---
+
+*see also: [[the stocks metaphor|the-stocks-metaphor]], [[reading papers|reading-papers]], [[mindset shifts|mindset-shifts]]*
\ No newline at end of file
new file mode 100644
index 0000000..ce7b760
@@ -0,0 +1,65 @@
+---
+visibility: public-edit
+---
+
+# prioritization: raise or fold
+
+the single most impactful framework i've adopted. it came from daily reflections around october 2025 and stayed because it actually worked.
+
+## the core idea
+
+"applying raise or fold means putting more effort into the things that matter and zero effort into the things that don't." no in-between. the middle ground — doing everything at 50% — is the worst possible strategy because you get mediocre results everywhere and great results nowhere.
+
+before every action: stop, ask "does this thing matter?" (maybe 20 seconds), then proceed with one choice. full commitment or full abandonment.
+
+## why this was hard
+
+i had a deeply ingrained habit of saying yes to everything. "mtfc was very much a yes brain mistake — stop saying yes to everything unconditionally." every opportunity felt important because each one had some upside. but the aggregate cost of many small commitments was devastating:
+
+- "very sad that i'm not able to do things — made a lot of commitments and can't fulfill all of them"
+- "projects with all the weird dynamics take up a lot of brain space. not having to think about it allows me to think about other more important things. it's even more detrimental than just losing time — brainspace is valuable."
+
+## what i dropped
+
+the liberating part of raise or fold was the dropping:
+- not doing extra athletics weight room
+- considering ditching competitions
+- not applying to a bunch of opportunities
+- not going to certain events
+
+"kinda liberating. don't always have to do everything. gives me more confidence and more freedom to select for the more important things."
+
+## what i raised
+
+when i raised, i went all in:
+- "couple day sprints to do crazy things are really great" — dedicating 2-3 full days to one project
+- one goal per day instead of fifteen
+- full focus blocks: "nothing but that one thing and reflection on it, constant thinking about it"
+
+## the intentionality connection
+
+raise or fold is really an extension of [[intentionality|agency-talk]]. the startup's framing was:
+
+"even if stuff is mundane and boring — what can you maximally get out of it? always be thinking about the goal and how best to reach it."
+
+example: interviewing people who seemed unimpressive. the fold option is to phone it in. the raise option: "i can get better at interviewing people. i'll learn from this."
+
+constantly optimize. but optimize what you're doing, not just how you're doing it.
+
+## the planning prerequisite
+
+raise or fold doesn't work without knowing what matters. "if it's important, plan more. if it's not important or you have tons of experience, don't need to."
+
+the planning failure mode: "i listed a couple of vague items that would be cool to do, and then kinda just went off doing other things. no sense of importance for certain things over others. no sense of scheduling."
+
+the fix: every morning, answer one question. what is the most important thing i can do today? everything else is either a raise-on-the-side or a fold.
+
+## the discomfort signal
+
+"say fuck no to unnecessary comfort and unintentionality." comfort-seeking is usually a signal that i'm folding on something important. the urge to scroll, eat, chat — it's the monkey asking to take the wheel (see [[mindset shifts|mindset-shifts]]).
+
+the practice: when i feel the pull toward comfort, that's the moment to raise. not through willpower — through reminding myself what i actually want.
+
+---
+
+*see also: [[the agency talk|agency-talk]], [[work sessions|work-sessions]], [[habit formation|habit-formation]]*
\ No newline at end of file
new file mode 100644
index 0000000..80617cb
@@ -0,0 +1,53 @@
+---
+visibility: public-edit
+---
+
+# sleep strategy
+
+the single hardest part of falling asleep is the mind refusing to stop. thinking about tomorrow, replaying today, planning, worrying, looping. the body is ready but the brain wont shut up.
+
+## the body scan breath technique
+
+this is what actually works for me. every breath, i pick one specific point of contact between my body and the bed and focus entirely on the physical sensation there.
+
+- breath 1: my right hand. the weight of it, the texture of the sheet against my palm, the temperature.
+- breath 2: my right elbow pressing into the mattress. the pressure, the warmth where skin meets fabric.
+- breath 3: the back of my head against the pillow. the way it sinks in slightly.
+- breath 4: my left ankle. the specific feeling of the blanket draped over it.
+
+the trick is specificity. not "my hand" but "the exact feeling of my ring finger resting against my middle finger." not "my shoulder" but "the point where my shoulder blade makes contact with the mattress."
+
+why this works: it forces the mind into the present. you literally cannot think about tomorrow while simultaneously paying attention to the specific pressure of your right elbow against the bed. the future and past require abstraction. physical sensation is immediate. every time the mind drifts to planning or worrying, the next breath pulls it back to a specific body part.
+
+this is more effective than counting sheep or breathing exercises because those are repetitive enough that the mind can do them on autopilot while still worrying. the body scan requires genuine attention — each point is different, each sensation is unique.
+
+related to [[resets]] — this is the sleep-specific version of the "reflecting (just thinking about stuff and staring into space)" reset, except directed inward at physical sensation rather than outward at thoughts.
+
+## the wall inversion
+
+lie on the floor. put your legs up against the wall, as straight as you can. just chill there for 30 seconds to a minute.
+
+the blood flow shift is immediate — you feel it in your legs within seconds. the gentle pressure change in your head is calming. its a physiological reset that doesnt require any mental effort. works especially well right before getting into bed.
+
+this is the same principle as the "hang from your knees" tired reset from [[resets]], but more controlled and more comfortable. you can do it every night as part of a wind-down routine.
+
+## wim hof / cyclic hyperventilation
+
+the most aggressive relaxation tool. 30-40 deep breaths (inhale fully through the nose, exhale passively through the mouth), then hold on empty lungs for as long as comfortable. the breath hold is where the magic happens — a wave of calm floods in as CO2 builds and the body shifts into parasympathetic mode.
+
+this isnt subtle. 2-3 rounds of this and your nervous system is fundamentally different than it was 5 minutes ago. the tingling in your hands and face during the breathing rounds is the hyperventilation doing its thing — shifting blood pH, dumping adrenaline, then crashing into deep relaxation on the hold.
+
+i use this for two situations:
+1. **cant sleep because wired/anxious** — the hyperventilation burns off the nervous energy, and the breath holds force parasympathetic activation. 2 rounds is usually enough.
+2. **tired but need to stay awake** — paradoxically, 1 round of wim hof is also the best way to snap out of grogginess. the adrenaline hit during the breathing rounds is a full physiological wake-up. the difference is whether you do 1 round (energizing) or 3 rounds (deeply calming).
+
+this connects to [[exercise-as-reset]] — its the breathing equivalent of a 10-minute run. both work by overwhelming the current physiological state and forcing a reset.
+
+## the stack
+
+for nights when sleep is really hard, stack all three:
+1. wall inversion (30-60 seconds) — passive physiological shift
+2. wim hof (2-3 rounds) — active nervous system reset
+3. body scan breathing in bed — mental present-anchoring until sleep
+
+most nights the body scan alone is enough. the full stack is for when things are really cooked.
\ No newline at end of file
new file mode 100644
index 0000000..9b49229
@@ -0,0 +1,77 @@
+---
+visibility: public-edit
+---
+
+# social strategy: the graph search approach to people
+
+the most useful social framework i learned came from a combination of startup mentors, a VC visitor, and my own experience reaching out to hundreds of people over several months.
+
+## the node theory
+
+"once you find a node, don't let go. good nodes bring you in flows of people." a startup cofounder framed networking as graph search:
+
+- people are nodes
+- connections are edges
+- exceptional people tend to cluster
+- finding one exceptional person gives you access to their entire cluster
+- "when finding a node, chance that it's connected [to others] given that everyone is searching is very high"
+
+a VC visitor had a similar model: building a talent search engine where people are valued by their connections and updated with new information. "have a lot of false positives — people who seem smart that aren't actually smart." the big question isn't avoiding false positives — it's avoiding false negatives (missing exceptional people).
+
+## the event heuristic
+
+"if there's even a 1% chance [of meeting someone exceptional], you should go."
+
+some of the best connections came from mediocre events. the event quality doesn't determine the people quality — it's a search problem. go, find the interesting people, ignore the rest.
+
+practical: arrive with an intention. "when going to event, have an intention." not "i'll network" — something specific like "i want to find 2 people working on X" or "i want to practice presenting my project."
+
+## the reach-out system
+
+"just reach out. lots of people are very cool. ignore the not cool ones."
+
+my approach evolved:
+1. find interesting people (through events, mutual connections, online presence)
+2. reach out with something specific (not "let's chat" — "i saw your work on X, i'm working on something related")
+3. have a 15-30 minute conversation
+4. follow up within 24 hours
+5. maintain the relationship with periodic check-ins
+
+"spending time helping [a mentor] with his stuff" — the best relationships are mutual. find ways to be useful, not just to extract value.
+
+a mentor: "open to chatting at least once every two weeks." this is the cadence that works — frequent enough to maintain momentum, infrequent enough to not be annoying.
+
+## reading people
+
+"reading people is a really good skill. you can also refine it by just telling your read of them to them."
+
+learned at the startup: form a quick impression, then check it against reality.
+
+things that are unreliable signals:
+- credentials alone ("lots of programs are kinda just mid even though they have a lot of good stuff on their website")
+- confidence alone ("unless you really know a person, they are probably less cool and less smart than you think")
+- talking a big game without showing results
+
+## the appreciation habit
+
+"consistent with show appreciation. a friend very much has a good habit of being like 'i think you're cool, like your projects.'"
+
+proactive appreciation is a superpower for relationship maintenance. tactics:
+- take selfies with people at events, send them after
+- mention specific conversation items and jokes in follow-ups ("kindness notes: mention specific things especially conversation items")
+- do something special — personalized notes, custom format, anything that shows effort
+- initiate appreciation circles at gatherings
+
+"for appreciation of people, it's a bit hard for me — need to make it easier." the solution: mark moments of genuine appreciation in real-time (in notes) so you have specific things to reference later.
+
+## the mutual growth model
+
+the startup cofounder's life plan: "make the best team. grow alongside them. be able to grow them the best, and understand them the best. synergy is crazy powerful."
+
+this reframed social strategy from "networking for opportunities" to "building a growth ecosystem." the people around you aren't resources — they're compounding assets, just like the [[stocks metaphor|the-stocks-metaphor]] applied to relationships.
+
+"there is a need for mutual willingness to spend time together. it matters. hard to make friends so if someone good, hold on. also bouncing ideas + creative flow that comes with talking to people."
+
+---
+
+*see also: [[social wins|social-wins]], [[asking good questions|asking-good-questions]], [[the stocks metaphor|the-stocks-metaphor]]*
\ No newline at end of file
new file mode 100644
index 0000000..3494c69
@@ -0,0 +1,49 @@
+---
+visibility: public-edit
+---
+
+# team dynamics
+
+reflections on what makes teams work, from math competitions to startup internships.
+
+## the bandwidth principle
+
+"more bandwidth in comms is always better: meet often, be as synced as possible." see [[resyncing]] for specific tools.
+
+the opposite — splitting things equally and working independently — feels efficient but produces worse results. the sum of parts equals whole, just multiprocessing but worse. real collaboration requires overlap, redundancy, and constant communication.
+
+## good environments
+
+the three qualities of a good team environment:
+- **honest** — people say what they actually think, see [[feedback-and-honesty]]
+- **urgent** — there's energy and momentum, not slack
+- **stress-free** — urgency without anxiety. this is the hard balance.
+
+## assume no ill will
+
+from a math competition team experience: i felt the team wasn't doing strong work, wasn't on the same page. i got suspicious of people's effort and intentions.
+
+the realization: "these are all just my perceptions, many times wrong or exaggerated." suspicion makes team dynamic cooked. the better stance:
+
+- assume no ill will
+- assume everyone is fighting their own battle
+- express what you feel and why it matters (see [[feedback-and-honesty]])
+- don't ask for anything specific — just share, then keep working
+
+## values over output
+
+"i value my relationship with these people — even if we submit a perfect thing but become farther apart, that's not worth it." this is a non-obvious priority: the relationship matters more than the deliverable. a team that stays connected produces better work long-term, even if the immediate output suffers.
+
+## the looking-down trap
+
+"at school, sometimes look down on people thus try to do a lot of work myself." this is ego-driven and counterproductive. the fix: invest in the team, build people up (see [[gratitude-and-appreciation]]), and trust the collective.
+
+## picking people
+
+"picking the right people is very important, working with people you don't vibe with is tiring." and the related lesson: "figure out what you want earlier and optimize for that" — from a hackathon partner search.
+
+you can't always choose your team, but when you can, optimize for vibe and complementary skills. when you can't, invest in [[relationship-repair]].
+
+## community building
+
+"community is definitely not as easy as some good descriptions, maybe some food." building community requires sustained effort beyond the obvious. this connects to [[intentionality]] — community doesn't happen by accident.
\ No newline at end of file
new file mode 100644
index 0000000..509b9b0
@@ -0,0 +1,79 @@
+---
+visibility: public-edit
+---
+
+# specific things that boosted energy and focus
+
+from hundreds of daily reflections, certain energy patterns emerged clearly. some of these are obvious in hindsight, others were genuinely surprising.
+
+## food: the biggest lever
+
+### food comas are the enemy
+
+"eating a lot is very distracting and clouding." this was maybe the single most impactful realization. food comas destroyed entire afternoons. the pattern was reliable: big lunch → 2 hours of diminished capacity → frustration → more eating for comfort → more brain fog.
+
+what worked:
+- strict food rules during intense work periods: one bagel, one fuel pack, fruits only
+- "before each meal, do a 2m [reflection] with the focus of food coma — remember previous cooked experiences"
+- eating until not hungry, not until full. sounds simple but this was an actual daily habit challenge for weeks
+- mangos on the side while working were surprisingly fine — "maybe mangos aren't all bad" — light snacking that didn't trigger a coma
+
+what didn't work:
+- trying to eat socially and work. mixing eating with connection led to overeating every time
+- eating at home in the evening when tired. "it is a common pattern that at night i eat a lot at home because parents make food and then i eat because it tastes good"
+
+### hydration timing
+
+"don't drink that much water before bed" — simple but the difference between waking up at 5:40 refreshed vs waking at 1am to pee and then being groggy all morning.
+
+## movement resets
+
+### cold showers
+
+cold showers as a brain reset became a key tool. not for the machismo of it — for the actual neurological shift. "showering 3 times is very nice" on productive days. each shower was a state transition, not just hygiene.
+
+### walking and biking
+
+"going outside and just observing is very thought provoking." walking wasn't just exercise — it was a mode switch. the best reflections happened while walking around the city. biking hard could replace or add to exercise and had the bonus of getting somewhere.
+
+"running with a backpack for an extended period is non-trivially useful" — turning commute time into training time.
+
+### volleyball and frisbee breaks
+
+short physical breaks during work sessions at the startup were magic. not long breaks — 20 minutes of volleyball, then back to the problem. the physical exertion seemed to clear whatever mental block was there.
+
+## environmental factors
+
+### the home problem
+
+"at home where i work the worst." this was a consistent finding. home had too many comfort triggers — food, youtube, bed, parents making food. the fix was simple: don't work at home if you can avoid it. coffee shops, libraries, the office — anywhere else.
+
+when stuck at home: standing desk, second monitor, laptop stand. physical setup that signals "this is work mode."
+
+### no music (sometimes)
+
+"turn phone, no music, hide others" — during deep focus blocks, music was actually a distraction, not a help. this was counterintuitive since i felt like music helped me focus. the data from my reflections said otherwise.
+
+## sleep: the foundation
+
+"for sleep: just don't think. more valuable to be clear headed."
+
+sleep onset was consistently terrible. i'd lie in bed thinking about projects, college, future, success. "sleep onset consistently horribly bad, can save an entire hour."
+
+what worked:
+- strict bedtime reminders (8:20 shower, 8:30 reflection)
+- meditation before sleep (even 5 minutes)
+- not doing stimulating work right before bed
+- "sleeping early is very important" — the obvious answer is the right one
+
+what consistently failed:
+- youtube before bed. "wow yt is crazy. now i've slept 2.5h past what i wanted to and i have a headache"
+- thinking about work problems. the solutions never came at midnight — they came after a good night's sleep
+
+## the meta-pattern
+
+energy management isn't about willpower. it's about setting up the environment and habits so that the right behaviors are easy and the wrong ones are hard. the best energy hack was the simplest: [[morning routines|morning-routines]] that started the flywheel spinning before my conscious brain could sabotage it.
+
+---
+
+*see also: [[morning routines|morning-routines]], [[work sessions|work-sessions]], [[habit formation|habit-formation]]*
\ No newline at end of file
new file mode 100644
index 0000000..0a42cc0
@@ -0,0 +1,69 @@
+---
+visibility: public-edit
+---
+
+# specific moments where a mindset change unlocked better performance
+
+not gradual evolution — specific, identifiable moments where something clicked and the before/after was noticeable.
+
+## "clear thinking me is in charge by default"
+
+the framing: there are two versions of me. the clear-thinking version and the monkey. by default, clear-thinking me is in charge. if monkey wants to do something, it has to ask permission.
+
+this sounds like a toy metaphor but it worked in practice. when i felt the urge to eat another cookie, scroll youtube, or skip a workout, there was a beat where i could ask: "is this the monkey or is this a deliberate choice?" the monkey didn't always lose — sometimes the cookie was worth it. but making it ask first changed the ratio dramatically.
+
+## "my potential is undefined"
+
+"my potential is undefined. should not be comparing to others. thus there is no such thing as 'behind.'"
+
+i was constantly comparing — to coworkers at the startup, to peers at school, to imaginary versions of myself. the comparison always made me feel behind. the shift was realizing that "behind" is only meaningful if everyone is on the same track. they're not.
+
+this unlocked the [[raise or fold|prioritization]] habit: instead of trying to keep up with everything, put maximum effort into things that matter and zero effort into things that don't. no in-between.
+
+## "turn 'have to' into 'get to'"
+
+"prepare yourself for negativity. turn 'have to' into 'get to': life is beautiful."
+
+this one came from a period where school felt like a prison after the freedom of the startup. everything was a chore. the shift was reframing: i don't have to go to class, i get to learn from smart teachers. i don't have to do homework, i get to practice skills that will compound.
+
+it didn't always work. but on the days it did, my energy was completely different.
+
+## the perspective switch for optimism
+
+"perspective switch for optimism is so real. always look for it."
+
+this was less a single moment and more a meta-realization: almost every bad situation has an optimistic framing available, and actively searching for it isn't delusion — it's a skill. the startup CEO modeled this constantly: bad test result? "great, we learned something." hardware broken? "now we know what not to do."
+
+the practice: when something goes wrong, spend 30 seconds looking for what went right or what was learned. not instead of fixing the problem — before fixing it. the emotional state matters for the quality of the fix.
+
+## "being intentional means i live longer"
+
+"being intentional and detail oriented, caring about everything → perceive more phenomena & experience more, meaning i live longer. e.g. longer days, time is flowing so slow. time flies when you don't perceive and don't think."
+
+this was a genuine insight that changed my relationship with time. unintentional days vanish. intentional days feel like they lasted a week. the same 24 hours, completely different experience of them.
+
+## the "just do it" moment
+
+"right now, i'm committing the entire week to go crazy. just do it. thank me later."
+
+there's a pattern in my reflections where i spend days analyzing what to do, planning systems, designing perfect routines — and then a single moment of "fuck it, just go" produces more output than all the planning combined.
+
+the planning isn't useless — it sets up the conditions. but the actual shift happens in a moment of commitment, not in a spreadsheet.
+
+## the identity shift from atomic habits
+
+"i heard about the guy who was 'religious about his oral care' and now i kinda wanna be that person." the insight from atomic habits that actually stuck: habits work better when they're identity-based rather than outcome-based.
+
+"i am someone who runs every morning" vs "i am trying to exercise more." the first one is an identity; the second is a goal. identities persist; goals expire.
+
+## "the feeling of spending 6 hours trying and failing is very humbling"
+
+"was very sad about it. now not very much so. learning is really in the struggle and the grind. also being upset about it isn't really going to help."
+
+critic voice: "bro what, that is so easy." response: "i know you're scared of not succeeding immediately for once in your life. it's all good. you can try some other strategies."
+
+this was the shift from performance orientation to growth orientation. failure went from being evidence of inadequacy to being evidence of learning. not overnight — but once the shift started, it accelerated.
+
+---
+
+*see also: [[the agency talk|agency-talk]], [[the stocks metaphor|the-stocks-metaphor]], [[habit formation|habit-formation]]*
\ No newline at end of file
new file mode 100644
index 0000000..151b16c
@@ -0,0 +1,58 @@
+---
+visibility: public-edit
+---
+
+# morning patterns that produced good days
+
+after months of daily reflections, a clear pattern emerged: the mornings that went well predicted the entire day going well. not perfectly — but the correlation was strong enough that i started treating mornings as the highest-leverage optimization target.
+
+## what actually worked
+
+### the urgency-after-wake pattern
+
+the best mornings started with immediate movement. wake up, bounce into shower, start the day with physical urgency. no lying in bed scrolling, no gradual warming up.
+
+"urgency after wake up, immediately bounce into shower to start day off with urgency" — this became a rule. the shower itself was a brain reset, not just hygiene. cold showers especially created a sharp mental state that carried into the first work block.
+
+### the 1-hour morning block
+
+on my best days, i spent the first hour on a combination of:
+- exercise or movement (even just a walk or biking hard)
+- meditation (5 minutes minimum)
+- reading something that resets my mindset (stoicism worked well)
+- reflection on the previous day
+
+"spend 1h exercising, meditating, playing music, reflecting. during the 1h, emphasize being intentional in my mindset."
+
+the key insight: this hour wasn't lost productivity. it was the investment that made the other 12 hours actually productive instead of scattered.
+
+### one goal for the day
+
+"only one goal for the day." this sounds limiting but it was transformative. before this, i was spraying and praying — listing 15 things, doing 4 of them badly, and feeling like i failed. with one goal:
+- i could remember what i was supposed to be doing during checkins
+- i could cycle through [[mindset shifts|mindset-shifts]] faster because i was internalizing one thing deeply
+- reviewing the day was simple: did i do the thing or not?
+
+### strict time reminders
+
+"having strict timeline reminders of 8:20 shower and 8:30 reflection is very good, prompting me to reflect each time." i used watch alarms and phone timers to create structure. without them, the morning would dissolve into responding to messages and random tasks.
+
+## what didn't work
+
+### doing things immediately instead of planning
+
+"made the mistake of doing things immediately instead of putting them on todo list — they weren't that important." the reactive morning where i jump straight into emails or messages always led to an unfocused day. the small dopamine hits of clearing notifications crowded out the important-but-not-urgent work.
+
+### skipping the morning for school
+
+at school, i noticed a pattern where i would skip planning and reflection entirely. "interesting pattern that at school, i just don't like planning / thinking / reflecting — some kind of social awareness trigger." the social environment was so stimulating that it pushed out the internal work.
+
+the fix: do the morning routine *before* getting to school, even if it means arriving slightly later.
+
+### morning scheduling and emailing
+
+"don't do scheduling & emailing & messages slop until afternoon. morning is good time." the morning brain is the clearest, sharpest version of yourself. using it on logistics is a waste. hard thinking in the morning, fun reading in the afternoon, logistics never (or at least after 3pm).
+
+---
+
+*see also: [[energy hacks|energy-hacks]], [[work sessions|work-sessions]], [[habit formation|habit-formation]]*
\ No newline at end of file
new file mode 100644
index 0000000..af2c67c
@@ -0,0 +1,71 @@
+---
+visibility: public-edit
+---
+
+# relationship and social strategies that worked
+
+some of the biggest wins weren't technical or productivity-related. they were social — figuring out how to connect with people in ways that were genuine and also strategic.
+
+## reaching out aggressively
+
+"great intentionality from reaching out has paid off." during the startup internship and after, i made a habit of reaching out to people cold. not spam — targeted, genuine outreach to people i found interesting.
+
+the results were disproportionate. one week i talked to 20+ people (calls, walks, coffee chats). some were amazing, some were mediocre. but the hit rate was high enough that the strategy clearly worked.
+
+"just literally talk to everyone (and be cool). balance between breadth and depth — gotta know people well, and know lots of people."
+
+## walks as social technology
+
+walks became my default social format. a cofounder told me: "one of the biggest ways i can get feedback is walks." he was right. walks are better than sitting meetings because:
+- no screen to hide behind
+- physical movement keeps energy up
+- you're side by side, not face to face (less confrontational)
+- natural pauses feel comfortable, not awkward
+- conversation goes deeper faster
+
+"the best conversations happened walking around the city at night or during breaks between work sessions."
+
+## appreciation circles and heart-to-hearts
+
+"initiating appreciation circle & more heart to heart convos was super great today." i started doing this at events and gatherings — just steering the conversation toward genuine appreciation of each other. it felt vulnerable at first but people responded incredibly well.
+
+"consistent with show appreciation — a friend very much has a good habit of being like 'i think you're cool, like your projects.' rephrased but same idea." making appreciation a habit, not just something that happens spontaneously.
+
+tactically: "take selfies with people at events and send it to them." small gesture, huge relationship maintenance.
+
+## the "talk to more people during school" discovery
+
+a pattern from weekly reflections: "talk to more people at school. spend more time talking to people." i'd been treating school as a productivity zone and social time as a separate thing. but the best social connections happened during the margins — before class, between periods, at lunch.
+
+"at school, spend more time socializing. spend time at home working." this division was simple and effective.
+
+## finding the right people
+
+"once you find a node, don't let go. good nodes bring you in flows of people." the CEO framed networking like a graph search problem:
+- find one exceptional person
+- that person is connected to other exceptional people
+- follow the connections
+
+"when finding a node, chance that it's connected [to other good nodes] given that everyone is searching is very high."
+
+practically: go to events even if they seem mediocre. "if there's even a 1% chance [of meeting someone exceptional], you should go." one of the best connections at the startup came from a mediocre fellowship event.
+
+## navigating conflict
+
+"make hard convos on call to retain the relationship and prevent misrepresentation." text is terrible for disagreement. calls preserve tone and allow real-time repair.
+
+when i had to navigate a tricky team switch situation: "many instincts for things to say (to be logical) but tried empathy & validation and that seemed to work well." the strategy:
+1. state my needs
+2. frame it as "we are working together"
+3. expand the state of possible outcomes
+4. find framings that aren't hurtful
+
+## the connection discovery
+
+"connection is so great, can connect in my own thinking, in convos, and also just talking to people." genuine connection — not networking, not strategic relationship-building — turned out to be the thing that made everything else work. [[bouncing ideas off people|social-strategy]] was inherently pleasurable and also the most productive thing i could do with social time.
+
+"bouncing ideas off people is such a good experience. asking what they think of certain things. show, not tell. also this is actually the life — building cool things and showing them to people."
+
+---
+
+*see also: [[asking good questions|asking-good-questions]], [[social strategy|social-strategy]], [[work sessions|work-sessions]]*
\ No newline at end of file
new file mode 100644
index 0000000..d85e38f
@@ -0,0 +1,79 @@
+---
+visibility: public-edit
+---
+
+# patterns of productive work sessions
+
+from tracking hundreds of work sessions across an internship and school, certain patterns emerged for when deep work actually happened vs when i was just sitting at a computer pretending.
+
+## the timer system
+
+the single most effective intervention: timers.
+
+- **30-minute focus blocks** with a forced 1-minute zoom-out at the end. "set a timer to come back to intentionality and adjust." the zoom-out wasn't optional — it was the moment to ask "am i actually working on the right thing?"
+- **20-minute tunneling checks.** "set 20m timers for 1m zoom outs. don't skip the 1h zoom outs." without these, i'd spend 2 hours going down a rabbit hole that wasn't actually important.
+- **the intentionality timer.** every 5 minutes during the morning routine, a reminder to be intentional. sounds aggressive but it trained the muscle.
+
+"think about whether it's important → only do if it's really important. plan 10m. intentionality. tunneling/cooked checks. reflect." — the whole workflow in one line.
+
+## what good sessions felt like
+
+### the agentic work state
+
+"just spent like 2 or so hours on anesthetics and got to a pretty good state, understood very clearly what was going on the entire time. very agentic and intentional about movements (even if not very fast)."
+
+this was the counter to the common failure mode of either:
+- ai-spamming: throwing everything at an LLM and copy-pasting without thinking
+- multitasking: having 4 tabs open and bouncing between them
+
+the good state was slower but the output was real. "i feel that this is the counter to a lot of sad experiences either multitasking or ai spamming."
+
+### the planning → execution pattern
+
+"very much underestimating time needed for implementing certain features. esp for app building, push myself to go faster and faster which is bad (vibe coding → break)."
+
+the pattern that worked: spend 10 minutes planning before any coding session. what am i building? what are the steps? what could go wrong? "if it's important, plan more. if it's not important or have hella experience, don't need to."
+
+### the lock-in day
+
+some days everything clicked. "super lock in day. interesting question to see how i can replicate that kind of fire." the characteristics:
+- woke up with urgency
+- one clear goal
+- eliminated distractions early
+- physical movement between sessions
+- no food comas (light eating)
+- social energy from earlier in the day carried forward
+
+## what killed sessions
+
+### the reactive trap
+
+"mark pointed out twice that i was doing a thing that was not important." the most common failure: being given something to do and doing it well, but not choosing the right thing to do independently.
+
+"if given thing to do, yes [intentional]. not really for what to do." execution without [[prioritization|prioritization]] is just organized busy-work.
+
+### the comfort spiral
+
+"there is an ease in unfocus and doing whatever that is a bit unsettling. very similar to youtube and sometimes eating sweets." comfort-seeking was the stealth killer. it didn't feel like procrastination — it felt like "taking a break" or "being flexible." but the break turned into an hour, and the flexibility turned into an afternoon of nothing.
+
+### multitasking
+
+"multitasking with vibe coding isn't that great. best is do vibe coding with planning or architectural stuff. context switch is not great." every time i tried to run two work streams simultaneously, both suffered. the feeling of productivity was an illusion.
+
+### the home environment
+
+work sessions at home were consistently worse than anywhere else. too many triggers for comfort behavior. the standing desk helped, the second monitor helped, but the best solution was just leaving.
+
+## the two-day sprint pattern
+
+"couple day sprints to do crazy things are really great." when i had a clear project and 2-3 uninterrupted days, the output was 10x what i'd produce in a normal week. the momentum built on itself — each completed piece fed motivation for the next.
+
+the key was not trying to sprint every day. sprints were special — preparation mattered, rest after mattered, and choosing the right project to sprint on mattered most.
+
+## the meta-lesson
+
+"constantly optimize" — but the optimization target shouldn't be hours worked. it should be quality of attention during the hours. one hour of truly focused, intentional work beats four hours of distracted grinding.
+
+---
+
+*see also: [[morning routines|morning-routines]], [[energy hacks|energy-hacks]], [[prioritization|prioritization]]*
\ No newline at end of file
new file mode 100644
index 0000000..c8a9743
@@ -0,0 +1,35 @@
+---
+visibility: public-edit
+---
+
+# vibe coding
+
+reflections on coding with AI. powerful but dangerous.
+
+## the good
+
+- "can trust claude to implement things" — once you know what to build, AI accelerates implementation massively
+- prototyping becomes viable in situations it wasn't before — AI makes your time cheap for exploration
+- /rewind is a useful tool when things go sideways
+- use voice to text — reduces friction, lets you think out loud
+
+## the dangers
+
+### AI rotting
+"AI rotting is such a thing — watch out for it." this is the slow erosion of your own understanding and skills when you let AI do too much thinking for you. the fix isn't to stop using AI — it's to stay engaged.
+
+### getting sucked in
+"so easy to get sucked in, need breaks at 10 minute intervals." vibe coding creates a flow state that feels productive but can become mindless. the 10-minute break rule forces you to [[zooming-out|zoom out]].
+
+### context switching
+"multitasking with vibe coding isn't that great; context switch is not great." when AI is generating, the temptation is to do something else. but context switching degrades both tasks.
+
+"whenever it's thinking, don't go to discord — actually think about how it's going." this is the key discipline: use the AI's thinking time to think yourself. review what it's doing, consider what you want next, stay engaged.
+
+## poorly vibe coded apps
+
+poorly vibe coded apps are bad. there's a quality floor that's easy to miss when AI is doing the heavy lifting. you still need [[intentionality]] about what you're building and why.
+
+## the meta-lesson
+
+vibe coding amplifies whatever you bring to it. if you come with clear thinking and a good plan (see [[software-workflow]]), AI makes you 10x. if you come with no plan and let it drive, you get a mess and learn nothing.
\ No newline at end of file
new file mode 100644
index 0000000..8c43606
@@ -0,0 +1,47 @@
+---
+visibility: public-edit
+---
+
+# articulation as memory
+
+"if something is articulated better, i remember it and its importance more."
+
+naming a thing gives you power over it. language shapes what you can think, what you can remember, and what you can use.
+
+## the mechanism
+
+there's a difference between experiencing a pattern and naming it. i'd been [[zooming-out|zooming out]] for years before i called it that. but once it had a name, it became a tool i could deploy deliberately instead of a thing that sometimes happened by accident.
+
+this is true across every domain i've worked in. in debugging: the moment you can name a bug pattern — "this is a [[assumptions-kill|hidden assumption]] bug" or "this is a state management race condition" — you've compressed hours of future debugging into a recognition event. instead of reasoning from scratch, you pattern-match.
+
+in life: "[[resyncing]]" is a thing i do all the time. but naming it made it conscious. now when i feel off-track, the word surfaces automatically: "i need to resync." the name is a handle that makes the concept graspable.
+
+## why names matter
+
+### compression
+
+a good name compresses a complex idea into something portable. "[[critical-path]]" carries a whole framework — prioritize the thing that blocks everything else, ignore the rest for now. without the name, you'd need to re-derive the framework every time. with the name, it's instant.
+
+this is why jargon exists. not to exclude people (though it does that too) — but because shared names for shared concepts make communication massively more efficient. the problem is when jargon becomes empty — when people use the name without the underlying understanding.
+
+### salience
+
+naming something makes it salient. it moves from background to foreground. before i named the [[the-reflection-gap|reflection gap]], i experienced it constantly but never noticed the pattern. naming it made it visible, and visibility is the prerequisite for doing something about it.
+
+this is also why [[narratives]] matter. the narrative you tell about your life determines which patterns are salient and which fade into noise. articulating a pattern is choosing to make it part of your story.
+
+### transmission
+
+named patterns can be shared. i can't transmit a vague feeling, but i can transmit "zoom out" or "binary search your life" and the recipient gets a tool they can use. writing this wiki is an exercise in articulation — turning lived experience into named, shareable patterns.
+
+## the risk
+
+over-naming is a thing. if you name everything, nothing is special. the names have to be load-bearing — they should point to genuinely useful concepts, not just be labels for obvious things. "take breaks" doesn't need a special name. "[[resets]]" — the deliberate practice of discarding your current mental state and starting fresh — does, because it's specific and non-obvious.
+
+there's also the risk of premature naming. naming a pattern before you fully understand it can freeze your understanding. the name becomes a box, and you stop updating the concept because the name feels final. good names should be held loosely — they're tools, not truths.
+
+## the practice
+
+when something keeps recurring — a frustration, a success pattern, a failure mode — i try to name it. sometimes the name sticks and becomes part of how i think. sometimes it doesn't, which usually means the concept wasn't as real as i thought it was. the names that survive repeated use are the ones that point to something true.
+
+this whole wiki is a naming project. [[perseverance]], [[modeling]], [[operation-optimization]] — each of these is an attempt to take something i've experienced and compress it into a handle that makes it usable. the [[writing-to-understand|writing]] does the discovery; the naming does the preservation.
\ No newline at end of file
new file mode 100644
index 0000000..df2f799
@@ -0,0 +1,65 @@
+---
+visibility: public-edit
+---
+
+# journaling systems
+
+the tool matters less than the habit. but the tool shapes the habit, and the wrong tool creates friction that kills the habit.
+
+## my systems
+
+### ideaflow
+
+this is where the deep reflections live. over a hundred entries at this point. ideaflow is good for longer-form thinking — when i need to work through something, not just record it. the reflections here are where most of my [[writing-to-understand|writing-as-discovery]] happens.
+
+the downside: it's a dedicated app, which means i have to decide to open it. that decision point creates friction. i don't reach for ideaflow for quick thoughts — the overhead isn't worth it for a sentence or two.
+
+### apple notes
+
+the quick capture tool. a thought hits me, i write it down. no formatting, no structure, no friction. the best thing about apple notes is that i already have it open — there's no activation energy.
+
+the downside: apple notes becomes a graveyard. things go in and rarely come out. it's write-heavy, read-light. i'll dump a thought and never revisit it, which means the [[the-reflection-gap|reflection gap]] is wide. the thought was captured but not processed.
+
+### weekly reflections
+
+structured, recurring. every week, look back: what happened, what went well, what didn't, what do i want to do differently next week. this is the closest thing i have to a closed-loop system — the weekly cadence forces re-reading previous reflections, which is where the actual [[resyncing]] happens.
+
+the downside: sometimes it becomes routine. going through the motions of a weekly reflection without actually reflecting. the structure that makes it consistent can also make it mechanical.
+
+### obsidian
+
+interconnected notes. good for building a web of ideas over time — linking concepts, seeing patterns across entries. the wiki-style structure rewards [[articulation-as-memory|naming things]] because named concepts become linkable nodes.
+
+the downside: setup cost is real. obsidian rewards investment, but the investment is front-loaded. and the temptation to build infrastructure (plugins, templates, workflows) instead of actually writing is significant. you can spend more time organizing your knowledge management system than actually managing knowledge.
+
+## what i've learned about systems
+
+### the best system is the one you use
+
+this sounds obvious but it eliminates most options. a beautifully designed journaling app that you open once a month is worse than apple notes opened daily. consistency beats quality. volume beats polish.
+
+### capture and processing are different
+
+the biggest mistake: treating capture and processing as the same thing. apple notes is great for capture — thought in, zero friction. but capture without processing is just hoarding. the thought needs to go somewhere: a reflection, a pattern, an action item. otherwise it's data, not knowledge.
+
+my current approach: capture in apple notes throughout the day, process during weekly reflections. the weekly reflection is where raw captures become insights. this two-stage process is messy but functional.
+
+### structure helps until it doesn't
+
+some structure is essential. "what went well, what didn't" is a useful prompt because it prevents reflections from being pure stream-of-consciousness. but too much structure — 10-question daily templates, color-coded categories, mandatory fields — turns reflection into paperwork.
+
+the right amount of structure: enough to prompt you past the blank page, not so much that filling out the form replaces actual thinking.
+
+### the re-reading habit
+
+writing is half the value. re-reading is the other half. without re-reading, reflections are write-only memory — they help during writing but fade afterward. building a habit of re-reading old entries is hard (it's less satisfying than writing new ones) but it's what closes the [[the-reflection-gap|reflection gap]].
+
+when i re-read old reflections, i notice patterns i missed in the moment. "i've written about this same frustration three times in two months" is a signal that wouldn't be visible from any single entry. the accumulation of reflections is more valuable than any individual one.
+
+## the meta-observation
+
+i've tried a lot of systems. the ones that stuck had low friction, recurring prompts, and some mechanism for re-reading. the ones that didn't stick were either too high-friction (dedicated apps i had to decide to open) or too unstructured (raw dumps with no processing step).
+
+the system i'd recommend to anyone starting: write something every week. anything. even three sentences. just make it regular. the regularity is the foundation; everything else — tools, templates, methods — is optimization on top of that foundation.
+
+and link your ideas together when you can. this wiki is the current evolution of that practice: [[articulation-as-memory|named patterns]], connected through links, building a web of understanding that's greater than the sum of its entries.
\ No newline at end of file
new file mode 100644
index 0000000..e574615
@@ -0,0 +1,57 @@
+---
+visibility: public-edit
+---
+
+# public vs. private
+
+writing for yourself and writing for others are different acts. both useful, but they exercise different muscles and produce different results.
+
+## private writing
+
+private writing is exploratory. it's where [[writing-to-understand|discovery]] happens. you can be wrong, confused, contradictory, half-baked. there's no audience to perform for, no standard to meet. the only goal is to get your thinking out of your head and onto the page where you can see it.
+
+my apple notes and ideaflow reflections are private writing. they're messy. they repeat themselves. they contain dead ends and bad ideas. and they're where most of my actual insight comes from, because the mess is where the real thinking lives.
+
+private writing is also honest in a way public writing struggles to be. you'll admit things to your own notes that you'd never publish. "i'm afraid this project is going to fail." "i don't actually understand how this works." "i'm angry about what happened and i'm not sure it's justified." that honesty is essential for genuine reflection (see [[feedback-and-honesty]]).
+
+## public writing
+
+public writing forces clarity. when someone else will read it, you can't leave the fuzzy parts fuzzy. you have to actually explain. you have to anticipate questions, fill gaps, make the logic explicit. this friction is productive — it's a forcing function for understanding.
+
+i've published things on my site that started as private reflections. the process of making them public always improved the thinking. not because i dumbed it down for an audience — because the audience requirement exposed the parts that weren't actually clear, even to me. i just hadn't noticed because i was filling in the gaps unconsciously when reading my own notes.
+
+this is why [[rubber-duck-and-zoom-out|rubber duck debugging]] works, scaled up. explaining to someone who can't read your mind forces you to make the implicit explicit.
+
+## the tension
+
+private writing maximizes honesty. public writing maximizes clarity. the ideal is both, but in practice they trade off.
+
+publishing creates an incentive to perform. you smooth out the rough edges, omit the parts that make you look confused or uncertain, emphasize the clean narrative over the messy reality. the result reads well but doesn't capture the actual experience. it's a [[narratives|narrative]] about what happened, not a record of what it felt like.
+
+the best public writing maintains the honesty of private writing. but it's hard. writing "i didn't know what i was doing" in a published piece requires [[confidence]] — confidence that honesty is more valuable than looking competent.
+
+## what i've learned
+
+### private is the default, public is the exception
+
+most writing should be private. not everything needs an audience. the value of writing is primarily in the thinking it generates, and that thinking happens whether or not anyone reads it. publishing should be reserved for pieces where the audience requirement would actually improve the thinking, or where the ideas might be useful to someone else.
+
+### public writing is a commitment device
+
+publishing something is a weak commitment to believing it. if i publish "i think X," i'm slightly more likely to act on X than if i just wrote it in my notes. the social accountability of a public statement — even to a small audience — creates a bridge across the [[the-reflection-gap|reflection gap]].
+
+### different tools for different purposes
+
+quick private thoughts → apple notes. they're frictionless, searchable, and i don't care if they're messy.
+
+deep private reflection → ideaflow, longer-form. when i need to actually work through something, not just jot it down.
+
+public synthesis → blog posts, wiki pages like this one. when i've thought about something enough to have a stable view worth sharing.
+
+weekly reflections → a hybrid. primarily private, but structured enough that they function as a [[resyncing]] checkpoint.
+
+### the semi-public sweet spot
+
+this wiki is an experiment in semi-public writing. it's public in the sense that anyone can read it. but it's not promoted, not optimized for an audience, not written to perform. it's personal knowledge made legible — primarily for my own benefit, with the public-facing constraint serving as a quality floor.
+
+the question i'm still working out: does semi-public writing get the clarity benefits of public writing without the performance cost? so far, mostly yes. writing these pages forces me to explain things clearly, but the low-stakes context means i don't feel pressure to polish away the uncertainty.
\ No newline at end of file
new file mode 100644
index 0000000..422249e
@@ -0,0 +1,57 @@
+---
+visibility: public-edit
+---
+
+# the reflection gap
+
+"for reflection, always amazing. sometimes though i reflect and then that's it."
+
+the gap between understanding something and doing something about it.
+
+## the problem
+
+writing a reflection feels productive. you sit down, think hard, articulate an insight, and walk away feeling like you've accomplished something. and you have — the [[writing-to-understand|understanding]] is real. but understanding is not change. insight is not action.
+
+i've written reflections where i clearly identified a problem, clearly articulated what i should do differently, and then... didn't do it differently. the reflection sat in a note somewhere and my behavior continued unchanged. the gap between the reflection and the behavior change is the hardest part of the whole process.
+
+## why the gap exists
+
+### insight feels like progress
+
+understanding a problem creates a feeling of resolution. your brain treats the act of articulating the problem as partially solving it. but the problem isn't solved — it's described. description is step one, not the finish line.
+
+### no mechanism for follow-through
+
+most reflection systems are write-only. you write the reflection and move on. there's no prompt to revisit it, no check-in on whether the insight led to change, no accountability loop. the reflection floats free, disconnected from the systems that actually govern your behavior.
+
+### the insight is abstract
+
+"i should be more [[intentionality|intentional]]" is an insight. it's also useless without specifics. what does intentional look like tomorrow morning? what's the first concrete action? abstract insights are hard to act on because they don't connect to specific moments of decision.
+
+## how to close the gap
+
+### from insight to action item
+
+the simplest technique: every reflection ends with a concrete next action. not "be more intentional" but "before starting work tomorrow, write down the one thing that matters most today." the action item has to be specific enough that you'd know whether you did it or not.
+
+### revisit, don't just write
+
+the value of weekly reflections isn't just the writing — it's the re-reading. looking back at last week's reflection and asking: did i actually do what i said i'd do? if not, why? the re-reading closes the loop.
+
+this is similar to [[resyncing]] — periodically checking whether your current trajectory matches your intended trajectory.
+
+### build it into systems
+
+if an insight is important enough, it should become a system, not just a note. "i notice i'm most productive in the morning" should become a rule: hard work goes in the morning, meetings in the afternoon. the insight moves from a reflection to a [[operation-optimization|workflow]].
+
+### share it
+
+telling someone your insight creates social accountability. it's also a filter — if you're not willing to tell someone "i realized i should do X differently," maybe the insight isn't as important as it felt during writing. [[public-vs-private|public writing]] is the scaled version of this.
+
+## the meta-reflection
+
+this page is itself a reflection about reflection. which means it's susceptible to the exact gap it describes. i've articulated the problem. the question is whether this articulation actually changes how i reflect going forward, or whether it joins the pile of insights that felt good to write and then faded.
+
+the honest answer: some of both. every time i write about the reflection gap, it gets a little more top-of-mind, a little more likely to influence the next reflection. it's not a switch that flips — it's a gradual rewiring. [[articulation-as-memory]] helps here: the more precisely i can name this pattern, the more likely i am to catch myself falling into it.
+
+and that's maybe the real lesson: closing the reflection gap isn't about one heroic act of willpower. it's about creating enough [[resets|resets]] and re-reads that the insight stays active instead of fading into the archive.
\ No newline at end of file
new file mode 100644
index 0000000..6845183
@@ -0,0 +1,45 @@
+---
+visibility: public-edit
+---
+
+# writing to understand
+
+writing doesn't record what you think. it discovers what you think. the act of putting words down changes the ideas themselves.
+
+## the discovery process
+
+joan didion said it plainly: "i write entirely to find out what i'm thinking, what i'm looking at, what i see and what it means." paul graham expanded on this — he estimates that half the ideas in any essay are ones he thought of while writing it. not before. during.
+
+this matches my experience exactly. i'll sit down to write about something i think i understand, and within a few paragraphs i'll hit a point where the sentence i'm writing doesn't quite work. the idea i had in my head was fuzzy, and the sentence demands precision. in the gap between the fuzzy idea and the precise sentence, new understanding forms.
+
+this is not a pleasant process. it's closer to [[rubber-duck-and-zoom-out|rubber duck debugging]] than to transcription. you're explaining your thinking to the page, and the page reveals that your thinking has holes.
+
+## why it works
+
+paul graham puts it well: "if writing down your ideas always makes them more precise and more complete, then no one who hasn't written about a topic has fully formed ideas about it." that's a strong claim but i think it's right.
+
+thinking feels fluid and complete in your head. you can hold a vague impression and feel like you understand something. writing forces serialization — you have to put one idea before another, make explicit connections, define terms. the constraints of language expose the gaps in thought.
+
+it's the same mechanism as [[assumptions-kill|assumption auditing]]. you think you know how the system works until you have to explain it step by step. the explaining surfaces the broken assumptions.
+
+## my experience with it
+
+i've written over a hundred reflections across different platforms — long-form in ideaflow, quick notes in apple notes, weekly reflections, blog drafts. the pattern is consistent: the writing that taught me the most was writing where i didn't know what i'd say when i started.
+
+the reflections where i sat down with a clear thesis and just wrote it out — those were fine. useful for [[articulation-as-memory|cementing]] what i already knew. but the reflections where i started with "i'm confused about X" or "something felt off about Y" — those were the ones that actually changed how i think.
+
+## the prerequisite
+
+you have to be willing to write badly. if you're editing while writing, you're not discovering — you're performing. the discovery happens in the messy first draft where you follow an idea wherever it goes, even if it goes somewhere dumb. especially if it goes somewhere dumb. because "dumb" ideas, articulated, sometimes turn out to be not dumb at all — or they reveal something about what you actually think that a polished version would hide.
+
+this connects to [[confidence]]. writing to understand requires the confidence to have bad ideas on the page. if you're afraid of writing something wrong, you'll stick to things you already know, and the discovery process doesn't happen.
+
+## the gap
+
+the frustrating part: writing reveals insights, but insights don't automatically change behavior. see [[the-reflection-gap]]. understanding what you think is necessary but not sufficient for acting on it. the question is always: what do i do with what i just discovered?
+
+## writing vs. talking
+
+talking also helps you think. but writing has an advantage: it's persistent. you can come back to it. you can notice contradictions between what you wrote last month and what you wrote today. you can watch your thinking evolve over time.
+
+talking is better for speed and for the social dimension — someone can push back in real time, ask the question that cracks open a new line of thinking. but for deep, sustained, honest thinking, writing is better. you can't bullshit a page the way you can bullshit a conversation.
\ No newline at end of file
new file mode 100644
index 0000000..f48fead
@@ -0,0 +1,35 @@
+---
+visibility: public-edit
+---
+
+# zooming out
+
+the practice of stepping back from work to see the bigger picture. one of the most consistently useful tools i've found.
+
+## what it looks like
+
+- take a walk with someone and talk about work
+- change of scenery — different room, go outside, work from somewhere new
+- spend time *thinking* about a problem instead of just grinding on it
+- step back, reflect, exercise
+
+i'm yet to have a zoom out that was not worth it. every single one has produced something — a reframe, a decision, a clarity moment that i wouldn't have gotten while tunneled in.
+
+## when to zoom out
+
+- when nothing is working — "backtrack like crazy" instead of pushing harder
+- when you feel stuck and the instinct is to keep going
+- when you realize you haven't asked "what are we even trying to do here?" in a while (see [[intentionality]])
+- when the work feels monotonous and creativity is dying
+
+at the neurotech startup i interned at, we had a structured version of this: a "growth" subteam focused on people development, habits, and zoom outs. the formal structure made it happen regularly instead of only when desperation hit. see [[startup-workflow]] for the full cadence.
+
+## the thinking trap
+
+spending time thinking about a problem is genuinely valuable. it gets insights you miss while tunneled. but the trap is that zooming out feels unproductive — your [[narratives]] around productivity can make you feel guilty for not typing.
+
+the fix: recognize that zooming out *is* work. some of my best breakthroughs came from walks, not from screens.
+
+## connection to resets
+
+zooming out overlaps with [[resets]] — especially the "tired" state resets like reflecting (staring into space) and going for walks. but zooming out is specifically about work clarity, not emotional regulation.
\ No newline at end of file