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

После примерно десяти лет коммерческой разработки я стал заметно больше ценить soft skills. Особенно после работы техлидом. Но когда начал вспоминать конкретные истории, формулировка «soft skills важнее hard skills» перестала мне нравиться.

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

Я увидел сложность, но сегодня начал бы разговор иначе

Когда я был Tech Lead, нашей команде предложили серьёзно переделать планшет заготовок для пиццерий. Хотели обновить UI и изменить сам подход к подготовке ингредиентов: система должна была выдавать сотрудникам задания, что приготовить и в каком объёме.

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

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

Отдельно хотели подключить весы: человек ставит на них продукт, а показания сразу попадают в систему. Без ручного ввода цифр.

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

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

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

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

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

Я не считаю, что коллега своим ответом обязательно что-то пообещал. Моя первая реакция была резкой, и сегодня я бы её поменял.

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

Для меня здесь и проявилась отдельная часть работы лида. Я мог видеть риск, но от того, как я его обсуждал, зависело восприятие моих аргументов. Сам факт, что я предупредил о сложности, ещё не означал, что у нас появилось общее понимание объёма и сроков.

Простой вебхук потребовал нескольких технических договорённостей

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

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

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

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

С выбором базы тоже не было мгновенного согласия. Архитектор предлагал рассмотреть DynamoDB или MongoDB: входящие данные представляли собой JSON. DevOps считали PostgreSQL допустимым вариантом. Мы выбрали PostgreSQL. Сейчас на ежемесячных встречах возвращаемся к вопросу, всё ли нормально работает.

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

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

Сама запись данных была только частью задачи. Нужно было учесть ограничения компании и обсудить аргументы коллег. Причём аргументы тоже были техническими. Их нельзя было заменить общим умением поддержать разговор.

Мне нужно было участвовать в обсуждении, а после выбора продолжать отвечать за результат. На этом примере мне сложно провести аккуратную границу между hard и soft skills: понимание решения и способность его согласовать понадобились одновременно.

Иногда техническая часть готова, а продолжения у неё нет

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

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

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

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

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

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

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

Даже заданный вопрос не гарантирует общего понимания

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

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

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

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

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

AI изменил мою работу, но не отменил техническую подготовку

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

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

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

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

Я не хочу записывать в soft skills всё, что происходит за пределами редактора кода. Оценка риска в алгоритме и выбор архитектуры требуют технического опыта. А обсуждение этой оценки с людьми добавляет к нему другую работу.

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

Если вам близки такие темы, я пишу о них в Telegram-канале «Разработчик без хайпа»