Владимир Швец: путь к успеху — это череда бесконечных ошибок
2026-02-21 00:32 Diff
https://skillbox.ru/media/code/vladimir-shvets-put-k-uspekhu-eto-chereda-beskonechnykh-oshibok/

#Интервью

  • 28 мар 2023
  • 0

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

Как стать программистом, не имея компьютера, что изменилось в IT за последние 15 лет и почему не всегда нужно обновлять код, даже если он устарел.

Иллюстрация: Gorodenkoff / Istock / Annie для Skillbox Media

Журналист, редактор. Фанат виртуальности во всех её видах — потому о ней и пишет.

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

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

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

Содержание

Изображение: издательство «Альпина Паблишер»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если компания, вместо того чтобы честно назвать свою зарплатную «вилку», начинает играть в игры «Все цифры — по запросу в директ» или «А на какой оклад вы рассчитываете?», я бы не стал тратить на неё время.

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

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

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

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

Не старайтесь уместить в резюме каждый ваш пет-проект: указывайте то, чем вы действительно гордитесь и что поможет «продать» вас как специалиста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не бойтесь спрашивать всех обо всём. Не стоит думать, что вы будете выглядеть дурачком, и доходить до всего самостоятельно. Это самая частая и самая нелепая ошибка.

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

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

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

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

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

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

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

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

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

Токсичные команды доведут вас до выгорания быстрее, чем вы успеете щёлкнуть пальцами. Проблемная же команда похожа на арену, где каждый хочет выйти победителем: издевательские код-ревью, агрессивные замечания или, на худой конец, прямой саботаж работы коллег — оно вам надо?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Куда, на ваш взгляд, будет двигаться отрасль в дальнейшем? И как, соответственно, развиваться новичкам?

— На мой взгляд, IT — такое же молодое, любознательное и живое существо, каким оно было, когда я только начинал работать. Оно любит играть, любит всё новое. И оно очень дружелюбное.

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

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

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

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

— Что обязан прочитать каждый айтишник? Какие сайты, сообщества, ютуб- и телеграм-каналы вы порекомендуете? Школы, конференции, обучающие платформы?

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

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

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

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

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу