Советы начинающим разработчикам. Принципы для тех кто хочет стать круче.
В IT-индустрии довольно часто звучат вопрос от начинающих специалистов из серии “Как мне развиваться?”, “Как мне стать более крутым специалистом?”. Сразу поясню, к начинающим специалистам я отношу людей с опытом работы от 0 до 3 лет. Если вы именно такой специалист, или более опытный но ставите перед собой профессиональные цели стать опытнее, успешнее, добиться карьерного роста – приглашаю вас ознакомиться с моими мыслями по этому поводу.
Представление
Для начала коротко о себе. Меня зовут Николай, сейчас я работаю руководителем проектов по внедрению и сопровождению Битрикс24. За все 6+ лет работы я работаю только в IT-индустрии, а свой карьерный путь начинал веб-разработчиком. Подробнее вы можете познакомиться с моим опытом в профиле Linkedin. На текущий момент у меня в подчинении 2 команды разработчиков и внедренцев, а суммарно за все время работы через меня прошли: около двух десятков junior-специалистов, около десятка middle-разработчиков, несколько seniorов и пара тим-лидов. Некоторые из них преодолели под моим руководством путь от разработчика до тим-лида. Поэтому в вопросе как развиваться разработчику мне есть что и о чем рассказать. В интернете полно статей посвященных этому вопросу, но все они либо углубляются в технические детали, либо почти полностью описывают работу по какой-либо гибкой методологии из разряда “работай по agile и все будет в шоколаде” или “переходите на работу по scrum и не будет никаких проблем и вопросов”. Но как показывает суровая реальность – статистики и реалии конкретных команд и специалистов, далеко не все что необходимо для построения в компании культуры и практики разработки ПО, а также создания атмосферы для успешного развития программистов по карьерной лестнице. Так что в своей статье я дам ответ на поставленный вопрос основываясь на личных наблюдениях, опыте и полученной обратной связи от своих коллег как нынешних так и бывших.
Отказ от ответственности
Все изложенное ниже является сугубо моим личным мнением и получено в результате собственного опыта, подкрепленного теоретическими познаниями проверенными на собственном опыте. Некоторые вещи могут не соответствовать той ситуации в которой находитесь вы, поэтому вот вам первый совет – в любой ситуации проанализируйте ее конструкцию, прежде чем начать применять свои собственные практики или общеизвестные шаблоны.
Ну а теперь начнем.
1. Широкая или узкая специализация
Многие кто только хочет стать программистом задаются вопросом “Какой язык(технологию) лучше выбрать для изучения?”. Устраиваясь на первую работу часто думают “Будет ли данная технология востребована и перспективна через 5-10 лет?”. Для ответа на эти вопросы нужно учесть одно большое НО – понятия “лучше” и “перспективнее” в данной ситуации весьма субъективны, и определяются буквально на уровне ощущений и возможной пользы в вашей будущей карьере. Придя в мир IT новичок довольно скоро обнаружит, что существует множество проектов, которые делаются на основе множества различных технологий, применяемых иногда в комплексе и знать их все нет никакой физической возможности. Так нужно ли гнаться сразу за всеми зайцами?
Однажды я услышал как наш тимлид в разговоре с одним из джунов произнес “Не распыляйся. Сфокусируйся сейчас на одной технологии/фреймворке. Специалист – это либо специалист в какой-либо области, либо не специалист ни в одной. Если хочешь разбираться на высоком уровне – необходимо постоянно заниматься, знать все детали достаточно глубоко.”
Я не раз видел подтверждение этих слов. Большинство специалистов с которыми я знаком – специалисты в узкой области. Они блестяще знаем свой предмет и можем в его рамках решать задачи, которые другим кажутся фантастикой. И можно было бы сказать, что “Окей. Принцип верен – все сошлось”, если бы не ряд НО.
Во-первых – есть целый ряд проектов, которые практически не требуют таких узких специалистов. Неоднократно я встречал проекты в которых нельзя было бы участвовать не обладая широкими познаниями сразу в нескольких технологиях. Люди обладавшие такими знаниями открывали перед собой новые горизонты возможностей, иногда ранее казавшиеся недостижимыми. Но участие в таком проекте – серьезное испытание, в отдельных случаях карьерное.
Во-вторых – мир технологий довольно часто меняется. Ограничить себя одной-двумя технологиями или даже языками программирования вряд-ли получится, так как будет высокий шанс потерять конкурентное преимущество и в конечно итоге оказаться менее востребованным специалистом.
Резюмируя выше написанное – не бойтесь пробовать новые технологии, которые вам понравились, но не хватайтесь за все сразу, а осваивайте их постепенно по мере погружения в каждую из них.
Знание основ и внутреннего устройства будет серьезным конкурентным преимуществом, особенно в случае когда вакансия среди всего прочего требует сильного знания 1 технологии и хотя бы базового других. Самое главное здесь соблюдать меру и четко определить приоритеты, на какую технологию вы тратите основное время, а на какие оставшееся.
2. Функциональная область
От специализации в языках программирования и технологии перейдем к другой важной вещи – функциональной области. Рассмотрим на простом примере, что такое функциональная область. Врачи делятся на кардиологов, стоматологов, нейрохирургов. Точно такое же разделение есть и у разработчиков: кто-то специализируется на интерфейсах, кто-то на распознавании объектов, другие пишут логику для игровых ботов.
Вопрос специализации не должен вас беспокоить как минимум в первые два года работы, так как в этот период основное время будет вами тратиться на вход в проекты, погружение в технологии. Данный вопрос просто не будет для вас актуален. Но с определенного момента вы начнете ощущать легкость в решении некоторых задач, все более и более сложных. Результат выполнения таких задач будет определяться не вашим знанием технологии или языка программирования, а вашим опытом в решении подобных задач. Это и будет вашей специализацией.
Компьютерная графика, компьютерная лингвистика, финансовое программирование – это все конкретные области получение опыта в которых требует немалого времени. Если вы хотите стать высококлассным специалистом в какой-либо области разработки, то вам нужно найти ту, которая будет вам нравиться по-настоящему. Ну а когда найдете – развивайтесь и совершенствуйтесь в ней.
3. Наставничество vs самостоятельное обучение
Не бывает двух полностью идентичных проектов. Не существует двух одинаковых команд. Отсутствуют также и единственное правильное решение задачи.
Перед начинающим специалистом всегда стоят много вопросов, у него множество сомнений ответить на которые он не может в силу отсутствия опыта. Представим такую ситуацию – вы получили готовый код, который успешно работает у всех ваших коллег по цеху, но не работает именно у вас. Такая ситуация у начинающего специалиста возникает постоянно, особенно в первый год работы. Степень сложности подобных проблем прыгает из состоянии “наверное это решается вот так” в “вообще не понимаю что происходит”.
При решении подобных проблем первым советом опытных специалистов является – научитесь самостоятельно разбираться в возникших проблемах максимально подробно и глубоко как только можете. Для этого необходимо научиться концентрироваться на причинно-следственной связи и правильно формулировать вопросы о проблеме. В первую очередь нужно научиться формулировать вопросы к себе и во вторую к Гуглу. Даже если вы уверены, что это не должно работать, вернитесь к началу, чтобы найти настоящую причину проблему. В 95% случаев с помощью Гугла вы обнаружите, что не вы первый сталкиваетесь с такой проблемой и минимум в 75% процентах случаев она имеет готовое решение.
Если вам “повезло” и вы попали либо в 5% либо в 25% оставшихся случаев, то вот вам следующих совет. После того как вы выполнили несколько неудачных попыток решить проблему самостоятельно, провели анализ проблемы, потратили на попытку решения существенное время (многие его называют “правило 20 минут”) – обратитесь к старшим коллегам. Таким образом вы не потратите их время на решение пустяка или перебор общеизвестных вариантов решения, но продемонстрируете умение правильно подходить к решению проблем.
Однако несмотря на все это недостаточное знание технологий и отсутствие практического опыта – весьма тягостный фактор. Поэтому правильным будет в первую очередь – в интенсивном режиме изучить использующиеся в проекте технологии разработки и примеры их использования, а также подводные камни. Но написать об этом легче, чем осуществить на деле. Обучающих материалов – воз и маленькая телега; не все они понятные, не все релевантные, не все покрывают проблемы с которыми можно столкнуться на практике. Спасательным кругом в этой ситуации становится “окружающая среда”. Оказаться в команде “экспертов” обладающим не только высоким уровнем знаний, но и готовностью ими делиться – очень большой плюс на старте карьеры. Разумеется в первую очередь вы должны сфокусироваться на самообучении, но наличие таких экспертов поможет вам преодолеть “потолок скорости” в самообучении. Но не стоит забывать, что прежде чем к ним обращаться, вам необходимо самостоятельно попробовать продвинуться хотя бы на шаг в решении проблемы.
При выборе места работы ищите такое, где есть эксперты готовые делиться своими знаниями. 1 год в компании, где эксперты делятся знаниями заменяют 3 года в компании, где никто не делится опытом.
4. Серебряной пули не существует
Работа в ИТ – это постоянные споры, борьба мнений, война принципов. На своем пути становления опытным разработчиком вы встретите немало людей, которые будут убеждать вас, что только они обладают правильным решением или мнением иногда подкрепляя это только теми фактами из личного опыта, которые доказывают их правоту (при этом умалчивая о противоположном). В один прекрасный день и вы присоединитесь к ним.
Можно или нет сделать задачу в указанный срок? Какая технология лучше: А или Б, а для задачи В? По какой методологии стоит разрабатывать проект и организовывать процесс работы? Достаточно ли хорош написанный код или ему все еще требуется рефакторинг? Закладывать возможность расширения системы с самого начала, или вы не видите со своего уровня junior developer’a всей картины? Как правильно оценивать качество и какая роль в этом процессе у разработчиков? И еще десяток-другой различных подобных вопросов, которые будут возникать в вашей голове постоянно в начале карьеры при получении задачи.
Зачастую на такие вопросы невозможно ответить однозначно даже в конкретной ситуации. Особенно из-за высокого уровня неопределенности за которым вам может быть объективного не видно подходящего ответа. Но следует помнить о том, что работа в ИТ практически всегда требует принятия решения на основе неполных данных.
Завершая очередной проект или закрывая задачу – оглянитесь и проведите анализ. Какие принципы, действия и технологии помогли ее успешному решению, а какие были ошибочными. Оцените также и уровень коммуникации с заказчиком. Постоянно анализируйте свою деятельность и советуйтесь с экспертами, чтобы успеть разглядеть все и определить все плюсы и минусы того или иного решения.
5. Большая или маленькая компания? ИТ или не ИТ?
Начало карьеры в большой компании – большой и очень ценный опыт. Осознание этого факта приходит где-то после 5-го года этого самого опыта. Увидеть работу крупной компании изнутри, понять как работают в ней все процессы как внешние, так и внутренние – это того стоит. Мне тяжело представить, что может быть лучше в начале пути, чем сочетание крупной компании и толкового коллектива. Однако всегда есть какое-то “но”.
Первое “но” состоит к том, что крупная ИТ-компания отличается от просто крупной компании. Выбирая между средней ИТ-компанией и крупной не ИТ-компанией нужно понимать возможные последствия. Рассмотреть лучше всего будет на сценарии ухода или увольнения.
Если вы уходите из ИТ-компании – у вас будут при себе основные базовые принципы и знания. Уход из не ИТ-компаний будет сложнее по ряду причин: специфичный опыт работы связанный с проектами и технологиями. От части это связано с тем, что в компании, где ИТ не является частью бизнеса гораздо важнее результат, чем процесс.Но именно правильный процесс обеспечивает рост разработчика и его развитие.
6. Продуктовая или аутсорсинговая компания
Бытует мнение, что работа в продуктовой ИТ-компании более престижно и финансово привлекательнее, а работа в аутсорсе – это на порядок или два ниже. Так ли лучше продуктовые компании, чем аутсорс? Одназначного ответа нет. И давайте посмотрим почему.
Основной плюс продуктовой компании, что вы имеете возможность выбрать продукт/проект или сферу деятельности над которыми хотите работать. Как следствие вы будете этим заниматься каждый день и не всегда так как этого будет хотеться именно вам. Теперь этот продукт Ваш и Вы своими действиями так или иначе влияете на его успех. Минус продуктовых компаний – большие объемы legacy-кода и высокие технические риски.
В аутсорсинговой компании вам придется заниматься теми проектами за которые платят деньги в текущий момент времени. Не всегда такие проекты интересны и есть риск оказаться на стагнирующем проекте. Хорошо если есть возможность сменить проект, но иногда это можно сделать только уволившись.
7. Качество против количества
Рассмотрев несколько организационных вопросов вернемся вновь к рассмотрению вещей касающихся непосредственно программирования.
На начальном этапе очень важно понять, что главное не количество написанного кода, а его качество. “Любое ПО создается с ошибками” скажете мне вы и вы будете абсолютно правы. Но на судьбу проекта влияет не сколько количество и качество ошибок, а то насколько эти ошибки принципиальны. Вам не раз придется столкнуться с ситуацией когда придется жертвовать качество кода ради соблюдения сроков поставки релиза, а в коммерческом программировании – это вообще постоянная история. Такая ситуация обычно демотивирует команду программистов, особенно если это не объясняется разумными причинами. Постоянное жертвование качеством кода зачастую выливается для сотрудников в постоянные переработки, а для компании в убытки. Оказавшись участником подобной ситуации нужно оценить 2 вещи. Во-первых – длительность подобного периода и его частота. Во-вторых – последствия такого решения. Однако у любой моменты 2 стороны. Быстрый релиз может быть не качественным, но своевременным, а недостатки качества можно исправить в последующих более спокойных релизах.
Как итог – иногда можно пожертвовать каким-то показателем, даже качеством кода, чтобы открыть для проекта новые возможности. Но если вы постоянно чем-то жертвуете и не получаете в ответ хороших результатов, то стоит задуматься о смене проекта или места работы.
8. Программы пишутся для людей
При проектировании и разработке любого программного обеспечения нужно помнить главное – программа должна помогать пользователю решать его задачи.
Ориентированность на пользователя – одно из главных правил любого человека который связан с разработкой программного обеспечения. Если этому вопросу не уделять достаточно внимания, то функционал софта будет неудобен для использования конечному пользователю, а что зачастую пользователи делают с софтом который им не удобен – перестают пользоваться и удаляют.
Будет ли пользователь хвалить софт или ругать полностью зависит от команды которая его делает. А чтобы сделать софт максимально ориентированным на пользователя, поставьте себя на место конечного потребителя, начните думать как думает он и тогда вы как разработчик сможете сделать свой софт лучше.
9. Про интерфейсы
Большая часть программистов в IT-индустрии занимается разработкой логики или другими словами backend-ом. Задачи по разработке интерфейса пользователя основная их масса считает неинтересными или даже недостойными их внимания. В кругах backend-разработчиков такие задачи считаются не пристижными, что там эти формы-кнопки делать, делов-то, мозгов не надо.
В чем-то в этих рассуждениях есть рациональное зерно. Ведь действительно разработка алгоритмов и разработка интерфейсов – совершенно разные задачи, которые требуют каждая своего подхода. Но не нужно забывать о том, что алгоритмы и логика – это внутренние органы проекта, а интерфейс – его лицо. И именно лицо видит пользователь запуская ваше приложение и взаимодействует с ним.
Плохая новость заключается в том, что задачами разработки интерфейса мало кто хочет и еще меньше кто умеет действительно заниматься. Проблема разработки интерфейса не ограничивается только программированием. Достаточное количество frontend-разработчиков умеет делать интерфейсы по макетам, но не так много из них делает это на профессиональной основе. Еще гораздо меньше может объяснить почему сценарий использования А лучше чем сценарий использования Б. Ну и совсем мало тех кто может с нуля спроектировать готовый и качественный интерфейс, а также прописать сценарии использования и их преимущества перед другими сценариями. И вот тут начинаются хорошие новости: если вы заметили, что способны понимать какой интерфейс лучше и почему, предлагать удачный UX/UI-решения – вы можете стать очень серьезным конкурентным специалистом открыв для себя новую область задач, которая довольно интересна, чтобы там ни говорили backend-разработчики. Единственный небольшой минус, который может быть – небольшой уход непосредственно от самого программирования.
10. Смена места работы
По статистике основная масса работников меняет работу после двух-трех лет. С высокой долей вероятности в их числе окажитесь и вы. Смена происходит по самым разным причинам: неудовлетворенность зарплатой, отсутствие интересных задач и т.п.
Самой распространенной причиной смены является именно финансовая. Рассмотрим ставший уже каноническим пример. Juior-level разработчик получает предложение по которому зарплата в 1,5-2 раза выше. Такой коэффициент в начале карьеры кажется огромным повышением и перед искушением сложно устоять. Но здесь может скрываться большая ошибка. Согласно статистике через 2 года вы снова окажетесь перед выбором нового места работы. Итого у вас уже будет 4 года опыта и 2 места работы, но много ли проектов за это время вы завершили? Был ли среди завершенных проектов хоть один крупный? Для любого разработчика со стажем в 4 года, отсутствие крупного проекта в портфолио – это серьезный недостаток и этот момент может вызвать сомнения не только у рекрутеров фирмы куда вы захотите перейти, но и поставит под сомнение ваши профессиональные навыки перед другими техническими специалистами. Я расскажу вам как подобные прыжки начинающих специалистов выглядят в глазах рекрутеров, тим-лидов и менеджеров-проектов которые причастны к найму. Человек не научившись хорошо делать задачи типа А или не освоив технологию А, переключается на задачи типа Б или технологию Б. Это дает сигнал к тому, что человек может быть не склонен доводить проблемы до логического завершения. Как известно переключение – всегда влечет за собой накладные расходы. Но не всегда переключение негативно. Основной позитив заключается в возможности на новом месте получить возможность поработать в более крутой команде или над более интересным проектом, а ваш профессиональный рост пойдет быстрее. Вы должны ощущать, что переход будет для вас существенным прорывом и донести это на собеседовании, тогда вы не ошибетесь.
В сухом остатке – в первые три года перед тем как сменить работы задумайтесь над реальными причинами, которые толкают вас на этот шаг. Повторюсь: интенсивное изучение технологий и прокачка навыков – задача №1 на первые три года. Наличие завершенных задач и проектов – задача №2. Финансовый рост – №3. Если поставить финансы на первое место, то вы обнаружите, что за прошедшие 3 года в индустрии вы научились только решать задачи строго ограниченного круга в рамках конкретного проекта и не обладаете достаточными знаниями, которые могут быть необходимы на новом месте, но которыми будут обладать ваши конкуренты.
Наконец-то заключение
Начало карьеры – время когда необходимо работать над своими техническими навыками и научиться темпу работы, который необходим при работе в реальных условиях. Это также и время когда нужно заняться развитием самодисциплины. Это время когда можно понять чем вам больше всего нравится заниматься, а чем не нравится совсем. Это тот период когда можно совершить большое количество ошибок и безболезненно научиться на них, а также одержать немало побед.
При правильном разборе полетов и произведении правильных выводов на начальном этапе карьере можно выработать нужное отношение к работе и наработать все необходимые в последующем навыки. В этом случае к четвертому году опыта вы подойдете с хорошим набором технических навыков, реальным проектным опытом и пониманием многих реальных проблем проектов и задач, а также способами их решения. И конечно же получите отличное подспорье для дальнейшего развития.