Всем привет. Меня зовут Олег, я Senior Front-End разработчик в компании Genesis. Хочу начать с утверждения, что карьера front-end разработчика может достаточно динамично развиваться, если прикладывать к этому определенные усилия. В профессии я 5 с лишним лет. В этой статье я хочу поделиться своим опытом, который будет полезен как начинающим разработчикам, так и тем, кто уже имеет определенный опыт в front-end разработке.
Мотивация
В моем жизненном опыте существуют два уровня мотивации относительно карьерных перспектив на старте пути.
Первый – это выбор образования, который был достаточно прямолинеен и произошел от банального «сидения за компом», как, возможно, и у большинства молодых IT-специалистов.
Второй уровень – это осознание того, что реализация первого должна приносить определенный материальный доход, и, более того, что она соответствует ожиданиям рынка труда. Дополнительно, я оценил сферу разработчика как безграничную в плане возможностей, где я могу стать кем и как угодно, если буду регулярно работать над улучшением своих скиллов, как в общении, так и в прикладных аспектах разработки.
Мой первый профессиональный опыт
Мне, конечно, хотелось бы начать с того, как я с первого раза прошел собеседование в идеальную компанию своей мечты, сразу влился в коллектив, и быстро принялся идеально выполнять все порученные мне задания. Однако, это было не так.
Изначально я, как среднестатистический подросток 19 лет, попросту прожигал свое время, не понимая, чем хочу заняться в будущем. Во мне зрела идея того, что нужно добиться большего и начать применять знания, которые я получил благодаря нашей образовательной системе. Собравшись с духом, я решил обратиться к своему старому другу за помощью и советом. Он подсказал мне, что нужно начать с выбора языка, а также очертил набор базовых знаний, необходимых для прохождения собеседования. Также, он выступил как мой первый, хоть и условный, заказчик, который писал мне ТЗ для домашних проектов. С его помощью, мне удалось подготовиться для собеседования на должность full-stack разработчика. После нескольких неудачных попыток, мне все же удалось найти ту компанию, которая поверила в меня и дала старт в IT-мире.
Это был важный период в моей карьере, во время которого мне довелось пообщаться с большим количеством разноплановых заказчиков и научиться находить общий язык с коллегами разного уровня и возраста. Также, у меня появилась возможность самостоятельно разрабатывать проекты; впрочем, не без «набивания шишек» и исправления собственных ошибок по выходным.
Со временем я начал чувствовать в себе больше уверенности и сил совладать с более сложными задачами. Переосмысливая свою текущую деятельность и общие предпочтения, я принял решение, что создавать интерфейсы мне ближе и приятнее. В итоге я получил замечательный опыт, выпустил в свет несколько небольших проектов и познакомился с большим количеством интересных людей с разными взглядами на работу и жизнь. Самое главное — я начал чувствовать себя уже не студентом, а полноценным программистом, который готов покорять новые front-end вершины.
Топ-3 урока, которые я вынес из своего первого опыта
Поначалу, все боятся. Первое время у меня было ощущение, что меня уволят, что я ничего не смогу или делаю что-то не так. Эти чувства испытывают многие начинающие разработчики, и это нормально. Главное – это научиться работать с ними (концентрироваться на результате, доверять себе и своим решениям) и не давать им себя поглотить, стойко выдерживая все сложности.
Пообщаться с людьми иногда полезнее прежде, чем писать код. Когда я получал свои первые задачи, я сразу рвался писать код и думать, как это реализовать, не осознавая, что дьявол кроется в деталях. Проводя больше времени на уточнение всех особенностей задачи и поиске подводных камней, я стал учитывать больше особенностей на ранних этапах и совершать меньше ошибок, которые пришлось бы переделывать. Например, уточнив все особенности фичи, я понял, что она имеет коллизию с другим функционалом, что не позволило бы пользователю полноценно использовать нужный ему интерфейс.
Нужно давать себе отдыхать. Это может быть достаточно банальный совет, но для меня на тот момент он не был очевиден. Чем больше вы выматываетесь, тем меньше пользы вы принесете как для проекта, так и для себя.
Векторы развития Front-End разработчика
Первый профессиональный опыт развил мое понимание того, что проекты могут быть структурно поделены в таких направлениях как B2C, e-commerce, fintech и т.д. Это улучшило мое мышление как разработчика о необходимости анализа требований проекта и восприятия того, что ты делаешь со стороны пользователя. Соответственно, для себя я смог определить несколько дальнейших направлений в развитии.
Одно из направлений — техническое, с такими профессиями как: Tech-lead, Principal Engineer, Head of Engineering и т. д. Особенностями данной ветки развития являются глубокие знания технических спецификаций разработки, создание архитектуры для разных приложений, а также умение выбирать и адаптировать нужные технологии под тип поставленной задачи.
Другое направление — менеджерское, с такими профессиями как: Team-lead, Dev-manager, Project manager и т.д. Данное направление отличается от технического более углубленным общением с людьми. Необходимо уметь строить команду, раскрывать потенциал сотрудников, а также анализировать и понимать потребности бизнес части проекта.
Проблемы, которые могут возникнуть
Адаптация на проекте. Это проблема возникает у всех независимо от опыта работы. Поначалу вы всегда привыкаете к проекту, стилю написания кода, построению бизнес-процессов и к людям, вовлеченным в этот проект. Очень круто, если вам повезло, и вы попали на проект с детальной документацией. В этом случае в первую очередь стоит уделить как можно больше времени на ее прочтение — так у вас в будущем возникнет меньше вопросов. К сожалению, в моем опыте это случалось не часто. В основном, документация либо вообще отсутствовала, либо присутствовала в минимальном объеме. Тем не менее, в подобных ситуациях не стоит расстраиваться, поскольку при правильном подходе можно быстро сформировать общее понимание о проекте. Вначале, необходимо провести встречи с менеджером, который руководит проектом, уточнив:
а) процессы разработки;
б) формирование команды;
в) текущее состояние проекта.
Также, будет полезно пообщаться с программистом, который построил архитектуру данного приложения или работает на проекте дольше всех. У него вы сможете узнать:
а) основные принципы построения архитектуры проекта;
б) базовый набор используемых библиотек;
в) стилистические особенности при написании кода и т.д.
На начальных этапах не нужно стесняться брать самые простые задачи (например, исправление мелких багов или внесение незначительных улучшений), которые уже долгое время находятся в backlog. Также, отличной идеей может стать написание тестов. Это поможет вам начать разбираться в проекте с минимальными рисками даже при отсутствии детальной документации.
Период адаптации в среднем длится от одного до трех месяцев. Тем не менее, если проект объективно большой либо содержит сложную бизнес-логику, его изучение может затянуться на более длительный срок. В данном случае, очень важно построить план и поэтапно следовать ему. Более того, не нужно стесняться задавать глупые вопросы коллегам; возможно, так вам будет легче изучить сложные аспекты проекта.
Переработка. Это достаточно сложная проблема, которая может испугать начинающих разработчиков. Для себя я определил несколько причин из-за которых происходит переработка:
а) переоценка возможностей;
б) необходимость проекта;
в) эксплуатация сотрудников.
Переоценка возможностей происходит, когда на должность нанимают кандидата с недостаточным набором скиллов, или в случае, если кандидат подался на должность, к которой не готов. Однако, это не худший сценарий, поскольку все еще можно исправить и извлечь выгоду из сложившейся ситуации. В первую очередь, следует взять волю в кулак и начать изучать материал, необходимый для данной должности. Также, стоит обратиться к линейному менеджеру, очертить план развития и, возможно, обсудить прохождение курсов и дополнительных интенсивов. Хороший работодатель будет стараться удерживать сотрудника, который стремится к развитию и в будущем сможет принести больше пользы.
Иногда бывают ситуации, когда переработок требует определенный проектный период. Особенностью данных случаев является то, что переработка не должна длиться долго. Обычно, это исчисляется днями или неделями, но в редких случаях несколькими месяцами. Часто бывают ситуации, когда перед крупным релизом или выходом на продакшн, особенно в небольших компаниях, необходимо работать больше и интенсивнее обычного, чтобы проект получился идеальным. К таким ситуациям стоит относиться лояльно и стараться достичь поставленных целей вовремя. В моем опыте осознание необходимости проекта сильно помогало расти как специалисту, приносило опыт работы в стрессовых ситуациях и поднимало ценность в глазах работодателя.
Третья причина переработки – это эксплуатация. К сожалению, на рынке ИТ данная проблема до сих пор встречается. При эксплуатации работодатель может накладывать бесконечный груз ответственности на сотрудника; давать объем работы, который объективно не соответствует выделенному времени; обесценивать ваш вклад в развитие продукта, и постоянно обещать улучшение рабочей обстановки в ближайшем будущем. Если положительной динамики не наблюдается, я бы рекомендовал перейти в другую компанию. Более спокойная ситуация в другой обстановке и на другом проекте будет полезнее для развития и сохранит ваши нервы.
В общем и целом, в процессе развития могут возникать разнообразные проблемы. Главное, на мой взгляд, не поддаваться панике, а принимать их как вызов. Проработанные планы решения проблемы, а также правильно сделанные выводы помогут вам стать высококвалифицированным специалистом.
Роль обучения
Основное образование и литература. Ключевую базу знаний я приобрел из колледжа и университета. Но я однозначно уверен в том, что будущий front-end разработчик не должен фокусироваться на книгах по программированию образца 1994 года, поскольку это сфера достаточно динамично развивается и меняется. Но при этом, некоторые технические сведения все равно можно почерпнуть из ранних публикаций таких как: Design Patterns: Elements of Reusable Object-Oriented Software, Clean Code: A Handbook of Agile Software Craftsmanship и других.
Их прочтение необходимо для общего понимания того, как организован процесс разработки и как строить сложные, устойчивые системы. При этом, необходимо искать доступ к более современным ресурсам, например egghead, frontendmasters.com и множеству других. Однако, большинство ресурсов достаточно редко адаптированы на русский и, еще реже, украинский языки.
Дополнительные знания и социальные сети. Для приобретения современных знаний, я так же подписался на несколько социальных каналов тематического направления. К примеру, это несколько каналов в Twitter, таких как JavaScriptDaily или CSS-Tricks и блоги людей, например, Dan Abramov / Kent C. Dodds, связанных с обновлением или улучшением репозиториев библиотек для программных разработок, которые мы, как команда, сейчас используем. Но при этом, важно помнить, что на более высоких уровнях должностей, очень важно правильно и доступно презентовать идеи своей деятельности как уверенного программиста. Поэтому, в последнее время я обращаюсь к тем самым ранним публикациям, которые связаны с определенными паттернами для разработки, нежели исследую техническую составляющую. Также, несколько каналов на YouTube, которые я сейчас использую:
webDev — современный русскоязычный канал, в котором все о современных трендах, и простое описание сложных принципов в программировании.
DesignCourse — прекрасный англоязычный канал, который показывает проекты со стороны дизайнера. Для front-end разработчика это очень ценная информация, так как профессия предполагает тесное сотрудничество с дизайнерами.
Fireship — условно развлекательный контент на английском, который вкратце рассказывает об front-end новостях.
JSConf — кладезь всего что есть сейчас в JS-мире, лекции из самых популярных JavaScript конференций.
Требования к знаниям
Требования к junior позициям. Возвращаясь к требованиям для начинающих программистов, я отмечу, что багаж знаний даже для начинающей должности должен быть значительно выше того, чем был в начале моей карьеры. Люди, которые собеседуют потенциальных соискателей, стали более требовательны, так же, как и динамика рынка стала более высокой благодаря возрастающему интересу к программной разработке в целом. Понимание структуры и логики языка программирования тоже очень важна, поскольку для человека, который не владеет нею, займет очень много времени для дальнейшего изучения. При этом, проект сам по себе может требовать более интенсивной вовлеченности и расширенной базы знаний. Также, понимание причинно-следственных связей, например, осознание роли динамических библиотек и их изменений для программного кода, стали более весомы даже для уровня тех, кто начинает карьеру во front-end.
Разница между middle и senior позициями. Если говорить о разнице между требованиями к знаниям, то junior-разработчики должны владеть отличным пониманием теоретической части, например, как работает язык, как работает браузер, как это все взаимосвязано и т.д. Также, у младших специалистов может отсутствовать понимание того, как взаимодействовать с командой, или как строить сложные системы, которые будут легко масштабироваться и будут гибкими для изменения.
В то же время, специалисты уровня middle — это своего рода эксперты в использовании методов разработки и успешном применении их к определенной бизнес-проблеме. Для специалистов этого уровня важно понимать принципы работы в команде и пользу взаимодействия друг с другом.
Senior — это эксперт как в разработке, так и в обучении и коучинге. Специалист, занимающий эту должность, больше времени уделяет анализу клиентских потребностей и их интерпретации в технической форме, нежели самой разработке.
Тем не менее, это видение может измениться в будущем и многие вещи идут к усложнениям, поскольку JavaScript, как основная концепция для front-end разработки остается прежней, но количество библиотек, приложений, и методов их применения динамично растет.
Роль английского
Разработчикам очень важно не забывать о роли английского языка, который нужен как для коммуникации с внешними клиентами, так и для восприятия обучающих материалов, доступных в основном на английском.
В процессе работы я регулярно использую свои знания английского, общаясь с менеджерами разного уровня, читаю документацию к продукту, и даже просто общаюсь с англоговорящими коллегами на разные темы.
Моя позиция заключается в том, что английский нужно держать на уровне минимум intermediate, поскольку при поиске работы вероятны случаи удаленных собеседований с иностранными заказчиками, так же, как и в случае переключения между проектами. Но главное – быть уверенным в том, что, если внезапно нужно переключится с русского или украинского на английский, ты все равно сможешь объективно доносить свою идею собеседнику.
Управление людьми и лидерство
Одна из главных проблем у разработчиков, как в моем, так и в случае других людей, которых я знаю – это в достаточно молодом возрасте освоить soft skills. Они предполагают управление командой, общение с требовательными заказчиками, и решение рабочих конфликтов.
Из личного опыта, мое управление конфликтами отчасти строилось на примере общения с опытным разработчиком, работающим в данной сфере более 15 лет и имеющим определенное влияние на другого сотрудника, который также имел свою личную, местами неконструктивную точку зрения на ход событий. Для разработчиков – это типичный пример стагнации, где лидерство теряет смысл, если человек сфокусирован на своей личности, нежели чем на необходимости командного духа и ориентации на желания клиента. Дополнительно, на senior уровне я начал читать литературу по психологии и групповой терапии, что позволило мне мыслить более открыто и конструктивно.
Мои советы Front-End разработчикам
Не пугайтесь сложностей, которые, возможно, являются отголосками вашей прошлой рабочей деятельности.
Осознайте, что на младших позициях разработчиков вам стоит фокусироваться на проблемах технического характера, но на старших должностях вы должны думать о конкретно вашем влиянии на бизнес и того, как стратегические проекты в этом сопутствуют.
Ищите точки соприкосновения с людьми разных поколений, поскольку коммуникация так же важна, как и техническая экспертиза.
Ну и, конечно, работайте над своими знаниями и разговорной речью – мы хоть и работаем в технической сфере, но гуманитарная, или soft skills часть тоже важна для быстрого карьерного роста.
