Как перестать бесить коллег-разработчиков

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

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

Беспорядок в работе

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

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

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

«Без мастерства вдохновение — всего лишь сухой тростник, трясущийся на ветру», — Иоганнес Брамс, немецкий композитор и пианист

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

Неуважение к чужому времени

Некоторые разработчики всё время опаздывают на совещания. Конечно, время от времени опаздывают все, но постоянно — только те, кто делает осознанный выбор.

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

Общее потраченное время — n*(t1+t2), где

n — количество людей;

t1 — время опоздания;

t2 — время, потраченное на пересказ.

Простой сценарий:

В команде шесть разработчиков. Один опаздывает на 10 минут. Команда тратит 5 минут, чтобы ввести его в курс дела. Общее потраченное время — 6*(10+5). Полтора часа впустую.

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

Игнорирование не связанных с кодом аспектов

Иногда можно услышать что-то вроде: «Мой интерфейс ужасен, потому что я не дизайнер». Согласитесь, полная ерунда. Кодинг — всего лишь одна из сфер ответственности. Быть хорошим разработчиком — это, прежде всего, внимательно относиться к своей работе. Стоит обращать внимание на такие вещи, как UX, архитектура и бизнес-стратегия.

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

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

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

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

Поиск оправданий вместо решений

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

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

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

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

Полемика о неизвестном вместо решения проблемы

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

«Истина всегда заключается в простоте, а отнюдь не в преумножении и усложнении вещей», — Исаак Ньютон, умный парень

В разработке ПО специалистам приходится сталкиваться как с техническими, так и с нетехническими проблемами.

Работая в сфере точных наук, мы привыкли к роскоши разделения всего на чёрное и белое. Любые разногласия решаются тестированием кода в «песочнице» или запуском определённой части программы, чтобы проверить ход её выполнения.

Во всех остальных вопросах помогает чтение документации, обращение к экспертам или банальный поиск в Google.

Постоянные жалобы и аура негатива

Есть много позитивно настроенных разработчиков, с которыми приятно работать. Но есть и такие, сотрудничать с которыми — сплошное мучение. Негатив заразен. Если кто-то жалуется, фокус смещается в сторону негатива. Рано или поздно это настроение передаётся другим.

«Негатив — враг креатива», — Дэвид Линч, режиссёр

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

Болтовня на совещаниях

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

Прямолинейность при общении порой творит чудеса. Это позволяет лучше понять друг друга и ситуацию.

Типичный случай, когда разработчик начинает разговаривать со специалистами из других областей на своём профессиональном жаргоне. Иногда тот же дизайнер кивает в ответ фронтендеру, который разглагольствует о JavaScript. Что угодно, лишь бы он замолчал…

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

Присвоение чужих заслуг

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

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

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

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

Поэтому нужно понимать, когда стоит присвоить, а когда — признать успех.

В заключение

Процесс самосовершенствования разработчика — постоянный и почти не прекращающийся труд. Иногда стоит сделать паузу, оглянуться назад и подумать о проделанной работе. Искусство профессиональной саморефлексии помогает придерживаться верного курса. А самосовершенствование, в конечном счёте, позволяет продолжать получать удовольствие от того, что мы создаём.