#вопрос как прокачивать скиллы, будучи интровертом?

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

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

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

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

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

100500 плохих сигналов

Почти все больные системы мониторинга, которые я видел, объединяет одна черта — они шлют бесполезные алёрты.

Какая разница, что места на сервере осталось 20 гигов или что выросло количество соединений в состоянии TIME_WAIT? Человек, которого PagerDuty отрывает от пикника с друзьями, хочет знать ответ на простой вопрос — надо ли прямо сейчас всё бросать и чинить проблему? Метрики с железок на такой вопрос никогда не ответят.

Чтобы ответить, нужно смотреть на бизнесовые метрики. Они у каждого свои, но в роли базовых стоит использовать 4 золотых сигнала, о которых я недавно писал: время ответа, запас по CPU, количество запросов и количество ошибок. Если все 4 параметра в норме, то в бизнесе, скорее всего, всё ок. И наоборот, если какой-то параметр выбивается — нужно лечить.

P.S. Мой вебинар об автоматизации уже в эту субботу! Там будет целая секция про мониторинг и devops, приходите.

Что делать, если меня отстраняют от дел?

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

Почитайте тут — https://bureau.ru/soviet/20200521/.

Полезно получилось ответить?

Если пора спать — значит, пора спать

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

Сколько бы мы ни посмотрели фильмов про хакеров и как бы романтично ни выглядела работа за двумя мониторами под покровом ночи, гигиену труда никто не отменял. Любому человеку нужно регулярно спать. Кому-то — 6, кому-то — 8 или даже 10 часов. Почитайте «Здоровый сон», если не верите.

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

Если пора спать — ложитесь спать.

Проверить через два дня

Многим программистам (и менеджерам) не хватает простого навыка — проверить через два дня.

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

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

Кто должен проверять через два дня, если задачу делали впятером? Конечно ты.

Смеяться в коде

Обожаю смеяться в коде. Самый распространённый товар в тестах ГдеМатериала у нас назывался «Камаз Отходов». Иногда он трансформировался в «Камаз Овец» или «Камаз Гвоздей». Большинство прорабов звали «Львовичами» («Петрович» не хотелось по понятным причинам).

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

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

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

Научи ловить рыбу

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

Неопытные программисты в ответ на просьбу по-быстрому что-нибудь сделать обычно что-нибудь делают. Продвинутые даже выстраивают системы реагирования, типа «Сегодня Вася делает все задачи по-быстрому, а завтра — Федя».

Опытные же, наоборот, — не дают рыбу, а учат её ловить: они не сбрасывают пароль, а делают кнопку для сброса пароля; не меняют телефон, а делают поле в админке; не делают выгрузки, а ставят Metabase или PowerBI. В ГдеМатериале у меня вообще было правило, что разработчик никогда не участвует в операционке, что бы ни произошло: так мы тратим время разработчика не на решение задачи, а на фичу, которая нужна, чтобы подобные задачи больше никогда не приходили.

​Запись вебинара об автоматизации разработки

2 часа разговоров про построение рабочего места, мониторинг, хостинг, запуск проектов в одно лицо и (самое главное) про огородики и дизайн.

В честь первого дня продаж, цена — 1800 рублей.

Качество ведения проекта

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

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

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

Фабрика фич и просранное время

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

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

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

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

#вопрос
Почему в твоей письменной/печатной речи так много грубых слов типа «говно» и так далее?

Если программисты себя считают элитой, то почему их общение (не только твоё) скатилось до смеси сленга с быдлятиной?

И второй, про сленг. Тебе правда нравится изобилие сленга и слов типа «фейлить», «факапить» и прочих в твоих текстах?

————
#ответ

Сленг складывается помимо нашей воли. Идти против сленга — глупо. Представьте себе дальнобойщика, который по рации скажет «Вижу засаду ГИБДД» вместо «машинка работает», или кладовщика, который назовёт рохлю «вилочным погрузчиком» — поймёте, о чём я.

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

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

Поэтому здесь я пишу коротко и без заморочек — как писал бы в рабочий чатик или в личку товарищу. Единственное отличие — недавно здесь появился корректор (Ольга, привет!): теперь, надеюсь, мои писюльки стало воспринимать ещё чуть легче.

Лайв-девопс: поднимаем кластер на docker swarm для W1D1

На прошлом стриме о докере вы просили рассказать, как запускать контейнеры не только на своей машине, но и в продакшене.

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

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

Ребята любезно разрешили мне сделать это публично, так что приходите на ютуб в 14:00 воскресенья — будем поднимать маленький кластер на docker swarm при помощи моего любимого Ansible. Как обычно, всё будет в лайве и без репетиций, так что никто не знает, получится ли у меня вообще что-нибудь.

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

Полезно получилось?

Не отдавайте технические решения

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

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

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

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

​Сегодня я немного пожалел, что 3 года назад ушёл из студии Лебедева.

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

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

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

#вопрос. А расскажи просто по пунктам про корпоративную культуру в компании? Как сделать, чтобы люди забирали ответственность?

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

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

Но вживую я такого не видел, поэтому мой подход к ответственности — простой:

1. Отдавать людям ответственность.
2. Если не берут — отдавать другим людям.

Задать вопрос → fedor@borshev.com

Хороший код не соответствует ТЗ

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

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

Если программист ни о чём, кроме ТЗ, не думал и из последних сил родил к дедлайну гору говнокода, то, скорее всего, всё, что умеет эта гора, — это чётко соответствовать ТЗ. Но то, изначальное, ТЗ уже никому не нужно — пока делали код, уже Путин успел три раза выступить, мир стал другим!

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

См. также:

— Почему длинные ТЗ не работают
— Почему важно писать хороший код

Я ушёл в офлайн где-то рядом с Монгольской границей, так что постов сегодня и в понедельник не будет.

Тут тихо и красиво, а самое главное — LTE встречается раз в 100 километров

:-)

​Забота 80 уровня от DigitalOcean

Недавно экспериментировал со своим облачным огородиком и получил вот такое письмо от DigitalOcean. Типа «Мы тут видим, что у тебя редис смотрит наружу. Это точно ок?»

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

Если облажался — признавай сразу

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

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

Во-первых, критика — это комплимент: если к вам никто не приходит рассказывать о ваших недостатки — значит, вы или ничего не делаете, или всем вокруг на вас пофиг. За любую критику (если она конструктивна, конечно) нужно говорить «Спасибо» — человек оторвал жопу от кресла, подошёл к вам, чтобы вы могли улучшить свою работу. Это же круто!

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

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