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

1656546493 ne budte razrabotchikom programmnogo obespecheniya s kotorym vy ne mozhete

от Брюса Флоу

V2SZVjq5q2lBffW-LIvCGbhLsB8Oj7uUFTYr
Фото: Kobu Agency на Unsplash

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

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

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

И есть разработчики, которые меня очень раздражают.

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

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

Имея неаккуратное мастерство

Вы знаете этого разработчика. Тот разработчик, который называет переменные, имеет опечатки в названиях функций и оставляет остатки старых комментариев в коде. Разработчик, который не может запустить форматировщик кода, несмотря на то, что ему сказали 5 раз. Разработчик, игнорирующий проблемы с ворсинками, даже когда IDE кричит на них.

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

Еще хуже, что неадекватное отношение увеличивает шансы на ошибки в программном обеспечении. Исправление ошибок стоит денег и времени.

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

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

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

«Без мастерства вдохновения является просто тростником, расшатанным ветром»

— Иоганнес Брамс, немецкий пианист и композитор

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

Неуважительное отношение ко времени других

Есть тот разработчик, который постоянно опаздывает на встрече. Каждый время от времени опаздывает. Но опаздывать всегда – это выбор.

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

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

Total time waste = n x (t1 + t2)

n = number of people

t1 = time late to meeting

t2 = time wasted bring the developer up to speed

Пример сценария:

В команде шесть разработчиков. Один разработчик опаздывает на 10 минут. Команда занимает 5 минут, чтобы привести их к скорости. Общая потеря времени составит 6x(10+5) минут. В общей сложности это было бы потеряно 90 минут.

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

Пунктуальность – это отношение.

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

Пренебрежение некодовыми аспектами работы

Иногда я слышу, как разработчик говорит: «Интерфейс, который я создал, безобразен, потому что я не дизайнер». Это заставляет меня перейти в режим Халко и перевернуть свой стол.

Кодирование – это только одна из обязанностей разработчика.

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

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

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

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

Наличие целостного представления о вещах позволит нам лучше понять другие роли.

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

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

Говорить об оправдании вместо решений

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

Типичными оправданиями являются ограничение времени, недостаточные знания или сложность задачи.

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

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

Это имеет много преимуществ:

  • Дает команде лучший шанс предложить помощь или решение
  • Позволяет команде изучить проблему
  • Предоставляет лучшую картину хода выполнения задания

Мы делаем разговоры о решениях. Мы ведь инженеры. Инженеры решают проблемы.

Философия о неизвестном вместо того, чтобы выяснить проблему

Во многих случаях коллеги спорят о технических темах на основе своих мнений. Мнения, не подтвержденные никакими фактами.

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

«Истину всегда можно найти в простоте, а не в множественности и путанице вещей».

– Исаак Ньютон, умный чувак

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

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

Нетехнические вопросы разрешаются путем чтения документации, вопросов у экспертов или поиска в Google.

Жаловаться и иметь ауру негатива

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

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

«Негатив – враг творчества».

— Дэвид Линч, режиссер

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

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

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

Бродит на встречах

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

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

Во время общения переход непосредственно к делу творит чудеса. Коллеги лучше поймут нас и ситуацию.

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

Знать, с кем вы разговариваете, и говорить на их жаргоне – это здравый смысл. Иногда здравый смысл не бывает обычным.

Украсть кредит для себя

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

Чаще это сообщается коварным, непростым способом. Записи о получении кредитов разумно намеканы.

Такие стратегии могут обеспечить краткосрочную видимость этого лица.

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

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

Есть много способов предоставить кредит. Можно упомянуть вклад коллеги во время Daily Scrum. Мы можем поблагодарить коллегу по электронной почте и скопировать их руководителя.

Предоставление надлежащего кредита имеет множество преимуществ:

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

Итак, давайте знать, когда отдать или взять кредит.

Вывод

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

Будем разработчиком программного обеспечения, с которым мы любим работать.

Добавить комментарий

Ваш адрес email не будет опубликован.