Первый месяц в стартапе оставляет след. Здесь нет медленного вхождения и нет недели просмотра обучающих видео в ожидании, пока IT-отдел подготовит ноутбук. С первого же дня от вас ждут, что вы будете создавать, ломать и чинить вещи, которыми будут пользоваться реальные люди. Я быстро осознал это, присоединившись к Treevah — компании, создающей инструменты, которые помогают соискателям организовывать процесс подачи заявок. Тридцать дней в среде на ранней стадии развития научили меня программированию больше, чем любые учебные классы или соревнования.
Ритм беспощаден
В Treevah работа не ждет, пока вы освоитесь. Команда стремится перевести продукт из альфа-версии в бета-версию и, в конечном итоге, в продакшн, а это значит, что каждая задача имеет вес. Здесь нет места работе «для галочки» или заданиям, которые можно просто отправить в почтовый ящик профессора. Когда вы выпускаете новую функцию, она попадает прямиком к пользователям, которые пытаются отслеживать дедлайны, интервью и последующие контакты в поисках следующей работы.
Этот темп изматывает. Вы двигаетесь быстро каждый божий день, и объем работы накапливается быстрее, чем вы ожидаете. Дедлайны — это не абстракция; они привязаны к вехам, которые определяют, сможет ли компания обслуживать больше соискателей или исправить пробелы в текущем пользовательском опыте. Эта тяжесть давит на вас. Но она также дает ясность, которую трудно найти в крупных организациях. Когда я завершаю задачу, я могу провести прямую линию между тем, что я построил, и человеком, которому теперь стало проще управлять своим поиском работы. Такое чувство ответственности встречается редко, и именно оно заставляет верить, что усталость того стоит.
Навыки растут быстрее в продакшне
До этого лета большая часть моей энергии уходила на публичные выступления и хакатоны. И то, и другое научило меня соображать на ходу и представлять идеи под давлением. Хакатоны, в частности, тренируют умение на скорую руку собирать рабочие демо-версии за считанные часы. Но есть разница между проектом на выходные, который впечатляет судей, и продакшн-кодом, который должен выдерживать контакт с сотнями реальных пользователей.
Месяц, посвященный веб-разработке в Treevah, помог восполнить этот пробел. В школе проекты идут с определенными ограничениями. Объем работ фиксирован, требования разжевывают, а если ваша схема базы данных рушится, вы можете оправдаться этим на слайде презентации. В стартапе же ваша схема должна работать, потому что реальные соискатели хранят в ней реальные данные о своих заявках. Цикл обратной связи здесь мгновенный и беспощадный. Когда страница загружается медленно или форма не сохраняется, никого не волнуют ваши оценки; людей волнует то, не упустили ли они только что возможность трудоустройства.
Это давление стимулирует рост. Вы учитесь писать более чистый код не потому, что этого требует критерий оценки, а потому, что именно вы будете отлаживать его в полночь. Вы учитесь задавать более точные вопросы во время код-ревью, потому что развертывание сломанной сборки означает, что реальные пользователи упрутся в стену. Возможности здесь бьют гораздо сильнее, чем школьные проекты. Ошибки стоят дороже, а значит, уроки усваиваются лучше.
Приземляющая реальность багов
Если и есть один миф, который я хотел бы развенчать, так это идея о том, что каждый баг в ПО — это драматический логический сбой. Некоторые, конечно, таковыми являются. Но многие баги, с которыми я столкнулся в Treevah, были безумно мелкими. Они прятались на виду и отнимали часы моей жизни.
Постоянно повторялись две закономерности. Первая — дублирующиеся правила CSS. Когда несколько разработчиков работают над одним и тем же компонентом в течение нескольких спринтов, стили раздуваются. Один человек добавляет утилитарный класс отступа, а другой прописывает значение жестко прямо в файле компонента. По отдельности ни один из них не ошибается. Но вместе они создают сдвиги верстки или войны специфичности, из-за которых кнопка выглядит нормально в Chrome, но сломана в Safari. Чтобы отследить такое, нужно открывать инструменты разработчика в браузере и построчно изучать вычисленные стили вместо того, чтобы читать элегантную алгоритмическую логику.
Второй проблемой было определение элементов вне их родительских div. Триггер модального окна или выпадающий список могут добавиться не в тот узел DOM. Экран выглядит почти правильно, и вы предполагаете, что структура верна. Но затем возникает конфликт z-index или событие клика всплывает к неверному обработчику, и внезапно пользователь не может закрыть всплывающее окно, которое перекрывает его форму заявки. Это не задачи по компьютерным наукам. Это пространственные и структурные ошибки, которые накапливаются, когда вы работаете в быстром темпе.
На поиск некоторых из этих багов уходили недели. Я вглядывался в код, убеждал себя, что логика верна, и забредал в тупики, которые ни к чему не вели. Это чувство разочарования вполне реально. Кажется, будто ты упускаешь что-то очевидное, и так оно и есть. Но удовлетворение от того, что ты наконец заметил дублирующееся правило или не на своем месте стоящий закрывающий тег, — это удивительно