Разработчик — это программист, экстрасенс и антрополог: иногда ему лучше не писать код и ненавидеть свой продукт Статьи редакции
За 20 лет в техотрасли инженер Джастин Этередж усвоил несколько уроков: не всем нужны «гибкие» методологии и инновации, единственно верного решения не существует, долгие исследования приводят к аналитическому параличу и что хотеть в отпуск не значит не хотеть работать.
Инженер-разработчик Джастин Этередж в техиндустрии уже 20 лет: сперва он работал в небольших проектах и стартапах, а затем занялся консалтингом и попробовал свои силы в крупных компаниях. В 2021 году он руководит продуктовым агентством Simple Thread, в котором когда-то трудились два человека, а теперь — 25.
Этередж считает, что знать всё невозможно и не все советы применимы для каждого. Однако за время работы он вынес уроки, которые, возможно, натолкнут на мысли как разработчиков, так и руководителей проектов.
ПО — инструмент от человека для человека
Инженер должен всегда помнить о том, зачем, кто и как будет использовать его продукт, будь то внешний API или клиентский интерфейс, и что может быть особенно важно для потребителя. Любой продукт должен решать конкретные задачи, а разработчик — создавать, а затем повышать его ценность.
Лучший код — его отсутствие
Во-первых, считает Этередж, не все решения в проекте должны упираться в код, как бы того ни хотелось разработчикам. «Я всё понимаю, такова природа человека: спроси программиста, как решить проблему, и он станет опираться на собственные навыки», — говорит инженер. Однако это не всегда так: просто порой нетехнический выход менее очевиден.
Во-вторых, разработчики нередко любят изобретать велосипед — даже когда у них уже есть готовые решения. У команды, безусловно, могут быть причины написать свой собственный код, но иногда она отказывается от сторонней системы просто потому, что страдает от синдрома неприятия чужой разработки.
Меньше разговоров – больше дела
Одни разработчики сразу начинают писать код, как только возникает проблема. Другие без конца её исследуют, что в результате приводит к аналитическому параличу: команда слишком старательно пытается найти идеальное решение и не действует, потому что боится ошибиться.
Идеала не существует
Автор языка программирования C++ Бьёрн Страуструп говорил, что есть только два вида языков: «те, на которые все жалуются, и те, что никто не использует». Такую же логику можно применить к разработке, считает Этередж.
Компании часто не могут правильно распределить бюджет, отказаться от ненужных функций и вовремя остановиться. В результате они раздувают масштаб разработки и забывают о главном — идеала не существует. По словам инженера, разработчик никогда не построит единственно верную архитектуру, не погасит технический долг и не разработает безукоризненный интерфейс.
Вопросов много не бывает
Разработчик должен всегда подвергать сомнению предположения команды и привычные для неё подходы — даже если они «уже сто лет работают». Помочь в этом могут и новые сотрудники: иногда вопросы, которые они задают, и проблемы, с которыми сталкиваются, указывают на недостатки в существующих системах.
А прежде чем браться за новую функцию, стоит разобраться, какие задачи она должна решать и кому нужна. Если пользователь, который о ней попросил, точного ответа не даёт, то разработчик должен сам задавать уточняющие вопросы — пока не поймёт.
Лучше сторониться низкой эффективности, чем бежать за высокой
Разработчики думают, что на рынке труда существуют чрезвычайно продуктивные инженеры, которые за один день могут создать то, что другие не менее компетентные и трудолюбивые сотрудники построили бы за две недели. Однако это всего лишь миф.
Инновации не так уж нужны
Представители индустрии много говорят об инновациях, хотя на самом деле чаще всего просто хотят больше заработать — и желательно недорогим способом. А пользователи тем временем не любят отказываться от привычек и переучиваться.
Если команда хочет внедрить принципиально новую разработку, то пускай изначально готовится к продолжительной негативной реакции, пишет Этередж. И если эта разработка действительно повысит ценность продукта, то, возможно, оно того стоит.
Ненависть к продукту лучше безразличия
По словам Этереджа, нет ничего страшнее старшего разработчика, который никак не относится к собственному инструменту и не знает, как подходить к разработке. Лучше высказать точку зрения, с которой остальные разработчики и начальство категорически не согласны, чем не иметь мнения в принципе, считает он.
Порядок в памяти — порядок в будущем
Данные, считает Этередж, надолго переживут кодовую базу проекта, поэтому их нужно постоянно упорядочивать и чистить. В противном случае компания в будущем не сможет на них опираться: в системе будет слишком много «грязных» данных — ненужных, неполных и неактуальных.
Старый не значит устаревший
Технология, которую проект использует даже спустя годы, — это не пережиток прошлого и «динозавр», а «акула»: ей удалось выжить в постоянно изменяющемся мире технологий, и не потерять ценность. Заменять такие разработки нужно только при наличии веской причины.
Скромный не значит несведущий
Разработчик может молчать не потому, что ему нечего сказать, как считают некоторые начальники, пишет Этередж. Просто многие инженеры-программисты высказываются, лишь когда их об этом попросят. А тех сотрудников, что говорят слишком часто и слишком много, обычно слушать не хочет никто. Поэтому руководителям стоит чаще общаться со всем отделом.
Чем больше инженер пишет, тем эффективнее коммуникация
Разработчики, считает Этередж, должны регулярно оттачивать навыки письменной коммуникации: вести журналы, обновлять документацию. Так они не только лучше вникают в проблемы и доносят их до команды, но и упрощают жизнь самим себе, поскольку все данные они заранее задокументируют в системе.
Гибкость — понятие субъективное
О гибкости в 2020-х говорят практически все компании, но «быть гибким» — это прежде всего пробовать что-то новое постепенно. Это необходимо, чтобы экономить время, деньги и силы, и с лёгкостью начинать заново, если не получилось. Всё остальное — маркетинговые истории, считает Этередж.
Результат принадлежит разработчикам
Инженер хочет до последнего чувствовать себя причастным к продукту, а лишившись этого, он попросту потеряет интерес к работе, считает Этередж. Поэтому большинству разработчиков нравится контролировать процесс от начала до конца.
По этой же причине популярностью пользуется DevOps-подход: когда команда сама приносит ценность, строит, тестирует, автоматизирует и сама же отвечает за результат.
На собеседовании нужно получше узнать самого человека
Пытаться понять во время собеседования, как кандидат проявит себя в команде, — это пустая трата времени. Даже, казалось бы, опытный и хорошо осведомлённый специалист рискует не оправдать ожиданий: он может оказаться ненадёжным коллегой и высокомерным невежей, который постоянно опаздывает на встречи.
Так что во время собеседований начальство и рекрутеры должны прежде всего понять, что кандидат из себя представляет как человек и насколько он заинтересован в конкретной должности.
Мысли инженера нашли отклик у пользователей Reddit:
- «Если у сотрудника есть мнение относительно технологии, значит, он уже работал с её альтернативами. Я, например, ненавижу Oracle. Причин у меня много, но основная одна: я знаю, на что способны другие реляционные системы управления базами данных, так что Oracle на их фоне — дрянь».
- «Обидно, когда коллеги приравнивают вопросы к непониманию. Недавно на меня пожаловалась младшая сотрудница: ей надоело разжевывать для меня работу каждого системного элемента. Она решила, что я ничего не смыслю, а мне лишь хотелось добиться ответа — почему инструмент решили разработать именно так, а не иначе. Причём чтобы она же сама поняла, как его можно улучшить».
- «Задача инженера — принести пользу клиенту, а не написать код. Так я говорю половине своих подопечных, когда слышу, что они не хотят заниматься документацией или что обновлять Jira — это глупость».
- «За 40 лет работы я усвоил один важнейший урок: ПО — это социальный сервис, созданный для человека».
Что-то у этого чела разработчик дюже дофига всем всего должен. В статье на него переложены задачи PM, PO, UX техрайтера и чуть ли не маркетолога - зачем такому монстру вообще на кого-то работать?
Зачастую, что без наличия крупного капитала, эти люди не смогут реализовать и 10% своих навыков, это будет стрельба из пушки по воробьям с соответствующей финансовой отдачей.
Согласен с вами. Это была ирония с моей стороны что такой человек-оркестр и инвестора пропитчит - получит финансирование, и маркет фит найдёт, да ещё и закодит всё сам.
Комментарий недоступен
Верные формулировки.
Да многим разработчикам плевать на клиента. Для них разговор о ценности продукта для пользователя это то же самое, когда мама рассказывает, что нужно шапку надеть, чтобы уши не отпали - бла-бла-бла, она еще открывает рот или можно к Петьке в гости уже идти, без шапки, конечно.
Комментарий недоступен
Понимание ценности продукта приходит с опытом и говорит о зрелости разработчика.
Или не приходит.
И это тоже нормально, нужны не только разработчики, но и простые программисты, которые могут выполнить задачу в точности по ТЗ без необходимости выполнения какого-то анализа и поиска решения.
Это разрабы без своих собственных проектов.
какой-то цитатник кэпа
Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда, когда нечего убрать.
Многие моменты нашли отклик, согласен со многим. Было интересно прочитать, спасибо)
Как человек с 20 лет с опытом коммерческой разработки, а у меня откола 5000 клиентов. Могу сказать что в этой статье написано все от и до как есть!!!
Комментарий недоступен
Ньюби произносится. А ещё в русском есть слово новичок.
Вообще не факт, что опытный будет регулярки использовать. Зависит от условий задачи, например бюджета, или объема данных, или количества правил и т.п.
С jQuery тоже самое, все зависит от обстоятельств.
«Задача инженера — принести пользу клиенту, а не написать код. Так я говорю половине своих подопечных, когда слышу, что они не хотят заниматься документацией или что обновлять Jira — это глупость»
На нашу Джиру клиенту точно насрать.
Сложно приносить пользу клиенту, когда в Джире бардак. Наверняка тогда и во всем остальном бардак.
500
Принести пользу клиенту - это да, но клиент не всегда знает, чего он хочет, поэтому и приходится изобретать этакое
"я знаю, на что способны другие реляционные системы управления базами данных, так что Oracle на их фоне — дрянь"
Хаха, лучше оракла не видел ничего.
Остальные базы целостность данных плохо держат под нагрузкой. Оракл лучше всех это может делать. Меньше всего дэдлоков, и нет грязных чтений.
Примеры из практики
MySQL — это самая странная база. Таймаут по умолчанию 30 секунд. Если база разрастется, то в один прекрасный момент всё начнет отваливаться.
MSSQL — грязные чтения, блокировки