Фото автора Christina @ wocintechchat.com на Unsplash

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

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

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

Они бросают вызов клиентам

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

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

Как однажды сказал Стив Джоб:

Люди не знают, чего хотят, пока вы им это не покажете. — Стив Джобс

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

Мой вывод:

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

У них никогда не кончается работа

В разговоре один на один с моим менеджером он объяснил мне эту концепцию. Он сказал:

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

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

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

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

Мой вывод:

У них есть видимость в других командах

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

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

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

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

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

Мой вывод:

  • То же, что и последний пункт.

Они слушают и объясняют

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

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

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

И если я на самом деле что-то делаю, они тоже слушают и позволяют мне делать то, что я хочу.

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

Мой вывод:

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

Они не боятся смотреть на исходный код

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

В StackOverflow есть много ошибок, но, к сожалению, ошибки, которые мы видим при попытке поддержать веб-приложение восьмилетней давности, обычно не могут быть найдены в Интернете. Однако библиотека все еще существует на GitHub, и исходный код там. Используйте их.

Много раз, когда в нашем конвейере сборки возникала ошибка, после того, как я ничего не мог найти в Google (или, может быть, я просто недостаточно тщательно искал), мой наставник упоминал в Slack, что было обновление с библиотекой, которую мы использовали, и был баг. Он уже открыл вопрос для них. А пока можно заняться бла-бла-бла…

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

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

Мой вывод:

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

Последние мысли

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

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

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