Разговор с ночным небом

Ночь. Рабочий день позади, понедельник подошёл к концу. Весь день разбазаривал интеллектуальную собственность за пару-тройку золотых. Мои потуги ничего не значат в масштабах вселенной. Кстати, как она? Пора навестить старую подругу.

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

Накинул кофту - и вот ковш Большой Медведицы уже над моей головой.

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

Вселенная! Сколько всего небесных объектов она нянчит в своих объятиях? Таких чисел я не знаю... Но знаю одно - с тех далеких краёв, откуда до нас ещё не дошёл свет, на меня тоже кто-то смотрит.

Кто он? Или оно? С чего мы вообще взяли, что наши местоимения им подходят?

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

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

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

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

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

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

В конце концов, ночное небо - прекрасный слушатель и крайне хреновый рассказчик... Как и я.

Как новенький сервис превращается в легаси помойку

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

1 шаг. Восторг и энтузиазм

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

2 шаг. Не хватает тяги

Наша ракета отлично стартанула. Вкушаем первые плоды переписанного сервиса. Радуемся. Но начинаются первые проблемы. Бесплатный пробный период хорошей жизни закончился - нагрузка начинает возвращаться обратно. В начале нам дали люфт. Но халява быстро кончилась — бизнесу снова понадобились фичи "на вчера". Вынуждены меньше фокусироваться на прекрасном будущем и всё больше концентрироваться на грустном настоящем. Начинаем активно поддерживать текущую версию сервиса и параллельно разрабатывать новую.

3 шаг. Кто же убийца?

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

4 шаг. Кто мы и откуда пришли

Энтузиазма поубавилось. Сервис уже переживает первые послабления в качестве в угоду скорости. Надо скорее дописывать MVP. Качество, структура и масштабируемость перестали быть приоритетом. Руководство уже и не помнит, зачем всё это затеяли. Сама идея становится всё более призрачной.

5 шаг. Мы не сеем, мы жнём

MVP готово. Переезжаем на наше новое детище. На старый сервис можно поставить печать [DEPRECATED] и убрать на задворки. Начинаем пользоваться и выполнять новые задачи уже там.

6 шаг. Мне кажется, мы здесь уже были

Через пару недель разработки появляется стойкое ощущение дежавю. Сервис вроде новый, построен аккуратнее. Но почему-то замечаются те же ошибки. Местами - те же подходы. Уже есть зоны кода, в которые никто не решается лезть. "Чёрные дыры" проекта. Да и багов меньше не стало. Мы же не сделали вторую версию такой же кривой, как первая? Мы же могли потратить время и ресурсы впустую? Ведь так?

7 шаг. Убийцей был дворецкий!

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

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

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

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

Четвертое - ретроспективу стоило провести до старта. Определиться какие ошибки были совершены в старом сервисе и учесть их в новом.

Может, дело во всех этих факторах сразу. Кто знает. Но итог мы видим: новый сервис довольно быстро начал повторять судьбу старого. Возможно, правильнее было есть слона по кусочкам - переписывать раздел за разделом в старом сервисе, интегрировать и тестировать на ходу, а не замахиваться на «новое идеальное» целиком.

Заметки в никуда

Ценность разработчика. Мысли о том самом…

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

Баланс между качеством и скоростью

Качество и скорость - это две противоположные крайности одного спектра.

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

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

Хороший разработчик должен быть посередине этого спектра. Каждое решение им принятое должно:

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

• иметь возможность базового масштабирования, без фанатизма, но с заделом на возможные изменения завтра

• учитывать временные рамки, воспринимая время как ограниченный ресурс

• работать с ограничениями, которые всегда есть, иначе легко сойти с намеченного плана

Продуктовое мышление

Хороший разработчик не ограничивается своим куском кода и клочком текста в ТЗ. Перед тем как приступить к задаче, важно выстроить полную картину. Зачем эта задача бизнесу? Кому это нужно? Какую боль пользователя решает? Чего это нам будет стоить? Иногда ответы на эти вопросы проясняют картину лучше, чем ТЗ от менеджера.

Спор "как правильно"

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

Предсказуемость

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

Работа с неопределенностью

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

Долгосрочность решений

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

Заметки в никуда. Подписаться

Как не сливать бюджет на разработчиков без задач?

Представим ситуацию. Большой аутсорс, 5 распределённых команд, у каждой обычно в работе по 1–3 проекта. Наступает момент, когда текущий проект сдан, а новый проект ещё не утверждён: документы в стадии подписания, а ТЗ ещё не сформировано. Команда разработчиков ждёт отмашки, возникает свободное время между проектами. Что делать? Бюджет утекает на разработчиков, которые ничем не заняты. Какой выход из ситуации, когда кончились задачи?

Я очень часто сталкиваюсь с этим кейсом, и по моему опыту есть решение. Если дать разработчику волю, он скорее свалит в кофейню, чем будет просиживать штаны, пока нет проекта или задач. Пустая трата ресурсов для вас обоих. Но из свободного времени можно извлечь выгоду как для команды, так и для самого разработчика - последний выиграет даже больше. Речь идёт об обучении. И я говорю не о курсах или конференциях. Лучшее обучение - это практика. В одной из команд мы сделали следующее. Каждому разработчику дали задание: описать свой пет-проект, который он хочет реализовать, и список технологий, которые он при этом прокачает.

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

Каждый рабочий день разработчики должны пилить свой пет-проект под флагом вашей компании и рассказывать о своём прогрессе и планах на дейлике. Тимлид в свою очередь должен контролировать их, проводить ревью и по возможности помогать и консультировать. Наша задача - дать возможность разработчику наконец-то реализовать свои идеи не после тяжёлого рабочего дня, а прямо тут, за деньги (его же ЗП). Полная свобода действий в плане развития и прокачки навыков.

Что мы в итоге имеем и в чём выгода?

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

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

Заметки в никуда

Гигачад на сцене, быдлокодер в опенспейсе

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

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

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

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

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

Заметки в никуда