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

Будьте добры для себя, своей карьеры и других

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

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

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

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

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

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

Раздражение # 1: небрежное мастерство

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

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

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

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

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

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

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

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

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

Раздражение №2: неуважительно относиться к чужому времени.

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

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

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

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 минут. Команде нужно пять минут, чтобы они разобрались. Общая потеря времени составит 6x (10 + 5) минут. В общей сложности это будет потрачено зря 90 минут.

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

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

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

Раздражение # 3: игнорирование некодовых аспектов работы

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

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

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

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

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

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

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

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

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

Раздражение №4: Говорить об оправданиях вместо решений

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

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

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

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

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

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

Мы говорим о решениях. В конце концов, мы инженеры. Инженеры решают проблемы.

Раздражение # 5: философствовать о неизвестном вместо того, чтобы выяснять проблему

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

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

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

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

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

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

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

Раздражение № 6: жалобы и аура негатива.

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

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

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

- Дэвид Линч, кинорежиссер

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

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

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

Раздражение # 7: бессвязность на собраниях

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

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

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

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

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

Раздражение № 8: Кража уважения к себе

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

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

Такие стратегии могут сделать этого человека заметным в краткосрочной перспективе.

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

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

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

Есть бесчисленное множество преимуществ должной заслуги:

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

Таким образом, давайте знать, когда отдавать или принимать кредит.

Заключение

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

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

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