Развитие для разработчика — learning as a lifestyle

Photo by UX Indonesia on Unsplash

Об авторе: Меня зовут Игорь Сорока. Мне нравится развиваться, учиться и рассказывать об этом другим. Разрабатываю software продукты и интересуюсь IT. Также записываю подкасты, чтобы делиться интересными историями и новостями. У меня есть телеграм канал Geek Export, на котором пишу для программистов про карьеру в Европе и мире.

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

Однако, всегда наступает момент, когда цель достигнута, а фанфары прозвучали. Для меня такой ачивкой было устроиться в IT компанию. Вот он, переломный момент. Ты перестаешь так активно активно учиться новому, когда уже работаешь. Новые скиллы тоже осваиваешь, но становится очень комфортно. Пропадает запал, и философия «Stay hungry, stay foolish» постепенно исчезает.

Я пришел в команду, где программировали на Java. Использовали хитрый фреймворк для Dependency Injection (не Spring). Сначала звучало немного страшно, но когда onboarding пройден, а базовые навыки для работы получены, жить становится легче. В тот момент и наступает стагнация. Уже через 3-4 месяца постоянной работы объем новых знаний был получен, и я выдохнул от этой гонки за стэком компании. Как раз в этот момент я понял, что пора продолжать развиваться. 

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

Быть в курсе

Постоянно читайте блоги, слушайте подкасты и смотрите туториалы на ютубе, потому что они развивают кругозор, даже если темы не будут понятны сразу, со временем станет интереснее. Однажды я слушал подкаст, в котором говорили про serverless, который хорошо подходит под определенные бизнес-задачи. Через некоторое время, когда я думал над реализацией нового проекта, где-то на подсознании кликнуло «можно же использовать AWS Lambda». Почему бы и не попробовать!

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

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

Помимо аудио контента, нужно и можно читать Хабр, vc.ru, Medium, и много других блогов как на русском, так и на английском. 

Practice English

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

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

Photo by Kieran Wood on Unsplash

Использовать новые технологии на работе

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

  • преимущества
  • недостатки
  • влияние на бизнес и клиента
  • влияние на продукт и развитие компетенций
  • примерную архитектуру
  • сроки исполнения
  • количество человеко-часов (workload)

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

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

Не переставайте пробовать новые языки и фреймворки в рутинных задачах. Чаще всего новые технологии решают старые проблемы и помогают что-то улучшить. Старый jQuery проект можно переписать на React или Vue. Обязательно частями и в рамках MVP реализации — в этом плане Vue хорошо встраивается в готовые сборки.

С бэкэндом похожая история. Если уже есть  код на Java, можно попробовать переписать один сервлет на Kotlin. Опыт написания кода с использованием новых инструментов сложно недооценить. Быстро изучить нужную технологию или освежить знания можно на интерактивном курсе от JetBrains. Пробуйте использовать новое, а менеджерам можно всегда это преподать как развитие навыков без отрыва от производства.

Не стесняться просить помощи

Люди технического склада ума большие любители зарываться в проблему и глубоко копать. Даже те, кто приходят в индустрию без специализированного образования — со временем становятся такими же. Чем дольше я в IT, тем больше есть соблазн самому все решить и закопаться в дебри source code малоизвестного репозитория и эзотерического языка. Не стоит бояться просить помощи у более опытных коллег. Неважно, будет это в офисе, в slack, stackoverflow или в чатике в телеграме. Тут может быть важно не то, из какой команды коллеги, а насколько они знают эту тему или фреймворк.

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

Как же попросить помощи в решении хитрой проблемы? В одном из моих выпусков подкаста гость Дмитрий, который работает Data Engineer и имеет потрясающий опыт смены деятельности, предложил такой оригинальный способ: если не можешь найти решение задачи думая изо всех сил в течении 15 минут, то есть смысл обратиться к более опытному коллеге за помощью. Конечно для каждого это время будет разное, но здесь важен факт таймбоксинга. То есть ставить себе временные рамки, чтобы не прокрастинировать и не отвлекаться на котиков.

Экспериментировать в свободное время

Постараться найти свободное время и попробовать open-source технологии на своем localhost, писать коммиты в репозитории других людей — это очень развивает. Нужно включать любопытство и пытаться написать на новом фреймворке или языке что-то сложнее чем «Hello, world». Если это Ruby, то стоит точно попытаться написать не просто сервер, возвращающий строку по запросу, а прикрутить, например, аутентификацию. Также развернуть на Heroku или AWS в контейнере. Репозиторий на GitHub потом поможет и в ситуации, где надо убедить начальство использовать именно эту технологию, а также при поиске работы или фриланса. Только не забывайте писать хорошие и понятные README на английском.

Расширять сеть контактов

Связываться с докладчиками конференций, ведущими каналов с туториалами и в Телеграме. Для этого отлично подходит LinkedIn, twitter и иногда Instagram. Чаще всего эти люди очень рады, когда читают фидбэк о том, что они делают. Высказывайте свое мнение всем, кто создает контент, но будьте доброжелательны. В основном, люди делают такие вещи по фану, для самовыражения и желания поделиться тем, что их интересует. Я всегда стараюсь писать докладчикам и авторам хороших статей или видео.

Photo by Erik Mclean on Unsplash

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

Связываться с людьми в мире IT (и за его пределами) очень сильно помогает развиваться. Когда вы обрастаете связями и становитесь частью комьюнити, которое в англоязычной версии очень доброжелательное и приветливое ко всем новичкам, у вас появляется уверенность в себе и мотивация. Даже из подписок на каналы, где публикуются новые и интересные статьи и материалы, можно почерпнуть множество полезного. Есть, например, подборки твиттер аккаунтов по тематикам. Там можно подписаться на интересных евангелистов или популяризаторов технологий.

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

Например, когда общаешься с новыми людьми и тебя просят представиться. Скрининговый звонок рекрутера часто начинается с фразы «Расскажи о себе». И тут не работает фраза из серии “Меня зовут Джон и я работаю бэк-енд разработчиком на Java.” Нужно найти свою фишку. Короткий рассказ о себе с яркой деталью это шанс создать свою историю и запомниться: “Я — Джон. Разрабатываю опен-сорс проект, который дает советы садоводам, как лучше выращивать розы”. Хороший питч привлечёт именно тех людей и возможности, которых ищете. Важно то, как мы транслируем в мир свои мысли и идеи. Услышав ключевую фразу, легче заинтересоваться и начать разговор сразу на актуальную тему.

Делать паузы

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

Каждые полгода нужно делать паузу и спрашивать себя: а в том ли направлении я развиваю свои навыки? Нужно ли углубить свои знания, либо начать развиваться в смежной области? Если ответ — да, то начать можно с того, чтобы узнать все об экосистеме, с которой работаешь. Если выучить только React, то особенного движения не получится, даже если станешь гуру в этой библиотеке. Без знаний NodeJS, yarn, SCSS и прочих зависимостей фронтэнда — никуда.

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх