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

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

Selleo

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

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

ПО — инструмент от человека для человека

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

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

Лучший код — его отсутствие

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

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

Синдром неприятия чужой разработки — позиция, при которой инженер не хочет принимать чужие идеи и вместо этого тратит время на «переизобретение» того, что уже существует.

Меньше разговоров – больше дела

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

Разработчик узнает больше, если начнёт искать решения на практике — только так он и найдёт лучшее. Если в команде есть склонность к излишнему анализу, то ей следует установить сроки: к решению не пришли — переходим к действию.

Идеала не существует

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

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

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

Вопросов много не бывает

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

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

Лучше сторониться низкой эффективности, чем бежать за высокой

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

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

Поэтому лучше сосредоточиться на том, чтобы не нанимать низкоэффективных сотрудников — тех, что сделают всего 10% от среднестатистической нормы: они не просят обратной связи, не тестируют код, не учитывают пограничные кейсы и попросту тратят ресурсы компании.

Инновации не так уж нужны

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

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

Ненависть к продукту лучше безразличия

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

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

Порядок в памяти — порядок в будущем

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

Старый не значит устаревший

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

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

Скромный не значит несведущий

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

Чем больше инженер пишет, тем эффективнее коммуникация

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

Гибкость — понятие субъективное

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

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

Результат принадлежит разработчикам

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

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

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

На собеседовании нужно получше узнать самого человека

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

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

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

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

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

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

Что-то у этого чела разработчик дюже дофига всем всего должен. В статье на него переложены задачи PM, PO, UX техрайтера и чуть ли не маркетолога - зачем такому монстру вообще на кого-то работать?

Ответить
Развернуть ветку
Денис Демидов

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

Ответить
Развернуть ветку
Хозяин

Согласен с вами. Это была ирония с моей стороны что такой человек-оркестр и инвестора пропитчит - получит финансирование, и маркет фит найдёт, да ещё и закодит всё сам.

Ответить
Развернуть ветку
Rick

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

Ответить
Развернуть ветку
Павел Бойченко

Верные формулировки.

Ответить
Развернуть ветку
Mercator

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

Ответить
Развернуть ветку
Иван Крючков

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

Ответить
Развернуть ветку
Алексей Коньшин

Понимание ценности продукта приходит с опытом и говорит о зрелости разработчика.

Ответить
Развернуть ветку
Mercator

Или не приходит.

Ответить
Развернуть ветку
Алексей Коньшин

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

Ответить
Развернуть ветку
Александр Помидоров

Это разрабы без своих собственных проектов.

Ответить
Развернуть ветку
Дмитрий Богданов

какой-то цитатник кэпа

Ответить
Развернуть ветку
Жесткий лолипоп

Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда, когда нечего убрать.

Ответить
Развернуть ветку
Иван С.

Многие моменты нашли отклик, согласен со многим. Было интересно прочитать, спасибо)

Ответить
Развернуть ветку
Eugeneer

Как человек с 20 лет с опытом коммерческой разработки, а у меня откола 5000 клиентов. Могу сказать что в этой статье написано все от и до как есть!!!

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Nice Man

Ньюби произносится. А ещё в русском есть слово новичок.

Ответить
Развернуть ветку
Igor Kalashnikov

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

С jQuery тоже самое, все зависит от обстоятельств.

Ответить
Развернуть ветку
Хозяин

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

На нашу Джиру клиенту точно насрать.

Ответить
Развернуть ветку
Mercator

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

Ответить
Развернуть ветку
Влад maizanin

500

Ответить
Развернуть ветку
Игорь Зозуля

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

Ответить
Развернуть ветку
Dmitry Rybakov

"я знаю, на что способны другие реляционные системы управления базами данных, так что Oracle на их фоне — дрянь"

Хаха, лучше оракла не видел ничего.

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

Примеры из практики

MySQL — это самая странная база. Таймаут по умолчанию 30 секунд. Если база разрастется, то в один прекрасный момент всё начнет отваливаться.

MSSQL — грязные чтения, блокировки

Ответить
Развернуть ветку
Читать все 23 комментария
null