О чем молчат Лиды: начало карьеры разработчика. принципы. или как стать Middl’ом
Привет! Программирование — это непростой предмет, а индустриальная разработка программного обеспечения — очень сложный. В нашей ИТ индустрии не так уж редко можно услышать вопросы от младших коллег из серии «как мне развиваться?», «что нужно делать, чтобы стать профессионалом высокого уровня и как можно быстрее?», «что делать, если развиваться не получается, а интересных проектов нет?», «что должен знать миддл?». Если у вас от 0 до 3-х лет опыта в ИТ, вы начинающий специалист (или только собираетесь им стать) и ставите перед собой подобные цели профессионального и карьерного роста, ищете правильные пути, как этих целей достичь — этот пост для вас, добро пожаловаться под кат. Возможно, он также будет интересен тимлидам и менеджерам, в общем, всем, кто занимается обучением и развитием специалистов.
Для начала, позвольте представиться. Меня зовут Анатолий и если опустить должности и ранги, то прежде всего я Разработчик, потому что в широком смысле слова всю свою карьеру занимался разработкой, исследованиями и управлением разработчиками. Мой опыт в индустрии 10+ лет. Он достаточно разнообразен и простирается от финансовых систем и веб сайтов, до продуктов, алгоритмов и систем машинного обучения. Основное, однако, как мне кажется, состоит в том, что я сам был на месте целевых читателей этой статьи и впоследствии начал заниматься в разных аспектах развитием молодых программистов. На текущий момент через меня прошло уже в общей сложности более 2-х десятков junior developers и стажеров. Поэтому, считаю, что мне есть о чем рассказывать. Большое количество материалов по обсуждаемому вопросу, которые можно встретить, посвящены либо чисто техническим темам, либо, к примеру, почти слепому следованию Scrum«у. (типа — «если не знаешь что делать, попробуй работать по scrum’у и все будет зашибись» :)) Как бы не казалось из реалий и статистик отдельных команд и специалистов, это далеко не все вещи, составляющие практику и культуру разработки ПО. Поэтому, думая о чем писать, я решил, что не буду повторять эти сведения, а лучше постараюсь сфокуссироваться на темах, про которые не так много пишут или говорят. Поехали!
Да, в качестве дисклеймера, хотелось бы сказать, что описанное есть мое личное мнение, подтвержденное опытом и теоретическими знаниями, которые на этом опыте были проверены. Оно может не соответствовать той реальности, в которой вы окажетесь, поэтому позвольте дать вам сразу первый совет статьи: прежде всего, в любых сложных ситуациях стоит проанализировать её конструкцию, до того, как применять какие-то известные вам практики и паттерны вида «если, то». Детали очень важны. Вот теперь — поехали! :)
1. Широкая vs Узкая специализация
Часто люди, которые только хотят научиться программировать задаются вопросом, какую технологию выбрать для изучения, да и вообще, на каком ЯП, грубо говоря, «лучше писать код». Люди, которые устраиваются на свою первую работу думают о том, будет ли их текущая технология перспективна и востребована через пару-тройку лет и далее. (некоторые — совсем не думают, но это чаще всего не есть хорошо) »Лучше» и »перспективнее» здесь — это весьма субъективные понятия, определяемые на уровне ощущений и возможной пользы для дальнейшей карьеры. Достаточно быстро новичкам в ИТ может стать ясно, что многие проекты делаются на достаточно большом количестве технологий, а всего знать-то и невозможно. Так нужно ли гнаться за всеми зайцами?
К примеру, на первом году работы я получил ценное замечание от своего тимлида о том, что необходимо сфокусироваться на какой-то одной области, потому что специалист либо в чем-то специалист, либо, грубо говоря, не специалист ни в чем. Чтобы знать что-то на достаточно высоком уровне, необходимо заниматься этим постоянно и глубоко вникать в детали — чистая правда и трудно с этим поспорить. И действительно, практика это подтверждает: большинство известных мне специалистов (кто может таковыми считаться) — это узкие специалисты. Некоторые из них просто блестяще знают свой Предмет и поэтому решают в рамках него задачи небывалой крутизны. На этом месте можно было бы сказать «ОК, значит, принцип верен — все сходится», если бы не несколько НО. Дело в том, что спектр проектов, где будут востребованы такие узкие специалисты существенно уже, чем, понятно, у специалистов более широкого профиля. Не раз мне встречались проекты, участие в которых было бы просто невозможным без наличия широких познаний в нескольких технологиях сразу. Люди, которые этими знаниями обладали, открывали для себя новые, порой недоступные двери. А участие в отличном, уникальном проекте — это очень серьезное и полезное карьерное испытание, способное принести вам много ценного опыта и прочих бенефитов. Второе НО состоит в том, что мир технологий постоянно меняется и строго ограничив себя знанием одной-двух технологий или ЯП, можно естественным образом начать терять конкурентное преимущество и стать менее востребованным специалистом.
Итого, коротко можно сказать так: не бойтесь пробовать технологии, которые вам нравятся! Возможно, вы не станете экспертом в 3-х языках программирования сразу, или в 5-ти фрейморках, но знание их основ и внутреннего устройства — это серьезное конкурентное преимущество, если при прочих равных вы попадете на вакансию, где требуется сильное знание 1 технологии и базовое нескольких других. Главное здесь — мера и ограничение. Важно четко определить приоритеты, на изучение какой технологии вы тратите основное время, на изучение каких — оставшееся.
2. Функциональная область
От специализации в языках программирования и технологиях разработки мы плавно переходим к следующей важной вещи — функциональной области. Привести пример легко из жизни: как у врачей есть стоматологи, а есть кардиологи, так и среди разработчиков бывает специализация, и речь здесь вовсе не только о вышеупомянутых технологиях или языках программирования. Разработчики специализируются на разном: кто-то занимается интерфейсами пользователя, кто-то процессит данные на кластерах, кто-то распознает изображения, а кто-то пишет логику для игрового бота. Примеров уйма.
Возможно, в первые 2 года работы или даже больше вас и не будет беспокоить вопрос специализации, поскольку вход в проекты и технологии, на которые вы попадете, будет занимать существенное время, и этот вопрос просто не будет актуальным естественным образом. Однако, начиная с определенного момента, вы почувствуете легкость в решении все более и более сложных задач в какой-то области, и результат будет определяться во многом уже не степенью того, как детально, к примеру, вы знаете стандартную библиотеку того ЯП, с которыми вы работаете, или как виртуозно вы владеете продвинутым синтаксисом этого ЯП, а вашим опытом в конкретной функциональной области. Компьютерная графика, компьютерная лингвистика, финансовое программирование — все это конкретные области, на изучение и обретение практического опыта в которых уходят месяцы и годы. Если вы ставите перед собой цель стать спецом высокого уровня, найдите ту область, которая вам по-настоящему нравится. И если она вам действительно нравится — развивайтесь и работайте в ней с удовольствием, и все получится!
3. Наставники и самостоятельное обучение
Не существует двух полностью одинаковых проектов. Не существует одинаковых команд. Порой и не существует единственно правильного решения, будь то глобальное решение об архитектуре большой части системы или локальное решение о способе хранения файлов в репозитории. Перед начинающим специалистов встает много вопросов и сомнений. Вопросов, на которые в силу отсутствия опыта может так сразу и не найтись ответа. Вы получили готовый код и он совсем не работает, хотя у других коллег все нормально; процедура установки сервиса в 1 случае из 6 завершается с ошибкой — и хоть убейся, но непонятно, почему; вы не можете настроить сетевую часть сервиса, хотя делаете все по инструкции и перечитали ее уже 7 раз. Такие ситуации у разработчиков, тестировщиков и админов возникают постоянно. Степень сложности проблем может варьироваться от уровня «наверное, нужно копать куда-то туда» до «куда копать — совсем не понятно». Первый совет, который хорошо знают и дают опытные специалисты (и, наверняка, вы его уже от них слышали) состоит в том, что вам необходимо научиться как можно более самостоятельно разбираться в проблемах, когда вы в них вязните. Как правило для этого необходимо концентрироваться на причинно-следственной связи и научиться формулировать правильные вопросы о проблеме. В первую очередь — к самому себе, во-вторую очередь — к Гуглу. Оно ведь не просто так «все не работает», даже если вы в этом уверены, попробуйте вернуться «к началу», чтобы найти реальную причину проблемы. И, скорее всего, вы не один такой с подобной проблемой, просто погуглите и убедитесь в этом. Далее, следующий простой совет: только после того, как вы сделали несколько неудачных попыток и провели анализ проблемы самостоятельно, потратив существенное время (как правило, измеряется в часах, иногда — в днях) — обратитесь к старшим коллегам. Так вы не потратите их ценное время на решение ерундового вопроса, который бы вы и сами легко могли решить, применив большую усидчивость. Тем самым вы продемонстрируете, что у вас выработался правильный подход к решению проблем. Многие проблемы, кажущиеся на первый взгляд сложными и непонятными, решаются гуглением в прямом смысле за 5 минут.
Но говорить — это легко, а на деле недостаточное знание технологий разработки и отсутствие практического опыта будут являться весьма тягостным фактором. Поэтому, правильная задача номер 1 — это изучение технологий разработки и примеров их использования в достаточно интенсивном режиме. И снова: легко сказать, а на деле обучающих материалов дофига и больше, не все они понятные, не все они релевантные, не все они покрывают проблемы, которые придется решать на проекте на практике. И вот здесь вам может помочь среда. Оказаться в команде «экспертов», которые не только обладают высоким уровнем знаний, но и готовы умело этим знанием поделиться — это лучшее, что может быть на старте карьеры. Да, все правильно, вы должны прежде всего сделать фокус на самостоятельном обучении, но так или иначе, у вас будет иметься естественный потолок скорости. Преодолеть его и помогут компетентные наставники. Однако, прежде чем к ним обратиться, задайте себе вопрос: точно ли вы застряли и не можете самостоятельно продвинуться в решении проблемы хотя бы на шаг?
Итого: ищите работу, где есть люди знающие Предмет и заинтересованные в том, чтобы и вы стали знать его лучше! Это позволит в достаточно короткие сроки существенно повысить уровень вашей экспертизы. Избегайте места, где совсем не готовы делиться знаниями. 4 года работы в таком месте будут равны двум (и меньше) в другом.
4. Нет серебрянной пули
Работа в ИТ индустрии — это постоянный диалог, спор, иногда — борьба мнений, а иногда и война принципов. Поверьте мне, вы встретите немало людей, которые будут убеждать вас в том, что они и только они обладают наиболее правильным решением или мнением, подкрепляя или не подкрепляя его фактами. Порой это чувство будет распирать и вас самих!
Возможно или невозможно сделать задачу в обозначенный срок? Что лучше: технология А или технология Б для задачи В? По какой методологии стоит разрабатывать проект и организовать процесс работы? Достаточно ли хорош написанный код и уже пора остановиться его полировать или же ему все еще требуется рефакторинг? Закладывать ли возможность расширения системы с самого начала, даже если расширения не ожидается, а вы не видите со своего уровня junior developer«a всей картины? Как правильно оценивать качество изделия и какая роль в этом процессе у разработчиков? И еще десяток-другой различных подобных вопросов.
Под частую, на эти и многие другие вопросы невозможно дать однозначного решения в конкретной ситуации. Хотелось бы его иметь, но иногда его просто не видно объективно, потому что уровень неопределенности на проекте может быть достаточно высок. Это в каком-то смысле идет в разрез одной негласной культуре, широко принятой в программировании: постоянный поиск и предложение лучших решений с помощью более совершенных технологий. Мы постоянно инстинктивно заставляем себя принимать решения на основе неполных данных.
И вот здесь программирование в своем микромире и разработка ИТ проектов уже в больших масштабах перестают быть сколько угодно точными дисциплинами и начинают быть искусством. Искусство строится на принципах и подходах, оно определяется ими.
Завершая очередной проект или более менее массивную задачу оглянитесь назад и проведите анализ: какие принципы помогли этой задаче или этому проекту прийти к успеху (или наоборот — зафейлиться)? Было ли здесь дело в том, какой язык программирования был выбран и в том, как он чудесно подошел, или, может быть, уровень взаимодействия с вашим заказчиком или партнером был настолько хорош, что вы могли заниматься самой задачей большую часть времени, не тратя время на издержки коммуникаций? Постоянно анализируйте, ищите новые принципы и советуйтесь с наставниками, как эти принципы разглядеть и определить.
5. О больших и маленьких компаниях, об ИТ и не ИТ
Многие молодые специалисты хотят работать в компаниях, про которые они слышали, продуктами или изделиями которых они пользовались. В каких-нибудь Эпплах, Гуглах или Майкрософтах (недавно появился неплохой термин — «Гуяндбук») или их русских аналогах (уж на сколько это возможно). Начинать карьеру в большой компании — это очень, очень ценный опыт. (Особенно это понимаешь на 11-ый год этого самого опыта :)) Увидеть, как работает большая компания изнутри, и как в ней организованы процессы — поверьте, это того стоит. Наверное, мне сложно представить что-то лучшее, чем набор из крупной ИТ компании и толкового коллектива на старте карьеры. Однако, всегда есть свои НО.
Первое НО состоит в том, что «крупная ИТ компания» достаточно сильно отличается от просто «крупной компании» (особенно, в российских реалиях). Если у вас есть выбор, пойти в маленькую или среднюю ИТ компанию или пойти в крупную не ИТ компанию (например банк или еще какую-нибудь финансовую или торговую компанию), вы должны понимать возможные последствия. А последствия в наихудшем случае будут следующими: если ИТ компания закроется или вы захотите из нее уйти — вы уходите со знаниями и принципами. Если же вы захотите уйти не из ИТ компании в ИТ компанию, то по ряду причин это будет сделать сложнее. Это может быть и отсутствие нужного и релевантного опыта, и специфичность проектов и придирчивость рекрутеров и нанимающих коллег к вашим прошлым местам работы (вспомните фирму Pearson Hardman из известного сериала, которая нанимала только из Гарварда. Такие истории нередки и в реальности. Типа «нанимаем только из продуктовых компаний», итд). В компаниях, где ИТ не является основным видом бизнеса, все в прямом смысле крутится вокруг этого бизнеса. Результат очень важен, процесс его достижения — гораздо менее важен. Но именно правильный процесс закладывает правильные принципы, которые затем помогут вам принимать решения и производить что-то очень качественное и сложное на выходе в достаточно непростых проектах. Если производить что-то качественное и полезное — это и есть ваша цель, учитывайте это.
6. Продуктовые и аутсорсинговые компании
Одна из моих самых любимых тем, поскольку я работал и в первых, и во-вторых. Продолжая тему придирчивости, в индустрии существует определенное мнение, что работать в продуктовых ИТ компаниях не только более престижно, но и денежно, а к этому еще и прилагается набор самых интересных проектов, которые только можно сыскать. Работа же в аутсорсе на проектах под заказ, по мнению некоторых специалистов — это классом ниже. Правда это или нет?
Отвечу: Нет. Не все так просто.
Основной плюс продуктовых компаний состоит в том, что человек, приходя туда, фактически имеет возможность выбирать проект/продукт или сферу деятельности, со всеми вытекающими из этого следствиями (например, возможность работать над воистину уникальными и сложными задачами). Одно из главных следствий: вы будете разрабатывать ВАШ продукт, делая его лучше, каждый день. Не всегда это будет идти просто и так, как вам хочется, но это Ваш продукт. Вы во многом влияете на его успех, по крайней мере на своем уровне.
В аутсорсинговых же компаниях сотрудник как правило не имеет такого выбора, и более того, периодически вынужден сидеть из-за этого в определенном смысле на иголках. Интеграторы и аутсорсеры занимаются теми проектами, за которые платят деньги здесь и сейчас. Не все такие проекты будут интересны определенному классу программистов. Для сотрудника аутсорсинговой компании всегда есть риск оказаться на абсолютно не интересном и стагнирующем проекте, при этом, подчастую, единственным способом сменить проект будет увольнение из компании.
Основной же минус продуктовых компаний — это большие объемы legacy кода и меньший фокус на процессах разработки (с большим фокусом на прямоту рук и извилины), при более высоких технических рисках. Второй неслабый минус — неуспех одного проекта может поставить крест на всей компании. Ознакомьтесь со статистикой закрытых стартапов за последние 5 лет и убедитесь в этом. Это далеко не все плюсы и минусы, но остальное, боюсь, лежит далеко за рамками этой статьй.
7. Качество vs количество
Вернемся к непростому предмету программирования. Крайне важно на начальном этапе карьеры уяснить важный принцип: корректность кода всегда должна быть превыше всего. С другой стороны, любое программное обеспечение создается с ошибками. То, на сколько принципиальными они оказались, вполне может повлиять на дальнейшую судьбу проекта или продукта. Так или иначе, коммерческое программирование — это бизнес и без прибыли он не может существовать. Вам обязательно и не раз встретятся ситуации, когда качеством кода (а иногда и самого функционала) жертвуют, чтобы быстрее выпустить релиз. Иногда, это значительно демотивирует команду, особенно, если мотивы таких решений не объясняются. Возможно, это будет во многом демотивировать и вас. Мне известны проекты, на которых сроки постоянно горели, а релизы постоянно выкатывались с потерей во внутреннем (код) или внешнем (функционал) качестве. На них люди работали по выходным от недель до нескольких месяцев. Что происходило дальше? В худшем случае для компании — убытки. В худшем случае для сотрудников — потеря здоровья. Поэтому, оказавшись в ситуации, где постоянно жертвуют качеством стоит оценивать 2 вещи: а) длительность этого б) последствия (, а они могут быть положительными и отрицательными). С другой стороны бывают и другие примеры: быстрый релиз системы мог быть не очень качественным, но был очень своевременным. Система была далеко не идеальной, но основной базовый функционал в ней добротно работал. В итоге, ее недостатки были исправлены в течение следующих двух релизов, а пользователи системы были в таком восторге, что в проект были вложены вдвое больше ресурсы, работали над ним уже без перегораний и был сделан очень богатый и крутой функционал, который принес бизнесу большую пользу. С точки зрения конечной цели — это успех.
Итого: иногда стоит пожертвовать каким-то показателем (показателем качества или каким-то другим) сейчас, чтобы открыть какие-то возможности для проекта в будущем. Если вы постоянно чем-то жертвуете и не видите, что получаете с этого хорошие результаты глобально (а в слабом смысле — локально, субъектвно для вас) — стоит подумать о смене проекта.
8. Программы делаются для людей
Программные системы бывают очень сложными. Их сложность иногда сравнивают со сложностью современного самолета, говоря что в оном и того меньше элементов, чем в какой-нибудь популярной операционной системе. Над любым более-менее крупным проектом может работать команда в десятки, а то и сотни человек. Каждый из них делает свой кусок этого софта, порой и не имея понятия о внутреннем устройстве остальных его частей, а возможно и о том, как пользователь будет ими пользоваться. Это реалии. Всего знать невозможно. Во все уголки системы заглянуть бывает просто физически невозможно, уж на столько их много. Иногда это приводит к чрезмерному фокусу на низкоуровневых технических задачах и уходу в такие дебри, где совсем забывается изначальная цель. А изначальная цель софта — помогать пользователю решать его задачи. Об этом важно помнить всегда.
Ориентация на пользователя — важнейшее качество программиста, тестировщика, менеджера, всех, кто создает программы. Если вы не будете уделять достаточного внимания этому вопросу, то функционал вашего софта будет содержать много видимых пользователю изъянов, создающих неудобство при использовании, так, что ваш пользователь не будет до конца счастлив (если не разочарован), а в последствии и вы сами: видеть результат своей работы и пользу, которую она приносит — это, на самом деле, одна из главных мотивационных составляющих работы в ИТ.
Будет ли несчастливый пользователь пользоваться вашим продуктом или удалит его в первый же день установки? Будет ли он хвалить вас за то, что вы ему внедрили или пожалуется вашему менеджеру на качество? Это зависит во многом именно от вас.
О чем это все, спросите вы? Сформулирую просто: будьте пользователем своего же продукта, ставьте себя на его место пользователя, начните думать как он, и, возможно, вы найдете способ, как сделать продукт лучше, уже как разработчик.
9. Об интерфейсах
БольшАя (возможно, и бОльшая) часть программистов, разрабатывающих логику и backend считает задачи по программированию интерфейса пользователя недостаточно интересными. Это де факто считается непрестижным (хотя, если взять Web последних времен, то в этом принципе были и положительные изменения). Якобы для этого и программировать-то уметь не надо. Что там, формочки клепать? Раз, раз и готово. Так или иначе, в этом есть определенное рациональное зерно. Разработка библиотек алгоритмов и разработка интерфейсов, конечно — это разные виды деятельности. Но интерфейс — это лицо приложения. Не имея этого Лица в достаточно хорошем качестве, счастье пользователя будет получить непросто. У меня для вас еще более интересные новости: этим не только не хотят заниматься, но и мало кто действительно хорошо умеет, на самом деле. Потому что непосредственно программированием проблема не ограничивается. Достаточное количество людей умеют в той или иной степени кодировать интерфейсы по макетам, не так много занимаются этим на постоянной профессиональной основе. Гораздо меньше людей могут объяснить, почему интерфейс или сценарий использования А им кажется более удачным, чем сценарий Б. Уже совсем мало людей умеют спроектировать качественный интерфейс с нуля и сценарии его использования. Таким образом, хорошие новости: если вы обнаружили у себя способности понимать, какой интерфейс лучше, а то и предлагать удачные UX/UI решения — вы можете стать очень конкурентным специалистом, откроете для себя новую интересную область задач, хотя, в определенном случае, вам придется отойти немного от непосредственно самого программирования.
10. О смене места работы
Известная и неумолимая статистика: огромное количество людей покидает свое первое место работы уже на второй или третий год. И вы также будете в их числе с высокой вероятностью. Происходит это по-разным причинам: от маленькой зарплаты, до отсутствия интересных задач и других вещей.
Первая причина, связанная с деньгами, весьма распространена. Канонический пример устроен так: джуну приходит оффер с ЗП в 1.5–2 раза выше. Такой коэффициент, понятное дело, на старте карьеры возможен, и он кажется просто огромным повышением, тяжело будет устоять перед таким предложением. Именно здесь может скрываться основная ошибка. Люди переходят на новое место работы, которое они тоже через 1–2 года с высокой вероятностью покинут, скорее всего уже и не из-за финансовых вопросов. Итого — у вас уже 4 года опыта, а много ли вы сделали законченных проектов или хотя бы крупных релизов? Почему именно на старте карьеры это может быть не самым лучшим решением вполне понятно: человек не научившись хорошо делать задачи А переключается на то, чтобы делать задачи B. Будь то другой проект, другая предметная область или технология. Переключение, как хорошо известно из программирования, содержит накладные расходы. Однако, не всегда такое переключение негативно. Пожалуй, основной позитив, который здесь может вас ждать — это возможность участия в более крутом проекте с более крутой командой, попав в которую, ваш профессиональный рост будет идти гораздо быстрее. Вы должны ощущать, что переходите с заметным отрывом, тогда, скорее всего, не ошибетесь.
Итого: перед тем как сменить работу в первые 1–3 года, подумайте над реальными причинами, которые вас побуждают это сделать. Снова повторимся: интенсивное изучение технологий и повышение skills в первые 3 года опыта — это задача номер 1. Завершенные задачи и проекты, качественно — задача номер 2. Финансовый рост — номер 3. Если вы ставите финансы первым номером, то, возможно, в будущем с удивлением для себя обнаружите, что за 4 года в индустрии вы научились только решать задачи из строго ограниченного круга на вашем проекте и не знаете и половину того, что вам может потребоваться при устройстве в другую компанию, где бы вы хотели работать.
Заключение
Начало карьеры — это то время, когда стоит работать над своими техническими скиллами и научиться темпу работы, который достаточен для проектной работы в реальных условиях. Это время, когда необходимо развивать самодисциплину. За него можно понять для себя, чем Вам больше всего нравится заниматься, а чем — совсем не нравится. За него также можно совершить большое количество ошибок и немалое количество побед. И первое и второе, при правильном разборе полетов и произведении правильных выводов на данном этапе карьеры является Победой, важно выработать именно такое отношение и не сдаваться! В конце концов, к четвертому году опыта вы подойдете при лучшем исходе: а) с хорошим набором hard skills б) c реальным проектным опытом в) с пониманием многих проблем и решений. Это отличное подспорье, чтобы развиваться дальше!
P.S. Автор будет рад критике и отзывам на статью в комментариях и лс. Особенно, если вам понравилась статья и ее тематика, то напишите, о каких связанных с ней темах вы бы еще хотели почитать в следующих статьях.
