Разработчик — это программист, экстрасенс и антрополог: иногда ему лучше не писать код и ненавидеть свой продукт Статьи редакции

За 20 лет в техотрасли инженер Джастин Этередж усвоил несколько уроков: не всем нужны «гибкие» методологии и инновации, единственно верного решения не существует, долгие исследования приводят к аналитическому параличу и что хотеть в отпуск не значит не хотеть работать.

Инженер-разработчик Джастин Этередж в техиндустрии уже 20 лет: сперва он работал в небольших проектах и стартапах, а затем занялся консалтингом и попробовал свои силы в крупных компаниях. В 2021 году он руководит продуктовым агентством Simple Thread, в котором когда-то трудились два человека, а теперь — 25.

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

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

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

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

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

Автор языка программирования C++ Бьёрн Страуструп говорил, что есть только два вида языков: «те, на которые все жалуются, и те, что никто не использует». Такую же логику можно применить к разработке, считает Этередж.

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

Разработчик должен всегда подвергать сомнению предположения команды и привычные для неё подходы — даже если они «уже сто лет работают». Помочь в этом могут и новые сотрудники: иногда вопросы, которые они задают, и проблемы, с которыми сталкиваются, указывают на недостатки в существующих системах.

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

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

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

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

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

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

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

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

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

О гибкости в 2020-х говорят практически все компании, но «быть гибким» — это прежде всего пробовать что-то новое постепенно. Это необходимо, чтобы экономить время, деньги и силы, и с лёгкостью начинать заново, если не получилось. Всё остальное — маркетинговые истории, считает Этередж.

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

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

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

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

Мысли инженера нашли отклик у пользователей Reddit:

• «Если у сотрудника есть мнение относительно технологии, значит, он уже работал с её альтернативами. Я, например, ненавижу Oracle. Причин у меня много, но основная одна: я знаю, на что способны другие реляционные системы управления базами данных, так что Oracle на их фоне — дрянь».
• «Обидно, когда коллеги приравнивают вопросы к непониманию. Недавно на меня пожаловалась младшая сотрудница: ей надоело разжевывать для меня работу каждого системного элемента. Она решила, что я ничего не смыслю, а мне лишь хотелось добиться ответа — почему инструмент решили разработать именно так, а не иначе. Причём чтобы она же сама поняла, как его можно улучшить».
• «Задача инженера — принести пользу клиенту, а не написать код. Так я говорю половине своих подопечных, когда слышу, что они не хотят заниматься документацией или что обновлять Jira — это глупость».
• «За 40 лет работы я усвоил один важнейший урок: ПО — это социальный сервис, созданный для человека».

#разработка #программирование #разработчики