Пару недель назад я опубликовал Часть 1 простых вещей, которые могут сделать вас лучшим разработчиком. А теперь перейдем ко второй части.
Разберитесь в проблеме, прежде чем ее решать
Я знаю, это звучит очень очевидно, но поверьте мне, это происходит не так часто, как мы думаем. Несмотря на то, что существует множество факторов, способствующих возникновению этой проблемы, основными из них являются: «культура выполнения задач как можно скорее» и «задачи, сфокусированные на выполнении, а не на проблеме».
В культуре ASAP людей соблазняют сосредоточиться на нехватке времени, забывая при этом самое важное - решение. Это дает бессознательное представление о том, что лучше сделать что-то быстро, чем что-то, что решит проблему.
Что касается неправильного фокуса, давайте представим два описания задачи: «Обновить БД до самой последней версии» или «Разрешить пользователям использовать самые последние синтаксисы запросов через БД». Последний фактически информирует о проблеме и, как следствие, дает возможность ответственному лицу подумать о наилучшем решении. Вместо того, чтобы покупать новую версию БД и устанавливать ее на компьютерах каждой компании, можно просто установить патч, который все равно решит проблему за меньшее время и с меньшими затратами.
Вы можете подумать, что разработчик не виноват, если задача плохо описана. Напротив, независимо от ситуации, лицо, ответственное за реализацию решения, должно убедиться, что понимает проблему, которую пытается решить. Если непонятно, спросите.
При таком подходе исполнитель задачи сможет:
- Предложите лучшее решение.
- Подумайте о разных пользовательских кейсах.
- Предложите более быстрое или более эффективное решение.
- Сообщите лицу, поднявшему проблему, если уже что-то реализовано (только другим способом), что может решить проблему.
Никогда не говорите «Так было всегда»
Рассмотрим такой сценарий: Пол начинает новую работу, а менеджер делает все возможное, чтобы нынешний заменяемый сотрудник делился с Полом всем, что он знает. Таким образом, Пол сможет продолжить разработку и поддержку проекта самостоятельно. Через неделю сотрудник поделился всем, что знает, предоставил надлежащее руководство по своей повседневной деятельности (включая сценарий, который он вручную выполняет каждый месяц) и уходит из компании. Теперь главный - Пол.
Через полгода менеджер ищет помощи и спрашивает Пола, над чем он сейчас работает. Пол отвечает, что он запускает ежемесячный сценарий проекта, и менеджер спрашивает: «Почему?».
Павел отвечает, что «так было всегда», что будет правильным, если мы примем во внимание, что он делал только то, о чем его просили. Однако из-за того, что он проигнорировал влияние задачи на бизнес или почему он это делал, ответ неверен. Чтобы этого избежать, важно проявлять любознательность и понимать, почему дела обстоят именно так. Возможно, 2 года назад было принято решение запустить скрипт вручную из-за нехватки времени, но ожидалось, что в какой-то момент он будет автоматизирован. Возможно, это было временное решение для другой команды, и оно больше не требуется. Дело в том, что вы никогда не узнаете, пока не перестанете использовать этот ответ и не начнете задавать правильные вопросы.
Не отслеживаю
Вы, наверное, слышали, что «отсутствие новостей - это хорошие новости», но поверьте мне, люди могут скулить за вашей спиной, обвиняя вас в том, что вы не доставили что-то вовремя, или говорили, что последнее задание, над которым вы работали, не полностью решено. Поскольку мы принимаем вещи как должное, после доставки чего-то мы обычно думаем, что все работает нормально, однако человеку, которому нужно исправление, может показаться, что вы знаете, что оно все еще не работает. Как это исправить? Просто отслеживая. Единственный способ убедиться, что ваш молчаливый коллега доволен или удовлетворен вашим последним решением, - это напрямую спросить его.
Обычно этим должен заниматься менеджер проекта или мастер скрам, однако люди делают ошибки, и мне не нужно объяснять, как вас будут рассматривать как лучшего разработчика, если вы проявите инициативу в «последующих действиях». Кроме того, заинтересованные стороны оценят вашу заботу о том, чтобы их проблемы были решены.
Не изменять собственный код
У меня есть два основных правила относительно отправки электронного письма: 1. Никогда не отправляйте его в пылу эмоций. 2. Всегда перечитывайте это. Дело в том, что я обычно в конечном итоге вношу некоторые изменения, так как чтение собственного электронного письма ставит меня на место человека, который его получит.
Когда дело доходит до кодирования, разницы нет. Вы помните то время, когда смотрели на свой собственный код и не могли его понять? Возможно, этого бы не произошло, если бы вы просто снова прочитали свой код перед фиксацией. Вот список некоторых других преимуществ перепроверки собственного кода:
- Убедитесь, что ваш код будет понятен, если кто-то еще попытается его исправить.
- Буквально рефакторинг.
- Исправьте ошибку или опечатку.
- Вспомните другой случай пользователя и улучшите свое решение.
- Улучшите производительность или архитектуру.
Если это звучит как что-то слишком сложное, я предлагаю спланировать ревизию перед фиксацией или ревизию в различии перед созданием запроса на вытягивание. Делайте это так, как будто вы редактируете чужой код.
Станьте владельцем
Представьте себе сценарий, в котором вы только что завели новую собаку, и все остальные в вашем доме ухаживают за ней, кроме вас. Звучит честно? Если нет, то почему ваш код отличается? Такое поведение со своим кодом создает впечатление, что вам все равно. Вы должны понимать, что приобретение права собственности не только поможет бизнесу, но и создаст вам хороший профессиональный имидж. Вот некоторые действия того, кто действительно берет на себя ответственность:
- Пишите код, думая, что если что-то пойдет не так, вы обязаны исправить это. Хотя может и не быть.
- Если кто-то берет на себя задачу, убедитесь, что она все еще находится под вашим контролем. Не позволяйте ему теряться только потому, что его переназначили другим людям.
- Убедитесь, что он хорошо задокументирован, а код написан так, чтобы вы чувствовали гордость, взяв на себя управление проектом.
- Убедитесь, что вы сообщили и зарегистрировали все события, которые произошли в течение жизненного цикла задачи / проекта. Если кто-то полностью вне проекта проверит задачи, сможет ли он понять все принятые решения и сделанные изменения?
Это выглядит довольно просто, правда? Давайте посмотрим на некоторые проблемы, которые возникают, когда никто не берет на себя ответственность:
- Сложно отследить статус задачи, из-за чего в команде возникает куча вопросов.
- Существует множество ошибок, архитектурных проблем и сбоев инфраструктуры, потому что никто не заботился о том, чтобы правильно разработать задачу.
- Задачи теряются, пока об этом не попросит кто-то из другого отдела. Затем мы возвращаемся к первому этапу, пытаясь выяснить все, что связано с задачей.
- Она назначается каждому в команде, но никогда не решается. Вы можете не решить эту проблему самостоятельно, но когда вы берете на себя ответственность, вы заботитесь о ком-то, кто может помочь вам исправить это.
Заключение
Читая этот список, возможно, вы почувствовали, что именно этим должен заниматься каждый в своей повседневной профессиональной деятельности. К сожалению, это не так. Разработчикам легко сосредоточиться на методах кодирования, но при этом забыть о некоторых взглядах и подходах, которые могут иметь решающее значение. Реальность такова, что многие вещи, которые определяют хорошего программиста, напрямую не связаны с кодом. В результате эти простые привычки могут стать небольшим изменением, которое поможет вам улучшить положение разработчика.
