Решение проблем для разработчиков нового программного обеспечения

Как развитие индивидуального подхода может повысить ваше влияние

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

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

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

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

Программирование - это командный вид спорта

Оглянись. Сотрудничают ли опытные разработчики? На протяжении своей карьеры я работал в таких компаниях, как IBM, Blackberry, Shopify, а теперь и в Lever. Я наблюдал и практиковал множество способов проведения мозгового штурма и проверки идей. Они варьируются от совместной деятельности команды, такой как парное программирование, интерактивная доска и мозговые штурмы в Slack, а также комментарии по проблемам и запросы на вытягивание (PR), до более формальных процессов большой компании, таких как обзоры технических проектов и комиссии по обзору архитектуры.

Получите обратную связь заранее и часто

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

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

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

Определите партнера заранее

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

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

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

Progress! = Написание кода

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

Подчеркните свой прогресс, используя новые методы

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

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

Определите лучшие инструменты для отслеживания прогресса на каждом этапе.

Документирование = общение = сотрудничество

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

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

Проверяйте рано и часто

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

«Пятиминутный разговор на раннем этапе может сэкономить вам часы на переписывание позже».
- DJ Houghton

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

Понять проблему

Вам поставили задачу - отлично! Первый шаг - понять проблему. Есть ли несколько способов решить эту проблему? Часто на этом этапе вашей карьеры задача подскажет вам, каков именно ожидаемый результат. Может быть, там даже будут скриншоты. Однако никто не знает, что вы обнаружите, когда начнете работать над решением, поэтому не ожидайте, что оно всегда будет работать именно так, как вас просили.

«Почему» перед «Что»

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

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

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

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

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

Настройте свою среду

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

Подтвердите свое мышление

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

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

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

Возможно, самое главное, вы добились заметного прогресса (не только в написании кода). Что-то праздновать!

Определите свой подход

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

Создавайте альтернативы

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

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

«Для меня было важным понять, что у меня есть возможность / сила сформировать мнение и отстаивать тот подход, который я считаю лучшим! Раньше я предлагал несколько подходов, но ждал, пока мой наставник скажет мне, какой путь выбрать. Я должен был понять, что можно сформировать мнение, чтобы сделать предложение, даже если оно в конечном итоге не станет избранным. Это учится! " - Стефани Вонг

Совсем недавно я предложил этот подход тому, кто только начал со мной работать. На следующий день у нее была запланирована еженедельная сессия парного программирования со своим техническим руководителем. Она подготовила свой список подходов, плюсов и минусов, а также мнение, из которых следует выбрать. Позже технический руководитель сообщил мне, что это был самый продуктивный сеанс парного программирования, который у них был. Когда я попросил мой новый отчет поразмышлять над этим, она сказала следующее: «Мне всегда говорили готовиться к сеансам парного программирования, но никто никогда не объяснял, как может выглядеть подготовленное».

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

Сломай

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

Держите это маленьким

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

Сделайте это тестируемым

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

Разбейте это дальше

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

Собираем все вместе: рабочий процесс успешного инженера

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

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