Как стать суперпрограммистом?


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

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

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

Соблюдение сроков

Опыт показывает, что это уложиться в срок — это самая трудная часть работы.

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

ZN4Oyq1ey4t-6zw0LFHgHgqWX_3LxCm0tnzuasBJ
Прим. перев.: Карл Саган — астроном, астрофизик и выдающийся популяризатор науки.

Вероятно, вы знакомы с ребятами…

  • …которые даже после шестого совещания не могут предложить подходящее решение задачи;
  • …которые на вопрос о работе «Как продвигается?» отвечают «В процессе!», хотя сами уже несколько часов залипают над каким-нибудь крохотным случайным вопросом;
  • …которые несколько дней проводят исследование, а потом понимают, что исследуемый объект изначально не работает;
  • …которые находят в коде что-нибудь на их взгляд странное и потом тратят кучу времени, исправляя надуманную проблему.

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

Я знаю, о чем вы подумали: «Окей, вижу, куда ты клонишь: пока я теряю время, компания теряет деньги». И да, и нет. Конечно, иногда компания напрямую теряет прибыль из-за задержек, однако, что более важно — растраченное на пустяки время влияет на самого разработчика.

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

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

Сделайте базовый обзор темы, соберите нужную информацию, подготовьте ресурсы для запуска — и действуйте. Нет смысла перечитывать всю документацию по API просто для того, чтобы установить соединение. Всегда что-нибудь, да пойдет не так.
Заранее предугадать не получится — поэтому не переживайте на этот счет и просто работайте. Конечно, если вдруг задача совсем невыполнима, то об этом надо знать. Это, кстати, аргумент в пользу проведения сессий планирования и присутствия в команде архитектора ПО.

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

  • за 1 день получить общее понимание задачи и начать кодить;
  • 5 дней вчитываться в документацию.

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

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

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

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

Общение

-LpqhUMeJF_FhjKOI5pDYbMLsso1BeP6B5m6KIDv
Иллюстрация: Karol Podleśny

Общение — это выдающийся инструмент для решения проблем, который к тому же поможет освоить предыдущие три достоинства. Доказательства? Давайте представим такие ситуации:

  • Не уверены, стоит ли дальше совершенствовать код или уже хватит? А если продолжать, то как? Спросите коллегу и лучше более опытного. Так вы узнаете, достаточно ли хорош код и убережете себя от улучшения того, что и так отлично работает. Если же что-то не так, то получите совет или, на крайний случай, узнаете, к кому дальше можно обратиться.
  • Необходимо проверить, правильно ли работает разработанная вами функция? Обратитесь к тестировщику. Обычно тестировщик лучше знает устройство разрабатываемой системы и подскажет, какое воздействие на неё может оказать ваша функция, и где может скрываться подвох.
  • Не уверены, что сможете выполнить задачу? Спросите архитектора или посовещайтесь с коллегами. Их опыт и знания помогут прояснить ситуацию.

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

Вот несколько советов из моего личного опыта:

  • Общением можно решить любую проблему. Правда, умение находить нужного собеседника приходит с опытом. И да, реально круто временами отвлекаться от непрерывного кодинга.
  • Не бойтесь чего-то не знать. Людям это свойственно. Тем более, так вы покажете, что осознаете пределы своих умений, и что вы партнер, а не мудак.
  • Застряли над чем-то? Воспользуйтесь правилом 30/60 — если не получается решить легкую задачу за 30 минут, а сложную — за 60, то пора обращаться за помощью.
  • Попросите коллег о фидбеке. Если они отказываются, то попросите тимлида собрать о вас фидбек.
  • Интересуйтесь мнением других людей — иногда это открывает совершенно новые перспективы.

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

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

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

А вы — суперпрограммист?

Содержание статьи показалось очевидным? Отлично — вероятно это означает, что вы прекрасный разработчик.

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

Пройдитесь еще раз по всем пунктам, прочтите мою предыдущую статью, и честно ответьте себе, делаете ли вы всё как надо. Если да — поздравляю! Если нет — не переживайте, всё придет со временем, просто делайте свою работу. Успехов!

Полный текст статьи читайте на Нетология