Привет! Программирование – это непростой предмет, а индустриальная разработка программного обеспечения – очень сложный. В нашей ИТ индустрии не так уж редко можно услышать вопросы от младших коллег из серии «как мне развиваться?», «что нужно делать, чтобы стать профессионалом высокого уровня и как можно быстрее?», «что делать, если развиваться не получается, а интересных проектов нет?», «что должен знать миддл?». Если у вас от 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.: Автор будет рад критике и отзывам на статью в комментариях и лс. Особенно, если вам понравилась статья и ее тематика, то напишите, о каких связанных с ней темах вы бы еще хотели почитать в следующих статьях.

Комментарии (20)


  1. kloppspb
    30.09.2018 18:38

    БольшАя (возможно, и бОльшая) часть программистов, разрабатывающих логику и backend считает задачи по программированию интерфейса пользователя недостаточно интересными.

    Это как-то за гранью логики вообще. OK, давайте ревертнём: вы считаете, что человеку, который разрабатывает UI, должны быть интересны потроха вот этой конкретной хранимки, например?

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


    1. PastorGL
      30.09.2018 22:32

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

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

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


      1. kloppspb
        30.09.2018 23:02

        Что-то всё это напоминает модное нынче «фулстэк». Когда за ноль денег хотят всего, и побольше.

        > Ты ещё обязан понимать, что чувствует твой конечный пользователь

        Мой конечный пользователь — админ, рулящий каким-нибудь Communigate, или чем-то по SNMP, или чем-то ещё в этом духе. А какие у него юзеры — вот чесслово, не моя забота.

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

        А это вообще совсем другой уровень.

        > никто не заставляет, можно всю жизнь в мидлах проходить

        Можно. Если не определишься с интересами, а останешься «компьютерщиком». Потому как:

        > Если тебе нравится всю жизнь заниматься только стрелочными переводами

        От специализации всё равно никуда не деться. И если ты, например, спец по инструментальным способам анализа разных видов трафика, и добиваешь код библиотек какого-нибудь wireshark, то при чём тут UI?

        P.S. ОС Windows, например, не видел со времён XP. Ну разве что редко в виртуалке бывает потребность её запускать. Только для проверки корректности сборки некоторых модулей с помощью gcc. Нафига мне знать что думают про UI её пользователи?


        1. MazayAl
          01.10.2018 09:50
          +2

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


        1. JekaMas
          01.10.2018 13:25
          +3

          Скорее не разница между full и не full stack, а разница между "писать код" и "решать задачу".


          1. PastorGL
            01.10.2018 15:54
            +1

            Именно что.

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

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


    1. syfim
      01.10.2018 23:57

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

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


  1. ankh1989
    01.10.2018 00:59
    +3

    Много букв. Я бы написал покороче:

    — Как сталь мидлом? Поработать 2-3 года и сменить компанию. Точно также становятся сеньором: работают ещё 3-4 года и меняют компанию.
    — Как получать много денег за ту же самую работу? Менять команды, проекты и компании при первой возможности. Каждый раз когда вы меняете компанию, вы договариваетесь о зарплате и остальных плюшках с HR. Просто работая внутри компании вы не сможете прийти к HR и сказать, что хотите в 2 раза больше денег за ту же самую работу. В идеале надо менять компанию пару раз в год и каждый раз выбивать повышение, но это будет выглядеть плохо в вашем резюме. С другой стороны если вы долго (5 лет) торчите в одной компании, это тоже выглядит плохо в врезюме.
    — Как иметь много возможностей для смены компании, команды и проекта? Заводить и поддерживать полезные знакомства. Сейчас вы два интерна и кодите мелкий проект на лето, а через 15 лет ваш друг будет вице-президентом в большой корпорации. Вам это знакомство очень пригодится. Гораздо больше чем знание стандарта C++.
    — Как проходить собеседования? У вас должно быть нужное количество лет опыта и нужное количество интересных и важных на вид проектов. Количество лет опыта придаёт вашим словам вес. Именно поэтому нужно менять проекты как можно чаще: сделали что то существенное в важном проекте, добавили строчку в резюме и поменяли проект. Когда вы будете менять компанию и иметь значение будет лишь то как выглядит со стороны ваша роль в этих проектах и сколько их было. Не тратьте время зря на бесполезные проекты: представьте как будет выглядеть в резюме эта строчка и если она выглядит не очень, то и заниматься этим не стоит.


    1. MrEsp Автор
      01.10.2018 09:01

      Букв, действительно, немало, т.к. статья ориентирована на начинающих разработчиков, поэтому, короче не получилось. :)
      По вашим комментариям 1-3: ну, я все же фокуссировался на качестве, которое называется skill (не номинальную смену должности из-за перехода). Если skill есть, то за ним как правило и подтягиваются более хорошие финансовые и карьерные условия.
      Вы же как раз пишите пример логики, который я привожу в разделе «Смена работы». Чем смена работы, особенно в первые 3 года опыта может быть плоха — я привожу пример в статье. Будете прыгать — опыта так можете и не получить нормального. Но да: ЗП поднимите, должность, возможно, тоже поднимите. Потом захотите поработать на более крутом проекте — упс, не получается.

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


      Опыт — отличная вещь, чтобы а) попасть на собеседование на интересную позицию б) при условии, что вы прошли тех. интервью, быть при прочих равных первым кандидатом на нее.
      На собеседованиях (если мы говорим про позиции jun-dev-senior) вы во многом продаете ведь не опыт, а ваше знание технологий и умение решать задачи прямо на собеседовании (например, писать код на листочке).

      Не тратьте время зря на бесполезные проекты


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


      1. AndreyGaskov
        01.10.2018 11:03

        Будете прыгать — опыта так можете и не получить нормального. Но да: ЗП поднимите, должность, возможно, тоже поднимите. Потом захотите поработать на более крутом проекте — упс, не получается.


        По моим наблюдением наоборот: самый качественный опыт получают те новички в профессии, которые первое время гонятся за деньгами, даже ценой частой смены работы. В рамках выбранной специализации, конечно. Причин, думаю, несколько:
        1. Зачастую новичкам приходится соглашаться на первую же работу, на которую их взяли, так как отсутствие хоть какой-нибудь работы — это всегда стресс. Устроившись же можно спокойно подготовиться, детальнее посмотреть на рынок труда, походить по разным компаниям, и в итоге значительно улучшить условия.
        2. Адекватные успешные компании с интересными проектами обычно не жмутся на зарплату даже новичкам. В компании, где больше платят, junior наверняка получит более ценный опыт. Зачем ждать 3 года, чтобы туда перейти?
        3. Работодатель не ценит тех, кто достался ему очень дёшево. Будут нагружать всякой ерундой, которую другие программисты делать отказываются. Если же зарплата адекватно высокая, работодатель будет всячески прокачивать новичка.

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


  1. polarnik
    01.10.2018 03:15

    Вопрос про вопрос «что должен знать мидл?». Один из комментариев раскрывает один из способов повышения — смена проекта или компании. А если говорить про вариант работы на том же проекте, то такой вопрос задаёт себе каждый лид.

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

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

    Как лучше такую систему сделать?


    1. MrEsp Автор
      01.10.2018 09:17

      Как лучше такую систему сделать?


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

      На самом деле, ваш вопрос, пожалуй, самый сложный во всем этом процессе, связанном с формальным ростом внутри компании. Лично я не очень верю в систему баллов, ее сложно обосновать и сложно гранулировать (например, если у вас 100 баллов — вы получаете повышение, а если 98 — не получаете. ну бред же!). Но с другой стороны, сотрудники, которые проходят курсы и получают сертификаты как правило, знают в среднем больше и обладают большой мотивацией, которая и должна быть вознаграждена в итоге.
      Вообще, общий подход, принятый во многих больших компаний — это постановка целей. Цели не только получают ранг, степень выполнения, но и степень влияния на команду, отдел и бизнес целиком. Например, если вы сделали очень простую систему, в которой может не быть ничего выдающегося с технической точки зрения, то она может экономить компании значительные деньги. Если же вы сделали систему, которая сложна и неповторима (в значении «сложно сделать») — это отличный пример, который показывает, что произошел рост в квалификации на качественном уровне, заслуживающий поощрения.
      Но, понятно, что когда мы масштабируем эту систему оценки на всю компанию, то в ней встречаются сложные и неоднозначные кейсы, связанные с тем, что разные менеджеры по своему трактуют важность и степень достижений, с тем, наконец, что в компании существуют лимиты на повышения. Например, если есть 10 человек, которые получили отличные и одинаковые оценки на performance review, то для них нет гарантии, что они получат одинаковое вознаграждение. В целом, этот процесс имеет много изъянов и вещей, связанных со случайностью. Случайность работает в обе стороны: вам повезет и вы выполните какую-то важную цель из-за благоприятного стечения обстоятельств, либо наоборот.


      1. polarnik
        02.10.2018 00:15

        в компании существуют лимиты на повышения

        Такое видел. Лимиты заранее не известны даже руководителям. И может случиться так, что завершилась оценка, отправлено обоснование повышений команды руководителю, он согласует, уже оглашает команде даты и суммы. А потом выясняется, что о-па и упс, лимиты есть.
        Бюджет надо заранее выяснять, просчитывать.

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

        Спасибо за акцент на степени влияния на команду и бизнес. Думаю стоит оценить этот фактор, не выделял его явно


      1. polarnik
        02.10.2018 00:27

        Какой подход порекомендуете при выборе целей?

        Пример подхода — если есть на входе список из 7-ми целей, выбираю три наиболее интересные и важные основываясь на интуиции. Цели соответствуют SMART и их три.

        На что обратить внимание при формировании и выборе целей?


        1. MrEsp Автор
          02.10.2018 08:54

          Я видел самые разные примеры целей в разных компаниях. От «сделать такую-то техническую задачу Х» до «стать экспертом в системном администрировании». Цели первого вида ставить легко. Если есть какой-то проект, то его имплементация, та часть, которая возложена на вас, — это и есть цель. Иногда пытаются ставить вероятностную цель: пытаются угадать, на какой процент изменится поведение системы или пользователей. Заранее какой процент получится предугадать сложно, поэтому здесь риск недостижения может быть сколь угодно велик, в общем, на свой страх и риск :) Цели второго типа — они слишком общи и сложно измеримы. Тем не менее, есть компании, которые все равно требуют такие цели ставить потому, что у сотрудника должен быть вектор развития, который такими целями и управляется.


  1. nick_gabpe
    01.10.2018 11:05

    Для меня как для Juniora главной проблемой пять лет назад было попасть на собеседование.
    Многие компании просматривают отклики на hh, но не дают никакоц обратной связи. В итоге со второго интервью меня взяли, а дальше было просто :)
    Самое забавное когда компании проигнорировавшие тебя пять лет назад сейчас зовут на интервью.


  1. stanislavkulikov
    01.10.2018 15:36
    +1

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


    1. MrEsp Автор
      01.10.2018 22:51

      то вы узнаете только те технологии, которыми эта компания пользуется.


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


  1. RomanPokrovskij
    01.10.2018 16:56
    +1

    как стать мидлом? заявится и устроится сеньером и поработать с полгода.


  1. artemcarabash
    01.10.2018 21:44

    Автору спасибо за статью, узнал себя в ней. К сроку подходит мой третий год, и как раз встаёт вопрос о смене места. И к счатью (или несчатью) участились входящие сообщения на том же SO и LinkedIn. Грань пока не ясна, а надо ли менять или поднатаскаться ещё пока есть возможность.