Хабрахабр

О чем молчат Лиды: начало карьеры разработчика. принципы. или как стать 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. Об интерфейсах

Это де факто считается непрестижным (хотя, если взять Web последних времен, то в этом принципе были и положительные изменения). БольшАя (возможно, и бОльшая) часть программистов, разрабатывающих логику и backend считает задачи по программированию интерфейса пользователя недостаточно интересными. Что там, формочки клепать? Якобы для этого и программировать-то уметь не надо. Так или иначе, в этом есть определенное рациональное зерно. Раз, раз и готово. Но интерфейс — это лицо приложения. Разработка библиотек алгоритмов и разработка интерфейсов, конечно — это разные виды деятельности. У меня для вас еще более интересные новости: этим не только не хотят заниматься, но и мало кто действительно хорошо умеет, на самом деле. Не имея этого Лица в достаточно хорошем качестве, счастье пользователя будет получить непросто. Достаточное количество людей умеют в той или иной степени кодировать интерфейсы по макетам, не так много занимаются этим на постоянной профессиональной основе. Потому что непосредственно программированием проблема не ограничивается. Уже совсем мало людей умеют спроектировать качественный интерфейс с нуля и сценарии его использования. Гораздо меньше людей могут объяснить, почему интерфейс или сценарий использования А им кажется более удачным, чем сценарий Б. Таким образом, хорошие новости: если вы обнаружили у себя способности понимать, какой интерфейс лучше, а то и предлагать удачные UX/UI решения — вы можете стать очень конкурентным специалистом, откроете для себя новую интересную область задач, хотя, в определенном случае, вам придется отойти немного от непосредственно самого программирования.

10. О смене места работы

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

Канонический пример устроен так: джуну приходит оффер с ЗП в 1. Первая причина, связанная с деньгами, весьма распространена. Такой коэффициент, понятное дело, на старте карьеры возможен, и он кажется просто огромным повышением, тяжело будет устоять перед таким предложением. 5-2 раза выше. Люди переходят на новое место работы, которое они тоже через 1-2 года с высокой вероятностью покинут, скорее всего уже и не из-за финансовых вопросов. Именно здесь может скрываться основная ошибка. Почему именно на старте карьеры это может быть не самым лучшим решением вполне понятно: человек не научившись хорошо делать задачи А переключается на то, чтобы делать задачи B. Итого — у вас уже 4 года опыта, а много ли вы сделали законченных проектов или хотя бы крупных релизов? Переключение, как хорошо известно из программирования, содержит накладные расходы. Будь то другой проект, другая предметная область или технология. Пожалуй, основной позитив, который здесь может вас ждать — это возможность участия в более крутом проекте с более крутой командой, попав в которую, ваш профессиональный рост будет идти гораздо быстрее. Однако, не всегда такое переключение негативно. Вы должны ощущать, что переходите с заметным отрывом, тогда, скорее всего, не ошибетесь.

Снова повторимся: интенсивное изучение технологий и повышение skills в первые 3 года опыта — это задача номер 1. Итого: перед тем как сменить работу в первые 1-3 года, подумайте над реальными причинами, которые вас побуждают это сделать. Финансовый рост — номер 3. Завершенные задачи и проекты, качественно — задача номер 2. Если вы ставите финансы первым номером, то, возможно, в будущем с удивлением для себя обнаружите, что за 4 года в индустрии вы научились только решать задачи из строго ограниченного круга на вашем проекте и не знаете и половину того, что вам может потребоваться при устройстве в другую компанию, где бы вы хотели работать.

Заключение

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

S. P. Особенно, если вам понравилась статья и ее тематика, то напишите, о каких связанных с ней темах вы бы еще хотели почитать в следующих статьях. Автор будет рад критике и отзывам на статью в комментариях и лс.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть