Источник: Habr.com
Date: 2019-09-08
Привет! Программирование – это непростой предмет, а индустриальная разработка программного обеспечения – очень сложный. В нашей ИТ индустрии не так уж редко можно услышать вопросы от младших коллег из серии «как мне развиваться?», «что нужно делать, чтобы стать профессионалом высокого уровня и как можно быстрее?», «что делать, если развиваться не получается, а интересных проектов нет?», «что должен знать миддл?». Если у вас от 0 до 3-х лет опыта в ИТ, вы начинающий специалист (или только собираетесь им стать) и ставите перед собой подобные цели профессионального и карьерного роста, ищете правильные пути, как этих целей достичь – этот пост для вас, добро пожаловаться под кат. Возможно, он также будет интересен тимлидам и менеджерам, в общем, всем, кто занимается обучением и развитием специалистов.
Для начала, позвольте представиться. Меня зовут Анатолий и если опустить должности и ранги, то прежде всего я Разработчик, потому что в широком смысле слова всю свою карьеру занимался разработкой, исследованиями и управлением разработчиками. Мой опыт в индустрии 10+ лет. Он достаточно разнообразен и простирается от финансовых систем и веб сайтов, до продуктов, алгоритмов и систем машинного обучения. Основное, однако, как мне кажется, состоит в том, что я сам был на месте целевых читателей этой статьи и впоследствии начал заниматься в разных аспектах развитием молодых программистов. На текущий момент через меня прошло уже в общей сложности более 2-х десятков junior developers и стажеров. Поэтому, считаю, что мне есть о чем рассказывать. Большое количество материалов по обсуждаемому вопросу, которые можно встретить, посвящены либо чисто техническим темам, либо, к примеру, почти слепому следованию Scrum’у. (типа — “если не знаешь что делать, попробуй работать по scrum’у и все будет зашибись” :) ) Как бы не казалось из реалий и статистик отдельных команд и специалистов, это далеко не все вещи, составляющие практику и культуру разработки ПО. Поэтому, думая о чем писать, я решил, что не буду повторять эти сведения, а лучше постараюсь сфокуссироваться на темах, про которые не так много пишут или говорят. Поехали!
Да, в качестве дисклеймера, хотелось бы сказать, что описанное есть мое личное мнение, подтвержденное опытом и теоретическими знаниями, которые на этом опыте были проверены. Оно может не соответствовать той реальности, в которой вы окажетесь, поэтому позвольте дать вам сразу первый совет статьи: прежде всего, в любых сложных ситуациях стоит проанализировать её конструкцию, до того, как применять какие-то известные вам практики и паттерны вида «если, то». Детали очень важны. Вот теперь — поехали! :)
Часто люди, которые только хотят научиться программировать задаются вопросом, какую технологию выбрать для изучения, да и вообще, на каком ЯП, грубо говоря, «лучше писать код». Люди, которые устраиваются на свою первую работу думают о том, будет ли их текущая технология перспективна и востребована через пару-тройку лет и далее. (некоторые — совсем не думают, но это чаще всего не есть хорошо) «Лучше» и «перспективнее» здесь — это весьма субъективные понятия, определяемые на уровне ощущений и возможной пользы для дальнейшей карьеры. Достаточно быстро новичкам в ИТ может стать ясно, что многие проекты делаются на достаточно большом количестве технологий, а всего знать-то и невозможно. Так нужно ли гнаться за всеми зайцами?
К примеру, на первом году работы я получил ценное замечание от своего тимлида о том, что необходимо сфокусироваться на какой-то одной области, потому что специалист либо в чем-то специалист, либо, грубо говоря, не специалист ни в чем. Чтобы знать что-то на достаточно высоком уровне, необходимо заниматься этим постоянно и глубоко вникать в детали — чистая правда и трудно с этим поспорить. И действительно, практика это подтверждает: большинство известных мне специалистов (кто может таковыми считаться) — это узкие специалисты. Некоторые из них просто блестяще знают свой Предмет и поэтому решают в рамках него задачи небывалой крутизны. На этом месте можно было бы сказать «ОК, значит, принцип верен — все сходится», если бы не несколько НО. Дело в том, что спектр проектов, где будут востребованы такие узкие специалисты существенно уже, чем, понятно, у специалистов более широкого профиля. Не раз мне встречались проекты, участие в которых было бы просто невозможным без наличия широких познаний в нескольких технологиях сразу. Люди, которые этими знаниями обладали, открывали для себя новые, порой недоступные двери. А участие в отличном, уникальном проекте — это очень серьезное и полезное карьерное испытание, способное принести вам много ценного опыта и прочих бенефитов. Второе НО состоит в том, что мир технологий постоянно меняется и строго ограничив себя знанием одной-двух технологий или ЯП, можно естественным образом начать терять конкурентное преимущество и стать менее востребованным специалистом.
Итого, коротко можно сказать так: не бойтесь пробовать технологии, которые вам нравятся! Возможно, вы не станете экспертом в 3-х языках программирования сразу, или в 5-ти фрейморках, но знание их основ и внутреннего устройства — это серьезное конкурентное преимущество, если при прочих равных вы попадете на вакансию, где требуется сильное знание 1 технологии и базовое нескольких других. Главное здесь — мера и ограничение. Важно четко определить приоритеты, на изучение какой технологии вы тратите основное время, на изучение каких — оставшееся.
От специализации в языках программирования и технологиях разработки мы плавно переходим к следующей важной вещи — функциональной области. Привести пример легко из жизни: как у врачей есть стоматологи, а есть кардиологи, так и среди разработчиков бывает специализация, и речь здесь вовсе не только о вышеупомянутых технологиях или языках программирования. Разработчики специализируются на разном: кто-то занимается интерфейсами пользователя, кто-то процессит данные на кластерах, кто-то распознает изображения, а кто-то пишет логику для игрового бота. Примеров уйма.
Возможно, в первые 2 года работы или даже больше вас и не будет беспокоить вопрос специализации, поскольку вход в проекты и технологии, на которые вы попадете, будет занимать существенное время, и этот вопрос просто не будет актуальным естественным образом. Однако, начиная с определенного момента, вы почувствуете легкость в решении все более и более сложных задач в какой-то области, и результат будет определяться во многом уже не степенью того, как детально, к примеру, вы знаете стандартную библиотеку того ЯП, с которыми вы работаете, или как виртуозно вы владеете продвинутым синтаксисом этого ЯП, а вашим опытом в конкретной функциональной области. Компьютерная графика, компьютерная лингвистика, финансовое программирование — все это конкретные области, на изучение и обретение практического опыта в которых уходят месяцы и годы. Если вы ставите перед собой цель стать спецом высокого уровня, найдите ту область, которая вам по-настоящему нравится. И если она вам действительно нравится — развивайтесь и работайте в ней с удовольствием, и все получится!
Не существует двух полностью одинаковых проектов. Не существует одинаковых команд. Порой и не существует единственно правильного решения, будь то глобальное решение об архитектуре большой части системы или локальное решение о способе хранения файлов в репозитории. Перед начинающим специалистов встает много вопросов и сомнений. Вопросов, на которые в силу отсутствия опыта может так сразу и не найтись ответа. Вы получили готовый код и он совсем не работает, хотя у других коллег все нормально; процедура установки сервиса в 1 случае из 6 завершается с ошибкой – и хоть убейся, но непонятно, почему; вы не можете настроить сетевую часть сервиса, хотя делаете все по инструкции и перечитали ее уже 7 раз. Такие ситуации у разработчиков, тестировщиков и админов возникают постоянно. Степень сложности проблем может варьироваться от уровня «наверное, нужно копать куда-то туда» до «куда копать — совсем не понятно». Первый совет, который хорошо знают и дают опытные специалисты (и, наверняка, вы его уже от них слышали) состоит в том, что вам необходимо научиться как можно более самостоятельно разбираться в проблемах, когда вы в них вязните. Как правило для этого необходимо концентрироваться на причинно-следственной связи и научиться формулировать правильные вопросы о проблеме. В первую очередь — к самому себе, во-вторую очередь — к Гуглу. Оно ведь не просто так «все не работает», даже если вы в этом уверены, попробуйте вернуться «к началу», чтобы найти реальную причину проблемы. И, скорее всего, вы не один такой с подобной проблемой, просто погуглите и убедитесь в этом. Далее, следующий простой совет: только после того, как вы сделали несколько неудачных попыток и провели анализ проблемы самостоятельно, потратив существенное время (как правило, измеряется в часах, иногда – в днях) – обратитесь к старшим коллегам. Так вы не потратите их ценное время на решение ерундового вопроса, который бы вы и сами легко могли решить, применив большую усидчивость. Тем самым вы продемонстрируете, что у вас выработался правильный подход к решению проблем. Многие проблемы, кажущиеся на первый взгляд сложными и непонятными, решаются гуглением в прямом смысле за 5 минут.
Но говорить — это легко, а на деле недостаточное знание технологий разработки и отсутствие практического опыта будут являться весьма тягостным фактором. Поэтому, правильная задача номер 1 — это изучение технологий разработки и примеров их использования в достаточно интенсивном режиме. И снова: легко сказать, а на деле обучающих материалов дофига и больше, не все они понятные, не все они релевантные, не все они покрывают проблемы, которые придется решать на проекте на практике. И вот здесь вам может помочь среда. Оказаться в команде «экспертов», которые не только обладают высоким уровнем знаний, но и готовы умело этим знанием поделиться — это лучшее, что может быть на старте карьеры. Да, все правильно, вы должны прежде всего сделать фокус на самостоятельном обучении, но так или иначе, у вас будет иметься естественный потолок скорости. Преодолеть его и помогут компетентные наставники. Однако, прежде чем к ним обратиться, задайте себе вопрос: точно ли вы застряли и не можете самостоятельно продвинуться в решении проблемы хотя бы на шаг?
Итого: ищите работу, где есть люди знающие Предмет и заинтересованные в том, чтобы и вы стали знать его лучше! Это позволит в достаточно короткие сроки существенно повысить уровень вашей экспертизы. Избегайте места, где совсем не готовы делиться знаниями. 4 года работы в таком месте будут равны двум (и меньше) в другом.
Работа в ИТ индустрии — это постоянный диалог, спор, иногда — борьба мнений, а иногда и война принципов. Поверьте мне, вы встретите немало людей, которые будут убеждать вас в том, что они и только они обладают наиболее правильным решением или мнением, подкрепляя или не подкрепляя его фактами. Порой это чувство будет распирать и вас самих!
Возможно или невозможно сделать задачу в обозначенный срок? Что лучше: технология А или технология Б для задачи В? По какой методологии стоит разрабатывать проект и организовать процесс работы? Достаточно ли хорош написанный код и уже пора остановиться его полировать или же ему все еще требуется рефакторинг? Закладывать ли возможность расширения системы с самого начала, даже если расширения не ожидается, а вы не видите со своего уровня junior developer’a всей картины? Как правильно оценивать качество изделия и какая роль в этом процессе у разработчиков? И еще десяток-другой различных подобных вопросов.