Все мы проходили (или пройдем) этап, когда все-таки серьезно решили устроиться в IT, готовились какое-то время, читали информацию, мечтали об успехе, и вот наконец устроились в первую компанию. Маловероятно, что получится испытать те же эмоции еще раз, ведь это момент, когда ты получаешь свои первые деньги за то, что прошлые условные полгода делал бесплатно. В этот самый момент кто-то может предпочесть стабильность, и останется в этой компании на достаточно длительное время.
Это третья статья из цикла возможных ошибок, которые могут допустить разработчики в начале своей карьеры. Из этого следует, что сейчас я буду рассуждать о том, почему такое решение может обернуться проблемой в будущем.
Прошлые статьиПримерный план будущих статей:
-
О выгорании на ранних этапах
-
О важности изучения языка, но не фреймворка
-
Когда ты перестаешь быть junior разработчиком
Если вам интересна какая-то из этих будущих тем больше, чем остальные, пишите в комментариях, постараюсь выпустить как можно раньше.
Disclaimer: эта статья не является абсолютным правилом, и ваш опыт может отличаться.
Давайте для начала определим исходные условия для появления проблемы, которую я опишу чуть ниже.
-
Это ваше первое местое работы
-
Вы работаете там достаточно продолжительное время (1 - 1,5 года +)
-
Вы работаете с одним и тем же лидом/ментором
-
Вы работаете на одном и том же проекте с одинаковым стеком
Если говорить грубо, вы устроились на работу, и у вас в целом особо ничего не поменялось за то время, пока вы тут работаете. Проблема возникает в тот момент, когда вы решите сменить место работы.
В чем же суть проблемы, спросите вы? Первая работа и опытный ментор имеют крайне сильное влияние на человека. У вас нет времени оценивать каждое требование, нет каких-либо особых предпочтений, вы полностью доверяете старшему разработчику и это нормально. В какой-то момент вы так привыкаете к каким-то правилам (или отсутствию правил), что весь процесс работы над задачей проходит автоматически.
Если вы сейчас думаете, что я буду говорить о том, что первый ментор может быть не таким уж опытным и передать неправильные знания, то вы ошибаетесь. Хотя такой вариант тоже возможен, но чаще всего это редкий случай.
Но если мы принимаем как факт, что все-таки первый лид был достаточно опытным, то где же кроется проблема? И ответ на этот вопрос - в гибкости. Возможно сейчас кто-то со мной поспорит, но нет плохой архитектуры и плохих правил как таковых. Есть не рекомендуемые конструкции, но это не делает их плохими. Опытный человек понимает, где это не принесет больших проблем, а где стоит все-таки потратить больше времени и продумать удобную, расширяемую архитектуру.
Но есть гораздо более важный момент, вы работаете в команде, а самая лучшая команда - это та, которая пишет как один человек. В таком случае задача может легко перейти другому разработчику, а когда тебе поступает новая, ты можешь легко разобраться, что происходит в участке кода, который писал не ты. Также в каждой команде принят стандартный workflow для задачи, включающий в себя даже такие этапы, как именование веток или названия коммитов.
И workflow хорош именно тем, что он гибкий. Он изменяется под нужды текущей команды, проекта, релизов, постановки задач. То есть нет такого единого стандартного решения, есть база, которая видоизменяется со временем.
Если вы еще не поняли, как выражается эта проблема, то более конкретно - в непринятии новых правил, требований, стека. На автомате человек делает как раньше, не понимая потом, почему его задачу не принимают и просят переделать. Ему может показаться, что к нему придираются и просят изменить что-то малозначительное, хотя если смотреть шире - то можно увидеть, что это может быть давно принятым правилом, и команде так удобнее.
Смена работы - это часто стресс. Особенно в IT, где от команды к команде может измениться все. Когда ты долго работаешь на одном месте и уходишь в другое, то довольно тяжело принять что твое понятие хорошо, здесь может быть вообще не хорошо. Или наоборот, то что ты считал плохим решением, здесь используется повсеместно. Самое главное - понять на этом этапе, что такое возникает не потому что в другой команде делают неправильно, а что они приняли такой вариант, потому что им было удобно с этим работать в данный момент времени.
Пример из жизни о правиле, которое не понятно сразуВ дальнейшем будут приводиться примеры, они взяты из личного опыта. Примеры необходимы для иллюстрации, как это происходит на практике с объяснением почему в данном проекте и команде было принято так, или почему вот так не сделали. Ни в коем случае они не сделаны, для того чтобы показать, что люди чего-то не понимали или были не правы.
На одной из моих работ руководитель откатывал все задачи с
формами, где нельзя было заполнить ее только с помощью клавиатуры.
И казалось бы, ну это же мелочь, и статистика показывает, что
обычные пользователи активно пользуются мышкой и редко нажимают
tab и enter (а уж про сочетание
shift + tab мало кто даже из IT знает). Но в той
компании руководитель активно участвовал в тестировании, и для
ускорения его прохождения он строго требовал, чтобы такая
возможность была, так как тогда он может закончить приемку задачи в
разы быстрее, что улучшает эффективность команды в целом.
Один из моих разработчиков довольно тесно работал с husky, и он предлагал ввести его в проект. И это действительно хороший инструмент, но было принято решение отдать предпочтение ci/cd, так как в команде есть правило о маленьких, атомарных коммитах, и частенько возникала ситуация, когда коммитили частично, и остальные файлы могли быть еще на стадии доработки.
Да, husky можно было бы настроить на изменения в
коммите, или перевести на команду push, но то ли я не
доразобралась, то ли что, но на push оно в результате
все равно отправлялось несмотря на то, что проверки
проваливались.
Другой момент - практика показала, что гораздо удобнее для команды, когда это происходит на стороннем сервисе и ты не прерываешь свою мысль над задачей в середине, потому что не можешь что-то закоммитить или запушить.
То есть в результате, контроль качества кода проводился, просто другим способом, который более привычен для большей части команды. Но разработчику все равно было некомфортно, потому что для него это было не то решение, к которому он привык.
Иногда проблема возникает из-за незнания по какой причине было принято определенное правило или использовалась какая-то библиотека в силу неопытности. Неосознанно, чтобы уменьшить "незнакомость" проекта и вернуться во что-то привычное, человек может начать продвигать технологии, которые использовались на прошлом месте работы. Иногда эти предложения могут быть серьезными усложнениями, не дающими в перспективе значительных улучшений в качестве и простоте кода.
Пример из жизни на эту темуДано: есть проект на Vue, который был написан бэкендщиком без знания клиентской архитектуры, и который в кратчайшие сроки нужно было привести в более менее работающий вид. Разработчик из команды предлагает ввести RxJS в проект (до этого он долго работал с Angular, это было кстати его первое место работы).
Немного почитав я вижу, что RxJS использует паттерн Observable, который уже реализован во Vue, и большинство потребностей в виде подписки на изменение переменной / реактивности и т.д. там уже реализованы из коробки. Предполагаю, что это очень классный инструмент, который можно круто применить. Но человек предложил его именно по причине, что он привык с ним работать. В данной ситуации не было особой пользы в его применении.
В том же проекте, часть файлов он написал на TypeScript
(большая часть была на JS). Мне очень нравится
TS, но по опыту я знаю что 2-я версия Vue не
очень хорошо с ним работает, и местами это вызывает трудности. В
результате больше времени тратится на то, как правильно этот тип
прокинуть, а то и вовсе просто пишется any. Также
нужно учитывать момент, что перевод проекта на TS - это
увеличение сроков, и в данном случае это было нецелесообразное
решение. Причина по которой он начал это делать довольно проста,
привычка и мысль, что так правильно, а по-другому плохо, значит
нужно переделать.
До этого я приводила примеры и описывала ситуации, которые возникают с людьми, которые работали с опытными менторами. Но все-таки стоит затронуть ситуацию с низкими стандартами кода, которая иногда встречается в тех же веб-студиях. Если в прошлых примерах разговор чаще шел о хороших практиках, которые просто не подходят под текущую ситуацию и стиль команды, то с людьми из следующих примеров чаще обратная проблема. Им наоборот кажется, что все правила - это усложнения и зачем заморачиваться, если и так все работает.
Бывает, что они могут отнестись с негативом к изменениям их кода в пользу более удобной архитектуры, которая рассчитана на дальнейшие изменения. Также может быть негатив к линтерам и форматтерам, если они с ним не работали, их могут раздражать эти "ошибки", которые они не считают ошибками, а своим стилем. Но как я уже объясняла выше, важно, чтобы команда писала как один человек, поэтому их задачи будут продолжать откатываться, чтобы привести все к единому стандарту.
Пример о непринятии замечаний в силу неопытностиЯ какое-то время работала в веб-студии, а потом попала в компанию с более строгими стандартами. Тогда по началу у меня часто возникали споры с дизайнером, потому что он очень внимательно проверял задачи, обращал внимание на то, посередине ли элемент, какой размер шрифта, как выглядит адаптив на каждом пикселе, какие ховеры у элементов, как выглядит при нажатии, и не остается ли ховер на мобильных устройствах.
Для меня это было абсолютно ново, и мне казалось что он отправляет на доработку просто из-за мелочей, которые не особо важны. По сути он научил меня тогда, как делать правильно, как улучшить UI/UX для обычного рядового пользователя, и почему важны такие мелочи. Конечно потом я поняла, что была не права, но также поняла для себя, что это сильно зависит от проекта и его задачи.
Проекты, к которым ты должен возвращаться (то есть рассчитанные на удержание клиента) должны быть как флагман в мире телефонов, то есть ты просто им пользуешься и все работает так, как ты ожидаешь и как ты хочешь. Тогда к нему возвращаться приятнее, и не хочется разбираться в другом продукте, который менее отзывчивый.
В практике встретилась довольно интересная задача о многосоставных опросах. Руководитель проекта хотел видеть опросы, которые перемешивались бы с кастомными страничками, и чтобы еще были а/б тесты. Так как сроки были довольно ужатые было принято решение захардкодить 2-х составной опрос, то есть он мог работать только при определенных условиях и рассчитан был на конкретные компоненты между опросами и конкретную очередность.
Но также при работе с задачей уже было понимание, что на данный момент это очень не гибко, руководитель хотел больше возможностей, так как на эти опросы была высокая ставка. Для этого я спроектировала архитектуру, включая возможности а/б тестирования, показа компонентов, возможности нескольких шагов и самое главное, гибкую. Я учла возможность добавлять и реализовывать другие параметры, которые возможно нам понадобятся в будущем.
Разработчик подошел к этому негативно, так как по его мнению это было лишнее усложнение системы. Для текущей задачи она действительно работала, но для того, чтобы по максимуму реализовать желания руководителя, было необходимо более серьезно подойти к вопросу архитектуры.
Кстати именно из-за этого в вакансиях на разработчиков может присутствовать строчка от n лет коммерческой разработки, не всегда у команды есть время ждать, пока новый сотрудник привыкнет к высоким стандартам, и более простым решением становится нанять того, кто на практике уже к этому привык.
Немного о фрилансе
Если человек долго работает в фрилансе, у него также могут возникнуть проблемы, когда он начинает работать в команде. Кстати по той же причине, что и у людей, еще не менявших до этого работу. Иногда у людей во фрилансе нет понимания, что при работе в команде ты не один показываешь результат, а вся команда, и оценивают ее в целом, а не кого-то отдельного. Соответственно, гораздо более приоритетен результат и продуктивность всех в общем, а не конкретно взятого сотрудника.
По секретуФрилансерам может прийти отказ после собеседования в продуктовую компанию именно по причине того, что собеседующий может засомневаться в том, что человек привыкнет к работе в команде и присутствию лида, который устанавливает определенные правила и контролирует их выполнение.
Заключение
Проблему я описала, а решение нет. Если вы впринципе не хотите
столкнуться с этой проблемой, то это абсолютно нормально сменить
несколько мест работы (только не через 3 месяца,
пожалуйста), даже при условии, что на текущей вас все
устраивает. В начале карьеры вы максимально гибки, и вам будет
легче адаптироваться, в дальнейшем в этом уже нет необходимости,
так как приходит понимание, почему важно придерживаться
определенных правил и где стоит гнуть свою линию, а где важнее
командная продуктивность.
Если же вы уже довольно длительное время в одном месте, и сейчас задумались о том, чтобы сменить работу, то настройте себя на максимальную гибкость, и попробуйте поработать в другом стиле, даже если для вас это будет непривычно. Старайтесь замечать хорошие вещи в новом подходе и не зацикливайтесь на старом. Получайте максимальный опыт от людей и пробуйте разные варианты, в этом же прелесть работы разработчиком, что жизнь всегда подкидывает что-то новое.
Если же вы недавно сменили и столкнулись с непринятием и негативом из-за новых правил, то постарайтесь оценить объективно, не является ли это стремлением к тому, чтобы вернуться в старые знакомые края, и действительно ли то, что вы считаете правильным, будет являться правильным для всей команды? Если вы считаете, что да, то постарайтесь аргументированно доказать свою точку зрения с практическими примерами, но также учтите сроки и пользу таких изменений и являются ли эти 2 метрики соразмерными.
Вообще в этой статье я также хотела поговорить о навыке релиза продуктов, но текста уже достаточно много, так что я поговорю об этом в следующий раз.
