Больше не работаю в ГдеМатериале

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

В разработке мы дошли до стадии, когда команда перестала во мне нуждаться — сильные разработчики, которые умеют общаться с бизнесом и не стесняются тратить время на исправление техдолга, вполне могут работать и без CTO. Вова, Дима, Леван, Лёша, Лёша, Никита — вы крутые, спасибо вам!

Ну а у меня впереди то же самое, что я сделал в ГдеМатериале, только умноженное на 10. Если вы хотите, чтобы мы с Саматом сделали в вашем бизнесе продуктовую разработку, которая внимательно слушает бизнес и не проёбывает дедлайны — пишите.

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

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

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

Важно ли вам будет через год, сколько заболевших коронавирусом найдут в России 18 марта? Или всё-таки вас будет волновать настроение, с которым вы проснётесь утром, количество денег на ваших счетах и отношения с близкими людьми?

Если второе — прямо сейчас перестаньте читать новости и займитесь делом.

​​Тесты снимают когнитивную нагрузку

Чтобы соответствовать бизнес-требованиям, нужно постоянно с ними сверяться (написал и почувствовал себя инфобизнесменом — покупайте мои курсы, кек).

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

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

У ребят с тестами все наоборот, спокойно: у них всегда на экране есть лампочка. Зелёная — все работает, красная — все сломалось. Конечно хорошие разработчики всегда ходят в пользовательский интерфейс, но только для того, чтобы увидеть картинку глазами пользователя.

А не чтобы убедиться, что не сломали все нафиг.

Сейчас очень горячие времена для всех служб доставки — люди сидят дома и делают в 2–5 раз больше заказов, чем обычно. Растёт нагрузка и на ИТ — всех этих юзеров нужно обслуживать: показывать сайты/каталоги/лендинги, принимать заказы, управлять курьерами. Уверен, пуканы горят не только у нас в iGooods — закрывались Окей и Утконос, вводят ограничения другие службы доставки.

Сегодня мы переменным успехом пролежали почти полдня. Сейчас заскейлились с пятикратным запасом, выдохнули и пишем пост-мортемы. Причины падений кажутся очевидными (надеюсь из-за послезнания), но я всё равно поделюсь парой советов, что делать, чтобы не быть как мы.
— Научитесь понимать, что происходит. Мастхев — APM, дешборды с нагрузкой по каждому серверу, количеством тасков в очередях и внутренними метриками приложения. Идеально подходит Датадог. Дешборды не должны быть «номинальными», в них нужно смотреть.
— Собирайте артефакты. Пусть логи буду доступны всегда в одном месте (лучше — в том же датадоге). Настройте контроль ошибок с помощью Sentry или Bugsnag, и приучитесь туда ходить.
— Сделайте приложение 12-факторным. Если приложение не может запуститься одной командой на вашей домашней тачке — вы не заскейлитесь.
— Проверьте, насколько ваша инфраструктура способна к горизонтальному масштабированию. Проведите лёгкий мысленный эксперимент — возьмите каждый сервер, который у вас есть и представьте, что рядом стоит второй такой же. Сможете его нагрузить?
— Заведите «план побега» на случай выросшей нагрузки. Пусть вся команда знает, какие сервисы нужно сохранять в любом случае, а какими можно на время пожертвовать. Мы в iGooods к примеру сразу сфокусировались на внутренних интерфейсах, чтобы сначала отвезти уже сделанные заказы, а потом принимать новые.

Очень часто под нагрузкой вылезает весь накопленный техдолг — не тяните, расплачивайтесь сейчас.

Живые советы в следующую среду

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

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

#вопрос: как разбивать монолит на части?

Я постараюсь ответить не про архитектуру (микросервисы или нет — думаю, вам виднее), а про управление процессом.

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

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

Как и с любым рефакторингом, важно не пропадать надолго: если вы берёте у бизнеса полгода, жиденько поясняя, что по-другому никак и «всё плохо» — скорее всего, что-то идёт не так. Подумайте, как разобрать вашу работу на понятные и короткие части: скажем для новых микросервисов можно использовать существующее HTTP API, а затягивать сразу какую-нибудь Kafka.

Задавайте свои вопросы на fedor@borshev.com

90%

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

Насчёт 90 я не совсем уверен, может и больше.

​Давно не рассказывал новостей об iGooods, исправляюсь.
Самое главное — мы смасштабировались, теперь работаем с запасом на x2 увеличение нагрузки. После обращения президента в среду был рекорд по RPS за всю жизнь сервиса — инфраструктуре, в целом, пофиг.

Смасштабировались конечно плохо, но быстро — просто заткнули дыры новым железом. Теперь смотрим в датадог, ищем самые нагруженные места и оптимизируем: где-то чиним кеш, где-то избавляемся от N+1. Узкие места — не API, а старое рельсовое приложение (кто бы мог подумать!): если нагрузка будет больше расти с мобилок, чем с десктопа — выдержим наверное x3 или даже x4.

Готовимся к ядерному апокалипсису — пишем план на случай если в Москве и Питере одновременно запретят выходить из дома всем, кроме служб доставки. Упираемся в техдолг — наша версия рельсы не даёт масштабировать БД: она банально не умеет писать в один сервер, а читать из другого. Известные гемы не проходят регрессионное тестирование, так что если не успеем бампнуть рельсу до апокалипсиса, придётся искать эксклюзивное железо под БД, вроде обещают за 3 дня поставить.

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

Нанимаем бекендеров в продуктовые команды, активно используем две триальные недели. Есть даже первый финишировавший — привет, Андрей!

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

Почти внедрили datadog — собираем уже все нужные метрики, настраиваем триггеры. Есть борды по 4 золотым сигналам для всего, кроме фоновых задач. Странный resque вместо sidekiq бесит — чтобы собирать статистику по наполненности очередей, приходится использовать prometheus посередине. Но тоже вроде справились.

#вопрос: как найти удалённую работу на полставки? Хочу перейти на частичную удалёнку, чтобы учить параллельно новое направление — NLP. Курсы по NLP требуют большого количества выполнения домашки поэтому не хочу на фулл-тайм.

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

Выделитесь из толпы — к примеру, направьте время, которое собирались тратить на парт-тайме, на собственный проект для портфолио. Если занимаетесь NLP — сделайте бота, который как-нибудь интересно и с пользой разбирает речь, к примеру делает эмоциональный анализ сообщений в рабочих чатах.

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

Задавайте вопросы на fedor@borshev.com.

Инфостиль в заголовках задач

Я не сильно докапываюсь к чистоте текста в задачах и служебной переписке: конечно клёво, когда люди пишут понятно, но не всем нужно это учить: нафига какому-нибудь руководителю логистической службы писать тексты на 8 баллов главреда? Главное, чтобы он мог хоть как-то сформулировать сигнал, что болит — а дальше придут опытные продакты/проджекты и всё выяснят.

Но есть одно место, где я жёстко включаю Ильяхова — это заголовки задач в трекере. На сколько вы бы захотели работать в команде, которая целый день занимается какой-нибудь «необходимостью реализовать новый механизм построения отчётности» и, чтобы не произносить это дерьмо в слух, называет задачи по номерам (типа «Как там задача 1238?»). Я — не хотел бы.

Вот пара правил для заголовков задач, которые помогут не превращать трекер в бухгалтерский отчёт:
— Из заголовка чётко понятно, что нужно сделать. Не «доработать логику корзины», а «Сделать, чтобы при удалении последнего товара корзина очищалась».
— Никакой воды: смело рубить всякие «необходимо реализовать» и «отсутствие возможности».
— В заголовке есть понятные для всей команды ключевые слова. Если задача про вкладку Логистика, то так и писать «логистика», а не «интерфейс менеджера-логиста».
— Если задача мало декомпозирована («привести в порядок учёт зарплаты») то заголовок должен описывать следующий понятный шаг, к примеру «Понять, почему заказ 100500 не пробросился в 1с» или «сделать кнопку «не согласен с расчётом».

Update: для любой проблемы уже давно написан специализированный сервис. Мне тут подсказали http://bugred.ru, который как главред, только для задач в трекере.

Как быть, если всё время уходит на разработку всё новых и новых фич?

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

#вопрос: У нас небольшая компания, и нет команды разработки, я — единственный программист. Поработал полтора года и что-то заскучал: задач хватает как раз примерно на одного человека. Конечно, мне всегда кажется, что их больше, чем я бы мог сделать, но это сглаживается отсутствием жестких сроков. Сделал — хорошо, не сделал — ну потом как-нибудь сделаешь. То есть бизнес готов мириться с тяготами ограниченного ресурса разработки, готов долго ждать выполнения задач, готов потерять разработчика и искать нового пару месяцев (и ничего плохого за это время не случится).

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

В конечном счете я потерял в этом смысл, потому что «и так все работает». Что бы ты порекомендовал в подобной ситуации? Стоит ли менять место работы, или же можно что-то исправить, чтобы не застаиваться?

————————
Ответ

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

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

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

Dotbot и Ansible

Настроить новый компьютер, особенно для программиста — это всегда тяжело: нужно ставить кучу программ и утилит, переносить их настройки (iCloud для них не работает).

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

Как только я это осознал, я занялся автоматизацией. Получилось не с первого раза, но в итоге получилось. На выходных представился случай проверить — мой основной ноутбук с Catalina после последнего обновления стал зависать по два раза в день.

В итоге, я развернул с нуля компьютер, на котором пишу этот пост, примерно за полтора часа. И это включая всё моё окружение для разработки, все маковские программы и заморочки вроде Karabiner Elements и BetterTouchTool.

Если тоже пользуетесь маком для разработки и не пугаетесь слов homebrew и git — посмотрите мои наработки на гитхабе. Не уверен, что они пригодятся из коробки, на даже если почерпнёте оттуда пару идей — буду рад.

Единицы смысла в электронной почте

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

Лебедев оценивает дизайнеров единицами смысла. У электронного письма есть похожий показатель — если вкратце, то в письме нет смысла, если в ответ на него прилетает ещё одно письмо.

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

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

Кстати, показатель осмысленности письма нужно разделять на количество тех, кто стоит в копии. Если письмо получит 10 человек — до каждого из них долетит только 0,1 смысла. Или вкладывайте в такие письма в 10 раз больше смысла, или пишите одному человеку.

#вопрос Есть разработчик, который неплохо справлялся с задачами в офисе — если и срывал сроки, то по объективным причинам. Сейчас из-за коронавируса команда полностью перешла на удалёнку, и разработчик начал срывать сроки — говорит, что ему не нравится работать на удалёнке. Чтобы вы могли посоветовать?

Я бы начал с разговора. Удалённая работа — это не «как в офисе в только дома», она требует совсем другого подхода.

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

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

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

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

Срочно в номер: бесплатный гитхаб для всех

Гитхаб бесплатно раздаёт свой корпоративный план. В смысле теперь можно иметь бесплатные репозитории с неограниченным количеством контрибьютеров — и на личном аккаунте, и на корпоративном. Деньги, видимо, будут зарабатывать на дополнительных сервисах — Packages, Actions (который, я верю, составит конкуренцию Circle, а потом станет золотым стандартом CI), на сапорте, и параноиках, конечно.

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

Что автоматизировать, чтобы быстрее писать код

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

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

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

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

Вебинар пройдёт 10 мая (в воскресенье) в 15:00. Если вдруг к этому времени отменят пропускной режим и все уедут на шашлык — сдвинем дату чуть-чуть вперёд. В любом случае, даже если не попадёте, билет лучше купить сейчас — запись будет дороже.

Участие стоит 1800 рублей, каждый понедельник цена повышается на 100 рублей.

Как дела в iGooods

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

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

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

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

Активно нанимаем. Сейчас ищем главного дизайнера, продакта и аналитика. Ну и рубистов конечно.

——

Когда я работал в ГдеМатериале, я рассказывал о своих делах с большим отставанием — сначала добивался результата, а потом говорил, как я это сделал. Если не получалось — просто не рассказывал. Теперь всё по-другому, я пишу здесь почти в реальном времени. «Почти», получается, потому что я всё-таки иногда ещё и работаю :-)

Кажется, из-за этого лага я выгляжу как Винстон Вулф из Pulp Fiction — как будто мы с Саматом пришли и решаем проблемы по чеклисту: «вот разбрызганные мозги, вот старые ковры, вот губка — оттираем, накрываем». На самом деле нет — лично я на прошлой неделе обосрался с двумя проектами в iGooods, нифига не сделал для запуска нового вебинара, потерял полдня потому, что почитал новости, и абсолютно не доволен результатами по большой внутренней задаче, о которой пока рано рассказывать.

Такие публичные отчёты нужны мне, чтобы быть в порядке: перечитал, что сделал, и кажется что не всё так плохо. Рекомендую такую практику всем — просто садитесь и раз в неделю рассказывайте, как у вас дела. Можно близким, можно каналу в телеграме, или Apple Notes или Day One, если почему-то не хотите публиковать.

Чеклисты

Обожаю чеклисты — с ними можно делать много дел, совершенно не подключая головы. Работать по чеклистам — это как писать код с тестами — не нужно всё время проверять, правильно ты делаешь свою работу или нет. У меня есть чеклисты на все случаи жизни:

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

Самое главное моё открытие в чеклистах — их можно дописывать. Скажем, чеклист о том, как начинать живой стрим, появился ещё до первого стрима и состоял из двух пунктов — «выставить свет» и «закрыть дверь». После того, как у меня во время стрима вылезло окно с почтой — там появился пункт «закрыть лишние программы». Когда я обнаружил, что не все VPN тянут нормальный битрейт — появился пункт «проверить вещание». Теперь там чуть больше 10 пунктов, каждый из которых экономит мне силы, позволяя не думать там, где можно не думать.

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

​Переносим разработку в облако

Недавно я посчитал, сколько будет стоить макбук, на котором комфортно писать код, и офигел: получилось где-то 250 тысяч. Такую сумму отдавать жалко, особенно учитывая, что за $40 в месяц на digitalocean можно арендовать дроплет, который всё равно окажется мощнее и быстрее.

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

В эту субботу будем разбираться, как можно целиком перенести разработку на удалённую машину. Поскольку это будет стрим, а я так ни разу не делал — результата не обещаю.

Суббота 14:00, приходите.