Трудно понять, что правильно или как все должно работать, когда вы младший разработчик. Я помню, когда я только начинал, я считал, что все, что делает мое начальство, правильно и как все делается в отрасли. Однако иногда все не так, как должно быть.
Я составил список из 3 красных флажков, которые должны заставить вас задуматься, если вы их увидите. Увидев одного из них, не значит, что пора собираться и искать новую работу. Это скорее список, который должен указывать на то, что что-то можно улучшить, или что вас может ждать сложный цикл разработки.
Правила для тебя
Для старших разработчиков или менеджеров проектов нормально действовать по другим правилам или ограничениям, чем вы. Возможность коммита непосредственно в основной ветке в кризисной ситуации или отсутствие потребности в большом количестве одобрений для принятия запросов на вытягивание — вот несколько примеров.
Что неприемлемо, так это когда для сдерживания негативной практики создается общекомандная система, а ваше начальство не чувствует себя обязанным участвовать, даже если они сами обязались быть лидером в продвижении изменений.
Несколько лет назад у нас возникла проблема, когда члены команды обменивались прямыми сообщениями друг с другом через Slack, когда была обнаружена ошибка. Сообщения вроде: «Привет, я видел xyz на странице новой учетной записи, можешь взглянуть на это?». Основная проблема заключается в том, что прямые сообщения в slack легко забыть и потеряться в шуме множества чатов, которые идут весь день. У нас была доска Jira для записи проблем, но люди отправляли сообщения, ожидая, что получатель создаст заявку Jira. Неудивительно, что если они будут записаны в Jira, это будет удар или промах. Проблема заключалась в том, что ошибки оставались неисправленными в течение нескольких недель, потому что прямое сообщение было либо забыто, либо пропущено.
Решение одного старшего разработчика заключалось в том, чтобы каждый сначала записывал ошибки на нашей доске Jira, а не отправлял прямые сообщения. В новой системе, когда вы видите ошибку, вы создаете тикет Jira и отправляете ссылку тому, кто лучше всего с ней справится. Таким образом, даже если предполагаемый исправитель забыл или пропустил сообщение, тикет Jira существует, и на него можно сослаться. Все были на борту, и старший разработчик, придумавший процесс, пообещал быть первым, кто согласится с ним.
Несколько недель спустя этот старший разработчик вернулся к старой привычке отправлять прямые сообщения с описанием обнаруженных им ошибок. Сколько бы тонких напоминаний я ни бросал, он никогда не воспользуется созданной им системой. Он быстро вызывал всех в команде, когда они забывали использовать новую систему. Я обнаружил, что этот двойной стандарт не только раздражает, но и подрывает авторитет этого старшего разработчика как эффективного лидера.
В любой среде, видя, что начальство не придерживается того же стандарта, что и вы, вы можете расстраиваться. Думаю, стоит отметить, что это разочарование оправдано.
Выбрасывание кода
Выбрасывание кода — это то, через что нам всем приходится пройти в какой-то момент. Существуют уважительные причины, по которым ваш код может быть выброшен. Иногда масштаб проекта меняется, и ваша функция больше не нужна. Или ваша работа над определенной функцией обнаруживает недостаток в вашей системе, который требует переосмысления того, над чем вы работали. Однако бывают случаи, когда выбрасывание кода должно вызывать тревогу. Примерами могут служить начальники, которые меняют свое мнение о том, как что-то делать в середине разработки, или заставляют двух разработчиков работать над одной и той же функцией, не осознавая этого.
Несколько лет назад я работал со старшим членом команды над новым веб-интерфейсом. Мы собрались и разделили задачи. Я отвечал за страницу аккаунта, а он отвечал за что-то еще. Я провел около 2 часов на странице, и когда я закончил, я показал ему свою работу. Выяснилось, что в процессе разработки у него появилась идея, как включить страницу учетной записи в то, над чем он работал, и моя страница учетной записи больше не была нужна. Он сидел в 5 футах от меня и не удосужился сообщить мне, что изменил план. В итоге я удалил 2 часа работы. Это стало обычным явлением для оставшейся части проекта. Я не искал повода работать с ним после того, как мы закончили.
По моему опыту, отказ от кода по неправильным причинам — это удар по моему моральному духу. Это также побудило меня активно стараться избегать работы с начальством, которое это сделало.
Знаменитые последние слова
Если ваша команда находится на этапе планирования нового проекта или функции и вы слышите фразу «это должно быть легко», это должно вас насторожить. По моему опыту, когда начальник описывает новый проект как «легкий», это может быть признаком того, что он его не понимает.
Это случалось со мной много раз, когда я был младшим разработчиком. Через некоторое время фраза: «Этот проект должен быть очень легким» подсказала мне, что мы движемся к катастрофе. Я не знал, как и когда, но это должно было быть плохо.
Может оказаться, что проект прост и выполняется без заминок. Или в вашем API обнаружен недостаток, который требует двухнедельного капитального ремонта, что будет стоить вам клиента. Не удивляйтесь, если все пойдет как по маслу.
Будучи младшим разработчиком, вы не будете нести ответственность за планирование больших объемов работы. Этот пример больше поможет вам предупредить вас, когда ваше начальство недооценило новый проект. Часто ничего не поделаешь, если вы новичок и не обладаете техническими знаниями, чтобы исправить кого-то или заняться планированием самостоятельно. Знайте, что иногда вы будете в пути, каким бы трудным он ни был.
