Discover

Discovery: первая встреча ученика с предметной областью

Это первые 1-2 дня ученика в системе. Цель — НЕ научить его делать работу области с нуля, а создать правильную ментальную модель и wow-эффект. Это критично: если первая сессия ощущается как «вот тебе чистый лист, сделай сложную вещь сам», ученик уйдёт в fixed mindset про «это не для меня, слишком сложно». Если первая сессия ощущается как «смотри, ты только что за 2 минуты осмысленно рассуждал про реальную вещь из этой области!» — он остаётся.

Главный принцип Discovery: wow ДО первой сложности. Сначала ощущение «я уже могу про это рассуждать», и только потом — реальная работа, где появятся компромиссы (trade-offs) и тупики.

Научное обоснование

• Wow-эффект снимает первичный страх «не смогу» и создаёт внутреннюю мотивацию (SDT)
• Сначала модель, потом детали — Ausubel (1968): advance organizers
• Worked examples первыми (Sweller, cognitive load theory): новичок учится быстрее, разбирая готовый пример, чем сразу делая работу сам. Discovery опирается на это: фазы 1-3 — это чтение и прикидка, а не самостоятельная работа с нуля.
• Сократическая подача («начни наивно → всплыви проблему → доработай») — ученик чувствует, что открывает решение сам. Это мягкое применение Generation > Reading в первый день (без перегруза).

Карьерная линия (подсветить под goal)

Прочитай profile.goal и profile.learner_profile. У большинства областей есть линия профессионального роста — от новичка к мастеру, который не только применяет правила, но и видит ограничения и ведёт работу «as a peer». Чем выше — тем больше проактивности и владения компромиссами (новичок находит развилку; опытный выбирает путь и обосновывает; мастер ведёт работу). Какой wow подсветить — зависит от goal (interview / startup / growth): привяжи первое переживание к той траектории, которая для ученика актуальна.

Пример карьерной линии (область System Design):

разработчик → senior инженер → архитектор / staff

• goal = interview → линия к senior/staff через интервью. Wow: «то, что ты сейчас сделал за 2 минуты — это первая фаза System Design интервью, requirements + estimation». Покажи, что формат интервью — это структура, которую можно освоить.
• goal = startup → линия к инженеру, который сам тащит инфраструктуру растущего продукта. Wow: эволюция zero→millions (фаза 2) — «вот как твой продукт переживёт рост от 100 до миллиона пользователей».
• goal = growth → линия к senior через глубину. Wow: разбор реальной архитектуры (Netflix/Discord) — «вот как это устроено на самом деле в проде».

Профиль модулирует тон (полные настройки — onboarding/references/profiles.md):

• career_switcher — опирайся на прошлый профессиональный опыт как ресурс, легитимируй тревогу ре-входа в учёбу. Покажи линию к конкретной начальной роли.
• women_stem — язык принадлежности с первого дня («как специалист, ты будешь...»), нормализуй сомнения.
• young_male_26 — спарринг-тон, дай продуктивный вызов, но на новой теме сначала опора (worked example). На сигналах застревания предлагай помощь сам.
• junior_growth — минимум базовых объяснений, быстрее к содержательному; базовый словарь области он уже знает.

Три фазы Discovery

Это структура знакомства, одинаковая для любой области. Конкретные сценарии под область наполняются в маркерах <!-- DOMAIN:examples -->.

Фаза 1: «Зачем это и первое "вау, я уже могу про это рассуждать"» (≈15 минут)

Цель: показать, что область — не магия для избранных, а рассуждение, которое доступно прямо сейчас. Дай ученику маленькую посильную задачу на рассуждение про реальную вещь из области — и зафиксируй wow: «Ты только что осмысленно рассуждал про реальную штуку из этой области — с этого всё и начинается».

Как устроена хорошая Фаза 1:

• Взять знакомый ученику объект/пример из области.
• Вместе, за пару минут, прикинуть/разобрать его на доступном уровне (порядок, направление, базовая логика — не точный экспертный ответ).
• Назвать wow явно: ученик уже сделал то, что считал «не для него».

Ключевое: ученику не нужно ничего делать с нуля. Просто показать, что он уже может рассуждать про предмет.

Пример сценариев Фазы 1 (область System Design):

Вариант A — прикидка нагрузки реальной системы (приоритетный wow):

1. Выбери знакомый сервис (Twitter, YouTube, Instagram).
2. Вместе, за 2 минуты, прикиньте порядок нагрузки: «200M активных в день, в среднем 2 действия → сколько в секунду?». Считаем только порядок величины, не точную цифру.
3. Wow-момент: «Ты только что оценил инфраструктуру сервиса на миллионы пользователей. Это называется back-of-envelope estimation, и с этого начинается любой серьёзный дизайн».

Вариант B — как из 6 символов работает URL shortener:

1. Спроси: «Как ты думаешь, как bit.ly/3xY7k превращается обратно в длинную ссылку?»
2. Разберите: короткий ключ → строка в БД → редирект. Прикиньте, сколько ссылок можно закодировать 6 символами (~62^6 ≈ 56 миллиардов).
3. Wow-момент: «Вся магия — это таблица из двух колонок и немного арифметики. Большие системы складываются из таких простых блоков».

Детали — references/session-1.md.

Фаза 2: «Как тема устроена и растёт» (≈20 минут)

Цель: дать обзор того, как устроен предмет области и как он усложняется/вырастает — каждый шаг решает конкретную проблему. Это advance organizer (Ausubel): сначала общая карта, потом детали.

Как устроена хорошая Фаза 2:

• Пройдите устройство/эволюцию темы вместе, по шагам, сократически: на каждом шаге спрашивай «что станет проблемой дальше?» — и только потом показывай следующий элемент как решение.
• Ученик должен увидеть, что сложная вещь не придумывается целиком — она вырастает из проблем по одной. Это снимает страх чистого листа.

Пример сценария Фазы 2 (область System Design) — эволюция системы zero→millions:

1 сервер (всё на одной машине)
   → проблема: данные теряются при рестарте, не масштабируется
+ отдельная БД
   → проблема: один сервер не тянет трафик
+ load balancer + несколько серверов приложения
   → проблема: каждый запрос бьёт в БД, она задыхается
+ кеш (часто читаемое — в память)
   → проблема: статика и медиа далеко от пользователей
+ CDN (контент ближе к пользователю)
   → проблема: одна БД не вмещает все данные
+ шардинг / репликация

На каждом шаге спрашивай: «Что, по-твоему, сломается первым при росте?» — и только потом показывай следующий блок как решение.

Детали — references/session-2.md.

Фаза 3: «Разбор готового примера» (≈15 минут)

Цель: научить читать готовый пример области, а не создавать свой. Это reading перед writing (worked example, Sweller). Reading — отдельный навык, более ранний, чем самостоятельное создание. Не пропускай его: он снижает когнитивную нагрузку перед первой настоящей задачей.

Как устроена хорошая Фаза 3:

1. Возьмите один готовый, не слишком сложный пример (эталонный артефакт области).
2. Пройдите по нему по частям: что делает каждый элемент и почему он здесь.
3. Передайте слово ученику (Generation): «Расскажи мне словами, как это работает / как через это проходит процесс».
4. Не требуйте создавать своё — только читать пример и объяснять, как он устроен.

Пример Фазы 3 (область System Design): возьмите готовую reference-архитектуру (простой news feed или URL shortener в полном виде), пройдите по слоям клиент → API → сервисы → кеш → БД, затем попросите объяснить, как запрос проходит через систему от пользователя до базы и обратно.

После Фазы 3 обнови progress/profile.json: Discovery пройден, unlocked = базовые основы области. В progress/completed_lessons.json добавь D1, D2, D3.

Критерии выхода из Discovery

• Ученик может объяснить своими словами, зачем нужна эта область
• Ученик сделал хотя бы одно посильное рассуждение про реальную вещь области (Фаза 1)
• Ученик понял, как тема устроена и как она растёт/усложняется (Фаза 2)
• Ученик прочитал готовый пример области и объяснил, как он устроен (Фаза 3)

Когда все четыре — Discovery завершён.

Что НЕ делать в Discovery

• Не заставляй делать сложную работу с нуля. Это всё впереди. Discovery — про мотивацию и чтение, не про самостоятельный синтез.
• Не наслаивай сложность рано. Один элемент за раз, каждый — ответ на конкретную проблему.
• Не перегружай теорией. Глубокая теория и полная классификация — это потом, не в Discovery.
• Не уходи в trade-offs глубоко. Назвать развилку — ок, требовать выбор и обоснование — рано.
• Не сравнивай с другими учениками. «У других уже...» → стереотип/угроза.
• Не извиняйся за простоту. «Это очень примитивный пример, но...» → обесценивание.

Язык принадлежности с первого дня

С самой первой сессии говори с учеником как с будущим специалистом области:

• ❌ «Если ты научишься, ты сможешь это делать»
• ✅ «Как специалист, ты будешь делать такие вещи каждый день»
• ❌ «Попробуй, может получится разобраться»
• ✅ «Ты сейчас рассуждаешь про это как специалист — давай я покажу, как это делают»

Разница микроскопическая, но она формирует идентичность. Особенно важно для women_stem и career_switcher. См. скилл feedback.

Связь с другими скиллами

• feedback — применяется везде. Особенно важно во время wow-эффекта: никакого «молодец!», только процессная конкретика («хороший ход — ты прикинул направление до того, как полез в детали»)
• scaffolding — в Discovery уровень = 1 (ПОЛНЫЙ): ведёшь за руку, разбираешь worked examples. Это нормально для начала; для областей с высокой когнитивной нагрузкой стартовый уровень и так выше.
• session-flow — первая сессия Discovery пропускает шаги 2-3 (streak, spaced review — их ещё нет)
• diagramming — Фаза 3 может опереться на этот скилл для разбора визуального примера (если домен его использует)
• Контентный скилл базовой компетенции области — Фаза 1 даёт первый вкус, дальше его развивает соответствующий доменный скилл

Ссылки

• references/session-1.md — детальный сценарий Фазы 1 (первое посильное рассуждение)
• references/session-2.md — детальный сценарий Фазы 2 (как тема устроена и растёт)
• references/session-3.md — детальный сценарий Фазы 3 (разбор готового примера)
• references/career-path.md — карьерный разговор (линия роста в области)
• onboarding/references/profiles.md — какой wow и линию подсветить под профиль