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

Работа постоянно меняется . Особенно, когда компания небольшая. Когда я пришел в OpenGov в качестве 180-го сотрудника, я не мог сказать, буду ли я делать ту же работу, что и тогда, месяц спустя. Вещи быстро меняются, компания пытается найти свое место на рынке, и это связано с постоянно меняющимися требованиями.
Вы культура . Когда компания небольшая, каждая новая вещь, процесс или техническое усовершенствование, введенное вами, могут быть приняты всей инженерной организацией. (или, в некоторых случаях, всей компании) и может стать частью культуры по мере роста компании. На мой взгляд, это очень приятно, и не у всех есть такая возможность. Всегда ищите, что можно улучшить, и пытайтесь начать обсуждение. Вам не нужно делать всю тяжелую работу самостоятельно; определение того, что можно сделать лучше, и принятие этого первого шага имеют большое значение.
Коснитесь каждой части стека . В стартапе, работающем инженером, роли редко имеют четкие границы «вещей», над которыми вас могут попросить поработать, особенно в качестве младшего инженера. Вы можете рассчитывать на работу с интерфейсом, серверной частью, инфраструктурой, базами данных и многим другим. От подготовки бэклога JIRA для функции до развертывания соответствующего кода — все является частью работы.
Вещи ломаются. Вы развертываете фрагмент кода, который ломает систему или ведет себя не так, как в среде предварительной разработки. Иногда инфраструктура ломается, и вы вообще ничего не можете развернуть! Все это возможности учиться и совершенствоваться. В opengov, несмотря на то, что у нас была специальная команда devops для решения подобных проблем, мы, как инженеры, также были знакомы с операционной стороной разработки программного обеспечения.
Документация важна. Поскольку мы заняты написанием и доставкой кода, документация имеет тенденцию отходить на второй план. Стоит регулярно выделять время на создание новой документации и обновление существующей. Хорошая документация, на мой взгляд, является признаком высокоэффективной команды. Поскольку люди приходят и уходят, особенно это касается стартапов, документация — это то, что помогает привлекать новых людей и распространять знания о различных системах и областях среди существующих членов команды.
Общение тяжелое . Чтобы привлечь внимание различных заинтересованных сторон к техническому проекту, вам необходимо объяснить, какую ценность он представляет для вашего клиента. Вы хотите потратить следующие пару спринтов на рефакторинг управления состоянием вашего приложения? Что ж, приготовьтесь объяснить продукту или вашему управляющему менеджером (который, в свою очередь, должен будет объяснить вышестоящему руководству), почему это важно. Иногда конечный пользователь получает прямую выгоду, например более быстрое время загрузки приложения, лучший UX и т. д. В других случаях выгодой может быть лучший опыт разработчика, который ускорит разработку функций в будущем. Что бы это ни было, правильно сформировать такое повествование может быть сложно, и даже если вы не участвуете в этих переговорах, я предлагаю всегда уменьшать масштаб и смотреть на свою работу с точки зрения пользователя.
Поиск подходящего наставника. Как и в других дисциплинах, наставничество может изменить правила игры для молодого инженера. Наставник не должен держать вас за руку, чтобы чему-то научить, а скорее подталкивать вас в правильном направлении. Они имеют большой опыт в этой области, являются опытными профессионалами и готовы поделиться своими знаниями с вами. Обратитесь к людям в вашей команде/компании, на которых вы равняетесь, и обсудите проблему, которую вы решаете, документ технического проекта, который вы пишете, или что-то, по чему вам нужны рекомендации.

Мемуары программистов