Поиск для созидателя: карта трека и почему это отдельный навык

Сцена, знакомая каждому. Вы пишете сервис. Всё идёт нормально ровно до момента, когда очередь начинает терять сообщения при перезапуске брокера, а в документации написано «at-least-once delivery» — и больше ничего. Работа встаёт. Не потому, что вы не умеете программировать, а потому, что вы не знаете одной конкретной вещи, и эта вещь где-то записана. Вопрос только — где, и как отличить правильный ответ от убедительного.

Дальше есть два способа действовать. Первый: открыть поисковик, вбить текст ошибки, открыть шесть вкладок, прочитать три ответа на Stack Overflow разной степени древности, скопировать конфиг из четвёртого, перезапустить, увидеть, что стало иначе, но не лучше, и потерять полдня. Второй: за десять минут понять, как называется механизм, за который вы зацепились, за двадцать найти нормативное описание этого механизма, за пять — убедиться, что оно относится к вашей версии, и за час поставить эксперимент, который отличает вашу гипотезу от соседней.

Разница между этими двумя способами — не в скорости чтения и не в удаче. Это навык, у которого есть внутреннее устройство, и ему посвящён этот трек.

Что здесь называется поиском

Важное сужение темы, чтобы не было недоразумений.

Это не трек про устройство поисковых систем. Инвертированный индекс, ранжирование, BM25, векторный поиск — интересные вещи, но они здесь ни при чём. Если вам нужно понять, как поиск работает изнутри, и тем более построить свой, идите в трек ИИ-инженерия, где разбирается ретривал, и в трек про базы данных, где разбираются индексы.

Это не трек про информационный поиск как научную дисциплину и не про SEO с обратной стороны прилавка.

Это не трек про то, как усваивать и запоминать найденное. Про извлечение из памяти, интервальное повторение, чтение технических текстов ради понимания и заметки как внешнюю память написан соседний трек Как учиться. Мы будем на него ссылаться там, где темы граничат, и не будем его пересказывать. Грубая, но рабочая граница: там — про то, что происходит с информацией после того, как вы её получили; здесь — про то, как её добыть и как понять, можно ли ей верить.

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

Последняя строка — ключевая и самая недооценённая. Большая часть неудачных поисков проваливается не на этапе поиска, а на этапе формулировки: человек ищет описание своих ощущений, а искать надо имя механизма. Этому посвящена первая глава.

Что про это известно из измерений

Область переполнена советами без данных, поэтому сразу оговорим, что здесь можно опереть на исследования, а что — только на отраслевую практику. Работ немного, они старше, чем хотелось бы, и почти все сделаны на разработчиках крупных компаний, то есть переносятся с оговорками. Но кое-что они показывают устойчиво.

• Поиск — не редкое событие, а часть цикла написания кода. Caitlin Sadowski, Kathryn Stolee и Sebastian Elbaum в работе How Developers Search for Code: A Case Study (FSE 2015, исследование на инженерах Google) зафиксировали медиану порядка десятка поисковых сессий по коду в рабочий день, причём большая часть — короткие, на несколько секунд, с целью вспомнить сигнатуру или найти пример использования.
• Веб встроен в процесс программирования, а не приделан сбоку. Joel Brandt с соавторами в Two Studies of Opportunistic Programming (CHI 2009) показали, что разработчики используют веб на трёх разных уровнях одновременно: чтобы вспомнить забытую деталь, чтобы разобраться в незнакомой технологии и чтобы разведать возможность подхода. Стратегия запроса на этих уровнях разная, а инструмент один — отсюда часть неудач.
• Категории поисковых задач различаются по успешности. Xin Xia с соавторами в What Do Developers Search for on the Web? (Empirical Software Engineering, 2017) собрали таксономию из десятков типов задач и показали, что тяжелее всего идут поиски, связанные с производительностью, надёжностью и выбором между технологиями, — то есть ровно те, где ответа в виде готового куска кода не существует.
• Переформулировка — норма, а не признак неумения. В исследованиях поисковых сессий разработчиков доля сессий с несколькими последовательными запросами велика; исходная формулировка почти никогда не финальная. Это укрепляет тезис, к которому мы вернёмся не раз: первый запрос делается ради словаря.

Чего в литературе нет: контролируемых экспериментов, показывающих, что конкретная методика поиска даёт измеримый выигрыш по времени решения задачи. Поэтому всё, что дальше в треке названо приёмом, — это разобранная отраслевая практика с объяснённым механизмом, а не доказанный протокол. Отличать одно от другого — само по себе часть навыка, и этому посвящена седьмая глава.

Цикл разведки

Поиск полезно представлять не как одно действие «спросить у поисковика», а как цикл с обратной связью, в котором каждый оборот улучшает словарь запроса.

Три вещи, которые видно из этой картинки и которые обычно пропускают.

Возврат из «Оценки» в «Словарь» — главный оборот. Первый заход в поиск почти всегда неудачен, и его настоящая ценность не в найденном ответе, а в найденных словах. Вы ищете «падает при большой нагрузке», натыкаетесь на страницу, где встречается слово «backpressure», и второй запрос уже другого качества. Опытный поиск — это два-три таких оборота, а не один длинный запрос.

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

Узел «След». Если после разведки не осталось записи, через полгода вы пройдёте тот же путь заново, и это будет не быстрее. Про то, как выглядит дешёвый и работающий след, — тринадцатая глава.

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

Одинаково искать ответы на разные типы вопросов — самая частая системная ошибка. Тип вопроса определяет, где смотреть и когда останавливаться.

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

Как выбрать глубину: два параметра

Сколько усилий вкладывать в разведку — решение, а не рефлекс. Полезно оценивать вопрос по двум осям: во что обойдётся ошибка и насколько дёшево проверить ответ у себя.

Практический смысл: в левом нижнем углу читать спецификацию — потеря времени, там достаточно первого разумного ответа и проверки за минуту. В правом верхнем углу первый разумный ответ — это заявка на инцидент: там нужен нормативный источник, и он у вас, скорее всего, есть. Ошибка происходит, когда человек применяет привычку одного угла к вопросу из другого.

Почему информационная среда стала хуже, и что это меняет

Приёмы поиска, которые работали десять лет назад, работают заметно хуже, и дело не в ностальгии. Изменилось несколько вещей одновременно.

Стимулы производителей контента сместились к объёму. Страница, которая пересказывает документацию своими словами и добавляет вступление на три абзаца, приносит деньги. Точный ответ в двух строках — нет. В результате первая страница выдачи по техническому запросу часто состоит из пересказов одного и того же первоисточника, причём пересказов, сделанных без понимания.

Порог производства текста упал до нуля. Генеративные модели сделали производство правдоподобных технических текстов почти бесплатным. Побочный эффект: доля страниц, которые выглядят как ответ, но написаны без проверки, выросла. Отдельный неприятный жанр — сгенерированные «туториалы», описывающие API, которого не существует.

Основная площадка вопросов и ответов сжалась. Активность на Stack Overflow после 2022 года заметно упала — данные о числе новых вопросов публичны и доступны в Stack Exchange Data Explorer. Часть трафика ушла в модели, часть — в закрытые Discord-серверы, которые не индексируются вообще. Практическое следствие: ответы на новые вопросы всё чаще существуют не в вебе, а в issue-трекерах, чатах и головах конкретных людей.

Веб перестал быть надёжно наблюдаемым. Google убрал оператор cache: и ссылку на кэш из выдачи в 2024 году; часть площадок закрыла API. Это делает Wayback Machine не экзотикой, а рабочим инструментом.

Что из этого следует для практики — три вещи, которые проходят через весь трек:

1. Смещайте вес с веб-поиска на индексы, где мусора структурно меньше: исходники, issue-трекеры, changelog, спецификации, рассылки, поиск по коду.
2. Проверяйте дату и версию раньше, чем содержание. Правдоподобный ответ, верный для версии 2016 года, дороже отсутствия ответа: он выглядит как знание.
3. Считайте модель отдельным источником с собственным профилем ошибок, а не заменой поиска и не оракулом. Об этом — восьмая глава.

Иерархия источников: короткая версия

Полный разбор — в четвёртой главе, здесь только скелет, потому что он нужен уже с первой страницы.

Правило, из которого вырастает вся глава: чем ближе источник к тому, что исполняется, тем меньше в нём слоёв интерпретации, и тем он дороже в чтении. Исходник не врёт никогда, но читать его дольше всего. Блог-пост читается за три минуты, но между вами и истиной стоит человек, который мог не понять, мог упростить и почти наверняка писал про другую версию.

Из этого не следует «всегда читайте исходники». Из этого следует, что вы должны знать, на каком уровне находитесь, и уметь спуститься на уровень ниже, когда ответ важен.

Карта трека

Тринадцать глав после этой:

1. От симптома к термину — как превратить «что-то не работает» в запрос, на который есть ответ. Почему поиск по тексту ошибки работает хуже, чем поиск по имени механизма, и как добывать словарь предметной области, которого у вас пока нет.
2. Операторы, движки и время — механика запроса: что из синтаксиса действительно работает, как ограничивать поиск площадкой и временем, чем отличаются движки и какие специализированные индексы стоит держать под рукой.
3. Поиск по коду и артефактам — GitHub code search, grep.app, поиск по реестрам пакетов и по локальному дереву. Как найти живой пример использования API, который нигде не описан.
4. Первоисточник против пересказа — спецификация, RFC, исходники, changelog, issue tracker. Как строить цепочку от чужого ответа к нормативному тексту и почему это занимает меньше времени, чем кажется.
5. Документация, которую вы видите впервые — как за двадцать минут понять, что в этой документации есть, где это лежит и чему в ней можно верить.
6. Когда документации нет — исходники, история изменений, issue-трекер и рассылки как основной источник. Приёмы археологии: pickaxe, blame, bisect, чтение обсуждений вокруг коммита.
7. Проверка: дата, автор, воспроизводимость — как отличить «работает» от «работало в 2016 на другой версии», как читать бенчмарки с конфликтом интересов и что такое триангуляция источников.
8. Модель как источник — профиль ошибок генеративной модели, почему уверенный тон не коррелирует с точностью, как строить проверяемые запросы и когда модель полезнее поиска.
9. Академический слой — arXiv, Scholar, препринты и рецензирование. Как читать статью, не будучи учёным, и как понять, меняет ли она ваши действия.
10. Где живут ответы — языки и корпуса: почему англоязычный запрос даёт другой набор ответов. Где находятся сообщества и как задать вопрос так, чтобы на него ответили.
11. Когда перестать искать — стоимость поиска против стоимости эксперимента, таймбоксы, признаки тупика и как проектировать проверку, которая закрывает вопрос.
12. Поиск во время отладки — отдельный жанр со своим порядком действий: что делать до первого запроса, что искать, а что искать бесполезно.
13. Воспроизводимый след — что оставить после разведки, чтобы через год не искать заново, и как это связано с решениями, которые вы принимаете сегодня.

Как читать этот трек

Главы связаны, но не строго последовательны. Три разумных маршрута:

• Полный, если вы учитесь. 00 → 13 подряд. Первые шесть глав — про добычу, следующие три — про доверие, дальше — про среду и границы.
• Аварийный, если у вас горит прямо сейчас. Глава 12 (отладка) → глава 01 (формулировка) → глава 06 (история изменений). Этого хватает, чтобы не потерять день.
• Гигиенический, если вы много читаете и вам кажется, что вы тонете. Главы 04, 07, 11, 13: первичность, проверка, остановка, след. Это четыре главы про то, как не производить работу вхолостую.

Трек рассчитан на инженера, который уже что-то строит. Если вы пока строите мало, а учитесь много, полезнее сначала пройти Как учиться, а сюда вернуться, когда появится поток реальных вопросов: без него приёмы отсюда негде применять, и они забудутся ровно так, как описано в главе про иллюзию компетентности.

Словарь трека

Несколько слов будут встречаться постоянно, поэтому договоримся о значениях сразу.

Последняя строка — самая полезная идея трека, если запоминать одну. Не бывает «надёжных» и «ненадёжных» источников вообще. Бывают источники с известным профилем ошибок, и с ними можно работать, потому что вы знаете, что именно проверять.

Как этот трек связан с остальным порталом

Практическое чтение схемы: если по ходу трека вам покажется, что какая-то тема раскрыта слишком коротко, скорее всего, она подробно разобрана в соседнем треке, и в тексте будет ссылка. Дублировать соседей мы намеренно не будем.

Чего в этом тексте не будет

Чтобы не создавать ложных ожиданий:

• Списка «лучших сайтов для программиста». Такие списки протухают за год, а навык — нет.
• Обещания, что поиск заменит понимание. Он не заменяет; более того, чем лучше вы понимаете область, тем эффективнее ищете, и это односторонняя зависимость. Хороший запрос требует знания слова, а слово берётся из понимания.
• Оценок конкретных сервисов в духе «этот лучше того». Где такое неизбежно, будет сказано, на какой момент это верно и как проверить самому.
• Разговора про сбор данных о людях. Это другая тема с другой этикой, и здесь её нет.

Антипаттерны, которые видно со стороны

Если вы наблюдаете за коллегой (или за собой на записи экрана), плохой поиск опознаётся по шести признакам. Каждый из них разбирается дальше в треке.

1. Двадцать открытых вкладок и ни одной прочитанной до конца. Признак того, что вопрос не атомарен: человек ищет всё сразу и поэтому ничему не может дать оценку.
2. Копирование команды из ответа без чтения того, что она делает. Работает до первого случая, когда не работает, — и тогда откатиться некуда, потому что модель происходящего не построена.
3. Возврат к тому же запросу третий раз за неделю. Признак отсутствующего следа: разведка была, результат испарился.
4. Спор о поведении системы без ссылки на источник. Двое обсуждают, что делает библиотека, вместо того чтобы за минуту открыть её исходники.
5. Аргумент «я где-то читал». Утверждение без датировки и без автора — это не знание, а воспоминание о знании.
6. Час поиска там, где эксперимент занимает пять минут. Самый дорогой антипаттерн и самый незаметный, потому что поиск ощущается как работа.

Мини-итог

• Поиск созидателя отличается от бытового ценой ошибки, наличием возможности проверить и незнакомым словарём предметной области.
• Это цикл, а не действие: главную ценность даёт возврат «нашёл новые слова → переформулировал запрос», а не первый заход.
• Тип вопроса определяет стратегию: фактический, терминологический, нормативный, опытный и причинный вопросы ищутся в разных местах и заканчиваются по-разному.
• Глубину разведки задают два параметра: цена ошибки и цена проверки. Вопросы из разных углов этой плоскости требуют разного поведения.
• Среда стала хуже: больше пересказов, меньше живых площадок, менее наблюдаемый веб. Ответ на это — смещение к первичным индексам, ранняя проверка даты и версии, осознанная работа с моделью как с отдельным типом источника.
• Разведка, после которой не осталось следа, будет повторена целиком.

Три уровня владения навыком

Полезно понимать, куда вы движетесь. Границы условны, но переходы между уровнями заметны со стороны.

Разница между вторым и третьим уровнем — не в знании сайтов, а в двух метаумениях: выбирать источник под тип вопроса и прекращать поиск. Оба они разобраны ближе к концу трека и оба неочевидны, потому что интуиция подсказывает обратное: искать дальше кажется продуктивным, а прекратить — сдаться.

Как проверить, что глава усвоена

Простое упражнение, которое имеет смысл проделать после каждой главы трека и особенно после этой. Возьмите последний реальный случай, когда вы что-то искали дольше двадцати минут, и ответьте письменно:

1. Какого типа был вопрос — фактический, терминологический, нормативный, опытный или причинный?
2. В каком типе источника лежал ответ и когда вы туда попали — сразу или после нескольких кругов?
3. Что было бы дешевле: продолжать искать или поставить эксперимент?
4. Осталось ли от этой разведки что-нибудь, кроме памяти?

Если на четвёртый вопрос ответ «ничего», вы уже знаете, какую главу читать первой.

Источники

• Sadowski C., Stolee K. T., Elbaum S. (2015). How Developers Search for Code: A Case Study. ESEC/FSE 2015 — dl.acm.org/doi/10.1145/2786805.2786855.
• Brandt J., Guo P. J., Lewenstein J., Dontcheva M., Klemmer S. R. (2009). Two Studies of Opportunistic Programming: Interleaving Web Foraging, Learning, and Writing Code. CHI 2009 — dl.acm.org/doi/10.1145/1518701.1518944.
• Xia X., Bao L., Lo D., Kochhar P. S., Hassan A. E., Xing Z. (2017). What Do Developers Search for on the Web? Empirical Software Engineering, 22 — link.springer.com/article/10.1007/s10664-017-9514-4.
• Stack Exchange Data Explorer — открытая база вопросов и активности, на которой можно самостоятельно проверить утверждения о динамике площадки: data.stackexchange.com.
• Internet Archive Wayback Machine — web.archive.org.
• Diátaxis — систематика технической документации Даниэля Проциды, полезная как карта чужих доков: diataxis.fr.
• Eric S. Raymond, Rick Moen. How To Ask Questions The Smart Way — catb.org/~esr/faqs/smart-questions.html.
• Bjork R. A., Dunlosky J., Kornell N. (2013). Self-Regulated Learning: Beliefs, Techniques, and Illusions. Annual Review of Psychology, 64 — про то, почему субъективная лёгкость плохо предсказывает знание; в поиске это проявляется как «прочитал ответ и решил, что понял».

Что дальше

Начнём с того места, где теряется больше всего времени, — с формулировки. От симптома к термину: как превратить незнание в запрос.