Как стать хорошим, нет, лучшим разработчиком?

«Если хотите совершенствовать свой код, не зацикливайтесь на тестах, разрабатывайте лучше». S.McConnell

Посещал ли вас когда-нибудь вопрос, как стать хорошим разработчиком? Скорее всего, да. Кто-то начинает задумываться об этом в начале своей карьеры, кто-то, уже успев «почувствовать боль» непрерывного поиска решений возникающих проблем. Давайте разберемся, в чем же заключается основная сложность становления человека как хорошего разработчика, с какими проблемами приходится сталкиваться на этом пути и как сделать так, чтобы рынок труда побыстрее начал работать на вас. В этом нам поможет Давид Аветиков, главный системный архитектор компании Bell Integrator. За плечами у Давида более 10 лет опыта разработки и реализация порядка 20 крупных систем для таких заказчиков, как МТС, Сбербанк, ВТБ, Доктор рядом и других.

Весь интернет сейчас пестрит рекламой и предложениями типа «Хочешь много зарабатывать?», «Программирование – это легко», «За неделю научим программированию» и т.д. Все эти лозунги создают огромный ажиотаж среди людей, которые даже представления не имеют, что такое на самом деле программирование, и что действительно на текущий момент нужно рынку. Как следствие – для junior Developer’а предъявляются значительные требования к знаниям, которыми он должен обладать для первого трудоустройства. Те времена, когда достаточно было изучить синтаксис любого языка и написать на нем «Hello, world!», чтобы устроиться на работу, давно прошли.

Первая проблема, с которой сталкивается каждый начинающий разработчик – «С чего начать?». Если к этой проблеме вы пришли, только преследуя цель зарабатывать больше, то вряд ли из этого получиться что-то хорошее. Вероятно, что через некоторое время вас начнет раздражать то, чем вам придется заниматься. Если же у вас есть более убедительные мотивы, то начинать нужно с изучения основ. Основ не только в направлении языка программирования, который вы выбираете, но и ИT в целом, как окружения, с которым вам придется работать.

Для начала изучите принципы работы баз данных. Любая корпоративная разработка включает в себя работу с ней. Как следствие – хорошим тоном будет знание SQL и соответствующего языка программирования (T-SQL, PL/SQL, PSQL… в зависимости от того, какую базу данных вы выберите для изучения). Не лишним будет знание таких вещей, как архитектура базы данных, механизмы блокировок, уровни изоляций транзакций, таблицы, представления, индексы, аналитические функции и принципы оптимизации запросов.

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

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

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

И, наконец, заведите GitHub аккаунт (где вы будете вести свои разработки и оттачивать навыки git-flow), напишите свою первую систему с использованием всего, что вы успели изучить (для примера, пусть это будет система учета посещений лекций студентами). Теперь вы готовы проходить свои первые интервью на Junior Developer’а!

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

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

Второе – следует тщательно изучить сам проект, как с точки зрения используемого стека технологий, так и с точки зрения бизнес-функциональности. В этом вопросе незазорно будет спросить у коллег, откуда начать копать, и параллельно мучить архитектора и/или аналитика проекта вопросами типа: «А почему тут так, если можно вот так…».

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

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

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

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

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

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

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

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

Приведу пример из собственной практики. Как-то директор департамента (одного крупнейшего сотового оператора) попросил меня составить недельный отчет и презентовать ему то, что мы сделали за минувший период. Мы тогда уже успешно внедрили mission critical систему, о которой он и хотел послушать. Писать в отчете рутину, которой мы занимались, на тот момент не имело смысла. Да и в глазах директора это могло показаться слишком малым достижением. Поэтому в отчете я написал только одну строчку: «Успешно разработана и внедрена интеллектуальная система мониторинга метрик предоставления качества услуг». По сути это была небольшая утилита, которая залезала в базу и снимала статистику по прохождению бизнес-процесса. Но что увидел директор? «Интеллектуальная» – очень модное на тот момент слово, и «Метрики предоставления качества услуг» – то, что на его должности волнует его больше всего. Как следствие, это «достижение» пошло по вертикальной иерархии вверх и принесло нам больше известности, чем внедрение всей системы.

Итак, подведем итоги.

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

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