Ваш перший місяць у стартапі залишає слід. Тут немає повільного входу в курс справи чи тижня перегляду навчальних відео в очікуванні, поки IT-відділ підготує ноутбук. З першого ж дня від вас очікують, що ви будете створювати, ламати й лагодити речі, якими справді користуватимуться люди. Я швидко це зрозумів, приєднавшись до Treevah — компанії, що розробляє інструменти для допомоги шукачам роботи в організації їхніх заявок. Тридцять днів у середовищі на ранній стадії навчили мене програмуванню більше, ніж будь-який університет чи змагання.
Ритм невблаганний
У Treevah робота не чекає, поки ви освоїтеся. Команда намагається перевести продукт із альфа-стадії в бета-стадію і, зрештою, у продакшен, а це означає, що кожне завдання має вагу. Тут немає місця для «чернеток» або завдань, які просто зникають у поштовій скриньці професора. Коли ви випускаєте функцію, вона потрапляє прямо до користувачів, які намагаються відстежувати дедлайни, співбесіди та подальші кроки під час пошуку нової роботи.
Такий темп виснажує. Ви рухаєтеся швидко щодня, а обсяг роботи накопичується швидше, ніж ви очікуєте. Дедлайни — це не щось абстрактне; вони прив'язані до етапів, від яких залежить, чи зможе компанія обслуговувати більше шукачів роботи, чи зможе виправити недоліки в поточному досвіді користування. Ця відповідальність тисне на вас. Але вона також дає чіткість, яку важко знайти у великих організаціях. Коли я завершую завдання, я бачу прямий зв'язок між тим, що я створив, і людиною, якій тепер легше керувати своїм пошуком роботи. Таке відчуття власності є рідкісним, і завдяки йому втома здається виправданою.
Навички швидше примножуються в продакшені
До цього літа більша частина моєї енергії витрачалася на публічні виступи та хакатони. І те, і інше навчило мене швидко думати та презентувати ідеї під тиском. Хакатони, зокрема, тренують збирати робочі демо-версії за лічені години. Але є різниця між проєктом на вихідні, який вражає суддів, і кодом у продакшені, який має витримувати контакт із сотнями реальних користувачів.
Місяць, присвячений веброзробці в Treevah, допоміг подолати цю прірву. У навчальних закладах проєкти мають «запобіжники». Обсяг обмежений, вимоги подаються на блюдечку, а якщо ваша схема бази даних «ляже», це можна легко пояснити на слайді презентації. У стартапі ж ваша схема має бути надійною, бо реальні шукачі роботи зберігають у ній реальні дані про свої заявки. Зворотний зв'язок миттєвий і безжальний. Коли сторінка завантажується повільно або форма не зберігається, нікого не хвилює ваша оцінка; людей хвилює те, чи не втратили вони щойно можливість отримати роботу.
Цей тиск стимулює ріст. Ви вчитеся писати чистіший код не тому, що цього вимагає критерій оцінювання, а тому, що саме ви будете налагоджувати його опівночі. Ви вчитеся ставити гостріші запитання під час перегляду коду, тому що розгортання зламаної збірки означає, що реальні користувачі вдаряться об стіну. Можливості тут просто сильніші, ніж у навчальних проєктах. Помилки коштують дорожче, тому й уроки запам'ятовуються назавжди.
Приземлена реальність багів
Якщо є один міф, який я хотів би розвінчати, то це ідея про те, що кожен баг у програмному забезпеченні — це драматичний логічний збій. Деякі, звісно, є такими. Але багато багів, з якими я зіткнувся в Treevah, були до нестями дрібними. Вони ховалися на видноті й марнували години мого життя.
Постійно повторювалися два сценарії. Першим були дубльовані правила CSS. Коли кілька розробників працюють над одним і тим самим компонентом протягом кількох спринтів, таблиці стилів розростаються. Одна людина додає утилітарний клас margin, а інша жорстко прописує значення у файлі компонента. Окремо жодна з цих дій не є помилкою. Але разом вони створюють зсуви макета або «війни специфічності», через які кнопка виглядає нормально в Chrome, але зламано в Safari. Щоб знайти причину, потрібно відкрити інструменти розробника в браузері та рядок за рядком перевіряти обчислені стилі замість того, щоб читати елегантну алгоритмічну логіку.
Другим було визначення елементів поза межами їхніх батьківських div. Тригер модального вікна або випадаючий список можуть бути додані не до того вузла в DOM. Екран виглядає майже правильно, тому ви припускаєте, що структура вірна. А потім з'являється конфлікт z-index або подія кліку спливає до неправильного обробника, і раптом користувач не може закрити спливаюче вікно, яке перекриває його форму заявки. Це не задачі з комп'ютерних наук. Це просто просторові та структурні помилки, які накопичуються, коли ви працюєте швидко.
Пошук деяких із цих багів займав тижні. Я вдивлявся в код, переконував себе, що логіка правильна, і блукав хибними шляхами, які нікуди не вели. Це справді виснажує. Здається, що ти пропускаєш щось очевидне, і так воно і є. Але задоволення від того, що ти нарешті помічаєш дубльоване правило або неправильно розміщений закриваючий тег, є напрочуд...