О Чем Молчат Лиды: Начало Карьеры Разработчика. Принципы Или Как Стать Мидлом

Привет! Программирование - это сложная тема, но разработка промышленного программного обеспечения - очень сложно.

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

делать, если не могу развиваться, а интересных проектов нетЭ», «что должен знать мидлЭ».

Если у вас опыт работы в ИТ от 0 до 3 лет, вы начинающий специалист (или только планируете им стать) и ставите схожие цели профессионального и карьерного роста, ищете верные пути достижения этих целей - этот пост это для вас, хорошо жаловаться под кат. Возможно, это также будет интересно тимлидам и менеджерам, в целом всем, кто занимается обучением и развитием специалистов.

Для начала позвольте мне представиться.

Меня зовут Анатолий, и если опустить должности и звания, то в первую очередь я Разработчик, потому что в широком смысле слова я всю свою карьеру занимался разработкой, исследованием и управлением разработчиками.

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

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

На данный момент через меня прошло в общей сложности более 2 десятков младших разработчиков и стажеров.

Поэтому я думаю, что мне есть о чем поговорить.

Большое количество материалов по обсуждаемому вопросу, которые можно найти, посвящено либо чисто техническим темам, либо, например, практически слепому следованию Scrum. (типа «если не знаешь, что делать, попробуй работать по Scrum и все будет хорошо» :) ) Как бы это ни казалось из реалий и статистики отдельных команд и специалистов, это не все дела которые составляют практику и культуру разработки программного обеспечения.

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

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

типа «если, То».

Детали очень важны.

А теперь — поехали! :)

1. Широкая и узкая специализация

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

(некоторые вообще не думают, но чаще всего это нехорошо)» Лучше " И " более перспективный «Здесь очень субъективные понятия, определяемые на уровне ощущений и возможных выгод для будущей карьеры.

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

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

И действительно, практика это подтверждает: большинство знакомых мне специалистов (кого можно считать таковыми) - узкие специалисты.

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

В этот момент можно было бы сказать «ОК, значит принцип правильный — всё подходит», если бы не несколько НО.

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

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

Люди, владевшие этими знаниями, открывали перед собой новые, порой недоступные двери.

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

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

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

Главное здесь – умеренность и ограничение.

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

2. Функциональная область

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

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

Есть много примеров.

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

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

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

Если ваша цель — стать специалистом высокого уровня, найдите область, которая вам действительно нравится.

А если оно вам действительно нравится, развивайтесь и работайте в нем с удовольствием, и все получится!

3. Наставники и самообучение

Начинающий специалист сталкивается с множеством вопросов и сомнений.

Вопросы, на которые из-за отсутствия опыта невозможно сразу ответить.

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

Разработчики, тестировщики и администраторы постоянно сталкиваются с такими ситуациями.

Степень сложности проблем может варьироваться от уровня «наверное надо где-то копать» до «куда копать вообще не понятно».

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

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

В первую очередь – себе, во вторую – Гуглу.

Дело не просто в том, что «все не работает», даже если вы в этом уверены, попробуйте вернуться «в начало», чтобы найти настоящую причину проблемы.

И, скорее всего, вы не единственный, у кого подобная проблема, просто погуглите и убедитесь сами.

Далее следующий простой совет: только после того, как вы предприняли несколько неудачных попыток и самостоятельно проанализировали проблему, потратив значительное время (обычно измеряемое часами, иногда днями) – обращайтесь к старшим коллегам.

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

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

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

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

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

проект. И вот здесь вам может помочь Среда .

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

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

Компетентные люди помогут вам это преодолеть.

наставники .

Однако прежде чем обратиться к ним, задайте себе вопрос: действительно ли вы застряли и не можете сделать ни шагу к решению проблемы самостоятельно? В общем: ищите работу, где есть люди, знающие предмет и заинтересованные в том, чтобы вы знали его лучше! Это позволит вам существенно повысить уровень своей экспертности за достаточно короткое время.

Избегайте мест, где вы совершенно не готовы делиться знаниями.

4 года работы в таком месте будут равны двум (или меньше) в другом.

4. Серебряной пули не существует

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

Иногда это чувство вспыхнет и внутри вас! Возможно или невозможно выполнить задачу в указанные сроки? Что лучше: технология А или технология Б для задачи С? Какую методологию следует использовать для разработки проекта и организации рабочего процесса? Достаточно ли хорошо написан код и пора прекратить его полировку или он все еще нуждается в рефакторинге? Стоит ли включать возможность расширения системы с самого начала, даже если расширение не предвидится, и вы не видите всей картины со своего уровня джуниор-разработчика? Как правильно оценить качество продукта и какая роль в этом процессе у разработчиков? И еще десяток-другой разных подобных вопросов.

На эти и многие другие вопросы зачастую невозможно дать однозначный ответ в конкретной ситуации.

Хотелось бы, чтобы это было, но иногда это просто не видно объективно, потому что уровень неопределенности по проекту может быть достаточно высоким.

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

Мы постоянно инстинктивно заставляем себя принимать решения на основе неполных данных.

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

Искусство строится на принципах и подходах, ими определяется.

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

5. О больших и малых компаниях, об ИТ и не-ИТ

В некоторых яблоках Google или Microsoft (недавно появился хороший термин — «Guyandbook») или их российские аналоги (насколько это возможно).

Начало карьеры в крупной компании – это очень и очень ценный опыт. (Особенно это понимаешь на 11 году этого самого опыта :)) Увидеть, как работает крупная компания изнутри, и как в ней организованы процессы – поверьте, это того стоит. Мне, наверное, сложно представить что-то лучше, чем подбор персонала из крупной IT-компании и толковой команды на старте карьеры.

Однако всегда есть некоторые НО.

Первое НО заключается в том, что «крупная ИТ-компания» сильно отличается от просто «крупной компании» (особенно в российских реалиях).

Если у вас есть выбор между переходом в небольшую или среднюю ИТ-компанию или переходом в крупную неИТ-компанию (например, банк или какую-то другую финансовую или торговую компанию), вы должны понимать возможные последствия.

А последствия в худшем случае будут следующие: если ИТ-компания закроется или вы захотите уйти из нее, вы уйдете со знаниями и принципами.

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

Это может быть отсутствие необходимого и актуального опыта, специфика проектов и придирчивость рекрутеров и нанимающих коллег к вашим прошлым местам работы (вспомните компанию Pearson Hardman из известного сериала, которую нанимали только из Гарварда.

Такие истории - не редкость в реальности.

Типа «мы нанимаем только из пищевых компаний» и т. д.).

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

Очень важен результат, процесс его достижения гораздо меньше.

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

Если ваша цель — создать что-то качественное и полезное, займитесь этим.

в учетную запись.

6. Продуктовые и аутсорсинговые компании

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

Работа на аутсорсе над заказными проектами, по мнению некоторых экспертов, – это низший класс.

Это правда или нет? Я отвечу: Нет. Не все так просто.

Главное преимущество продуктовых компаний в том, что человек, приходя туда, фактически имеет возможность выбрать проект/продукт или сферу деятельности со всеми вытекающими последствиями (например, возможность работать над действительно уникальными и сложными задачами).

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

Это не всегда будет так просто, как вам хочется, но это ваш продукт. От вас во многом зависит его успех, по крайней мере, на вашем уровне.

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

Интеграторы и аутсорсеры занимаются теми проектами, за которые деньги платятся здесь и сейчас.

Не все подобные проекты будут интересны определенному классу программистов.

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

Главный недостаток продуктовых компаний — большие объёмы легаси-кода и меньшая ориентация на процессы разработки (с большим упором на прямоту рук и мозгов), с более высокими техническими рисками.

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

Посмотрите статистику закрытых стартапов за последние 5 лет и убедитесь в этом сами.

Это еще не все плюсы и минусы, но остальное, боюсь, выходит далеко за рамки данной статьи.

7. Качество против количества

В начале вашей карьеры чрезвычайно важно понять важный принцип: правильность кода всегда должна быть на первом месте.

С другой стороны, любое программное обеспечение создается с ошибками.

То, насколько фундаментальными они оказались, вполне может повлиять на дальнейшую судьбу проекта или продукта.

Так или иначе, коммерческое программирование — это бизнес и оно не может существовать без прибыли.

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

Иногда это существенно демотивирует команду, особенно если не объясняются причины таких решений.

Возможно, это во многом демотивирует вас.

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

Люди работали на них по выходным от недель до нескольких месяцев.

Что произошло дальше? Худший сценарий для компании – убытки.

Худший сценарий для сотрудников – потеря здоровья.

Поэтому, если вы оказались в ситуации, когда качество постоянно приносится в жертву, стоит оценить 2 вещи: а) продолжительность этого б) последствия (а они могут быть как положительными, так и отрицательными).

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

Система была далека от идеала, но базовый функционал в ней работал хорошо.

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

С точки зрения конечной цели – это успех.

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

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

8. Программы созданы для людей

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

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

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

Это реалии.

Невозможно знать все.

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

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

И первоначальная цель программного обеспечения – помочь пользователю решить его проблемы.

Важно всегда помнить об этом.

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

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

: видеть результат своего труда и пользу, которую он приносит – это, по сути, одна из главных мотивационных составляющих работы в ИТ.

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

Вы спросите, что это вообще такое? Скажу проще: будьте пользователем собственного продукта, поставьте себя на место пользователя, начните думать как он, и, возможно, вы, как разработчик, найдете способ сделать продукт лучше.

9. Об интерфейсах

Это де-факто считается непрестижным (хотя, если брать Сеть последнего времени, в этом принципе произошли положительные изменения).

Видимо для этого даже не нужно уметь программировать.

Что там, клепальные формы? Один, один, и дело сделано.

Так или иначе, определенное рациональное зерно в этом есть.

Разработка библиотек алгоритмов и разработка интерфейсов, конечно, разные виды деятельности.

Но интерфейс есть лицо приложения .

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

У меня для вас еще более интересная новость: мало того, что они не хотят этим заниматься, так мало у кого это получается, на самом деле.

Потому что проблема не ограничивается самим программированием.

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

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

Очень немногие знают, как спроектировать качественный интерфейс с нуля и сценарии его использования.

Итак, хорошая новость: если вы обнаружите, что у вас есть способность понимать, какой интерфейс лучше, и даже предлагать успешные UX/UI-решения, вы можете стать очень конкурентоспособным специалистом, вы откроете для себя новую интересную область задачи, хотя, в определенном случае, вам придется немного отойти от самого программирования.

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

И вы тоже окажетесь в их числе с большой вероятностью.

Это происходит по разным причинам: от маленькой зарплаты до отсутствия интересных задач и прочего.

Первая причина, связанная с деньгами, довольно распространена.

Канонический пример работает так: джуниор получает предложение с зарплатой в 1,5-2 раза выше.

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

Вот здесь-то и может скрываться главная ошибка.

Люди переходят на новую работу, с которой тоже, скорее всего, уйдут через 1-2 года, скорее всего, не из-за финансовых проблем.

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

Будь то другой проект, другая предметная область или технология.

Переключение, как известно из программирования, содержит накладные расходы.

Однако такое переключение не всегда является отрицательным.

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

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

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

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

Заключение

Это время для развития самодисциплины.

Вы сможете сами разобраться, что вам нравится делать больше всего, а что совсем не нравится.

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

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

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

Теги: #развитие программиста #карьера #наставничество #обучение #Карьера в IT-индустрии

• Банк Хоум Кредит Уволил Около Половины Своих Сотрудников С Начала 2015 Года

  19 Oct, 24

• Слои В Мобильных Яндекс.картах

  19 Oct, 24

• Немного Об Архитектуре Программного Обеспечения

  19 Oct, 24

• Автор, Его Поклонники И Издатель — Третье Колесо.

  19 Oct, 24

• Рекомендации По Написанию Html-Кода Для Начинающих Веб-Разработчиков

  19 Oct, 24

• Использование Веб-Сервисов Amazon На Примере Wikipaintings.org

  19 Oct, 24

• Google (Goog): Третий Квартал 2010 Г.

  19 Oct, 24

• Восстановление Размытых И Расфокусированных Изображений С Помощью Фильтра Винера. Реализация На C++ Opencv

  19 Oct, 24

• Syncproj — Утилита Для Создания Проектов Visual Studio C++.

  19 Oct, 24

• Myspace Открывается Для Китайцев

  19 Oct, 24