Елена Правдина - Говорят, в IT много платят. Как построить успешную карьеру разработчика, оставаться востребованным и не выгорать [litres]

Доминирование профиля – выбирайте, где будете в ключевых ролях. Трудиться единственным программистом в поликлинике среди пожилых врачей – худшее место для вашего профессионального развития и карьеры. Выбирать иные гос– и военные корпорации – не лучшее решение. Гораздо разумнее выбор профильной IT-компании. То же верно в количественном плане для распределенных команд. Старайтесь попасть в команду, представленную в вашем городе в большинстве или же содержащую ядро, ключевые кадры. Мне доводилось быть частью «меньшинства» и ощутить трудности, с которыми сталкивалась наша часть коллег. В конференц-связях сложнее принимать участие: многое, что обсуждает голосом более многочисленная часть команды, плохо слышит меньшая, ряд шуточек своей атмосферы – следствие ежедневного пребывания рядом – неизбежно ускользают от удаленной малочисленной части. В результате складывается разделение «свои-чужие», подсознательно проецируемое большей частью из личных географических на рабочие отношения. Ощущаемое чувство отторжения обидно влияет на меньшую команду. Их не так внимательно слушают, предложения рассматривают более скептически, они становятся будто бы менее значительны для продукта, что снижает драйв по-настоящему цельной командной работы и не дает полноценно почувствовать принадлежность к важному и единому – такому значимому для нас как социальных существ. При технических спорах, разногласиях и конфликтах участники с большей вероятностью, даже неосознанно, примут сторону тех, с кем сидят физически. И к тому же они действительно склонны искренне проникаться идеями и образом мыслей своей, «близкой», части команды. Отсутствие же руководства, тимлидов в вашем подмножестве команды и каждодневного взаимодействия с ними подрывает мотивацию, расслабляет профессионально.

Специализированность – избегайте распыления. Совмещать в себе роли администратора, фронт и бэк-программиста может быть полезно разве что на самых начальных этапах вашей карьеры – на стадии «сборки», как и обсуждалось ранее. Лекции забываются, да и зачастую далеки от реальности, а вот закрепление на практике «всего понемногу» – верстки, поднятия своей БД и связи с ней, умения настроить операционную систему, написать консольные скрипты – вам очень пригодится и в любой более серьезной компании. Там, где нанимаются глубокие узкопрофильные специалисты, у вас уже не будет шанса попробовать себя и во фронтенде, и в бэк-разработке, и в администрировании. Полученные же на ранних этапах навыки позволят лучше понимать весь процесс и в частности принимать технические решения, удобные и рациональные для другого звена. Так, бэк будет вам очень благодарен и зауважает «в момент», если вы подскажете ему уместный формат API, да еще и исходящий из минимальных временных затрат на выборку данных из БД. Имея же базовый опыт, избегайте статуса «эникейщика», умеющего многое, но недостаточно глубоко и профессионально во всех ассоциируемых с ним вакансиях. По крайней мере, пока ситуация на рынке не изменится и по каким-либо причинам не отвернется от востребованности узких грамотных специалистов.

Старайтесь выбрать компанию со своим продуктом, если хотите остаться там надолго и построить карьеру. Избегайте аутсорс-компаний. Там вы будете каждый раз «начинать всё сначала», и закрепить свою глубину знания продукта по сравнению с новичками вам будет непросто. Однако если вы относительно начинающий специалист и хотите прокачать в себе навыки работы на скорость, общения с разными заказчиками, разноплановость техник, набить руку на разных проектах, начиная их с нуля, и прощупать многие предметные области, то крупные компании, работающие с заказными проектами, – полезный выбор.

Инструменты – исследуйте используемый технологический стек. Вы молоды? Не идите на легаси-проекты. Бесполезно растратите энергию – рынок нуждается в инновациях. Знаете редкую технологию или старый фреймворк и готовы иметь с ними дело? Используйте конкурентное преимущество. Тем не менее старайтесь избегать культа инструмента – век любого из них сейчас относительно недолог. Пробуйте смотреть немного со стороны (без шизофренических наклонностей) на возникающий периодически, как вспышки молнии, то тут, то там ажиотаж по поводу нового пакета, фреймворка или подмножества языка. Учите, но не становитесь его проповедником.

Один из моих руководителей так отзывался о кандидатах, недовольных перспективой разработки на самописном фреймворке вместо общепринятых инструментов: «Если люди не идут к нам из-за этого, нам такие идиоты не нужны». И хотя я сама, только придя в компанию, ратовала за переход на популярные средства, позднее призналась себе – отчасти он был прав. Фактор не должен быть ключевым для серьезного и опытного разработчика. Все знакомые мне коллеги успешно поддерживали и применяли параллельно и рабочий местный, и общепопулярный «карьерно-полезный» стек, оставаясь в курсе новостей и релизов последнего. Не привязывайтесь к одному инструменту, не создавайте себе кумира. Мне зачастую смешно нередко наблюдать жаркие споры о варианте А или Б, которые спустя несколько месяцев или лет неизбежно отправятся почивать в мир иной, пав смертью храбрых и положив себя на алтарь динамики отрасли.Учите сам язык, осознавайте теоретические концепты – всё, что устаревает медленнее. Исследуйте популярные фреймворки и решения, переучивайте их на новые – только не кидайтесь в омут с головой, едва пара хипстеров напишут им хвалебные оды! Подобные непреклонные горячие диспуты «одно лучше другого» обычно присущи либо вчерашним студентам, либо фанатикам с местами недостаточно широко развитым жизненным кругозором, либо постепенно обросшим косностью старичкам «одного фреймворка».

Трезво оценивайте потребность инструментов на рынке, их назначение – для каких проектов подойдет один, для каких другой. Рано или поздно вам понадобится отказаться от своей любви к фреймворку или библиотеке – это неизбежно в текущих реалиях. А потому лучше и вовсе не привязывайтесь к ним слишком сильно – чисто рабочие отношения, ничего личного. Побочные эффекты нарушения этого правила, увы, вредят руководителям, сильно погрязшим в любимых детищах – самописных решениях. Даже в крупных компаниях. Безусловно, хороший специалист освоит и новый местный фреймворк. Но только при явно большем среднего желании. А такой уровень тяги к познанию малоупотребимых и нередко посредственных фреймворков редко присущ высококлассным кадрам. Отсюда, зная инструменты, можно сделать вывод о будущих коллегах и их уровне.

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