В быстроменяющемся мире разработки программного обеспечения перестать самосовершенствоваться – значит встать на путь деградации. Технологии настолько быстро меняются, так что те, кто способен сохранять темп и учиться новому – получают все сливки, а кто не успевает, будут терять свою конкурентоспособность, и как следствие доходы. В этой статье я хочу рассказать об основных моментах, на которых можно прогореть на пути к профессиональному совершенствованию, а также о том, как этого можно избежать.
Они не получают обратной связи
Без сомнений конструктивная обратная связь это основной катализатор, который заставляет разработчика расти, развиваться профессионально и оттачивать свои навыки. Чтобы это ни было: ответ на ваш пул-реквест в гитхабе, сообщение на электронную почту от менеджера проекта или от клиента, разборы ваших задач на командных митапах. Такую обратную связь получают все и плохие и хорошие специалисты, но не все способны ее правильно принимать и обрабатывать.
Плохой вариант при получении фидбека у вас внутри включается такой монолог: «Да что он о себе возомнил, у меня уже пять лет опыта работы и куча запущенных проектов, а он мне пишет о какой-то неправильной обработке формы? Я уже достаточно хорош и не нуждаюсь ни в чьих советах!».
Однако, любая обратная связь должна натолкнуть вас на размышления о том: как же можно улучшить в будущем то, что я делаю, чтобы даже это незначительное замечание больше не всплывало.
Вот как правильно это делать:
Во-первых, если вы не до конца поняли суть замечания, то обязательно попросите уточняющие детали. Вполне возможно, что после этого вы яснее представите, о чем идет речь и скорей всего увидите действительную проблему, над которой стоит поработать. Не стесняйтесь вступать в диалог, пусть даже это будет не суперспециалист из другого отдела. Не замыкайтесь на своем коде, все-таки это только инструмент для решения человеческих задач. Общайтесь.
Ведите заметки. Прелесть работы программиста в том, что это высокоинтеллектуальное занятие: мысли, идеи, проблемы – все это можно выразить словесно на бумаге. Есть иллюзия, что можно уместить это в программном коде с комментариями, только ваши художественные переживания никому не интересны, они в первую очередь нужны вам. Делая отдельные заметки и возвращаясь к ним на следующий день, через неделю или даже месяц – вы можете быстро себя погрузить в прежний контекст и быстрее понять проблему, а возможно даже решить ее уже на этапе чтения. Также с помощью заметок вы можете понимать растут ли ваши способности или вы топчетесь на месте.
После получения ценных замечаний, которые вы считаете важными, обязательно отразите это в коде. Так вы не только улучшаете поведение программы, но также приучаете себя к ретроактивности. Чтобы не получилось так: «в одно ухо влетело, в другое вылетело». Умейте улавливать и копить энергию, а затем преобразовывать ее в стремление к совершенству.
Учите других. Вы получили хорошее замечание, проанализировали, улучшили свою работу – это все замечательно. Но если вы понимаете, что получили от этого пользу, то почему бы не поделиться этим же с другими. Наверняка в вашем окружении есть коллеги, которые пока еще совершают похожие ошибки, поделитесь также и с ними этим ценным замечанием. Так вы откроете для себя отличный инструмент для улучшения: обучая других, углубляешь и закрепляешь свое понимание обсуждаемого вопроса.
Они не задают вопросов
Разработка программного обеспечения очень загадочная область человеческой деятельности, очень многие вещи происходит в глубинах сознания программистов, небольшая часть из этого преобразуется в код, и совсем мизерная доля описывается в документации, если менеджер сможет заставить кодера написать эту документацию.
Но это же огромный и ценный опыт, а единственный вариант добыть эти знания из головы другого программиста – просто спросить. Конечно, тут приходится преодолевать целую вереницу психологических преград, начиная с природной застенчивости разработчиков и заканчивая постоянной занятостью кодированием. Многим кажется, что если отрывать коллегу от работы и спрашивать его, то на тебя могут подумать: «как же мне надоел этот незнайка, сиди и сам разбирайся!», однако, все обстоит совсем иначе. Любой хороший программист будет рад раскрыть свои гениальные наработки и обучить этому других, стоит только попросить об этом. Можно стараться все решать самостоятельно и доходить «своей головой», только часто это оборачивается тем, что к дедлайну у вас не будет нужной информации.
Переступайте через своего внутреннего интроверта и начинайте общаться, спрашивать, узнавать новое. Кто знает, может быть, это позволит стать вам тимлидом.
Они боятся сложных задач
Многие разработчики застревают в определенной колее (язык программирования, стек, область решаемых задач) и к сожалению, этому подвержены очень многие. Объясняется это просто: вначале очень тяжело добиться приемлемого уровня владения нужной технологией, требуется долгие часы изучения документации и отработки навыков, но постепенно решение задач сводится до автоматизма, код легко и просто пишется. Появляется большая гордость, что ты преодолел тяжелый период обучения и теперь крут, а тебе еще и платят хорошо. В общем, мотивации брать новые задачи совсем не остается.
На этом прекращается рост и начинается стагнация. Сложные задачи – это единственный способ обучиться новому полезному навыку. Вы можете бесконечно смотреть видео, читать книги или еще как-то пассивно потреблять информацию, но пока вы не начнете вбивать код и команды, никогда не получите той обратной связи, которая формирует важные нейронные связи. Такова природа человека.
Сейчас мы наблюдает взрывной рост технологий искусственного интеллекта, все трубят о том, что программистов скоро заменит машина. Только если приглядеться внимательнее, то ИИ – это всего лишь набор компонентов, запакованных в удобные контейнеры. Для развертывания этого требуется знания докера, кубера, API, сетевых технологий, фронтенда и бэкенда. Т.е. быть просто фронтендером и бэкендером, значит что вас с большой долей вероятности заменит искусная нейросеть решающая низкоуровневые задачи. А вот композиция решения из блоков, пусть даже очень умных блоков останется за человеком. Вам нужно выбиться на новый уровень понимания, так чтобы мыслить не категориями блоков кода, а целыми живыми контейнерами, со своими характерами, привычками и способом обучения.
Добиться конкурентоспособности в будущем можно только если постоянно ставить перед собой все более сложные задачи.
Они никогда не работают над своими собственными проектами
Это не значит, что нужно бросить постоянную работу и полностью посвятить все свое время пет-проектами, но каждый разработчик обязан попытаться создать собственный проект с нуля. Основная мотивация тут в том, что нет лучшего способа обучиться новым навыкам, чем применение их на практике, как я упоминал выше. В большинстве компаний разработчик сфокусирован лишь на очень узкой области и отвечает за небольшой участок работ, совсем другое дело, когда одному человеку нужно продумать архитектуру, выбор языка программирования, пользовательский интерфейс, продуктовый дизайн и еще массу других вещей, которые остаются невидимыми при работе в большой команде.
Еще большую пользу приносит собственный проект тем, что заставляет применять все свои знания на практике. Например, если делать проект из курса, где преподаватель просто говорит тебе делай 1-2-3 и получишь результат, то при реализации своей идеи тебе приходится сначала понять какие шаги сделать, потом найти способы реализации. В процессе естественно возникнут непредвиденные сложности, которые заставят погрузиться в документацию, задавать вопросы на форумах. Все это очень хорошо цементирует теоретические знания и создает прочную основу, которую можно без стеснения применять в будущем.
Они никогда не меняют роли или компании
Когда вы меняете роли в компании или просто меняете место работы, то случаются следующие вещи:
У вас появляются новые коллеги, которые могут научить многим интересным вещам;
Вы работаете над новыми задачами, которые заставляют думать вас по-другому и смотреть с разных сторон на привычные предметы;
Вам приходится работать с разными технологиями, которые опять же расширяют ваш горизонт познания и конечно, добавляют новые пункты в резюме.
Все эти переходы и переключения ответственности очень позитивно влияют на ваши качества программиста. Как при ковке металла, важно наносить удары по раскаленной болванке с разных сторон, создавать слои и перемешивать их, то же самое справедливо и для скилов программирования.
Если вам кажется, что не получится просто перейти в другую компанию из-за боязни потерять насиженное место, то можно хотя бы проходить собеседования. Вопросы от интервьюеров могут открыть для вас такие глубины собственного незнания, что вы бросите все любимые сериалы и приметесь по вечерам восполнять пробелы, которые открыли для себя при ответе на каверзные вопросы.
Они не меняют языки программирования
Очень многие начинающие, да и опытные программисты упускают потрясающие возможности к росту, когда сильно привязываются к одному языку программирования и считают, что лучше просто не существует. Язык программирования всего лишь инструмент для решения определенных задач. Если C++ разработчик ненавидит JavaScript, то он никогда не сможет оценить простоту создания фронтенд-приложения, которое отлично работает в браузере, хотя сам плюсовик может создавать невероятно быстрые низкоуровневые приложения для какого-нибудь микроконтроллера. Но этим самым он ограничивает свое видение.
Даже я, когда после долгих лет программирования на PHP начал постепенно изучать JavaScript, а потом и TypeScript, то мне открылись огромные преимущества строгой типизации, которые позволили начать эффективнее делать приложения на PHP. До этого я не мог понять зачем все эти сложности и лишний код.
Потом я испробовал разработку Android-приложений, здесь меня ждал сюрприз в виде четкого понимания истинного назначения паттернов-проектирования. В Java они применяются сплошь и рядом, даже для самых простых операций.
Изучение разных языков программирования, кроме самих навыков вырабатывает еще отличные аналитические способности, которые пригождаются при создании архитектуры новых приложений. Сами базовые принципы заложенные в Java, Python или PHP позволяют рассматривать проблему с множества точек зрения и выбирать оптимальные решения.
Переключаясь между языками, неизбежно приходится сталкиваться с различиями в них и нужно тратить дополнительные усилия, чтобы изучать документацию. При этом сами языки очень динамично развиваются, поэтому вы также вместе с ними начинаете скользить по новым версиям и впитывать технологические новшества. А занимаясь программированием на одном языке попадаешь в ловушку собственной экспертности и перестаешь интересоваться новшествами, да и зачем, итак, все отлично получается.
