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

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

Команда Vivid сделала это возможным. Если подумать, то пара ключевых различий между стартапами на ранней стадии и крупными технологиями сыграла решающую роль.

• Внимание. В Vivid большое внимание уделялось моему обучению. Меня поощряли выбирать то, над чем я хотел работать, задавать вопросы и говорить обо всем, что я хотел узнать. Я упомянул, что меня интересует, как Хорхе настроил монорепозиторий, и на следующий день у нас состоялось двухчасовое обсуждение плюсов и минусов Vite, Turborepo, pnpm и других. Несмотря на то, что это заслуга команды Vivid, внимание естественным образом привлекает небольшая команда. Моя работа была напрямую связана с успехом компании, поэтому помогать мне работать наилучшим образом было в интересах всех.
• Широта обучения. На ранней стадии развития компании нет устоявшейся кодовой базы, на основе которой можно было бы строить. Я так привык воспринимать такие вещи, как сценарии развертывания и строки подключения к базе данных как нечто само собой разумеющееся, но внезапно я обнаружил, что должен сам настраивать эти вещи. Я думаю, что в крупных компаниях вы очень глубоко изучаете одну тему, но в стартапе вы вынуждены лезть в дверь за каждой частью вашего продукта.
• Качество кода. Хотя стартапы обычно славятся плохим качеством кода, в Vivid такого точно не было. Я так много узнал о лучших практиках кода, когда мои PR отправляли обратно за исправлениями слишком много раз, чтобы сосчитать. Хотя в то время это было болезненно, сейчас я, безусловно, стал лучшим инженером и понимаю важность тщательного обзора кода.
• Веселье! И последнее, но не менее важное: стажировка в Vivid была самой веселой из всех, что я когда-либо получал на работе. Арьяман, Хорхе и Альберто создали такую ​​непринужденную атмосферу с первой недели, и теперь я чувствую, что просто работаю над проектом хакатона со своими действительно хорошими друзьями. На других работах мне не терпелось бы уйти с работы в 17:00, но здесь я с удовольствием остаюсь и работаю до тех пор, пока не придет время.

Когда я пишу этот пост всего в нескольких часах от нашей второй вечеринки по случаю запуска на той же крыше WeWork, где я встретил Арьямана, Хорхе и Альберто, мне почти жаль, что у меня тоже не было предложения Big Tech, от которого я отказался и присоединился к Vivid. Вместо этого я возвращаюсь в Колумбию на последний год обучения в колледже, взяв с собой четырех новых друзей и непреодолимое желание построить что-то на основе того, чему я научился.

Введите яркий

Я впервые лично встретил Арьямана, Хорхе и Альберто, когда они отказались от своих предложений о работе в Big Tech на вечеринке WeWork на крыше. Имея всего лишь краткую беседу за чашкой кофе с Арьяманом за неделю до этого, я подумал, что было так освежающе видеть волнение, которое они трое испытывали по поводу того, над чем они работали.

Я только что закончил стажировку в Microsoft и прошлым летом проходил стажировку в Meta. У меня было хорошее представление о том, как будет выглядеть жизнь в Big Tech, и хотя я не ненавидел ее, большая часть меня также задавалась вопросом, каково это — работать в стартапе. Наблюдение за тем, как команда Vivid радуется, когда они отказались от предложений моей мечты первокурсника, было тревожным звонком — я должен был увидеть, что я упускаю.

Неудивительно, что месяц спустя я подписал письмо с предложением стать первым стажером Vivid весной 2023 года.

Стержень

Я пошел в свой первый день работы в Vivid, не зная, чего ожидать.

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

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

Несколько ключевых выводов из наших мозговых штурмов:

• Важно создать продукт, который действительно нужен людям . Неважно, если ваш инструмент повысит производительность каждого члена команды на 10 % — никто не захочет нарушать текущий рабочий процесс ради незначительного улучшения. Скорее, если есть два или три инженера, у которых производительность увеличилась на 200 %, ваш инструмент будет гораздо более устойчивым.
• Конкуренты не дисквалифицируют идею. Раньше я думал, что если какая-то другая компания, какой бы маленькой она ни была, начала работать над идеей, похожей на мою, мне не следует ее развивать. Но теперь я вижу, что эти компании существуют как доказательство того, что существует реальная проблема, которую необходимо решить.
• Важно долгосрочное видение. Так же как и отказаться от плохой идеи. Я был удивлен, когда услышал, что Vivid отказывается от Styler. Как пользователь, я думал, что это хорошо выполненный продукт с надежным вариантом использования. Теперь я понимаю, что у Styler не было обозримой долгосрочной цели, и поворот был необходим для роста компании. Возможность отойти от идеи без четкого пути вперед, независимо от ошибки необратимых затрат, необходима для того, чтобы стартапы двигались быстро.

Ниже представлено изображение моего самого первого вклада кода в команду Vivid!

К концу первых двух недель в Vivid я перешел от незнания того, как написать ни строчки React, к уверенности в том, что смогу создать страницу с нуля — больше знаний, чем я получил за 12 недель прошлых стажировок.

Яркая синхронизация

Вторая часть моей стажировки была определена Vivid Sync. Мы уже знали, что при передаче от разработчиков к дизайнерам возникают серьезные трения. Но во время телефонного разговора с клиентом ведущий инженер поделился ключевой идеей: у этих разногласий была одна основная причина. Со временем библиотеки Figma начинают расходиться с репозиториями кода, что вызывает постоянное недопонимание между дизайнерами и разработчиками.

В течение недели после появления идеи мы нашли партнера по дизайну и приступили к созданию продукта, который по сути представлял собой систему управления задачами, связывающую компоненты Figma с кодовой базой через Github Issues.

Мне было поручено создать веб-интерфейс, который выглядел так:

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

Мозговой штурм Pt. 2

У Vivid Sync был фатальный недостаток — он не решил проблему клиента. Конечный пользователь был мотивирован обещанием сократить время, затрачиваемое на проектирование. В отличие от Styler, у Vivid Sync было четкое долгосрочное видение, которое заключалось в создании сквозной синхронизации между Figma и Code, но поставляемый продукт не экономил время инженеров — он фактически добавлял к общему количеству работы путем создания задач на ремонтные работы.

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

На этот раз я был готов к тому, что должно было произойти. Я поставил перед собой цель активно участвовать в обсуждениях идей. Я научился составлять листы гипотез, проводить конкурентные исследования и справляться с приливами и отливами дивергентного мышления, сводящегося к конкретной идее. Больше всего я узнал, какое влияние мое мнение может оказать на небольшую команду.

Фигма в код

Моя история коммитов на GitHub ясно показала, сколько времени мы потратили на разработку идей — 3 недели. Мы решили сразу перейти к самому важному для клиентов направлению — преобразованию дизайнов Figma в пригодный для использования код внешнего интерфейса. У нас было четкое долгосрочное видение, мы напрямую обращались к проблеме конечного пользователя, и у всех нас был гораздо более высокий уровень убежденности.

Когда дело дошло до разработки, я взял на себя ответственность за адаптацию новых пользователей. Цель адаптации состояла в том, чтобы позволить Vivid генерировать код, используя компоненты, уже находящиеся в кодовой базе пользователя.

Ключевой технической задачей было получение компонентов пользовательского кода и связывание их с соответствующими активами Figma, поэтому в любое время, когда использовался этот ресурс Figma, мы могли вызвать правильный компонент в коде. Свойства компонентов также должны быть согласованы, чтобы наш инструмент мог вызывать эти компоненты без ошибок.

У функции онбординга было несколько разных частей:

1. Приложение Гитхаб . Приложение Github подключается к репозиторию и возвращает все файлы .tsx в подключенном репозитории через REST API.
2. Микросервис Python . Микросервис Python, созданный с помощью Flask, использует алгоритм сопоставления NLP для семантического сопоставления компонентов кода с компонентами Figma.
3. Пакет обхода кода . Пакет обхода кода позволил мне связать вместе приложение Github и микросервис Python. Он получил файлы .tsx из приложения Github и вернул соответствующие компоненты из микрослужбы Python.
4. Внедрение Match Platform. Наконец, пользовательский интерфейс позволял проводить сопоставления и отправлять их в базу данных в бэкэнде.

Веселые фотографии!