Владимир Швец: путь к успеху — это череда бесконечных ошибок

Владимир Швец

---

Более 15 лет занимается коммерческой разработкой, в основном высоконагруженными веб-системами и приложениями. Работал почти на всех должностях корпоративной лестницы — от тестировщика до ведущего архитектора.

---

В издательстве «Альпина Паблишер» вышла книга «От джуна до сеньора. Как стать востребованным разработчиком». Это полный гайд по жизни современного айтишника, который охватывает весь карьерный путь и аспекты профессии — от оформления кода и составления резюме до борьбы с выгоранием, когда больше не хочется быть разработчиком.

Автор, Владимир Швец, сам прошёл все ступени карьерного и личностного роста и потому не понаслышке знает, о чём пишет. Мы поговорили с ним о его пути и о том, как начинающим айтишникам влиться в отрасль и избежать распространённых ошибок.

Содержание

• Что изменилось в IT за 15 лет?
• Кому идти в IT, а кому не стоит?
• С чего начать карьеру?
• О первых ошибках и о том, как их избежать
• Как и куда расти джуну?
• Немного о будущем

Что изменилось в IT за последние 15 лет?

— Как вы пришли в IT?

— Сколько себя помню, я всегда хотел писать код. В детстве я нашёл книгу по программированию на языке С — для меня до сих пор загадка, как она вообще оказалась у нас дома. Как только начал её читать — оторваться уже не мог. При этом никто в моей семье не работал программистом, даже компьютера у нас не было.

Практиковаться было не на чем, но я представлял, что бы мог поменять в примерах программ и как бы они стали работать после этого. Сказать, что я понял хотя бы половину из того учебника, было бы сильным преувеличением: почти всё после первого прочтения казалось китайской грамотой. Но с того момента желание узнать, как всё устроено, больше никогда меня не покидало. К окончанию школы я уже неплохо разбирался в коде и точно знал, что если идти в вуз — то только по техническому профилю.

Правда, получив степень бакалавра, я осознал, что обучение по большей части было пустой тратой времени. Институтская программа отставала от реального рынка IT лет на пять, а то и на десять. Ничего из того, чему нас учили, никак не помогло мне в дальнейшем трудоустройстве — лучше б я потратил эти четыре года на самостоятельное профессиональное развитие.

— Как менялась отрасль за эти годы?

— Она стала куда стабильнее и взрослее. Компании начали понимать, чего они хотят, кто им для этого нужен и сколько они готовы на это потратить. Со своей стороны, специалисты научились быстро переключаться на перспективные направления и стали куда лучше ориентироваться в социальном взаимодействии.

Индустрия постоянно заимствовала практики западных гигантов индустрии, пробуя подстраивать их под свою специфику. Что-то проходило больше, что-то — меньше. Но в любом случае прогресс налицо.

Рынок IT долго был милостив к работникам. Ищущий всегда находил если не работу мечты, то хотя бы стартовую точку, с которой можно начинать движение. Соискателям многое прощалось в плане компетенций и довольно щедро воздавалось в плане денег.

События прошлого года, разумеется, не прошли незаметно: компании стали куда внимательнее в вопросах найма и офферов. То, на что могли закрыть глаза ещё три года назад по части навыков кандидата, сегодня станет причиной отказа.

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

Станет ли прошедший год стимулом к ускоренному профессиональному росту специалистов? Не знаю, но я бы не отказался от такой перспективы. Станет ли это для компаний поводом возложить на сотрудников дополнительные обязанности с сохранением прежней зарплаты? Тоже не знаю, но определённо не хотелось бы.

Кому идти в IT, а кому не стоит?

— Какие IT-специалисты сегодня наиболее востребованны?

— Есть профессии, которые всегда в ходу, — веб-разработка, создание мобильных платформ. Если хочется чего-то более модного — это блокчейн, машинное обучение, большие данные. Хотя я придерживаюсь довольно консервативного подхода в вопросах популярности и востребованности: лучше заниматься тем, что вас действительно увлекает. Ничто не мотивирует лучше, чем личный искренний интерес к своей работе.

Если же говорить о бизнесе в целом — есть ощущение, что он начал уставать от дополнительных прослоек в корпоративных иерархиях и «специалистов широкого профиля по общим вопросам».

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

— Есть ли люди, которым идти в IT противопоказано? В частности, насколько правдив стереотип, что эта отрасль — не для гуманитариев?

— Моё отношение к этому простое: абсолютно всё, что придумано одним человеком, вполне под силу понять другому. Я не очень верю в разделение на технарей и гуманитариев. У всех нас в черепной коробке находится мозг, который, за исключением тяжёлых неврологических нарушений, работает примерно по одному и тому же принципу.

Поэтому все страхи из серии «я никогда этого не пойму» или «я слишком тупой для этого» считаю необоснованными и бесполезными. Это лишь повод сдаться и перестать пытаться, даже толком не начав. Единственное, что вам нужно, если вы хотите освоить IT-профессию, — это желание и упорство в моменты, когда станет сложно.

Впрочем, есть несколько категорий людей, которым, возможно, пока не стоит нырять в отрасль с головой. Допустим, если вы пришли только за деньгами — простите, но на этом вы долго не протянете. То же самое могу сказать про престиж или какие-то другие радужные рекламные перспективы — не стоит их ожидать, тут этого нет. Если вы не готовы отдавать разработке время, силы, преодолевать трудности — лучше воздержаться, IT будет требовать всего этого в объёмах, совершенно отличных от тех, что вы себе представляете.

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

— Давайте рассмотрим этот вопрос глубже. Чем в плане скиллов профессионал в IT отличается от дилетанта?

— Если говорить о требованиях самой индустрии, то они остаются неизменными — усердие, любознательность и постоянное развитие. Плюс два главных, на мой взгляд, качества: умение нести личную ответственность за принятые решения и чутьё, которое развивается вместе с опытом.

Для меня ответственность — это полная вовлечённость в каждый продукт, с которым специалист работает. Любое принятое решение должно проходить не просто формальную оценку с точки зрения бизнес-процессов, но и согласование с внутренним «Я». Профессионал прекрасно знает цену ошибки. По большому счёту, весь его богатый опыт профессионала — это огромный багаж ошибок и пройденных уроков.

Профессиональное чутьё — более эфемерное понятие, но и оно прекрасно знакомо каждому. В этом нет никакой магии, это всего лишь привычка думать на несколько шагов вперёд. В самом простом виде такое чутьё элементарно позволяет писать качественный, хороший код, но представляет собой куда более ценный навык. Это возможность предвидеть плохие архитектурные решения за годы до того, как они дадут о себе знать. Или предугадать курс развития продукта в самом начале его пути. Не говоря об умении договариваться с коллегами и клиентами, видеть продукт их глазами.

Разумеется, оба эти качества практически не формализуемы, но любой работодатель будет искать в кандидатах именно их — в конце концов, у него для этого есть собственные хорошо прокачанные ответственность и профессиональное чутьё. Поэтому всем начинающим я бы рекомендовал улучшать не только технические навыки, но и софт-скиллы — учиться видеть дальше, погружаться глубже, видеть IT-индустрию и её продукты как живых существ. Чем они питаются, как выживают, какой у них жизненный цикл, повадки, на что они реагируют сильнее? Это будет огромным конкурентным преимуществом.

С чего начать карьеру программисту?

— Что бы вы посоветовали новичкам, которые только начинают устраиваться на работу? Где её искать? Как выглядит правильная, грамотно составленная заявка по вакансии? И какое мнение о компании можно по ней составить?

— Наиболее правильная заявка по вакансии, на мой взгляд, говорит с вами честно и напрямую. Она должна описывать то, чем вам придётся заниматься, конкретно, без бессмысленного перечисления всех существующих технологий и фреймворков, без невыполнимых требований вроде «опыт разработки: 10 лет Java + 10 лет жонглирования». Когда в вакансии указывается «дружный коллектив и кофе с печеньками» — искренне советую закрыть её и забыть, как страшный сон. Если в компании предпочитают, вместо того чтобы показывать лицо, надевать шутовскую маску — подумайте, насколько они будут искренни с вами, если вы получите там должность.

Ещё один важный фактор — конкретное указание размера оплаты труда.

Любая компания заранее знает, сколько она готова потратить на нанимаемого разработчика, в этом нет никакой тайны.

— Как ведётся первоначальный отсев? На что смотрит рекрутер, читая резюме? Что нужно в нём указывать — и чего не стоит делать ни в коем случае?

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

Во-вторых, старайтесь писать коротко и по делу, не доливайте в резюме воды. «Стрессоустойчив, усидчив, ответственен» — всё это пустые слова. Просто опишите конкретный опыт и проекты, в которых вы участвовали.

Для новичков это будет выглядеть как список языков и технологий, в которых вы действительно разбираетесь и про которые можете открыто и долго говорить.

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

— Как готовиться к техническому собеседованию? На что обратить внимание?

— К этому моменту у вас уже будет представление о том, на какой проект вас нанимают, какой технологический стек там используется, а если повезёт поговорить на ознакомительном звонке с техническим специалистом — то и общее представление об архитектуре проекта.

Готовьтесь к техническому собеседованию «прицельно» — повторяйте те технологии, которые используются в компании, читайте примеры интервью по вашей специализации. Используя знания о том, над каким проектом вам предстоит работать, попробуйте спрогнозировать возможные вопросы.

Не забывайте: это компания позвала вас на собеседование, это она решает, нужны ли ей ваши время и навыки. Тут всё как с обычными человеческими отношениями: мы не можем всем нравиться, соответствовать ожиданиям всех людей.

Ваша задача на техническом собеседовании НЕ состоит в том, чтобы отвечать абсолютно корректно на любой вопрос. Люди — не машины. Если от вас ждут, что вы будете цитировать по памяти RFC 2616, — это явно не та работа, которая вам нужна. Задача работодателя на собеседовании — понять, насколько вы компетентны и насколько умело адаптируетесь в ситуациях, когда у вас недостаточно данных. Поэтому, если у вас спрашивают о чём-то, чего вы абсолютно не помните, — попробуйте ответить аналогией, или перевести разговор на то, в чём разбираетесь, или так и отвечайте: «Я не помню». В некоторых случаях такая откровенность может сыграть вам на руку.

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

Первые ошибки и как их избежать

— Допустим, собеседование пройдено успешно и работодатель сделал вам оффер. В каком случае от него лучше сразу отказаться?

— Как я уже говорил, при любом оффере не советую продавать себя дешевле, чем вы оценили в резюме. Не надо идти на сделку с совестью. Хотя для новичков это требование будет чуть менее категоричным — вам так или иначе придётся проработать какое-то время за меньшие деньги, но нарабатывая опыт и профессионализм. Не самая приятная перспектива, но и не самая удручающая.

Кроме того, оценивайте оффер с точки зрения здравого смысла. Если в нём подробно перечислены штрафы за возможные ошибки или указано, что переработки не оплачиваются, — подумайте несколько раз, нужно ли вам это и точно ли вы готовы в этом участвовать.

— Какие ошибки чаще всего допускает новичок в первые дни работы? На какие грабли непременно наступит каждый?

— Как гласит старое айтишное правило, любой новичок однажды обязательно уронит прод =). Если же говорить серьёзно, могу назвать самые частые оплошности, которых точно можно не допускать, если заранее о них знать.

Не пытайтесь впечатлить коллег скоростью своей работы и скромностью оценки своих задач. Поверьте, никому нет до этого дела. Всё, чего вы этим добьётесь, — загоните себя в вечный цейтнот.

Не перерабатывайте! Желая влиться в проект и как можно быстрее в нём освоиться, новички почти всегда умудряются нахватать явно больше, чем могут освоить. Притормозите, от такого подхода вы только снизите качество своей работы и будете ошибаться даже в тех местах, в которых не ошибались никогда. Все понимают, что вы новый человек и вам нужно время, чтобы во всём разобраться.

Вы новенький, вы работаете с новым проектом со своими правилами, подходами, принципами и архитектурой. Один вопрос может сэкономить вам многие дни работы. Наличие наставника — безусловный плюс, но, даже если его нет, не отчаивайтесь. Задать вопрос вы можете любому, кто может на него ответить.

Не ходите в чужой монастырь со своим уставом. Да, вам может показаться, что проект технологически устарел и вообще это всё легаси, всё надо взять и переписать! Не надо. У любого проекта есть своя история и свой путь взросления. Поработайте с ним какое-то время — и вы, возможно, поймёте, почему один из компонентов до сих пор написан на Фортране, а его никто не переписывает.

Я, возможно, скажу крамольную мысль, но я придерживаюсь её достаточно давно, чтобы в неё верить. Работайте с кодом так, как принято на проекте. Да, это может расходиться с руководством языка, на котором вы пишете. Да, это может не соответствовать рекомендациям и лучшим практикам. И тем не менее, вы работаете с людьми, которые будут поддерживать и расширять ваш код. Так оставайтесь в команде!

Вы ведь точно не хотите поднимать бунт и отказываться работать, пока в проект не будет интегрирован линтер? Вы, конечно, можете попытаться, но всё, чего вы добьётесь, — поднимете уровень напряжения в коллективе.

Что касается базовых правил оформления кода, я всего лишь приведу цитату из восхитительной книги «Совершенный код», которой руководствуюсь уже долгие годы: «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте». Пишите комментарии, тесты, продумывайте названия переменных и методов. Читайте код как текст — это очень помогает понять, где вы избыточны или нелогичны.

Не страдайте синдромом самозванца и не бойтесь облажаться. Не пытайтесь быть тем, кем вы не являетесь. Просто делайте то, что умеете. Честность, открытость и прямота ценятся в любом коллективе. Всегда найдутся люди, с которыми вам будет интересно общаться, и события, на которых вам захочется присутствовать. Даже если вы действительно интроверт — попробуйте дать себе шанс. Это будет непросто, но это даст огромный толчок вашей карьере. Вы не сможете всегда выезжать только на технических навыках. Более того, спустя какое-то время вы и не захотите этого.

Обращайте внимание на атмосферу в команде. Хорошая, слаженная команда станет для новичка самым простым и комфортным способом начать работать. Вам всегда подскажут, спокойно, без критиканства, объяснят, как надо делать и как не надо. Тут необходимо уточнение: даже самая хорошая команда может поначалу показаться «неправильной». Стоит потратить некоторое время, чтобы понять, как все эти люди работают вместе.

Но из этого же следует и другой очень важный совет. Если вы поняли, что попали в банку со змеями, — плевать на оффер, плевать на деньги, плевать на самый шикарный проект на свете. Ничего из этого не стоит ваших нервов и здравого рассудка.

Как и куда расти джуну?

— Как понять, что ты засиделся на одном месте и не растёшь?

— Это одна из тех вещей, которые невозможно объяснить: это можно только почувствовать. Но когда ты это почувствовал — это ни с чем не спутаешь.

Объективным признаком того, что вы начинаете «ржаветь», можно считать выгорание и депрессию. Ваша работа начинает казаться абсолютно пустой. Задачи, которые раньше вызывали интерес и ажиотаж, теперь навевают тоску и беспокойство. Вам кажется, что ваши усилия ничего не стоят, что вы только допускаете ошибки, выполняете абсолютно бессмысленную работу, которая никому не нужна.

Разумеется, все эти ощущения могут быть связаны и с личной жизнью, тем, что происходит вне работы, но ключевой фактор — ощущение постоянного дежавю, когда все ваши задачи становятся похожи друг на друга, рабочие дни сливаются в один длинный, скучный, непродуктивный день.

Попробуйте разобраться: что именно привело вас в эту точку? Точно ли это проблема проекта, над которым вы работаете? Возможно, вы испытываете проблемы с рабочими процессами внутри команды, вас используют как человека для «черновой» работы? Понять, что пошло не так, — первый шаг к тому, чтобы разработать стратегию спасения.

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

— Что меняется в жизни человека при переходе от джуна к мидлу, от мидла к сеньору?

— Смело могу предположить, что с каждой из этих ступеней у человека становится всё меньше свободного времени. Если же без шуток, то каждый переход делает специалиста мудрее и терпимее. Вероятно, многие специалисты со мной не согласятся, но я всего лишь описываю то, как я видел этот рост в себе и в коллегах. На протяжении карьеры новичку придётся не раз пересматривать свои взгляды на индустрию, на личную вовлечённость, на взаимодействие с коллегами. Любые критические оценки, железобетонная уверенность и гордыня однажды разбиваются. И вам очень повезёт, если это произойдёт как можно раньше, когда цена ошибки будет не такой большой.

Любой рост требует усилий, болезненных трансформаций. Пройти этот путь достойно — значит научиться адаптироваться, принимать чужие мнения, слышать точку зрения, отличную от вашей, принимать чужие аргументы, если они объективнее ваших. Кому-то это будет даваться проще, кому-то сложней.

На просторах Сети можно встретить сколько угодно историй о том, что сеньор через три года работы — это нормально. Я в это не верю. Это не вопрос таланта, это не вопрос подкованности в технологиях, это вопрос того, сколько раз человек успел оступиться и подняться обратно.

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

— Как определиться, в какую сторону двигаться: развивать навыки в программировании или в администрировании, переходя в тимлиды, продакт-менеджеры?

Строго говоря, это вообще не вопрос выбора. Либо вам нравится селёдка под шубой, либо нет. Если вы попали в индустрию по одной специальности, но отчаянно ощущаете, что вам нужно что-то другое, — обязательно попробуйте это другое, прежде чем принимать решение о смене рода деятельности.

Верно и обратное. Однако в рамках компании вполне возможно попробовать себя в разных ролях, чтобы понять, что вам больше подходит и что приносит вам больше удовольствия в работе.