Как стать суперпрограммистом?
Светлана Шаповалова, коммерческий автор и переводчик, перевела еще одну статью Kamil Wysocki о том, как стать не просто хорошим, а суперским разработчиком, и что для этого нужно.
В предыдущей статье мы рассказали о двух важных характеристиках хорошего разработчика: качество кода и его ожидаемое поведение.
Теперь разберемся еще с двумя: соблюдением сроков и общительностью. Жаль, но эти качества встречаются у программистов не так уж часто, даже у ведущих. Но каждый разработчик должен знать, насколько это важно!
Соблюдение сроков
Опыт показывает, что это уложиться в срок — это самая трудная часть работы.
При этом она же чуть ли не самая важная. Беда в том, что большинство разработчиков легко теряются во времени и пространстве, почти как Карл Саган.
Прим. перев.: Карл Саган — астроном, астрофизик и выдающийся популяризатор науки.
Вероятно, вы знакомы с ребятами…
- …которые даже после шестого совещания не могут предложить подходящее решение задачи;
- …которые на вопрос о работе «Как продвигается?» отвечают «В процессе!», хотя сами уже несколько часов залипают над каким-нибудь крохотным случайным вопросом;
- …которые несколько дней проводят исследование, а потом понимают, что исследуемый объект изначально не работает;
- …которые находят в коде что-нибудь на их взгляд странное и потом тратят кучу времени, исправляя надуманную проблему.
Всё это не так уж плохо — эти парни определенно любознательны, настойчивы и любят свое дело. В профессии без этого никуда. Однако надо стараться контролировать такое поведение.
Я знаю, о чем вы подумали: «Окей, вижу, куда ты клонишь: пока я теряю время, компания теряет деньги». И да, и нет. Конечно, иногда компания напрямую теряет прибыль из-за задержек, однако, что более важно — растраченное на пустяки время влияет на самого разработчика.
Вы когда-нибудь встречали велосипедиста, который бы стал первоклассным спортсменом, лишь размышляя и читая о велоспорте? Вероятно, что нет. Без сомнения, он читал о теории и даже, возможно, имел наставника. Однако этим не ограничился: он влез на велосипед и стал тренироваться. Как раз это и ведет к успеху.
Первое, что необходимо понять, если вы еще не поняли: навыки и опыт растут благодаря практике, а не размышлениям. Я не прошу забросить рабочие исследования — я лишь прошу заниматься ими обоснованно.
Сделайте базовый обзор темы, соберите нужную информацию, подготовьте ресурсы для запуска — и действуйте. Нет смысла перечитывать всю документацию по API просто для того, чтобы установить соединение. Всегда что-нибудь, да пойдет не так.
Заранее предугадать не получится — поэтому не переживайте на этот счет и просто работайте. Конечно, если вдруг задача совсем невыполнима, то об этом надо знать. Это, кстати, аргумент в пользу проведения сессий планирования и присутствия в команде архитектора ПО.
Так, с этим разобрались. Но что насчет влияния, о котором я упомянул? Приведу пример. Скажем, вам надо провести исследование. При этом есть два возможных подхода:
- за 1 день получить общее понимание задачи и начать кодить;
- 5 дней вчитываться в документацию.
Выбирая первый из них, вы глубоко погружаетесь в задачу. Примерно на второй день вы столкнетесь с первыми проблемами, которые, скорее всего, разрешите к третьему дню работы. Четвертый и пятый уйдут на мелкие улучшения и общее совершенствование продукта. Грубо говоря, это значит, что вы почти неделю приобретали новый опыт — чего не случилось бы, решись вы 5 дней читать документацию. Это правило называется «быстрее ошибешься — быстрее справишься», и оно очень полезно для развития профессиональных навыков.
То же относится к бесконечным обсуждениям инструментов разработки, подходов и возможных решений: просто спросите себя, стоит ли оно потраченного времени. Если не уверены, значит точно нет, не стоит. Посоветуйтесь с кем-нибудь более опытным, чтобы определиться наверняка.
Кроме того, растрата времени влияет на положение в компании. Буду честен, если проблемы просто обдумывать, а не решать, то очень скоро люди станут иначе воспринимать и вас, и вашу работу. В долгосрочной перспективе это может оказаться невыгодным. Если вам нельзя будет доверить задания, которые требуют активных действий, знаний системы или навыков разрешения проблем, то разочарование будет взаимным.
Вывод: действуйте сразу же. Так вы получите больше опыта, решите задачу и все будут довольны.
Общение
Иллюстрация: Karol Podleśny
Общение — это выдающийся инструмент для решения проблем, который к тому же поможет освоить предыдущие три достоинства. Доказательства? Давайте представим такие ситуации:
- Не уверены, стоит ли дальше совершенствовать код или уже хватит? А если продолжать, то как? Спросите коллегу и лучше более опытного. Так вы узнаете, достаточно ли хорош код и убережете себя от улучшения того, что и так отлично работает. Если же что-то не так, то получите совет или, на крайний случай, узнаете, к кому дальше можно обратиться.
- Необходимо проверить, правильно ли работает разработанная вами функция? Обратитесь к тестировщику. Обычно тестировщик лучше знает устройство разрабатываемой системы и подскажет, какое воздействие на неё может оказать ваша функция, и где может скрываться подвох.
- Не уверены, что сможете выполнить задачу? Спросите архитектора или посовещайтесь с коллегами. Их опыт и знания помогут прояснить ситуацию.
Говорите с людьми. Выключите на полчаса корпоративный мессенджер и прогуляйтесь по офису, чтобы поболтать с коллегами. Вы удивитесь, как много всего интересного существует вне компьютера.
Вот несколько советов из моего личного опыта:
- Общением можно решить любую проблему. Правда, умение находить нужного собеседника приходит с опытом. И да, реально круто временами отвлекаться от непрерывного кодинга.
- Не бойтесь чего-то не знать. Людям это свойственно. Тем более, так вы покажете, что осознаете пределы своих умений, и что вы партнер, а не мудак.
- Застряли над чем-то? Воспользуйтесь правилом 30/60 — если не получается решить легкую задачу за 30 минут, а сложную — за 60, то пора обращаться за помощью.
- Попросите коллег о фидбеке. Если они отказываются, то попросите тимлида собрать о вас фидбек.
- Интересуйтесь мнением других людей — иногда это открывает совершенно новые перспективы.
Не всякому дано быть душой компании, да это и не нужно. Общаться — не значит приставать к каждому в офисе с разговорами. Это значит не бояться работать в команде, разговаривать с коллегами и высказывать свое мнение. Общение экономит время, укрепляет связи и помогает развиваться еще быстрее.
Общительный разработчик — это разработчик, который может справиться с любой задачей, и не важно, один или с помощью коллег.
Именно поэтому компании в курсе, что обычно навык общения хорошо развит у людей дела.
А вы — суперпрограммист?
Содержание статьи показалось очевидным? Отлично — вероятно это означает, что вы прекрасный разработчик.
Вы удивитесь, узнав, у скольки реально крутых программистов есть трудности с общением или соблюдением сроков.
Аналогично: масса джунов путается в вопросах качества кода и тратит слишком много времени на бесполезную деятельность.
Пройдитесь еще раз по всем пунктам, прочтите мою предыдущую статью, и честно ответьте себе, делаете ли вы всё как надо. Если да — поздравляю! Если нет — не переживайте, всё придет со временем, просто делайте свою работу. Успехов!
Полный текст статьи читайте на Нетология
