Публичные выступления, грамотные коммиты и еще два навыка для долгосрочного роста программиста
2026-02-26 19:50 Diff
https://ru.hexlet.io/blog/posts/how-prog

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

Это адаптированный перевод статьи 5 Difficult Skills That Pay Off Exponentially in Programming. Повествование ведется от имени автора.

Содержание

Что такое долгосрочный рост

Посмотрите на эту диаграмму:

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

Навык 1. Баловаться с игрушками

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

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

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

При этом не я один заинтересовался программированием благодаря баловству с игрушками. Илон Маск, Джефф Безос, Ларри Пейдж и Стив Джобс тоже разбирали и собирали обратно разные механизмы, когда были детьми.

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

  • Механизм должен быть самым простым
  • Ваш интерес должен быть естественным
  • У вас есть детское любопытство к вещам, которые вы не понимаете

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

Навык 2. Бросать себе вызов

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

«Что значит бросать себе вызовы? Это значит делать больше, чем от тебя просят. Всегда будь на один шаг впереди»

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

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

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

func readParams()

Как бросить себе вызов? Ну, вы могли бы изменить функцию так, чтобы она могла принимать первым параметром имя файла конфигурации. Код было бы проще читать и менять. Мы можем просто указать имя myfile.config как значение по умолчанию.

func readParams(filename: String="myfile.config")

Вот сколько всего надо учесть после этой маленькой перемены:

  • Во время жизни программы конечный пользователь или клиентский программист могут изменить файл конфигурации. Это приведет к перезагрузке исполняемого кода. Так что надо оптимизировать код так, чтобы файл конфигурации действительно можно было менять. Например, реализовать инкапсуляцию.
  • Если исходить из предположения, что файл конфигурации относится к пользователю, то возникает вероятность того, что пользователей у нас несколько, но устанавливают они одно и то же приложение.
  • И не забываем про функцию экспорта export(). Она экспортирует на диск, сеть, на сторонний сервис обмена сообщениями (на почту, например). Можно импортировать функцию так: readParams(). Тогда приложение становится переносимым (portable) между машинами. Переносимость = Выше ценностное предложение (value proposition) = Бóльшая, более надежная клиентская база.

Если вы не приняли этот вызов и написали код как в первом варианте — никто вас за это не съест. И новые баги из-за этого тоже не появится. Но представьте ситуацию: пользователям очень понравилось такое приложение, они поставили пробной версии пять звезд и жаждут продолжения. Но если не добавить функционал из второго варианта, то они вряд ли купят полную версию.

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

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

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

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

Навык 3. Быть грамотным

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

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

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

«В информатике есть только две сложных вещи: инвалидация кэша и придумывание названий» — Фил Карлтон

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

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

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

Навык 4. Уметь публично рассказывать о своей работе

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

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

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

Программист А:

Пользователь переходит на страницу входа. Он вводит логин и пароль, нажимает кнопку Войти. Если он введет символы #, & или *, то произойдет ошибка входа. Пользователь останется на этой же странице. После этого, если пользователь ввел корректные данные, то фронтенд-часть отправит API-запрос. Еще раз, пароль должен быть хэширован. Потом API сравнивает хэш пароля с тем, что есть в БД. Если имя пользователя не найдено в базе, то пароль проверяться не будет, поэтому сначала проверяется имя пользователя. А если и то, и другое совпадают, то код удовлетворения запроса возвращается из фронтенда. Если нет, то возвращается ошибка 401. Если вернулось одобрение, то пользователя перенаправляют на страницу с профилем. А еще запрошен токен и он будет валиден две недели.

Программист Б:

(После каждого пункта выступающий делает паузу. Там, где текст выделен жирным, он делает акцент при помощи тона голоса):

  • У нас есть два процесса. Первый — это фронтенд, второй — это бэкенд и API (рисует на доске два квадрата)
  • Оба общаются через запрос по сети HTTP (соединил квадраты стрелочками)
  • Фронтенд-часть должна принять данные от пользователя и проверить, валидны ли они
  • Бэкенд-часть должна проверить, совпадают ли данные от пользователя с данными в базе данных. Она проверяет, верен ли хэш пароля
  • И самое главное: Если ответ от бэкенда положительный, фронтенд получает токен, который действителен две недели. В течение этого срока пользователь сразу будет перенаправляться на страницу профиля. Логика проверки токена, очевидно, запускается до логики страницы входа
  • Вы можете посмотреть подробности запроса к API в документе, который я уже всем разослал/залил на облако.

(в этот момент на доске множество стрелочек, и каждая стрелочка пронумерована)

Чья презентация более успешна? Программист А может на 100% понимать, что происходит в коде, но ему определенно не удалось донести идею. Слушатели замучаются слушать его путанную речь и лишние подробности (например, про коды статуса HTTP). Программист Б — захватил и удержал внимание аудитории, а для любопытных составил документ с подробностями.

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

Вывод

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

Есть и другой тип программистов. Они воспринимают код как место, где можно соревноваться в продуктивности. Их девиз это: «Написал больше кода — выполнил больше тикетов». Такие программисты думают, что достичь вершин можно, бесконечно копируя код мастеров. Также они верят, что рецепт успеха — это побольше практики.

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

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