66533af33cc8927e7e5dbf04d06bcf6578f83d14
new file mode 100644
index 0000000..bdef3b2
@@ -0,0 +1,51 @@
+---
+visibility: public-edit
+---
+
+# young builder resources
+
+this is not a generic resource guide. this is what I (Harrison) have actually done, what I learned, and what I'd tell someone walking the same path.
+
+I'm a high school builder in the Bay Area. I've won 3.5 out of 5 hackathons, placed 2nd nationally at USAYPT, interned at a neurotech startup as their youngest hire, founded a Socratica chapter, published EEG research targeting IEEE TBME, and competed in more math/science competitions than I can count. I've also applied to programs I didn't get into (hi, RSI) and haven't raised a single dollar in formal funding.
+
+everything in this wiki is from personal experience. if I haven't done it, I say so.
+
+---
+
+## philosophy
+
+- [[anti-pipeline-manifesto|the anti-pipeline manifesto]] — why I chose growth over position, and why the standard pipeline is the most crowded lane
+- [[learning-paths|learning paths]] — my philosophy on learning by building. no courses, pull from resources, build things. specific paths for ML, web dev, hardware, research.
+
+## what you can do
+
+- [[competitions-hackathons|competitions & hackathons]] — every competition I've entered, how I did, and what I learned. hackathon advice from actually winning.
+- [[math-modeling|math modeling]] — the most underrated competitions for builders. HiMCM, MCM/ICM, M3 Challenge, MTFC, IMMC — and why modeling skills transfer to everything.
+- [[mun-debate|MUN & debate]] — how arguing, presenting, and thinking on your feet transfers to pitching, selling, and fundraising.
+- [[shipping-products|shipping products]] — you can build and ship real software with real users. the free stack, the process, and why products are your best credential.
+- [[hardware-projects|hardware projects]] — you can build physical things. Arduino → ESP32 → PCB design → integrated projects.
+- [[design-engineering|design engineering]] — physical design and fabrication. makerspaces, CAD, prototyping, and how to access tools.
+- [[publishing-research|publishing research]] — you can publish real research as a teen. how to find a PI, the process, journals, and the Davidson Fellows path.
+- [[creative-work|creative work]] — video, music, writing. creative outlets are real builder credentials and competition entries.
+- [[open-source|open source]] — contributing to open source is the most meritocratic environment. nobody cares about your age, only your code.
+- [[giving-talks|giving talks]] — you can present your work publicly. Socratica 5mof, conferences, hackathon demos, and the confidence flywheel.
+- [[personal-infrastructure|personal infrastructure]] — building your own tools teaches you more than any course. solve your own problems.
+
+## how to get there
+
+- [[summer-programs|summer programs & internships]] — I-Lab, Math in the Mountains, TKS, a neurotech startup. how I cold-emailed my way into a neurotech startup.
+- [[work-experience|work experience]] — startup internships via cold email, research assistant roles, paid work, and freelancing. you don't need formal programs.
+- [[communities|communities]] — the communities I'm actually in: Socratica (founded), Hack Club, Sunday Dinners, AGI House, Incepto House, and more.
+- [[mentorship-networking|mentorship & networking]] — how to cold-email, build relationships, and find mentors without being cringe.
+- [[funding-grants|funding & grants]] — an honest account: I haven't done formal funding. here's what I've earned and why I haven't needed more yet.
+- [[knowledge-management|knowledge management]] — building a personal knowledge system that compounds. notes, spaced repetition, CRM, reflection.
+- [[tools-stack|tools & stack]] — the exact tools I use daily. Claude Code (500+ sessions), Vercel, Cloudflare, Supabase, and the $0 stack.
+
+## other opportunities (haven't done these)
+
+directory of competitions, programs, and awards i haven't personally done but are worth knowing about. brief listings — go look them up if interested.
+
+- [[other-olympiads|other olympiads & math competitions]] — USACO, Putnam, ARML, Math Kangaroo, and more.
+- [[other-writing-competitions|writing competitions]] — literary competitions beyond Scholastic.
+- [[other-entrepreneurship-competitions|entrepreneurship competitions]] — business/startup competitions for high schoolers.
+- [[other-awards-scholarships|awards, scholarships & fellowships]] — honors and funding worth knowing about.
\ No newline at end of file
new file mode 100644
index 0000000..8b0c5d8
@@ -0,0 +1,107 @@
+---
+visibility: public-edit
+---
+
+# the anti-pipeline manifesto
+
+there's a pipeline. you know the one.
+
+AMC → AIME → USAMO. RSI. ISEF. Intel/Regeneron STS. perfect GPA. 15 APs. research with a professor. found a nonprofit. president of three clubs. volunteer trip to Guatemala. letter of recommendation from a Fields Medalist.
+
+apply to MIT, Stanford, Harvard. get in. go to FAANG. or go to McKinsey. or do a PhD. or start a startup with your college roommate using a playbook you learned from a YC lecture.
+
+this pipeline works. I'm not going to pretend it doesn't. people who follow it end up at good schools and get good jobs.
+
+but here's what nobody says: **the pipeline is crowded, the pipeline optimizes for credentials over capability, and the pipeline produces people who are very good at following pipelines.**
+
+## growth > position
+
+the most important decision I've made as a builder is choosing growth over position.
+
+**position** is where you are on a legible status ladder. your school's rank, your SAT score, which program accepted you, which company you interned at. position is what other people can see and evaluate.
+
+**growth** is how fast you're getting better at things that matter. how much you learned this month. how much harder of a problem you can solve now vs. six months ago. how much more capable you are as a builder.
+
+these are not the same thing, and they often conflict.
+
+- spending a summer grinding AMC problems to improve your score from 110 to 125 is position optimization. spending that summer [[shipping-products|building a product]] that ships to real users is growth optimization.
+- doing research with a famous professor so you can name-drop them is position. doing research on a problem you genuinely care about with whoever will mentor you is growth.
+- applying to RSI because everyone says you should is position. see [[summer-programs]] for an honest look at which programs matter. applying because you specifically want to do research at MIT this summer is growth.
+
+the growth path is scarier because it's less legible. see [[learning-paths]] for how to actually learn outside the pipeline. nobody has a rubric for "learned a lot and became more capable." but it compounds faster because you're actually building skills, not just building a resume.
+
+## the credential trap
+
+here's the trap: every hour you spend on credentials is an hour you're not spending on capability.
+
+I deliberately chose NOT to do RSI. NOT to follow the YC pipeline. NOT to optimize for prestige.
+
+instead I:
+- interned at a neurotech startup as their youngest intern — not because it was prestigious, but because the [[work-experience|work]] was interesting
+- published EEG research targeting IEEE TBME — not because I needed a publication, but because the science was cool
+- won math modeling competitions (HiMCM, MCM/ICM, M3, MTFC) — not because they look good, but because I love applied math
+- won 3.5/5 [[competitions-hackathons|hackathons]] — because hackathons are fun and you learn fast
+- started a builder community at my school — because I wanted a [[communities|community of builders]], not because I needed "founded a club" on my resume
+
+none of these were chosen for their prestige value. same philosophy applies to [[funding-grants]] — pursue funding for the work, not the resume line. they were chosen because they made me better at things I care about. the resume impact was a side effect, not the goal.
+
+## the Asian STEM male problem
+
+I'll say the thing everyone thinks but nobody says out loud.
+
+if you're an Asian male in STEM — and especially if you're in the Bay Area — the "standard pipeline" is literally the most crowded lane you could possibly be in. there are thousands of students with your same profile: perfect grades, AMC/AIME, research, robotics club, piano.
+
+admissions officers have seen your application a thousand times. not because there's anything wrong with you, but because the pipeline produces identical-looking candidates.
+
+the way to differentiate is not to do the same things better. it's to do different things entirely. build something nobody else has built. solve a problem nobody else is solving. have experiences that can't be replicated by following a playbook.
+
+this isn't about gaming admissions. it's about being genuinely interesting — and the way to be genuinely interesting is to do genuinely interesting things, not to follow the same path as everyone else more efficiently.
+
+## the FOMO trap
+
+every ambitious teen I know (including me) deals with FOMO. someone got into RSI. someone won ISEF. someone raised funding. someone got into Y Combinator.
+
+here's the antidote: **FOMO is about position, not growth.**
+
+you feel FOMO when someone else's position improves relative to yours. you don't feel FOMO when someone else learns something new — because learning isn't zero-sum.
+
+when you catch yourself feeling FOMO, ask: "am I jealous of what they're learning, or what it looks like?" if it's the latter, it's not worth your attention.
+
+## fit over selectivity
+
+when choosing what to do — programs, competitions, internships, projects — optimize for fit, not selectivity.
+
+a program with a 50% acceptance rate that perfectly matches your interests will make you grow faster than a program with a 2% acceptance rate that doesn't.
+
+the "most selective" program is not the "best" program. it's the program with the most applicants relative to spots. that's a measure of demand, not quality.
+
+ask:
+- will this give me skills I can't get elsewhere?
+- will this connect me with people I want to learn from?
+- will this let me work on problems I care about?
+- will I be in an environment where I can do my best work?
+
+if the answer to these is yes, go. if the answer is "it'll look good on my application," skip it.
+
+## the 0.8/0.2 split
+
+here's my framework for thinking about college apps as a builder:
+
+**spend 80% of your time building. spend 20% of your time on presentation.**
+
+the 80% is the work itself — the projects, the research, the competitions, the learning. this is what actually makes you a strong candidate.
+
+the 20% is making sure the work is visible and well-communicated — your personal site, your github, your essays, your application. this matters, but it's secondary.
+
+most pipeline students invert this ratio. they spend 80% of their time optimizing for how things look and 20% on the actual work. that's why their applications feel hollow — because they are.
+
+if you've spent 4 years genuinely building things, the application writes itself. you have real stories, real impact, real growth to talk about. the hard part is doing the work, not describing it.
+
+## what this means practically
+
+1. **build things you care about.** not things that look good. the things that look good in hindsight are always the things that were genuine.
+2. **go deep, not wide.** one real accomplishment is worth ten resume lines.
+3. **choose your own path.** if everyone is doing X, that's a reason to consider doing Y.
+4. **embrace illegibility.** the best things you do might not be easily explainable on a resume. that's fine. the people who matter will understand.
+5. **play long games.** the pipeline optimizes for what looks good at 17. building real things optimizes for what you'll be good at when you're 25.
+6. **don't be contrarian for its own sake.** the anti-pipeline is not "do the opposite of everyone." it's "do what's genuinely right for you, even if that happens to be different from what everyone else is doing." sometimes the pipeline IS the right path. just make sure you're choosing it, not defaulting to it.
\ No newline at end of file
new file mode 100644
index 0000000..bc98ea0
@@ -0,0 +1,60 @@
+---
+visibility: public-edit
+---
+
+# communities
+
+the single most important thing for a young builder is finding other people who are building. not people who talk about building — people who are actually making things. your peer group determines your trajectory more than any program, course, or mentor.
+
+here are the communities I'm actually part of and what I've gotten from each.
+
+## communities I founded
+
+### Socratica at my school
+- **what:** IRL coworking sessions. show up, work on your passion project, demo what you made at the end.
+- **the backstory:** I started a Socratica chapter at my school in December 2025. Socratica is a global network — started at a Canadian university, now 40+ chapters in 10+ countries. 2500+ people at the 2025 symposium.
+- **why I started it:** I wanted a community of builders at my school. not a club with officers and meetings — a space where people just show up and make things.
+- **what I learned:** organizing something is one of the highest-leverage things you can do. you meet everyone, you shape the culture, and you learn logistics. the demos at the end of each session are the best part — you see what everyone's working on and it's genuinely inspiring.
+- **how to start one:** check socratica.info. they have a toolbox for starting chapters. the format is simple — show up, work, demo. the simplicity is the point.
+
+## communities I'm active in
+
+### Hack Club
+- **what:** global nonprofit network of high school coding clubs. 1000+ clubs, 80,000+ students. founded by Zach Latta.
+- **the real value:** the Slack community. hundreds of technical teenagers active at all hours. code review, project feedback, collaborators at 2am.
+- **honest take:** probably the single best community for high school builders who code. the culture is "ship things" not "talk about shipping things." free, online, genuinely welcoming.
+- **also:** Hack Club Bank is a fiscal sponsorship platform — they'll hold money for your projects legally. useful if you're running events or need to handle money as a minor.
+
+### Sunday Dinners
+- **what:** invite-only dinner series for young builders in the Bay Area.
+- **what I get from it:** these are where you meet people a few years ahead of you. college-age founders, early-career engineers, people starting companies. the conversations are higher-level than high school communities.
+- **how I got in:** know someone who goes. attend adjacent events. build something notable enough that organizers invite you. see [[mentorship-networking]] for how to make these connections.
+
+### AGI House / SVFounders
+- **what:** AGI House hosts AI-focused events in SF. SVFounders is a founder community connected through its organizer.
+- **what I get from it:** the Bay Area has an ecosystem of builder communities that's unmatched anywhere else. as a teen, you won't get into everything, but showing up to public events and being genuinely interesting goes a long way. I won a [[competitions-hackathons|hackathon]] at AGI House which helped.
+
+### Incepto House
+- **what:** regular hacking sessions. I've been going since December 2025.
+- **what I get from it:** a smaller, more intimate builder community than the big events. you actually get to know people and work alongside them. the organizer creates a good environment for focused building.
+
+### Twitter/X builder scene
+- **what:** there's a loose community of young builders on Twitter. you recognize them by the projects in their bios and the threads about what they're building.
+- **honest take:** twitter is where you build a public identity as a builder. sharing your [[open-source]] work and [[shipping-products|products]] here compounds your visibility. it's also where you find mentors, collaborators, and opportunities you wouldn't find anywhere else. the key: post about what you're building, not what you think about building. show your work.
+- **how to start:** follow builders whose work you admire. reply thoughtfully. share your own projects. don't try to be an "influencer" — just be someone who builds things and talks about it.
+
+### G4G / Math in the Mountains / math community
+- **what:** Gathering 4 Gardner is a math/puzzle community. Math in the Mountains is a [[summer-programs|program]] in Jackson, WY directed by a renowned mathematician where I was a counselor (summer 2025).
+- **what I get from it:** the math community is its own world. the people are some of the most interesting I've met. it's a different vibe from tech — more playful, more curious, less transactional.
+
+### university dorm lectures
+- **what:** lecture series happening at university dorms. I attend these.
+- **honest take:** you learn a lot and meet interesting people. the talks tend to be more intellectual than typical tech events. see [[giving-talks]] for how to go from attending to presenting.
+
+## how to actually get value from communities
+
+1. **show up consistently.** the best relationships form over months, not at a single event.
+2. **contribute before you ask.** help others with their projects before asking for help with yours.
+3. **be the person who [[shipping-products|ships]].** in any community, the person who's always launching things gets the most attention and the best opportunities.
+4. **don't community-hop.** pick 1-2 communities and go deep rather than joining 10 and being a ghost in all of them.
+5. **organize something.** starting a Socratica chapter was one of the best things I did. organizers meet everyone.
\ No newline at end of file
new file mode 100644
index 0000000..5329081
@@ -0,0 +1,141 @@
+---
+visibility: public-edit
+---
+
+# competitions & hackathons
+
+i've done a lot of competitions. here's an honest account of every one — what it was, how I did, and what I actually learned.
+
+## hackathons (3.5 wins out of 5)
+
+hackathons are where I learn fastest. you compress months of learning into 24-48 hours, and you come out with something real. the [[communities]] you find through competitions are often where lasting relationships start.
+
+### TRAE Solo Hackathon (Oct 2025)
+- **result:** 1st place out of 29 ($1500)
+- **where:** a tech company's office
+- **what I learned:** solo hackathons force you to scope ruthlessly. no teammate to split work with means every feature choice matters.
+
+### AGI House Agent Skills Build Day (Mar 14, 2026)
+- **result:** won
+- **team:** built a Claude skill with two teammates. also launched referral.bike at the same event.
+- **what I learned:** the best hackathon teams have complementary skills, not overlapping ones.
+
+### EventConnect at an AI company's hackathon event
+- **result:** won audience vote
+- **team:** built with a friend
+- **what I learned:** audience votes reward demos that feel magical. polish the demo.
+
+### MongoDB Agentic Memory & Context Engineering Hackathon (Oct 11, 2025)
+- **result:** top 6 out of 70
+- **where:** SF
+- **what I learned:** "top 6 out of 70" feels like almost-winning, which is its own kind of useful. close losses sharpen you.
+
+### Gemini Multimodal Hackathon (Oct 18-19, 2025)
+- **result:** produced OnCue demo
+- **what I learned:** multimodal demos are hard to scope. the "wow" moment needs to be in the first 30 seconds.
+
+### organizing: Startup Pitch Hackathon (May 9, 2026)
+- co-organizing this. $5k/$2.5k/$1.25k prizes. being on the other side of hackathons teaches you what judges actually look for.
+
+### upcoming: SF Hackathon (Apr 25, 2026)
+
+### hackathon advice (earned from actually winning)
+
+1. **the demo is everything.** judges spend 2-5 minutes with your project. if you can't show something impressive in that time, nothing else matters.
+2. **scope aggressively.** the #1 mistake is building too much. pick one impressive thing and polish it.
+3. **the 70/30 rule:** spend 70% of your time on the core feature and 30% on the demo/presentation. most teams invert this.
+4. **pick the right prize track.** "best use of [sponsor API]" categories are usually less competitive than "best overall." using a sponsor's API well is often a free win.
+5. **tell a story.** judges remember the team that had a compelling "why" more than the team with the most features.
+6. **[[shipping-products|ship it]].** having a live URL or working app beats a slide deck every time.
+
+## math competitions
+
+math competitions teach you to think precisely under pressure. the skills transfer to everything.
+
+### AMC 10
+- **scores:** 91.5/73.5 (2024), 88.5/97.5 (2023)
+- **honest take:** the canonical pipeline. I did it, it was useful for building mathematical maturity, but I didn't make AIME and that's fine. the AMC grind has diminishing returns if you're not naturally headed toward USAMO.
+
+### HiMCM (Nov 2025)
+- **team:** three teammates
+- **what we did:** fire/evacuation scenario, Monte Carlo simulation
+- **honest take:** massively underrated competition. see [[math-modeling]] for the full breakdown. this is the closest to actual applied math/engineering work. 36 hours, real-world problem, build a model. I love math modeling competitions more than contest math.
+
+### COMAP MCM/ICM
+- **result:** Meritorious (top 10%)
+- **what we did:** spectral bisection, cellular automata, graph traversal
+- **honest take:** harder and more prestigious than HiMCM. competing as high schoolers against college teams and placing top 10% was a genuine accomplishment.
+
+### M3 Challenge
+- **result:** 143/770 (top 19.8%), qualified for second round
+- **honest take:** 14-hour math modeling challenge, free to enter. good entry point into modeling competitions. we qualified for the second round which felt great.
+
+### MTFC
+- **result:** semifinalist (2025-26)
+- **what we did:** equitable bus routing
+- **honest take:** the problem was genuinely interesting. applied math with social impact.
+
+### IMMC 2026 (Mar 18-23)
+- international math modeling. similar flavor to HiMCM/MCM but with an international pool.
+
+### BmMT
+- **result:** 2nd best puzzle round score (2023)
+
+### SMT (a university math tournament)
+- **result:** honorable mention individual + team
+
+### NMT (my school's math tournament)
+- I co-lead this. organizing a math tournament teaches you logistics, problem-writing, and community-building all at once.
+
+## physics competitions
+
+### USAYPT (Jan 2026)
+- **result:** 2nd nationally. the format (physics meets debate) also develops [[giving-talks|public speaking]] skills
+- **team:** 11 members
+- **honest take:** unique format — physics meets debate. you present research, other teams poke holes in it. teaches you to defend ideas rigorously. placing 2nd nationally with this team was one of my proudest moments.
+
+### F=ma Exam (2026)
+- the qualifier for USAPhO. took it.
+
+## science & research competitions
+
+### BL4S / CERN BeamLine for Schools (submitted Mar 2026)
+- **team:** four members
+- **what:** proton beam shielding simulation
+- **honest take:** writing a proposal for actual CERN beam time forces you to think like a real physicist. even if we don't get selected, the proposal-writing process was incredibly valuable.
+
+### Davidson Fellows (submitted Feb 2026)
+- **what:** submitted my paper on anesthetics/EEG
+- **honest take:** this rewards depth. you need to have done something genuinely significant. I submitted my EEG [[publishing-research|research]].
+
+### Golden Gate STEM Fair (early Mar 2026)
+- regional science fair.
+
+### Breakthrough Junior Challenge
+- **result:** top 40%
+- **what I did:** RL intuition video
+- **honest take:** this is a video competition, not a research competition. production quality matters as much as scientific accuracy. top 40% isn't a win, but making the video taught me about science communication.
+
+### Congressional App Challenge
+- **what I submitted:** Pause app
+- **result:** congressional certification
+- **honest take:** relatively low bar compared to other competitions, but the certification from your congressperson is a nice touch.
+
+### other competitions I've done
+- **BIG Idea Competition:** Honorable Mention
+- **Scholastic Writing Awards:** submitted Dec 2025
+- **NACLO:** open round (computational linguistics — surprisingly fun)
+- **PicoCTF 2024:** cybersecurity CTF. good for learning security basics.
+- **Wharton Data Science:** participated
+- **Fed Challenge (NY Fed):** did this with a teammate. made a corn podcast. yes, a corn podcast.
+- **Ethics Bowl:** went 2-1
+
+## chess
+
+won USATW U1000 6-0, placed at SF Scholastic, won at a local tournament, bughouse 8-0. chess is the thing I do for fun that happens to also be competitive.
+
+## the meta
+
+competitions are tools, not goals. I did a lot of them — probably too many. the ones that taught me the most were the ones where I was genuinely interested in the problem (math modeling, USAYPT, hackathons), not the ones where I was chasing a result.
+
+if you're going to compete, go deep in one or two areas rather than shallow in five. see [[learning-paths]] for why interest-driven learning beats credential-driven learning. I went too wide sometimes. a national-level result in one thing is worth more than mediocre participation in everything.
\ No newline at end of file
new file mode 100644
index 0000000..97e763b
@@ -0,0 +1,65 @@
+---
+visibility: public-edit
+---
+
+# creative work
+
+creative outlets are real builder credentials. they differentiate you from the "STEM robot" stereotype and teach communication skills that transfer to everything. the best builders I know are also musicians, writers, filmmakers, or artists — because creativity is creativity, regardless of medium.
+
+## video production
+
+### YouTube: Dumb Derivatives
+
+I ran a YouTube channel called "Dumb Derivatives" where I made educational science/math videos:
+
+- **RL intuition video** — submitted to Breakthrough Junior Challenge, placed top 40%. the production quality matters as much as the science in BJC. it's a video competition, not a research competition.
+- **Manim mathematical induction video** — used 3Blue1Brown's Manim library for mathematical animations. learning Manim is a superpower for anyone who needs to explain math visually.
+- **Pi estimation video** — Monte Carlo pi estimation, visualized
+- **piano performances and ukulele covers** — music content, because why not
+- **Pause launch video** — product launch videos are an underrated way to get users for the things you [[shipping-products|ship]]
+- **Databox timelapse** — timelapse of building a [[hardware-projects|hardware project]] from start to finish. documenting the build process makes hardware projects 10x more shareable.
+
+### Breakthrough Junior Challenge
+
+the BJC is a global video competition for teens (ages 13-18) to explain a complex scientific idea in under 1:30. the winner gets a scholarship, their teacher gets $50,000, and their school gets a $100,000 science lab. deadline is usually late June.
+
+I placed top 40%, which isn't a win — but making the video taught me science communication, video editing, and how to distill complex ideas into short formats. even if you don't win, the video lives on your YouTube channel forever as a portfolio piece.
+
+### video production skills
+
+tools I use: Premiere Pro, After Effects, Photoshop. these are industry-standard and free through many school licenses. DaVinci Resolve is a free alternative that's genuinely professional-grade.
+
+project videos, demo recordings, launch trailers — video production skills make everything you build more visible. a 60-second demo video gets more engagement than a 2000-word blog post.
+
+## music
+
+music is the thing I do purely because I love it. it's not strategic, it's not for my resume — but it ends up mattering anyway.
+
+- **piano:** self-taught, started 9th grade. being self-taught at something is its own kind of proof that you can learn independently.
+- **ukulele:** self-taught, summer 2024
+- **Ableton production:** original compositions — "Edge of Chaos," "Contemplation," "Changing All My Colors." music production is programming-adjacent (sequencing, signal processing, layering) and the creative process is identical to building software: start with a rough idea, iterate, refine.
+
+music is worth mentioning because the [[anti-pipeline-manifesto|anti-pipeline]] explicitly values being genuinely interesting. admissions officers, mentors, investors — they all respond to people who have depth outside their main thing.
+
+## writing
+
+### Scholastic Art & Writing Awards
+
+I submitted in December 2025. the categories cover everything: poetry, short story, novel, journalism, personal essay, humor, science fiction. if you write at all, submit — the regional → national pipeline is worth engaging with.
+
+### other writing
+
+- **literary magazine submissions** — school and external magazines
+- **blog drafts** — "The End of Fragmented Software" and other essays. even unpublished writing sharpens your thinking.
+- **essay writing as self-understanding** — writing about what you're building and why forces you to articulate things you only vaguely understood. some of the best writing I've done was never published — it was just for me.
+
+## creative work as competition entries
+
+creative work can be submitted to:
+- Breakthrough Junior Challenge (video)
+- Scholastic Writing Awards (writing)
+- Congressional App Challenge (if the app has creative elements)
+- film festivals (short films, documentaries)
+- music competitions
+
+the [[anti-pipeline-manifesto]] point: being genuinely interesting means having genuine interests — not just strategic extracurriculars. creative work that you do because you care about it reads as authentic because it is authentic.
\ No newline at end of file
new file mode 100644
index 0000000..b723409
@@ -0,0 +1,74 @@
+---
+visibility: public-edit
+---
+
+# design engineering
+
+physical design and fabrication are accessible skills. you don't need an engineering degree to laser-cut a part, 3D print an enclosure, or solder a circuit. if you have access to a makerspace — and more people do than realize it — you can build physical things right now.
+
+## access to fabrication
+
+### school makerspaces
+
+my school's makerspace has laser cutters, 3D printers, soldering stations, wood shop, and metal shop. I spent a summer there (I-Lab internship, summer 2024) learning to use every machine and building out a section of the shop itself. see [[work-experience]] for more on what that taught me.
+
+not every school has a professional-level shop, but many have at least a 3D printer or a basic electronics lab. use what you have.
+
+### community makerspaces
+
+if your school doesn't have a makerspace, community options exist:
+
+- **public libraries** — increasingly have 3D printers, laser cutters, and basic electronics stations. many offer free or cheap access to teens.
+- **dedicated makerspaces** — membership-based workshops with full tool access. look for local ones on makerspaces.com or Google Maps.
+- **university makerspaces** — some university fab labs allow community access, especially for students. ask.
+- **TechShop successors** — after TechShop closed, many regional makerspaces filled the gap.
+
+the key: you don't need to own the tools. you need access to them for a few hours at a time.
+
+### online fabrication
+
+for things you can't make locally:
+
+- **JLCPCB / PCBWay** — PCB fabrication starting at $2 for 5 boards. design in KiCad, upload the gerber files, receive professional boards in a week. see [[hardware-projects]] for the full workflow.
+- **SendCutSend** — laser cutting and waterjet cutting from uploaded files. metals, plastics, wood.
+- **Shapeways / JLCPCB 3D printing** — if you need materials your local 3D printer can't handle (metal, resin, nylon).
+- **PCB assembly services** — JLCPCB and PCBWay will also solder components onto your boards for a few dollars per board.
+
+## projects that teach you
+
+design engineering is best learned by building things for real use cases, not exercises.
+
+### things I built
+
+- **magnetic chess set** — a gift. custom woodwork with embedded magnets so pieces snap into place. this taught me precision woodworking and thinking about user experience in physical objects.
+- **wolf toys for a local zoo** — designed and fabricated toys that actual wolves would play with. the constraint of "this has to be safe and interesting for a wolf" forced creative thinking.
+- **Rube Goldberg machine** — the classic. teaches systems thinking — each stage depends on the previous one working reliably.
+- **soap box derby racer** — full-scale vehicle. structural engineering, aerodynamics (or at least an attempt at it), and the experience of building something big.
+- **Boop boardgame** — game design is product design. you're designing for user experience, playability, and manufacturability.
+- **puzzle box** — mechanical design with hidden mechanisms. teaches you to think about how parts interact.
+
+### project ideas for getting started
+
+- **custom phone stand** — 3D print or laser cut. simple, useful, teaches the design-to-fabrication pipeline.
+- **enclosure for an electronics project** — if you're doing [[hardware-projects]], designing a case for your ESP32 project is a natural next step.
+- **a gift** — making something physical for someone forces you to think about quality and finish in a way that personal projects don't.
+- **a tool** — something you actually need. a cable organizer, a desk shelf, a custom bracket. solving your own problem is the best motivation.
+
+## the design process
+
+1. **sketch first.** pen and paper. don't jump into CAD. get the concept right before you commit to dimensions.
+2. **CAD it.** Fusion 360 (free for students), Onshape (free, browser-based), or FreeCAD (open source). parametric modeling lets you change dimensions without starting over.
+3. **prototype.** 3D print or laser cut the first version. it will be wrong. that's fine — the point is to find what's wrong cheaply.
+4. **iterate.** fix what's wrong, print again. physical prototyping cycles are slower than software (hours, not seconds), so think before you print.
+5. **finish.** sanding, painting, assembly. the difference between "I made this" and "this looks professional" is in the finishing.
+
+## skills that transfer
+
+design engineering skills transfer to:
+
+- **[[hardware-projects]]** — understanding mechanical design makes your electronics projects better (enclosures, mounting, thermal management)
+- **[[shipping-products]]** — if you ever build a physical product, you need to know how things are made
+- **[[publishing-research]]** — experimental apparatus design is a huge part of lab research
+- **[[work-experience]]** — fabrication skills are directly employable (my I-Lab internship was literally this)
+
+the combination of software skills + fabrication skills is rare and powerful. most teen builders are software-only. adding physical fabrication to your toolkit makes you a more complete engineer and opens up project possibilities that pure software builders can't touch.
\ No newline at end of file
new file mode 100644
index 0000000..1f18d1f
@@ -0,0 +1,55 @@
+---
+visibility: public-edit
+---
+
+# funding & grants
+
+I'll be honest: I haven't done any formal funding programs. no Thiel Fellowship, no Emergent Ventures, no 1517, no Z Fellows. the only money I've made from building is hackathon prizes.
+
+here's what that actually looks like.
+
+## what I've actually earned
+
+### hackathon prizes
+- **$1500** — 1st place at TRAE Solo [[competitions-hackathons|Hackathon]] (Oct 2025)
+- various smaller wins at AGI House, an AI company's hackathon event
+
+that's it. that's the financial outcome so far. I'm not going to pretend otherwise.
+
+## why I haven't pursued formal funding
+
+a few reasons:
+
+1. **I haven't needed it yet.** the free stack (Vercel, Cloudflare, Supabase, GitHub Education) means you can [[shipping-products|build and deploy products]] for $0. see [[tools-stack]] for the full breakdown. I haven't hit a point where money was the bottleneck.
+2. **the projects I've built haven't been "fundable" in the traditional sense.** hackathon projects, research, tools for myself — these aren't venture-scale businesses (yet).
+3. **I'm not anti-funding, I just haven't had the right thing to fund.** applying for funding without a clear use for the money is a waste of everyone's time.
+
+## programs I'm aware of but haven't done
+
+I'm not going to write detailed guides on programs I haven't experienced. but these are the ones I know about through my network:
+
+- **Thiel Fellowship:** $200k over 2 years to skip/leave college and build. ~15 fellows/year. the most prestigious young builder fellowship. managed by 1517 Fund.
+- **Emergent Ventures (Tyler Cowen):** $1k-$50k grants, minimal strings attached. reportedly fast process. 13+ eligible. this is probably the most accessible one for young builders.
+- **1517 Fund:** VC fund backing founders without college degrees. also runs Medici Project ($1k grants for interesting projects).
+- **Z Fellows:** $10k + one week in SF with mentorship.
+- **Hack Club grants:** various grant programs for teen projects throughout the year. Hack Club is also one of the best [[communities]] for young builders.
+
+if I end up doing any of these, I'll update this page with an honest account.
+
+## the practical reality of money as a teen builder
+
+the legal stuff is annoying:
+- you can't sign contracts as a minor — parents may need to co-sign
+- bank accounts need to be custodial or have a parent on them
+- incorporating requires a parent or adult as director
+- grant income is taxable
+
+the workarounds:
+- **parent as legal wrapper:** many teen founders have a parent as the technical officer/director. standard practice, investors are used to it.
+- **fiscal sponsors:** Hack Club Bank holds money legally and disburses it to you. useful for running events or receiving grants.
+
+## what I'd tell my past self
+
+don't optimize for funding. build the thing. if it's good, the funding will follow. every funding application is 10x stronger if you have a working prototype with users. and the [[mentorship-networking|connections]] you make through the application process can be as valuable as the money.
+
+and honestly — the free tier of modern dev tools is so generous that "I need money to build" is rarely true for software projects. the bottleneck is almost never money. it's time, skill, and knowing what to build. often a [[work-experience|paid internship]] or hackathon prize is a more practical path to funding your work.
\ No newline at end of file
new file mode 100644
index 0000000..1d5a69a
@@ -0,0 +1,73 @@
+---
+visibility: public-edit
+---
+
+# giving talks
+
+you can give talks and present your work publicly as a teenager. nobody will stop you — and in most builder [[communities]], they'll actively encourage it. public speaking is one of those skills that compounds: every talk makes the next one easier, and every talk puts you in front of people who might become [[mentorship-networking|mentors]], collaborators, or friends.
+
+## start small: the 5-minute-of-fame format
+
+the easiest way to start is Socratica's 5-minute-of-fame (5mof) format: five minutes, any topic, friendly audience. the stakes are low and the feedback is immediate.
+
+I gave a 5mof at Socratica on vibe coding — framed as a guessing game ("what can/can't Claude Code do?"). five minutes is short enough that you can't spiral into anxiety about it, but long enough to say something real. the audience is other builders who are there to support each other, not to judge.
+
+if your school or community doesn't have a Socratica chapter, start one. see [[communities]] for how.
+
+## conference talks
+
+once you've done a few informal talks, conferences are the next step.
+
+### talks I've given
+
+- **ILC (Innovative Learning Conference):** presented a talk about innovation culture at my school with a friend. this was a prepared talk at a real education conference — slides, audience of educators and students.
+- **university dorm lectures:** presented on consciousness, drawing on my EEG/neurotech background from my neurotech internship and [[publishing-research|research]]. the audience was university students, which was intimidating but taught me to present to a technical crowd.
+- **Asilomar Microcomputer Workshop (AMW):** invited to speak by an organizer (May 2026). this is an invitation-only workshop — the talk came through [[mentorship-networking|network connections]], not a cold application.
+
+### how to get conference speaking slots
+
+1. **start at your school.** class presentations, club demos, school assemblies. every opportunity to present counts as practice.
+2. **present at community events.** Socratica 5mof, [[competitions-hackathons|hackathon]] demo days, meetup lightning talks. these are the farm league.
+3. **apply to conferences with student/lightning talk tracks.** many conferences explicitly welcome student speakers:
+ - **JSHS (Junior Science and Humanities Symposium)** — present original STEM research, regionals to nationals
+ - **NeurIPS** has had a High School Projects Track with 330+ submissions
+ - **education conferences** like Deeper Learning often feature student speakers
+ - **local tech meetups** usually have open lightning talk slots — just ask the organizer
+4. **get invited through your network.** my AMW talk came through a connection, not an application. when people know your work, invitations follow. this is why [[shipping-products|shipping products]] and [[publishing-research|publishing research]] matter — they make you someone worth inviting.
+
+## hackathon demos as speaking practice
+
+every [[competitions-hackathons|hackathon]] ends with a demo. this is public speaking in disguise — you're pitching your project to judges and an audience in 2-5 minutes. the pressure of a timed demo with stakes teaches you:
+
+- how to explain technical work to non-technical people
+- how to structure a narrative (problem → solution → demo → impact)
+- how to handle Q&A
+- how to recover when your demo breaks live (and it will)
+
+if you're doing hackathons anyway, you're already practicing public speaking.
+
+## the pitch skill
+
+giving talks and pitching are the same muscle. the skills transfer directly to:
+
+- **[[funding-grants|grant applications]]** — many grants have a pitch component
+- **[[mentorship-networking|networking]]** — a 30-second explanation of what you're building IS a pitch
+- **[[competitions-hackathons|competition presentations]]** — USAYPT, science fairs, hackathon demos
+- **eventually, fundraising** — if you start a company, every investor meeting is a talk
+
+## practical tips
+
+- **practice out loud.** reading your slides silently is not practice. say the words, time yourself, record yourself.
+- **one idea per slide.** wall-of-text slides are a crutch. if you need to read your slides, you don't know your material.
+- **demos > slides.** a working demo is more compelling than any slide deck. show the thing.
+- **energy matters more than polish.** audiences forgive rough slides from someone who clearly cares about their topic. they don't forgive polished slides delivered in a monotone.
+- **ask for feedback.** after every talk, ask someone you trust: "what was unclear? what was boring? what should I cut?"
+- **record everything.** even phone recordings. watching yourself present is painful but educational.
+
+## the confidence flywheel
+
+here's what happens: you give a talk → someone in the audience is interested → they introduce you to someone → that person invites you to speak somewhere else → bigger audience → more connections → more invitations.
+
+talks build your reputation in [[communities]] faster than almost anything else. when you stand up and present, you become "the person who built X" in people's minds. that identity compounds.
+
+the [[mun-debate|debate and MUN]] skills transfer directly here — if you've done Model UN or Ethics Bowl, you already know how to argue, present, and think on your feet. the transition to tech talks is mostly about switching from persuasion to explanation.
\ No newline at end of file
new file mode 100644
index 0000000..39ef45c
@@ -0,0 +1,102 @@
+---
+visibility: public-edit
+---
+
+# hardware projects
+
+you can build physical things, not just software. hardware is harder — debugging is slower, iteration costs money, and you can't ctrl-Z a burnt component — but it's more impressive because fewer people do it. and the satisfaction of holding something you designed and built is different from anything in software.
+
+## my hardware journey
+
+each project taught me something the previous one didn't.
+
+### mug warmer circuit
+- MOSFETs, RC timing circuit for auto-shutoff
+- ~6 hours of debugging: dead transistor, dead LED, dead capacitor (three separate dead components in one project)
+- also built a taser from a capacitor and helicopters from motors during this period
+- **the lesson:** hardware debugging means swapping components one at a time and testing. there's no stack trace. patience is mandatory.
+
+### red/green LED status board
+- 3x5 multiplexed LED matrix on perfboard
+- first time using perfboard, first real C++ for hardware
+- **the lesson:** multiplexing is elegant — control 15 LEDs with 8 pins. understanding how hardware tricks reduce pin count gives you intuition for why chips are designed the way they are.
+
+### ESP32 audio (INMP441 I2S mic)
+- **30 hours of debugging.** thirty.
+- the key bug: `setFollowRedirects` was silently dropping the POST body on a Google redirect. one line fix unblocked everything.
+- **the lesson:** hardware bugs that are actually software bugs are the worst kind. the I2S mic hardware was fine the whole time — it was an HTTP client behavior that was wrong. you have to be willing to question every layer of the stack.
+
+### KiCad PCB design
+- learned the schematic → PCB layout workflow
+- figured out the correct ESP32-DevKit-V1-DOIT schematics (there are multiple versions floating around with subtle differences)
+- **the lesson:** PCB design is surprisingly accessible. KiCad is free, and fabrication costs $2-5 per board.
+
+### Databox
+- full ESP32 PCB → Google Sheets data pipeline
+- sensor data flows from hardware to the cloud via Apps Script
+- made a project video + timelapse of the entire build
+- **the lesson:** end-to-end projects (hardware + firmware + cloud) are rare and impressive. most people can do one layer. doing all three is a differentiator.
+
+## design engineering at school
+
+my school's makerspace gave me access to serious fabrication tools. not every school has a professional-level shop, but makerspaces are increasingly common — and community makerspaces exist everywhere.
+
+projects I built:
+- **magnetic chess set** as a gift — custom woodwork + embedded magnets
+- **wolf toys for a local zoo** — designed and fabricated toys for actual wolves
+- **circuits + micro:bits + servos** — small electronics projects that built my foundation
+- **Rube Goldberg machine** — the classic engineering exercise. teaches you to think about systems.
+- **soap box derby racer** — full-scale vehicle design and fabrication
+- **Boop boardgame** — game design + physical fabrication
+- **triangle puzzle, pen holder, puzzle box** — smaller projects that each taught a specific technique
+
+see [[design-engineering]] for more on the fabrication side.
+
+## getting started with hardware
+
+the path I'd recommend:
+
+### stage 1: Arduino
+- buy an Arduino Uno starter kit (~$30). it comes with LEDs, resistors, sensors, a breadboard.
+- build the example projects: blink an LED, read a sensor, control a servo.
+- this takes a weekend. you'll know within days if hardware excites you.
+
+### stage 2: ESP32
+- upgrade to an ESP32 dev board (~$8). it has WiFi and Bluetooth built in.
+- connect to the internet. send sensor data somewhere. control things remotely.
+- the jump from Arduino to ESP32 is where projects become "real" — they can talk to the internet.
+
+### stage 3: PCB design
+- learn KiCad (free, open source). design a simple board — even just an LED circuit.
+- order it from JLCPCB ($2 for 5 boards, ships in a week) or PCBWay.
+- holding a PCB you designed is a special feeling. it's also a concrete artifact you can show people.
+
+### stage 4: integrated projects
+- combine hardware + firmware + software. sensor → microcontroller → cloud → dashboard.
+- this is where you start building things that could be [[shipping-products|products]].
+
+## auditing CS140E
+
+I'm auditing CS140E (Winter 2026) — a university embedded OS course where you write OS components from scratch on a Raspberry Pi/ARM. you don't need to be enrolled to learn this material. the course materials and assignments are often publicly available.
+
+writing your own bootloader, your own memory allocator, your own interrupt handler — this is the deepest possible understanding of how computers actually work. it's the opposite of "vibe coding" and it makes you a dramatically better engineer at every level.
+
+## tools and resources
+
+- **KiCad** — free PCB design. the learning curve is real but the tutorials are good.
+- **Arduino IDE / PlatformIO** — for programming microcontrollers. PlatformIO is better for serious projects.
+- **JLCPCB / PCBWay** — cheap PCB fabrication. $2 for 5 boards. a hobbyist building a basic IoT sensor board can have it fabricated and shipped in under a week.
+- **Digikey / Mouser** — component sourcing. good parametric search.
+- **EasyEDA** — browser-based PCB design, simpler than KiCad but less powerful.
+
+## why hardware matters
+
+hardware projects develop a different set of skills than software:
+
+- **debugging without a debugger.** you learn to reason about physical systems systematically.
+- **understanding constraints.** memory, power, timing — hardware forces you to think about resources in ways software doesn't.
+- **full-stack thinking.** a hardware project touches electronics, firmware, software, mechanical design, and sometimes manufacturing. you become a systems thinker.
+
+the [[publishing-research|research]] opportunities are real too — hardware projects can become science fair entries, [[competitions-hackathons|competition submissions]], or published papers. and hardware experience is rare enough among teens that it stands out in [[work-experience|internship applications]] and [[mentorship-networking|cold emails]].
+
+see [[tools-stack]] for specific hardware tools, and [[design-engineering]] for the fabrication and physical design side.
\ No newline at end of file
new file mode 100644
index 0000000..bdef3b2
@@ -0,0 +1,51 @@
+---
+visibility: public-edit
+---
+
+# young builder resources
+
+this is not a generic resource guide. this is what I (Harrison) have actually done, what I learned, and what I'd tell someone walking the same path.
+
+I'm a high school builder in the Bay Area. I've won 3.5 out of 5 hackathons, placed 2nd nationally at USAYPT, interned at a neurotech startup as their youngest hire, founded a Socratica chapter, published EEG research targeting IEEE TBME, and competed in more math/science competitions than I can count. I've also applied to programs I didn't get into (hi, RSI) and haven't raised a single dollar in formal funding.
+
+everything in this wiki is from personal experience. if I haven't done it, I say so.
+
+---
+
+## philosophy
+
+- [[anti-pipeline-manifesto|the anti-pipeline manifesto]] — why I chose growth over position, and why the standard pipeline is the most crowded lane
+- [[learning-paths|learning paths]] — my philosophy on learning by building. no courses, pull from resources, build things. specific paths for ML, web dev, hardware, research.
+
+## what you can do
+
+- [[competitions-hackathons|competitions & hackathons]] — every competition I've entered, how I did, and what I learned. hackathon advice from actually winning.
+- [[math-modeling|math modeling]] — the most underrated competitions for builders. HiMCM, MCM/ICM, M3 Challenge, MTFC, IMMC — and why modeling skills transfer to everything.
+- [[mun-debate|MUN & debate]] — how arguing, presenting, and thinking on your feet transfers to pitching, selling, and fundraising.
+- [[shipping-products|shipping products]] — you can build and ship real software with real users. the free stack, the process, and why products are your best credential.
+- [[hardware-projects|hardware projects]] — you can build physical things. Arduino → ESP32 → PCB design → integrated projects.
+- [[design-engineering|design engineering]] — physical design and fabrication. makerspaces, CAD, prototyping, and how to access tools.
+- [[publishing-research|publishing research]] — you can publish real research as a teen. how to find a PI, the process, journals, and the Davidson Fellows path.
+- [[creative-work|creative work]] — video, music, writing. creative outlets are real builder credentials and competition entries.
+- [[open-source|open source]] — contributing to open source is the most meritocratic environment. nobody cares about your age, only your code.
+- [[giving-talks|giving talks]] — you can present your work publicly. Socratica 5mof, conferences, hackathon demos, and the confidence flywheel.
+- [[personal-infrastructure|personal infrastructure]] — building your own tools teaches you more than any course. solve your own problems.
+
+## how to get there
+
+- [[summer-programs|summer programs & internships]] — I-Lab, Math in the Mountains, TKS, a neurotech startup. how I cold-emailed my way into a neurotech startup.
+- [[work-experience|work experience]] — startup internships via cold email, research assistant roles, paid work, and freelancing. you don't need formal programs.
+- [[communities|communities]] — the communities I'm actually in: Socratica (founded), Hack Club, Sunday Dinners, AGI House, Incepto House, and more.
+- [[mentorship-networking|mentorship & networking]] — how to cold-email, build relationships, and find mentors without being cringe.
+- [[funding-grants|funding & grants]] — an honest account: I haven't done formal funding. here's what I've earned and why I haven't needed more yet.
+- [[knowledge-management|knowledge management]] — building a personal knowledge system that compounds. notes, spaced repetition, CRM, reflection.
+- [[tools-stack|tools & stack]] — the exact tools I use daily. Claude Code (500+ sessions), Vercel, Cloudflare, Supabase, and the $0 stack.
+
+## other opportunities (haven't done these)
+
+directory of competitions, programs, and awards i haven't personally done but are worth knowing about. brief listings — go look them up if interested.
+
+- [[other-olympiads|other olympiads & math competitions]] — USACO, Putnam, ARML, Math Kangaroo, and more.
+- [[other-writing-competitions|writing competitions]] — literary competitions beyond Scholastic.
+- [[other-entrepreneurship-competitions|entrepreneurship competitions]] — business/startup competitions for high schoolers.
+- [[other-awards-scholarships|awards, scholarships & fellowships]] — honors and funding worth knowing about.
\ No newline at end of file
new file mode 100644
index 0000000..ccc88c4
@@ -0,0 +1,46 @@
+---
+visibility: public-edit
+---
+
+# knowledge management
+
+most teens lose 90% of what they learn because they don't have a system. you don't need a complex system. you need a consistent one.
+
+## my system
+
+### notes: Obsidian
+- 921+ notes, 92 reflection tags
+- local-first, markdown-based, no vendor lock-in
+- everything goes here: project notes, meeting notes, ideas, research summaries, personal reflections
+- the key feature: bidirectional linking. every note links to related notes, which means your knowledge base becomes a graph, not a list. over time, connections emerge that you didn't plan.
+
+### spaced repetition: Mochi
+- cards for: stats, algebraic topology, E&M (Griffiths), mechanics
+- morning routine: Mochi review first, then self-study rotation
+- the principle: if something is worth learning, it's worth remembering. spaced repetition is the only evidence-based method for long-term retention.
+
+### relationships: Dex CRM
+- 124+ contacts in a tiered system
+- tracks: when I last talked to someone, what we discussed, how I know them, what they're working on
+- the tiers map to the relationship system described in [[mentorship-networking]]: close mentors, active advisors, warm contacts, loose network.
+- relationships decay without maintenance. a CRM ensures you don't lose touch with people who matter.
+
+### reflection: daily practice
+- ~8:45pm, ~30 min
+- lesson extraction, project direction, social dynamics
+- 92 reflection tags in Obsidian means I can search for patterns in my own thinking across months
+- reflection is how you convert experience into learning. without it, you repeat the same mistakes.
+
+## why this matters
+
+the research you read for one [[publishing-research|paper]] becomes relevant to a different project six months later — but only if you can find your notes on it. the technique you learned at a [[competitions-hackathons|hackathon]] applies to your [[shipping-products|product]] — but only if you remembered the details.
+
+your network from [[communities]], [[mentorship-networking|mentors]], [[work-experience|work]], and [[competitions-hackathons|competitions]] is one of your most valuable assets. but relationships decay. a simple system — even a spreadsheet — that reminds you to check in with people and records what you discussed is enough to maintain relationships that would otherwise fade.
+
+daily reflection forces you to articulate what you're learning, what's working, and what isn't. over time, you develop better intuition because you're actually processing your experiences instead of just having them.
+
+## how to start
+
+pick one habit. use whatever tool you already have — Apple Notes, Notion, Obsidian, a markdown file. every time you learn something interesting, write it down with a tag. after a month, you'll have a searchable knowledge base.
+
+see [[tools-stack]] for the full tool landscape.
\ No newline at end of file
new file mode 100644
index 0000000..3fc5e30
@@ -0,0 +1,84 @@
+---
+visibility: public-edit
+---
+
+# learning paths
+
+this is not "learn to code 101." if you're reading this wiki, you probably already know how to code, or at least how to start. this is about going from "can write code" to "can [[shipping-products|build things that matter]]" — and the specific paths that get you there.
+
+my fundamental belief: **you learn by building, not by studying.** courses are fine for initial exposure, but the real learning happens when you're stuck on a real problem at 2am and have to figure it out.
+
+## the core skill: going from "can code" to "can build products"
+
+this is the gap that separates hobbyist programmers from builders. it's not about knowing more languages or frameworks — it's about the meta-skills:
+
+1. **scoping:** knowing what to build and what to skip. the hardest part of any project is deciding what NOT to do.
+2. **shipping:** getting something in front of users. 90% of projects die in the gap between "it works on my machine" and "someone else can use it."
+3. **iterating:** using feedback to make it better. the first version will be wrong. that's fine.
+4. **debugging production:** when real users hit your thing, everything breaks differently than in development.
+5. **reading other people's code:** open source, documentation, stack overflow. 80% of building is reading, 20% is writing. a good [[knowledge-management]] system helps you retain what you read.
+
+how to develop these: **build 3 real projects.** not tutorials, not clones, not todo apps. real things that solve real problems for real people.
+
+- project 1: build something for yourself. automate something annoying, build a [[personal-infrastructure|tool you wish existed]].
+- project 2: build something for someone you know. your school, your club, your family's business. now you have a "user" who gives you feedback.
+- project 3: build something for strangers. put it on the internet. deal with the chaos.
+
+after these three, you'll have the meta-skills. the specific technologies don't matter nearly as much.
+
+## my path
+
+I started with p5.js in 6th grade — just making visual things because it was fun. moved to ML in 8th grade, not because "ML is hot" but because I had a specific question: can you classify anesthetic depth from EEG signals? that question led to a [[publishing-research|published research paper]] (CNN anesthetic depth classifier).
+
+the pattern: **a specific problem pulled me into each new domain.** I never sat down and said "I should learn ML." I said "I need to classify EEG signals" and ML was the tool that could do it. the learning was a side effect of the building.
+
+## self-directed learning vs. courses
+
+my take: **no courses. pull from resources, build things.**
+
+the problem with courses is they teach you to follow instructions, not to solve problems. a course gives you a path; real building requires you to find the path.
+
+that said, here's how I'd use structured resources:
+
+### for initial exposure to a new topic
+- **MIT OCW:** the best free resource for learning any technical subject deeply. the lecture notes and problem sets are more valuable than the videos.
+- **3Blue1Brown:** for mathematical intuition. his videos on linear algebra and calculus are genuinely the best way to build geometric intuition.
+- **fast.ai:** for ML/AI specifically. their "top-down" approach (build first, understand theory later) matches how builders learn.
+- **The Odin Project / Full Stack Open:** for web dev. project-based, not lecture-based.
+
+### for going deep
+- read the docs. seriously. React docs, Python docs, MDN for web. documentation is the most underrated learning resource.
+- read source code. find a well-written [[open-source]] project in your area and read how they solved the problems you're struggling with.
+- read papers. once you're past the basics, academic papers are where the cutting edge lives. arxiv.org for CS/ML, Google Scholar for everything.
+
+## the "vibe coding" path
+
+this deserves its own section because it's genuinely new.
+
+AI coding tools (Claude Code, Cursor, Copilot, etc.) have changed what's possible for solo builders. see [[tools-stack]] for my full AI coding setup. you can now build in a weekend what used to take months. this is especially powerful for young builders because:
+
+1. **you can prototype faster.** idea to working app in hours, not weeks.
+2. **you can work outside your expertise.** don't know CSS? AI handles it. need a database schema? AI generates it.
+3. **you can focus on what matters.** product thinking, user problems, design — not boilerplate.
+
+but there are traps:
+
+1. **you still need to understand what the AI is generating.** if you can't debug the code when it breaks (and it will break), you're stuck.
+2. **AI is a force multiplier, not a replacement for skill.** the best AI-assisted builders are the ones who already know how to build. they use AI to go 10x faster, not to go from 0 to 1.
+3. **don't let AI make you lazy about fundamentals.** understand how the internet works, how databases work, how auth works. you don't need to implement these from scratch, but you need to understand them.
+
+my approach: use AI tools aggressively for boilerplate, styling, and things you've done before. write the core logic yourself (or at least understand it deeply). I've done 500+ Claude Code sessions — it's my primary coding tool. but I also spent years learning fundamentals before AI tools existed.
+
+## key books and resources
+
+- **"Hackers & Painters" by Paul Graham:** the essay collection that defines builder culture. read at least "Hackers and Painters" and "How to Make Wealth."
+- **Paul Graham's essays (paulgraham.com):** the single best free resource on startups, building, and thinking clearly. start with "Do Things That Don't Scale" and "How to Get Startup Ideas."
+- **"Designing Data-Intensive Applications" by Martin Kleppmann:** when you're ready to understand how real systems work at scale. this is the book.
+
+## the meta-advice
+
+don't follow a "learning path." follow your curiosity.
+
+the best builders I know didn't follow a curriculum — they had a problem they wanted to solve and learned whatever they needed to solve it. the learning was a side effect of the building, not the other way around.
+
+if you're stuck on what to learn next, the answer is always: build something. and find a [[communities|community]] of people building alongside you. the gaps in your knowledge will reveal themselves, and then you'll know exactly what to learn.
\ No newline at end of file
new file mode 100644
index 0000000..5150b15
@@ -0,0 +1,96 @@
+---
+visibility: public-edit
+---
+
+# math modeling
+
+math modeling competitions are the most underrated competitions for builders. unlike contest math (AMC/AIME/USAMO), math modeling gives you a real-world problem and asks you to build a mathematical model to solve it. no memorization, no tricks — just applied thinking. the skills transfer directly to [[publishing-research|research]], [[shipping-products|product building]], and [[work-experience|engineering work]].
+
+if you like building things and you like math, this is your competition.
+
+## why math modeling is special
+
+contest math asks: "solve this problem that has a known elegant solution."
+math modeling asks: "here's a messy real-world situation. build a model. make predictions. justify your approach."
+
+the second one is closer to what engineers and researchers actually do. the skills you develop — framing problems, choosing assumptions, validating models, writing technical reports — are the same skills you use in [[publishing-research|research papers]], [[shipping-products|product analytics]], and [[work-experience|engineering internships]].
+
+also: math modeling competitions are team-based (usually 3-4 people), which means you're developing collaboration skills. and the results are strong on a resume — a top-10% finish in MCM/ICM as a high schooler is a real accomplishment.
+
+## the competitions
+
+### HiMCM (High School Mathematical Contest in Modeling)
+- **format:** 36 hours, teams of up to 4, November
+- **organizer:** COMAP
+- **what we did:** fire/evacuation scenario with Monte Carlo simulation and spectral bisection
+- **team:** three teammates and me
+- **my take:** this is the entry point. massively underrated. 36 hours is enough time to build a real model without the sleep-deprivation of a hackathon. the problems are genuinely interesting — real-world scenarios with no single right answer.
+
+### MCM/ICM (Mathematical Contest in Modeling / Interdisciplinary Contest in Modeling)
+- **format:** 4 days (Jan/Feb), teams of up to 3
+- **organizer:** COMAP
+- **result:** Meritorious (top 10%)
+- **what we did:** spectral bisection, cellular automata, graph traversal
+- **my take:** this is the college version, but high schoolers can compete. placing Meritorious (top 10%) as high schoolers competing against college teams was a genuine accomplishment. 4 days is enough time to go deep — our paper was substantial.
+- **2026 dates:** January 29 - February 2
+
+### M3 Challenge (MathWorks Math Modeling Challenge)
+- **format:** 14 hours, one weekend (Feb/Mar)
+- **organizer:** SIAM (Society for Industrial and Applied Mathematics)
+- **result:** 143/770 (top 19.8%), qualified for second round
+- **my take:** free to enter, $100,000+ in total prizes. the 14-hour constraint is brutal but teaches you to scope aggressively — the same skill you need for [[competitions-hackathons|hackathons]]. high school juniors and seniors eligible.
+
+### MTFC (Modeling the Future Challenge)
+- **result:** semifinalist (2025-26)
+- **what we did:** equitable bus routing
+- **my take:** the problems have a social-impact angle, which makes the modeling more interesting. "optimize bus routing for equity" is the kind of problem that doesn't have a clean mathematical answer — you have to make value judgments and defend them.
+
+### IMMC (International Mathematical Modeling Challenge)
+- **format:** 6-day sprint (March)
+- international pool of competitors
+- similar flavor to HiMCM/MCM but with more time and an international dimension
+
+## techniques worth learning
+
+these come up repeatedly across modeling competitions:
+
+- **Monte Carlo simulation** — randomly sample scenarios to estimate probabilities and outcomes. we used this for the fire evacuation model. versatile, intuitive, and works when analytical solutions are intractable.
+- **spectral methods** — eigenvalue-based approaches for graph problems. spectral bisection was key in both our HiMCM and MCM papers.
+- **cellular automata** — grid-based simulations where each cell follows local rules. emergent behavior from simple rules. great for modeling physical processes (fire spread, traffic, epidemics).
+- **graph traversal and network analysis** — most real-world problems can be modeled as graphs. shortest paths, flow optimization, community detection.
+- **optimization** — linear programming, integer programming, gradient descent. the core of most modeling problems is "maximize/minimize something subject to constraints."
+- **sensitivity analysis** — how does your answer change when you change your assumptions? judges care about this a lot. it shows you understand the limitations of your model.
+- **FEM simulation** — finite element methods for physics-based modeling. more advanced, but powerful for structural/thermal/fluid problems.
+
+## related modeling work outside competitions
+
+the modeling mindset extends beyond competitions. problems I've worked on:
+
+- elevator scheduling optimization
+- drone routing for delivery
+- disease testing strategies
+- Olympics scoring system analysis
+- irrigation optimization
+- sheep population dynamics
+- trading algorithm design
+- firefighter sweeping route optimization
+
+each of these is a self-contained modeling exercise that could become a [[publishing-research|research paper]], a section of a [[competitions-hackathons|competition submission]], or a portfolio piece for [[work-experience|job applications]].
+
+## practical advice
+
+1. **practice with past problems.** COMAP archives past MCM/ICM and HiMCM problems. SIAM archives past M3 Challenge problems. work through them under time constraints.
+
+2. **learn LaTeX.** your submission is a technical paper. LaTeX (via Overleaf) is the standard for mathematical typesetting. judges notice well-formatted papers.
+
+3. **master one simulation tool.** Python with NumPy/SciPy/matplotlib is the default. MATLAB works too (and MathWorks sponsors M3 Challenge). the tool doesn't matter — fluency does.
+
+4. **write clearly.** the paper matters as much as the model. judges read dozens of papers in a day. clear writing with good figures stands out. explain your assumptions, justify your choices, acknowledge limitations.
+
+5. **build your team deliberately.** you want: someone strong at mathematical formulation, someone strong at coding/simulation, and someone strong at writing/visualization. overlap is fine but coverage matters.
+
+6. **start with HiMCM.** it's the most accessible, the time pressure is manageable, and it teaches you the modeling-paper workflow. then move to MCM/ICM.
+
+math modeling is where [[learning-paths|mathematical thinking]] meets [[shipping-products|building things]]. the competitions are the structured version, but the modeling mindset applies everywhere — any time you're trying to understand a system, make predictions, or optimize something, you're modeling.
+
+see [[competitions-hackathons]] for the full competition landscape and [[publishing-research]] for turning modeling work into papers.
\ No newline at end of file
new file mode 100644
index 0000000..540a488
@@ -0,0 +1,121 @@
+---
+visibility: public-edit
+---
+
+# mentorship & networking
+
+the people you know determine the opportunities you get. this is true at every age, but especially true as a teen because you don't yet have a track record. the right introduction can change your trajectory more than any program or credential.
+
+but networking as a teen is awkward. you're reaching out to adults who are busy, you don't have much to offer yet, and the power dynamic is weird. here's how to do it without being cringe.
+
+## cold outreach that works
+
+the #1 mistake teens make in cold outreach: making it about themselves.
+
+"hi, I'm a high school student interested in AI and I'd love to pick your brain" — this is what every ambitious teen sends. it tells the recipient nothing about why they should respond, and it asks for their most valuable resource (time) without offering anything in return.
+
+here's what actually works:
+
+### the formula
+1. **specific compliment about their work.** not "I love your company" but "your paper on X changed how I think about Y" or "I saw your talk at Z and your point about W was something I hadn't considered."
+2. **what you're working on that's relevant.** "I'm building [specific thing] that relates to [their work] because [specific reason]."
+3. **a specific, small ask.** not "can we meet" but "I had one question about [specific technical thing] — would you have 5 minutes sometime?"
+
+### examples
+
+**bad:**
+> Hi Dr. Smith, I'm a junior at XYZ High School and I'm really passionate about neuroscience. I'd love to learn more about your research. Would you be willing to chat?
+
+**good:**
+> Hi Dr. Smith, I read your 2024 [[publishing-research|paper]] on CNN-based EEG classification and tried to reproduce your results using the PhysioNet dataset. I'm getting similar accuracy on the training set but my model overfits badly on the held-out data. I'm wondering if you did any specific regularization beyond what's described in the methods section — would you have 5 minutes to point me in the right direction?
+
+the first email is forgettable. the second shows you've done real work and have a specific, answerable question. busy people respond to specific questions.
+
+### the numbers game
+even with a great email, expect a ~10-20% response rate from cold outreach. this means you need to send volume. 50 thoughtful emails to people in your area of interest is reasonable. customize each one — templates get ignored.
+
+### follow-up
+follow up once after 5-7 days if you don't hear back. after that, stop. more than one follow-up is annoying.
+
+## the tiered relationship system
+
+not all relationships need the same investment. think of your network in tiers:
+
+### tier 1: close mentors (2-3 people)
+these are people who know you well, care about your development, and you talk to regularly (weekly or biweekly). they're the ones you call when you need real advice. finding these people is hard and takes time — they usually emerge from working together, not from cold outreach.
+
+### tier 2: active advisors (5-10 people)
+people who know your work, will respond to your emails, and you check in with every month or two. they'll make introductions for you and give advice when asked. these often start as cold outreach that turned into a genuine connection.
+
+### tier 3: warm contacts (30-50 people)
+people you've met, had a real conversation with, and could email without re-introducing yourself. you might interact a few times a year. these come from events, programs, and communities.
+
+### tier 4: loose network (hundreds)
+people who know of you or who you know of. twitter mutuals, people you've met briefly at events, friends of friends. this layer is maintained through public building — sharing your work online.
+
+the key insight: **most networking advice focuses on tier 3 and 4 ("work the room") when the real value is in tier 1 and 2.**
+
+## how to not be cringe
+
+the fastest way to make adults take you seriously as a teen:
+
+### do
+- **show your work.** having a github, a personal site, or a [[shipping-products|project]] you can point to is worth more than any introduction.
+- **be direct.** "I built X, I'm trying to figure out Y, I think you could help because Z" is better than beating around the bush.
+- **follow through.** if someone gives you advice or an introduction, follow up and tell them what happened. this is rare and memorable.
+- **be honest about what you don't know.** "I'm not sure if this approach makes sense" is more mature than pretending you know everything.
+- **respect their time.** 15-minute asks > 1-hour asks. email > meeting. don't ask someone to get coffee when an email would suffice.
+
+### don't
+- **don't name-drop.** "I know [famous person]" makes you look like you're trying too hard. let your work speak.
+- **don't ask for favors before building a relationship.** "can you introduce me to [your famous friend]" as a first message is a non-starter.
+- **don't perform maturity.** using corporate jargon and "professional" language makes you sound like you're cosplaying an adult. just talk normally.
+- **don't mass-send identical emails.** people can tell. it's insulting.
+- **don't be transactional.** relationships that exist purely for what you can extract from them are obvious and off-putting.
+
+## conference and event networking
+
+for teens, the best events are:
+- **[[competitions-hackathons|hackathons]].** you're literally building together. natural relationship formation.
+- **demo days.** watching other people's projects gives you conversation starters.
+- **meetups.** especially niche ones ("SF AI meetup" is too big; "SF neurotech meetup" is right).
+- **office hours.** many VCs, founders, and researchers do public office hours. these are designed for cold contacts to ask questions.
+
+### at events
+1. **ask questions after talks.** thoughtful questions get you noticed.
+2. **help with things.** volunteer to help organize. offer to help someone debug their demo.
+3. **follow up within 24 hours.** "nice to meet you" emails should be sent the same day.
+4. **don't try to meet everyone.** two real conversations are worth more than twenty handshakes.
+
+## online relationship building
+
+the internet makes it possible to build relationships with people anywhere in the world. the formula:
+
+1. **build in public.** share what you're working on — twitter, blog posts, github. this is passive networking.
+2. **engage thoughtfully with other people's work.** thoughtful replies, [[open-source|code reviews]], and feedback build relationships faster than likes.
+3. **be helpful.** answer questions in [[communities]], help debug other people's code, share resources. the most connected people are the most helpful people.
+4. **dm with substance.** "your project is cool" is forgettable. "I forked your project and added X — here's the PR" is unforgettable.
+
+## finding mentors specifically
+
+mentors are not found through programs or matching services. they emerge from genuine interactions.
+
+### where mentors come from
+- someone you worked with (at a [[competitions-hackathons|hackathon]], on an [[open-source]] project, at a [[summer-programs|internship]])
+- someone whose work you engaged with deeply and a conversation developed
+- a teacher or professor who noticed your work
+- an older builder in your community who you naturally gravitated toward
+
+### what mentors actually do
+- give you honest feedback (not just encouragement)
+- open doors you can't open yourself
+- help you think through decisions
+- share their mistakes so you don't repeat them
+- push you when you're coasting
+
+### what mentors DON'T do
+- hold your hand through every decision
+- do the work for you
+- guarantee outcomes
+
+the best mentor relationships feel like friendships between people at different stages, not teacher-student dynamics. you're bringing something too — fresh perspective, energy, sometimes technical skills they don't have.
\ No newline at end of file
new file mode 100644
index 0000000..0a6673b
@@ -0,0 +1,82 @@
+---
+visibility: public-edit
+---
+
+# MUN & debate
+
+MUN and debate teach you to argue, present, and think on your feet. these aren't "builder" activities in the traditional sense, but the skills transfer directly to pitching at [[competitions-hackathons|hackathons]], [[giving-talks|giving talks]], [[mentorship-networking|networking conversations]], and eventually fundraising. the ability to construct an argument and deliver it convincingly is a force multiplier for everything else you do.
+
+## my MUN experience
+
+I did Model UN through 8th-10th grade. here's the honest account:
+
+### conferences
+- **BMUN** (Berkeley Model United Nations)
+- **SFMUN** (San Francisco Model United Nations)
+- **NHSMUN** (National High School Model United Nations) — the big one, held in NYC
+- **NMUNC** (my school's MUN conference)
+
+### position papers
+- UNSC reform — how to restructure the Security Council for modern geopolitics
+- nicotine regulation — balancing public health with personal freedom
+- LGBT rights in Samoa — navigating cultural context and universal human rights
+
+position papers are underrated as a writing exercise. you have to research a country's actual position on a complex issue, then argue from that perspective — even if you personally disagree. this develops intellectual flexibility that transfers to everything from [[publishing-research|research writing]] to [[giving-talks|technical presentations]].
+
+## debate and related activities
+
+### Ethics Bowl
+- went 2-1
+- Ethics Bowl is different from traditional debate: it's collaborative argumentation, not adversarial. teams present ethical analyses and judges evaluate depth of reasoning, not rhetorical tricks.
+- the lesson: you can "win" by changing your mind when the other team makes a better argument. this is the most intellectually honest competition format I've found.
+
+### Fed Challenge (NY Fed)
+- economic policy analysis competition run by the Federal Reserve Bank of New York
+- made a corn podcast with a teammate
+- the lesson: presenting economic analysis to an audience teaches you to make complex systems legible. the same skill applies to pitching technical products to non-technical people.
+
+## the debate-to-builder pipeline
+
+this might seem like a stretch, but the connection is real. people who can argue well can also:
+
+### sell and pitch
+- every [[competitions-hackathons|hackathon demo]] is a pitch: problem → solution → demo → why it matters. the structure of a hackathon pitch is identical to the structure of a debate opening statement.
+- [[funding-grants|grant applications]] and investor pitches require the same skills: framing, evidence, persuasion, handling objections.
+
+### communicate technically
+- explaining your [[publishing-research|research]] to a non-expert audience
+- writing clear documentation for your [[shipping-products|products]]
+- presenting at [[giving-talks|conferences]]
+- [[mentorship-networking|cold emails]] — a good cold email is a micro-argument for why someone should respond
+
+### think under pressure
+- hackathon demos where your app breaks live and you need to pivot
+- Q&A after [[giving-talks|talks]] where someone challenges your approach
+- impromptu technical discussions where you need to reason on the spot
+
+### negotiate
+- scope discussions with [[work-experience|internship]] supervisors
+- feature prioritization with co-founders or teammates
+- defending your design decisions in code review
+
+## should you do MUN/debate?
+
+honest take: I stopped MUN after 10th grade because I wanted to spend that time building. MUN is time-intensive — conferences are full weekends, preparation is hours of research per committee.
+
+if you're already doing MUN or debate, the skills are genuinely valuable. if you're choosing between starting MUN and starting to [[shipping-products|build products]] — build products. you'll develop communication skills through hackathon demos, [[giving-talks|talks]], and [[communities|community]] interactions anyway.
+
+but if you've already done MUN or debate, recognize that you have a transferable skill set that most builders don't. the ability to structure an argument, read a room, and speak confidently under pressure is rare in technical circles. lean into it.
+
+## practical skills from MUN/debate that builders should steal
+
+even if you never do MUN, these techniques are worth learning:
+
+1. **the signpost.** tell people what you're going to say before you say it. "I'll cover three things: the problem, our solution, and the results." this works in hackathon demos, talks, and even cold emails.
+
+2. **the steel man.** argue against the strongest version of the opposing position, not the weakest. in product discussions, this means addressing the best objection to your approach, not dismissing the easy ones.
+
+3. **evidence over assertion.** "our app is fast" is an assertion. "our app loads in 200ms, which is 3x faster than the industry average" is evidence. MUN teaches you to back every claim with a source. builders should do the same.
+
+4. **the pivot.** when your argument isn't landing, pivot to a different framing. when your demo isn't resonating with judges, reframe the problem. same skill.
+
+5. **controlled delivery.** speaking slowly, pausing for emphasis, making eye contact. these physical techniques transfer directly to [[giving-talks|any public speaking situation]].
\ No newline at end of file
new file mode 100644
index 0000000..e189a10
@@ -0,0 +1,97 @@
+---
+visibility: public-edit
+---
+
+# open source
+
+contributing to open source is one of the highest-leverage things a teen builder can do. it's the most meritocratic environment you'll find — nobody cares about your age, your school, or your credentials. they care about your code. a merged PR speaks for itself.
+
+## why open source matters
+
+1. **public portfolio.** every contribution is permanently visible on your GitHub profile. any hiring manager, [[mentorship-networking|mentor]], or collaborator can click through and see exactly what you did, how you did it, and that someone else's project accepted your code.
+
+2. **reading other people's code.** this is 80% of real engineering and it's almost never taught in school. open source forces you to understand a codebase you didn't write, find the relevant part, and make a change that doesn't break anything.
+
+3. **connections with maintainers.** the people who maintain popular open source projects are often senior engineers, founders, or researchers. a good PR is one of the best [[mentorship-networking|cold intros]] you can make — you've already proven you can contribute.
+
+4. **real-world engineering practices.** CI/CD, code review, testing, documentation, git workflow, issue tracking. open source projects use the same tools and processes as professional engineering teams.
+
+## my open source contributions
+
+### OpenClaw (April 2026)
+- **first PR:** loguru fix — merged. a small fix, but it got my foot in the door.
+- **second PR:** vite fallback — addressing a build issue.
+- the lesson: start small. your first PR doesn't need to be a major feature. fixing a bug, improving docs, or cleaning up an error message is a legitimate contribution that helps the project and gets you familiar with the codebase.
+
+### IPD tournament
+- forked from existing implementations
+- rewrote for 10x speedup
+- the lesson: forking an existing project and substantially improving it is a form of open source contribution. you don't have to start from scratch — you can make something that exists dramatically better.
+
+## how to start contributing
+
+### step 1: find a project you actually use
+
+don't pick a random project from a "beginner friendly" list. pick something you actually use and care about. you'll be more motivated, you'll understand the user perspective, and your contributions will be better.
+
+think about:
+- tools in your [[tools-stack|development stack]]
+- libraries you use in your [[shipping-products|projects]]
+- apps you use daily
+- frameworks you're [[learning-paths|learning]]
+
+### step 2: look at issues
+
+search for issues tagged:
+- `good first issue` — explicitly meant for new contributors
+- `help wanted` — the maintainers are actively looking for help
+- `documentation` — often the easiest entry point
+- `bug` — small bug fixes are great first contributions
+
+resources that aggregate these:
+- **goodfirstissue.dev** — curates easy issues from popular projects
+- **goodfirstissues.com** — aggregates `good first issue` labels across GitHub
+- **firstcontributions.github.io** — step-by-step guide for your first PR
+- **forgoodfirstissue.github.com** — GitHub's official curation of impactful first issues
+
+### step 3: read the contributing guide
+
+every serious project has a CONTRIBUTING.md. read it. it tells you:
+- how to set up the development environment
+- the coding style and conventions
+- how to run tests
+- the PR process and review expectations
+
+skipping this step is the #1 reason first-time contributors get their PRs rejected.
+
+### step 4: submit a small PR
+
+your first PR should be small. a bug fix, a documentation improvement, a test case. small PRs get reviewed faster, are more likely to be merged, and teach you the contribution workflow without the risk of wasting weeks on something that gets rejected.
+
+### step 5: respond to review feedback
+
+your PR will get review comments. this is normal and good — it's free mentorship from experienced engineers. respond promptly, make the requested changes, and ask questions if you don't understand the feedback.
+
+## what to contribute
+
+ranked by difficulty and impact:
+
+1. **documentation fixes.** typos, unclear explanations, missing examples. every project has these. lowest barrier to entry.
+2. **bug fixes.** reproduce a reported bug, find the cause, fix it, add a test. this is the sweet spot of difficulty and value.
+3. **test coverage.** write tests for untested code. maintainers love this because nobody wants to write tests.
+4. **small features.** implement a feature from the issue tracker. make sure it's approved/wanted before you start building.
+5. **performance improvements.** profile, find bottlenecks, optimize. the IPD tournament 10x speedup falls here.
+6. **major features.** only after you know the codebase well. discuss with maintainers first.
+
+## the compounding effect
+
+open source contributions compound:
+
+- your GitHub profile becomes a living resume
+- maintainers remember good contributors and invite them to bigger work
+- other projects see your contribution history and are more likely to accept your PRs
+- the skills you develop (code reading, git workflow, code review) make you better at [[shipping-products|your own projects]]
+
+open source contributions become proof points for [[work-experience|internship cold emails]] — "I have 5 merged PRs in [project they use]" is a stronger signal than any resume line. and the connections you make with maintainers can become [[mentorship-networking|mentor relationships]] organically.
+
+the beautiful thing about open source: the barrier to entry is literally zero. you can submit your first PR tonight.
\ No newline at end of file
new file mode 100644
index 0000000..71e59e8
@@ -0,0 +1,22 @@
+---
+visibility: public-edit
+---
+
+# awards, scholarships & fellowships
+
+things worth knowing about even if you're not applying yet.
+
+---
+
+- **[US Presidential Scholars Program](https://www2.ed.gov/programs/psp/)** — one of the highest honors for HS students. nominated, not applied to.
+- **[Coca-Cola Scholars](https://www.coca-colascholarsfoundation.org/)** — $20k scholarship, 150 per year.
+- **[QuestBridge](https://www.questbridge.org/)** — college match program for high-achieving low-income students.
+- **[Catalyst Challenge](https://www.projectcatalyst.com/)** — innovation challenge.
+- **[Palantir Meritocracy Fellowship](https://www.palantir.com/)** — for underrepresented groups in tech.
+- **[AI Grant](https://aigrant.com/)** — funding for AI projects. no strings attached.
+- **[Society for Science JIC](https://www.societyforscience.org/broadcom-masters/)** — Junior Innovators Challenge, middle school science.
+- **[Churchill Scholarship](https://www.churchillscholarship.org/)** — postgrad, UK, STEM.
+- **[Rochester Discover Grant](https://www.rochester.edu/)** — undergrad research funding.
+- **[Extraordinary.com fellowship](https://www.extraordinary.com/)** — fellowship for young builders.
+
+for funding i've actually pursued, see [[funding-grants]].
\ No newline at end of file
new file mode 100644
index 0000000..ab5bc30
@@ -0,0 +1,24 @@
+---
+visibility: public-edit
+---
+
+# entrepreneurship competitions
+
+business/startup competitions for high schoolers. did a few of these (Congressional App Challenge, BIG Idea), most i haven't. see [[competitions-hackathons]] for what i've actually done.
+
+---
+
+- **[Conrad Challenge](https://www.conradchallenge.org/)** — apply science/tech to global issues, September-April.
+- **[Blue Ocean High School Entrepreneur Pitch Competition](https://www.blueoceancomp.com/)** — virtual pitch competition.
+- **[Wharton Global High School Investment Competition](https://globalyouth.wharton.upenn.edu/investment-competition/)** — portfolio/investment strategy, September-March.
+- **[GENIUS Olympiad Business](https://geniusolympiad.org/)** — environmental focus, two tracks.
+- **[Diamond Challenge](https://diamondchallenge.org/)** — business innovation + social innovation tracks. well-known.
+- **[NFTE World Series of Innovation](https://innovation.nfte.com/)** — ongoing challenges, global.
+- **a university business competition** — business plan + presentation.
+- **[DECA](https://www.deca.org/)** — marketing, finance, hospitality competitions. pretty well-known in schools.
+- **[FBLA](https://www.fbla.org/)** — various business events from coding to public speaking.
+- **[Rise (Schmidt Futures)](https://www.risefortheworld.org/)** — videos, projects, group interviews. prestigious.
+- **[GSEA](https://www.eonetwork.org/gsea)** — Global Student Entrepreneur Awards. college-level, for students running actual businesses.
+- **[Youth Citizen Entrepreneurship Competition](https://www.youthcitizen.org/)** — social impact focus, UN SDGs.
+- **Pirates Pitch Competition** — 350 words or less, teaches pitch basics.
+- **[LaunchX](https://launchx.com/)** — summer entrepreneurship program. build a real startup in a few weeks.
\ No newline at end of file
new file mode 100644
index 0000000..add9cdf
@@ -0,0 +1,18 @@
+---
+visibility: public-edit
+---
+
+# other olympiads & math competitions
+
+competitions i haven't done but are worth knowing about.
+
+---
+
+- **[USACO](https://usaco.org/)** — USA Computing Olympiad. programming contest, monthly online rounds, leads to IOI team. the CS equivalent of AMC→AIME→USAMO.
+- **[Putnam Competition](https://www.maa.org/math-competitions/putnam-competition)** — college-level math, notoriously hard. good to know exists even if you're not there yet.
+- **[ARML](http://www.arml.com/)** — team math relay + power round. regional teams compete nationally.
+- **[Math Kangaroo](https://www.mathkangaroo.org/)** — international, various grade levels, more accessible than AMC.
+- **[Purple Comet Math Meet](https://purplecomet.org/)** — online, team-based, middle/high school.
+- **[Caribou Contests](https://cariboutests.com/)** — monthly online math, international.
+- **Mu Alpha Theta Mathematical Minutes Video Contest** — make a 2-5 min math video explaining a concept.
+- **[NACLO](https://nacloweb.org/)** — computational linguistics olympiad. i actually did this one — see [[competitions-hackathons]].
\ No newline at end of file
new file mode 100644
index 0000000..1763f43
@@ -0,0 +1,24 @@
+---
+visibility: public-edit
+---
+
+# writing competitions
+
+literary competitions beyond Scholastic. haven't done most of these.
+
+---
+
+- **[NYC Midnight Short Story Challenge](https://www.nycmidnight.com/)** — October-December, multiple rounds, prompts given. also has a Flash Fiction Challenge (April-June).
+- **[Writer's Digest Annual Writing Competition](https://www.writersdigest.com/writers-digest-competitions)** — multiple categories, cash prizes.
+- **[The Moth International Short Story Prize](https://themothmagazine.com/)** — annual, significant prize money.
+- **[Narrative Magazine Story Contest](https://www.narrativemagazine.com/)** — annual, open to all.
+- **[Iowa Review Awards](https://iowareview.org/)** — poetry, fiction, creative nonfiction.
+- **[Fish Publishing Short Story Prize](https://www.fishpublishing.com/)** — international, Irish-based.
+- **[Bath Short Story Award](https://www.bathshortstoryaward.co.uk/)** — international, well-regarded.
+- **[Bridport Prize](https://www.bridportprize.org.uk/)** — UK, prestigious. short story/poetry/memoir/novel categories.
+- **[F(r)iction Literary Competition](https://frictionlit.org/)** — quarterly, themed.
+- **[SF Writers Conference Contest](https://www.sfwriters.org/)** — up to 1500 words, $35 entry.
+- **[Reedsy.com contest list](https://blog.reedsy.com/writing-contests/)** — curated list of essay contests. good meta-resource.
+- **[Poets & Writers database](https://www.pw.org/grants)** — searchable database of writing contests/grants/awards.
+
+for things i've actually submitted to, see [[creative-work]].
\ No newline at end of file
new file mode 100644
index 0000000..99296a0
@@ -0,0 +1,101 @@
+---
+visibility: public-edit
+---
+
+# personal infrastructure
+
+building your own tools teaches you more than any course. every tool you build for yourself solves a real problem — which means you're learning under real constraints, not artificial ones. and the tools you build often become the most interesting things in your portfolio, because they reveal how you think.
+
+## the principle
+
+if something annoys you, build a tool to fix it.
+
+not "file a feature request." not "google for an app." build it. the tool will probably be rough and specific to your workflow — and that's fine. the point isn't to build a polished product (though some of these do become [[shipping-products|real products]]). the point is to develop the instinct that you can bend your environment to your will.
+
+## tools I built for myself
+
+each of these started as "this is annoying, let me fix it" and turned into a real learning experience:
+
+### ContextFlow
+- keyboard shortcut triggers ChromaDB RAG search, injects relevant context into your prompt
+- the problem: I kept re-explaining the same context to AI tools. now a hotkey pulls in relevant docs automatically.
+- what I learned: RAG pipelines, ChromaDB vector search, keyboard shortcut hooks, prompt engineering at a systems level
+
+### ConvoFlow
+- real-time AI conversation orchestrator
+- Deepgram for speech-to-text, Gemini for AI responses, all in real-time
+- the problem: I wanted a flowing conversation with an AI, not a chat interface
+- what I learned: real-time audio processing, streaming APIs, orchestrating multiple services
+
+### VoiceFlow
+- macOS dictation app (Swift, AssemblyAI)
+- the problem: macOS built-in dictation wasn't good enough
+- what I learned: Swift development, macOS app architecture, AssemblyAI's API
+
+### Sides
+- AI-powered decision comparison tool
+- Next.js + Gemini
+- the problem: I make too many decisions by gut feel. wanted a structured way to compare options.
+- what I learned: building with Gemini's API, decision-framework UX design
+
+### wifi-client
+- auto-join networks, fill captive portals, manage a credential vault
+- the problem: I move between cafes constantly and dealing with captive portals is soul-crushing
+- what I learned: network APIs on macOS, web automation for captive portals, credential management
+
+### checklist-speedrun
+- keyboard-driven checklist runner with Google Sheets logging
+- the problem: morning routines kept slipping. wanted to gamify completing them with speed metrics.
+- what I learned: Google Sheets API, keyboard-driven UI design, personal data tracking
+
+### tmux-assistant-resurrect
+- custom tmux session management
+- the problem: losing tmux sessions meant losing work context
+- what I learned: tmux scripting, session state management
+
+### local-deep-research
+- local deep research infrastructure
+- the problem: wanted research capabilities that run locally without sending data to external services
+- what I learned: local LLM orchestration, research workflow automation
+
+## why this matters
+
+### learning by necessity
+
+every tool above taught me a technology I wouldn't have learned from a tutorial, because the motivation was different. tutorials give you artificial problems with known solutions. personal tools give you real problems where you have to figure out the solution — and the scope, and the UX, and whether it's even worth building.
+
+this is the purest form of [[learning-paths|learning by building]]. you can't be bored working on your own problems.
+
+### portfolio signal
+
+personal tools tell a story about how you think. when someone sees your GitHub and finds a collection of tools you built to solve your own problems, they learn:
+
+- you notice inefficiencies (product sense)
+- you can build solutions (engineering skill)
+- you follow through on ideas (execution ability)
+- you have taste (design sense)
+
+this is a stronger signal than any tutorial project or coding challenge.
+
+### the product pipeline
+
+many real products started as personal tools:
+- Dropbox started because Drew Houston kept forgetting his USB drive
+- Slack started as an internal tool at a gaming company
+- Rails started as the framework DHH built for Basecamp
+
+if your personal tool solves a problem other people have, it can become a [[shipping-products|product]]. WorkableCafes started because I personally wanted to know which cafes had good wifi. wifi-client started because captive portals annoyed me.
+
+## how to start
+
+1. **keep a friction log.** for one week, write down every time something in your workflow annoys you. "I wish X existed" or "why is Y so hard" or "I do Z every day and it takes too long."
+
+2. **pick the most annoying one.** the more annoying, the more motivated you'll be to finish.
+
+3. **build the simplest possible version.** a bash script counts. a single-file Python script counts. don't architect a full app — solve the problem.
+
+4. **use it.** if you don't use your own tool, it wasn't solving a real problem. iterate based on your own experience.
+
+5. **share it.** put it on GitHub. write a README. someone else might have the same problem — and now you have an [[open-source]] project.
+
+the tools you build for yourself are the most honest representation of you as a builder. they show what you care about, what you're capable of, and how you think about problems. see [[tools-stack]] for the technologies I use across all of these.
\ No newline at end of file
new file mode 100644
index 0000000..798ba31
@@ -0,0 +1,94 @@
+---
+visibility: public-edit
+---
+
+# publishing research
+
+you can publish real research as a teenager. not "student research" in scare quotes — actual papers in actual journals that actual researchers read. the barrier is lower than you think, and the process teaches you more than any class.
+
+## how to find a research mentor
+
+the hardest part isn't doing the research — it's finding someone willing to work with you. here are the paths that actually work:
+
+### cold email a PI
+
+this is the most direct route. find a professor or researcher whose work interests you, read their recent papers, and send them a specific email about their work. not "I'm a high school student interested in your field" — that's what everyone sends. instead: "I read your 2025 paper on X, tried to reproduce your results, and had a question about Y."
+
+the response rate is low (~5-10%), so send volume. 30-50 thoughtful, customized emails is reasonable. see [[mentorship-networking]] for the full cold email playbook.
+
+### through a program or internship
+
+research programs like RSI, SSP, Garcia, and Simons pair you with PIs. but you don't need a formal program. I found a researcher at a hospital research lab through my neurotech internship — visited them, discussed category theory, then we collaborated on a CNN binary classifier for anesthetic depth from EEG signals (<400 parameters). the internship opened the door, but the collaboration happened because I showed genuine interest and technical capability.
+
+see [[summer-programs]] for research-oriented programs.
+
+### through existing connections
+
+teachers, parents' colleagues, [[communities|community]] members — anyone in academia can introduce you. one warm intro is worth 20 cold emails.
+
+## the process
+
+research isn't magic. it's a learnable process:
+
+1. **read papers.** pick a field. read 10-20 papers. use Google Scholar, arXiv, PubMed. you'll be confused at first — that's normal. by paper 10 you'll start seeing the landscape.
+2. **find a gap.** what hasn't been done? what could be done better? what could be applied to a new domain?
+3. **reach out to someone working in that area.** propose a specific collaboration. "I noticed no one has tried approach X on dataset Y — I'd like to try it and I think your lab's expertise in Z would be valuable."
+4. **do the work.** build the model, run the experiments, collect the data. this is the part most people skip — they want the publication without the months of grinding.
+5. **write it up.** follow the structure of papers in your target journal. abstract, introduction, methods, results, discussion.
+6. **submit.** get rejected. revise. resubmit. this is normal.
+
+## my research
+
+### EEG anesthetic depth classifier
+- collaborated with a researcher at a hospital research lab on a CNN binary classifier for anesthetic depth from EEG signals
+- the model had fewer than 400 parameters — intentionally small to be interpretable
+- submitted to Davidson Fellows (submitted Feb 2026) and targeting IEEE TBME
+- this came from genuine curiosity about consciousness and brain signals, not from wanting a publication
+
+### phase change materials (PCMs)
+- paper on PCMs for AI data center cooling
+- applied materials science to a real engineering problem
+
+### AI bias
+- offense detection across datasets
+- examining how bias manifests differently depending on training data
+
+## where to publish
+
+### journals that accept high school research
+- **International Journal of High School Research (IJHSR)** — dedicated to high school student research, multiple issues per year
+- **Journal of Student Research (JSR)** — multidisciplinary, faculty-reviewed, accepts high school through grad students
+- **The Concord Review** — specifically for history research essays (5,000-9,000 words)
+- **PRESS Journals** — high-quality research and review articles across scientific disciplines
+- **Journal of Emerging Investigators (JEI)** — peer-reviewed, specifically for middle and high school students
+- **Curieux Academic Journal** — student-run, publishes across disciplines
+
+### real journals (not student-specific)
+- **arXiv** — preprint server, no peer review but gets your work out fast and cited. CS, physics, math, bio.
+- **IEEE student papers** — IEEE conferences often have student paper tracks
+- **field-specific journals** — many journals don't care about your age, only your work. if the research is good enough, submit to the real venues.
+
+### conferences and fairs
+- **JSHS (Junior Science and Humanities Symposium)** — present original STEM research, regional → national pipeline, fully funded
+- **Golden Gate STEM Fair / regional science fairs** — the ISEF pathway starts here
+- **ISEF** — the pinnacle of high school science fairs. $9M+ in prizes.
+- **NeurIPS High School Projects Track** — yes, NeurIPS has accepted high school submissions. 330+ submissions in their inaugural track.
+- **Davidson Fellows** — $10k, $25k, or $50k for significant research. not a journal, but a serious award that validates your work.
+
+see [[competitions-hackathons]] for Davidson Fellows and science fair details.
+
+## the Davidson Fellows path
+
+Davidson Fellows is worth special mention. it's a $10,000-$50,000 scholarship for students 18 or under who have completed a "significant piece of work." the bar is high — they want genuine contribution to a field, not a school project with a fancy title.
+
+the application is essentially: describe your work, its significance, and your process. research you publish can become a [[competitions-hackathons|Davidson Fellows submission]]. I submitted my EEG paper (submitted Feb 2026).
+
+## practical tips
+
+- **start reading papers now.** even if you don't understand everything. you'll learn the vocabulary, the structure, and what "good research" looks like in your field.
+- **use Semantic Scholar and Connected Papers** to find related work and understand the citation graph.
+- **learn LaTeX.** every serious paper is written in LaTeX. overleaf.com makes this easy.
+- **keep a research notebook.** document everything — your hypotheses, experiments, failures, insights. you'll thank yourself when writing the paper.
+- **research is slow.** my EEG paper took months. don't expect to go from "I want to do research" to "published paper" in a few weeks.
+
+the products you [[shipping-products|ship]] and the research you publish are the two strongest things you can put in a [[mentorship-networking|cold email]] or a [[funding-grants|grant application]].
\ No newline at end of file
new file mode 100644
index 0000000..8137200
@@ -0,0 +1,104 @@
+---
+visibility: public-edit
+---
+
+# shipping products
+
+you can build and ship real software with real users as a teenager. not toy apps, not tutorial clones — products that people actually use. the tools are free, the distribution is global, and nobody checks your ID before letting you deploy.
+
+this is the single most powerful thing you can do as a young builder. a live product with real users is worth more than any credential, any competition result, any program acceptance. it proves you can take something from zero to one.
+
+## what shipping actually looks like
+
+here's every product I shipped in high school, with honest numbers:
+
+### WorkableCafes
+- cafe wifi speed and outlet ranker
+- 350+ users
+- built a data scraping pipeline + synthetic data generation to populate the database
+- the lesson: people use things that solve specific, annoying problems. "which cafe has good wifi and outlets" is a real pain point.
+
+### Pause
+- macOS break enforcer app (Swift frontend + Vue dashboard)
+- 10 users, live at pausepausepause.com
+- submitted to Congressional App Challenge (got congressional certification)
+- the lesson: desktop apps are harder to distribute than web apps. 10 users for a macOS app you built in high school is honestly fine.
+
+### referral.bike / Fit Referrals
+- launched at AGI House (March 2026)
+- Next.js + Cloudflare
+- the lesson: launching at an event gives you instant users and feedback. see [[communities]] for where to launch.
+
+### debuff.dev
+- real-time pair programming tool
+- Svelte + PartyKit for real-time sync
+- the lesson: real-time features are hard. PartyKit makes them dramatically easier.
+
+### Databox
+- ESP32 PCB that sends sensor data to Google Sheets via Apps Script
+- included a project video + timelapse of the build
+- the lesson: [[hardware-projects|hardware products]] are more impressive because fewer people build them. the video documentation made this project 10x more shareable.
+
+### discord-lattice
+- Chrome extension that turns your Discord friends list into an interactive network graph
+- the lesson: browser extensions are an underrated distribution channel. people already have the browser open.
+
+## how to go from idea to shipped product
+
+### 1. scope aggressively
+the #1 reason projects die is scope creep. your MVP should be embarrassingly small. one core feature, working end-to-end. you can always add more later — but you can't add more to something that doesn't exist.
+
+ask: "what's the smallest thing I can build that someone would actually use?" build that. nothing else.
+
+### 2. use the free stack
+
+you can deploy a full-stack app for $0/month:
+
+| layer | tool | cost |
+|-------|------|------|
+| frontend | Next.js or SvelteKit | free |
+| hosting | Vercel | free |
+| database | Supabase (Postgres + auth + storage) | free |
+| CDN/DNS | Cloudflare | free |
+| domain | .me via GitHub Education | free |
+| payments | Stripe (pay per transaction) | free until revenue |
+
+see [[tools-stack]] for the full breakdown. you only start paying when you have paying users.
+
+### 3. use AI to move fast
+
+Claude Code, Cursor, Copilot — these tools let you build in hours what used to take weeks. I've done 500+ Claude Code sessions. the key is using AI for boilerplate and styling while understanding the core logic yourself.
+
+see [[learning-paths]] for the "vibe coding" section on how to use AI tools without becoming dependent on them.
+
+### 4. deploy on day one
+
+don't wait until it's "ready." push to Vercel or Cloudflare Pages on day one. having a live URL changes your psychology — it's real now, not a side project gathering dust in a git repo.
+
+### 5. get it in front of real users
+
+the product doesn't exist until someone besides you uses it.
+
+- **launch at events.** [[competitions-hackathons|hackathons]] and [[communities|community meetups]] give you a captive audience. I launched referral.bike at AGI House.
+- **share in communities.** Hack Club Slack, Twitter/X, relevant Discord servers, Reddit.
+- **tell everyone you know.** literally everyone. your friends, your parents' friends, your teachers. shameless promotion is a skill.
+- **post on Twitter/X.** builder Twitter is real. share what you're building, show screenshots, be honest about the process.
+
+## why this matters beyond the product itself
+
+products become your best credential for everything else:
+
+- **[[mentorship-networking|cold emails]]:** "I built X with Y users" is the strongest opening line possible
+- **[[summer-programs|internships]]:** a live product demonstrates more than any resume
+- **[[funding-grants|funding]]:** investors and grant committees want to see that you can execute
+- **[[competitions-hackathons|hackathons]]:** products you've already built can be repurposed or extended for competition entries
+- **college apps:** a product with real users tells a story that no GPA or test score can
+
+## common failure modes
+
+- **building something nobody wants.** talk to potential users BEFORE building. 5 conversations can save you months.
+- **polishing instead of shipping.** a rough product with users beats a polished product with none.
+- **building alone in silence.** share your progress publicly. the feedback loop is the whole point.
+- **giving up after 0 users on day 1.** getting your first 10 users is the hardest part. it doesn't happen automatically — you have to actively put the product in front of people.
+
+the things you ship are what make everything else possible. your [[publishing-research|research]], your [[giving-talks|talks]], your [[mentorship-networking|network]] — they all get stronger when you have real products to point to.
\ No newline at end of file
new file mode 100644
index 0000000..2d25213
@@ -0,0 +1,57 @@
+---
+visibility: public-edit
+---
+
+# summer programs & internships
+
+I didn't do the standard "prestigious summer program" pipeline. no RSI, no SSP, no PROMYS. I applied to RSI and didn't get in. instead of feeling bad about it, I ended up doing things that taught me more.
+
+here's what I actually did and what I learned.
+
+## what I did
+
+### my neurotech internship (Boston, summer 2025)
+- **what:** internship at a neurotech startup. I was their youngest intern.
+- **what I did:** EEG, fNIRS, and GVS [[publishing-research|research]]. real research on real brain-computer interface problems.
+- **how I got it:** not through a program. through building relationships and demonstrating capability. I [[mentorship-networking|cold-emailed]] startups doing work I cared about. most didn't respond. one did.
+- **what I learned:** working at a small startup is the best education you can get. you do real work — not glorified job shadowing. at a 5-20 person company, interns ship features and contribute to research. at a big company, they get a tour and a t-shirt.
+- **the bigger lesson:** the best internship you can get as a teen is at a small startup where you'll actually do real work. find a company doing something you care about, prove you can contribute, and offer to work for free or cheap.
+
+### I-Lab internship (summer 2024)
+- **what:** paid minimum wage. learned shop tools. see [[work-experience]] for more on what this taught me.
+- **honest take:** this was my first "real" work experience. not glamorous. but learning to use shop tools (see [[design-engineering]]) and being in a work environment as a teenager was grounding. not everything needs to be prestigious to be valuable.
+
+### Math in the Mountains (Jackson, WY, summer 2025)
+- **what:** math program directed by a renowned mathematician. I was a counselor.
+- **what I got from it:** being a counselor at a math program is different from being a student at one. you learn by teaching. the math community people I met through this are some of the most interesting people I know. the director is brilliant.
+
+### TKS Delta cohort
+- **what:** The Knowledge Society — 10-month program for ages 13-17. weekly sessions, cohorts of ~30 students. got in through a connection.
+- **honest take:** TKS is polarizing. the community is the real value — you meet other ambitious teens. the curriculum on "emerging tech" can feel surface-level if you're already technical. I got value from the peer group, not the content. see [[communities]] for communities that offer similar peer value.
+
+### RSI — applied, didn't get in
+- I'm including this because honesty matters. RSI is the "gold standard" research program, <2.5% acceptance rate. I applied. I didn't get in. it stung at the time. but looking back, the summer I spent at a neurotech startup was probably better for my growth than RSI would have been — I got to do real work at a real company, not a structured research experience designed for college apps.
+- this is the [[anti-pipeline-manifesto|anti-pipeline]] in practice. the "best" program isn't always the best path for you.
+
+### CS140E — a university embedded OS course (auditing, Winter 2026)
+- not a summer program, but worth mentioning. I audited this university course on embedded operating systems. you can learn from the best institutions without being enrolled.
+
+## the cold email strategy (how I got my internship)
+
+this is the most valuable advice on this page.
+
+1. **find startups doing work you care about.** < 50 employees is ideal. look at AngelList, YC's startup directory, or just search for companies in your area of interest.
+2. **write a specific email about what you'd contribute, not what you'd learn.** "I can build X for you" beats "I'd love to learn about Y from you."
+3. **include a link to something you've built.** a github repo, a live project, a paper — anything that shows you can do work.
+4. **follow up once after a week.** don't follow up more than that.
+5. **expect a ~5% response rate.** send a lot of emails. this is a numbers game.
+
+the key insight: small startups are always understaffed. if you can credibly contribute, they'll find a way to bring you on — even if they don't have a "high school internship program."
+
+## what I think about the program landscape
+
+there's a whole industry of "prestigious summer programs" marketed at ambitious high schoolers. RSI, SSP, PROMYS, ROSS, SUMaC, Clark Scholars, Garcia, Simons, MITES, LaunchX. some of them are genuinely excellent. most of them matter more for the credential than the learning.
+
+the fundamental question: **do you want to learn, or do you want a credential?** the best programs give you both. but if you're choosing between a prestigious program and working on something you actually care about — ask: will this program give me something I can't get on my own? if the answer is just "prestige," skip it.
+
+a summer spent [[shipping-products|building your own project]] or interning at a startup where you do real work can be more valuable than any program. programs are good for meeting people and getting mentorship you can't get otherwise. they're not good for getting a line on your resume.
\ No newline at end of file
new file mode 100644
index 0000000..32cc7f1
@@ -0,0 +1,87 @@
+---
+visibility: public-edit
+---
+
+# tools & stack
+
+these are the tools I actually use. not aspirational, not "I tried this once". for tools I've built myself, see [[personal-infrastructure]] — these are in my daily or weekly workflow.
+
+## AI coding tools
+
+this is the most important section. AI tools are the biggest force multiplier for solo builders right now. see [[learning-paths]] for the "vibe coding" section on using AI tools well.
+
+### Claude Code
+- **what:** Anthropic's CLI-based AI coding agent. runs in your terminal. reads your codebase, writes code, runs commands.
+- **my usage:** 500+ sessions. this is my primary coding tool. it's the closest thing to having a senior engineer pair-programming with you 24/7. for solo builders, this is game-changing.
+- **cost:** requires a Claude API subscription or Claude Pro/Max plan.
+
+### VS Code with Claude Code extension
+- my main editor. VS Code is the default for a reason — extensions ecosystem is unmatched.
+
+### Cursor
+- **what:** VS Code fork with AI built in. autocomplete, chat, codebase-aware editing.
+- **honest take:** I used this before moving to Claude Code as my primary tool. the inline editing (cmd+K) is fast for small changes. good tool, I just prefer the CLI workflow now.
+
+### GitHub Copilot
+- **what:** AI autocomplete in your editor.
+- **how I have it:** free through GitHub Student Developer Pack.
+- **honest take:** the tab-complete is seamless. less powerful than Claude Code for complex tasks, but the speed of autocomplete is hard to beat for quick edits.
+
+## hosting & deployment
+
+### Vercel
+- deploys frontend apps from a git push. zero-config. generous free tier (unlimited projects, 100GB bandwidth/month). this is where most of my projects live.
+
+### Cloudflare
+- CDN, DNS, Workers (serverless), Pages (static hosting), R2 (storage). the free tier is absurdly generous. I use Cloudflare DNS for everything.
+
+### Supabase
+- free Postgres database + auth + storage + realtime. the "Firebase but open source" play. great for MVPs. my go-to for any project that needs a database.
+
+### Railway
+- deploys backend services and databases. "heroku but modern." $5/month free usage. the simplest way to deploy a backend.
+
+## design
+
+### Figma
+- the industry standard. free tier is enough for personal projects. even as "just a developer," wireframing in Figma before coding saves time and produces better results.
+
+## hardware tools
+
+### KiCad
+- PCB design. open source. for when software isn't enough and you need to make physical things. see [[hardware-projects]] for the full hardware journey.
+
+## development environment
+
+### iTerm2 + tmux
+- iTerm2 as my terminal emulator. tmux for persistent sessions. every long-running process goes in tmux.
+
+### Git / GitHub
+- git for version control (obviously). GitHub for repos, CI/CD with Actions, and the Student Developer Pack. see [[open-source]] for contributing to other projects.
+
+### Obsidian
+- my note-taking tool. local-first, markdown-based. I keep everything here. see [[knowledge-management]] for the full system.
+
+### 1Password
+- password manager and secrets management. the CLI (`op`) is useful for injecting secrets into development environments.
+
+## the free stack
+
+here's the complete stack I use for launching projects at $0:
+
+| layer | tool | cost |
+|-------|------|------|
+| frontend | Next.js | free |
+| hosting | Vercel | free |
+| database | Supabase | free |
+| auth | Supabase Auth | free |
+| storage | Supabase Storage or Cloudflare R2 | free |
+| DNS/CDN | Cloudflare | free |
+| domain | .me via GitHub Education | free |
+| design | Figma | free |
+| IDE | VS Code + GitHub Copilot (student) | free |
+| AI coding | Claude Code | paid (worth it) |
+| CI/CD | GitHub Actions | free |
+| payments | Stripe (2.9% + $0.30 per txn) | pay per use |
+
+total monthly cost: $0 until you have paying users. see [[shipping-products]] for how to go from this stack to a live product. then Stripe takes a cut of revenue. zero upfront cost — you only pay when you're making money.
\ No newline at end of file
new file mode 100644
index 0000000..e8157fc
@@ -0,0 +1,81 @@
+---
+visibility: public-edit
+---
+
+# work experience
+
+you can get real work experience as a teenager without waiting for formal programs or turning 18. startups will hire you if you can demonstrate value. research labs will take you on if you show initiative. and "unglamorous" jobs teach you things that no prestigious internship will.
+
+## startup internships via cold email
+
+this is the highest-ROI path for a teen builder. small startups (< 50 people) are always understaffed and will bring on talented people regardless of age — if you can prove you'll contribute.
+
+### how I got my startup internship
+
+I interned at a neurotech startup as their youngest intern. I didn't find them through a program or a job board — someone in my network recommended me. but the reason they recommended me is that I had been building things and demonstrating capability for years.
+
+at a neurotech startup, I did real work: EEG, fNIRS, and GVS research on actual brain-computer interface problems. not job shadowing, not busy work — the kind of work that turned into a [[publishing-research|research paper]] targeting IEEE TBME.
+
+the lesson: at a 5-20 person company, interns ship features and contribute to research. at a big company, they get a tour and a t-shirt.
+
+### the cold email playbook for startups
+
+1. **find companies doing work you care about.** AngelList, YC's startup directory, Crunchbase, or just search for companies in your field.
+2. **target < 50 employees.** small enough that every person matters, big enough to have some structure.
+3. **lead with what you'll contribute, not what you'll learn.** "I can build X for you" beats "I'd love to learn about Y."
+4. **include a link to something you've built.** a [[shipping-products|live product]], a GitHub repo, a [[publishing-research|paper]] — anything that shows you can do work.
+5. **follow up once after a week.** then stop.
+6. **expect ~5% response rate.** send 40 emails, get 2 responses, convert 1. it's a numbers game.
+
+see [[mentorship-networking]] for the full cold outreach guide.
+
+## research assistant roles
+
+### a research organization
+- AI regulation dataset work
+- scored 200 companies on AI governance practices
+- wrote automation code for Google Forms
+- the lesson: research assistant work is unglamorous — lots of data entry, scoring, tagging. but it teaches you rigor, and you build relationships with the researchers leading the project.
+
+research positions often lead to co-authorship opportunities. the grunt work gets your foot in the door; the insights you contribute along the way earn you a spot on the paper.
+
+## paid work
+
+### I-Lab internship (summer 2024)
+- paid minimum wage
+- learned to use every shop tool — laser cutters, 3D printers, wood shop, metal shop
+- built out sections of the shop itself
+- the lesson: physical work experience is underrated. learning to use tools, being reliable, showing up on time — these are foundational skills that transfer everywhere. see [[design-engineering]] for more on what this unlocked.
+
+### a tutoring center (Aug 2024 - May 2025)
+- tutoring job, paid
+- the lesson: explaining things to people who don't understand them is one of the best ways to deepen your own understanding. tutoring teaches communication, patience, and the ability to meet people where they are. also: having a regular paycheck as a teenager is grounding.
+
+## open source contributions
+
+contributing to open source is unpaid work experience that's visible to everyone. I contributed PRs to OpenClaw in April 2026 — bug fixes and improvements. see [[open-source]] for the full guide.
+
+open source contributions on your GitHub profile are the most publicly verifiable form of work experience. any hiring manager or startup founder can click through and see exactly what you did.
+
+## freelance and contract work
+
+if you can [[shipping-products|build products]], you can do freelance work:
+- small businesses that need websites or tools
+- individuals who need automation or data work
+- other builders who need help with specific features
+
+the rates won't be great at first, but the experience compounds. every client project teaches you to work with requirements, deadlines, and people who aren't technical.
+
+## what "work experience" actually teaches you
+
+the specific technical skills matter less than the meta-skills:
+
+- **working on someone else's problems.** personal projects let you choose what to work on. work doesn't. learning to care about problems that aren't yours is a critical skill.
+- **operating in a team.** communication, coordination, not stepping on each other's code.
+- **shipping on a deadline.** not "when it's ready" but "by Friday."
+- **dealing with ambiguity.** real work rarely comes with clear specifications.
+- **being reliable.** showing up, doing what you said you'd do, following up.
+
+these transfer directly to [[competitions-hackathons|hackathons]], [[publishing-research|research collaborations]], and eventually to building your own company.
+
+the products you [[shipping-products|ship]] are your portfolio. the work experience you get validates that you can operate in a professional context. together, they make you a candidate that [[summer-programs|programs]] and [[mentorship-networking|mentors]] take seriously.
\ No newline at end of file