Федор Борщев

2018 год и свой огородик

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

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

Слева — свой огород, справа — заемная инфраструктура

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

Но когда все эти анализаторы логов ставит себе маленькая команда, хочется дать им калькулятор. Сколько времени уходит на решение тупейших проблем вроде нехватки места, криво обновившейся операционки или упавшего демона? А когда что-то падает посреди релиза?

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

Неужели ваше время стоит дешевле?

Топ-даун и прогрессивный джипег для программистов

Правило Парето гласит, что 80% времени программиста тратится на 20% требований. К примеру, на любом современном фронтенд-фреймворке работающую корзину в интернет-магазине можно запилить за день — можно будет добавить/удалить товар и отправить заказ.

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

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

Инженеры называют этот подход top-down, дизайнеры — прогрессивным джипегом.

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

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

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

Проверка через два дня не требует никакого напряжения и предотвращает кучу долга — в проекте не копятся неработающие и невнедренные фичи.

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

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

Плато продуктивности

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

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

Программист делает твою (да-да, твою) задачу

Работа с некачественным кодом сильно выматывает — вместо фокуса на цели приходится разбираться, о чем же думал «тот парень» (и тот, кто его подгонял). В таком режиме волна продуктивности превращается в болото: ∿∿—\____. Хочется уволиться и пойти работать машинистом метро.

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

Критика

Когда я только попал в Студию Лебедева, меня больше всего удивил не музей старья, и даже не кот Филя.

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

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

Только не кричите, как эти стоковые мужики

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

Критикуйте. Настраивайте жёсткий код-ревью. Делайте системы согласований. Собирайте обратную связь и ещё раз критикуйте.

Технические долги

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

Представь что ты увидел в магазине новый охуенный iMac pro. Можно пойти и накопить 400 тысяч (долго и муторно), а можно достать кредитку и купить прямо сейчас.

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

Технический долг — он как финансовый

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

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

Расплата по долгам

В командах у технического долга появляется еще одно вредное свойство — по долгам одного нерадивого участника приходится платить другим. Относись к такому долгу, как к деньгам: представь, что ты в баре, и нашел в кармане кредитку коллеги. Ты же не станешь угощать весь бар Макаланом, правда?

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

Какие технологии выбрать для нового проекта?

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

За пару дней до Нового Года я решил выбрать робот-пылесос. На рынке есть десятки брендов — iClebo моет полы, iRobot лучше всех строит карту помещения, Дайсон — мощный, а Сяоми вроде бы самый крутой, и стоит в 5 раз дешевле. Объединяет всех производителей одно — нихуя не понятно, какую из характеристик нужно выбрать, чтобы конкретно в моей квартире стало всегда чисто.

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

Выбор технологий с точки зрения менеджера

Ответ про пылесос я в итоге нашел на вечнозеленом ixbt. Но с языками программирования так не получается — вменяемых материалов нет. Даже если вы неделю будете изучать реддит, то узнаете только как правильно троллить ПХПшников или что наследование в Го лучше чем в Джаве. Какое это имеет отношение к срокам и целям — непонятно.

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

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

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

Еще раз — подойдет любой язык программирования (кроме JS, конечно). Главное, чтобы те, кто на нем пишет, гарантировали результат. И у вас было, кем их заменить.

Если остались вопросы про выбор — пишите на почту.

Писать тесты — вежливо

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

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

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

Хорошая передача эстафетной палочки — 3 ссылки на тесты
Хорошая передача эстафетной палочки — 3 ссылки на тесты

Не пишете тесты? Откройте лучше автомойку, или завербуйтесь к газовикам на север.

Автоматизация рутины программиста

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

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

6 сервисов для автоматизации рутины программиста

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

Если рядом с вами программируют хоть что-нибудь сложнее сайта-визитки на вордпрессе — проверьте эти 6 направлений:

  • Непрерывная сборка и запуск. Решает проблему с выкатыванием софта — программисту достаточно отправить коммит в репозиторий, дальше все случается без его участия — запускаются тесты, собирается фронтенд, снимаются метрики. Если код в коммите рабочий, продакшн обновляется автоматически. Хороший сервис — CircleCI.
  • Замер качества кода. Ключевые метрики — покрытие тестами, сложность, читаемость, наличие копипейста. Хороший сервис — Code Climate.
  • Отдельным пунктом — процент покрытия. Это соотношение кода, который выполняется во время прогона тестов к общему количеству кода в приложении. Если у вас проверяется меньше 80%, значит вы пишете плохой код. Если покрытие меньше 50%, а вы работаете над новыми фичами — вы работаете зря. Хороший сервис — Codecov.
  • Обработка ошибок. Хранит журнал ошибок и позволяет анализировать продакшн на основе реальных цифр, а не жалоб пользователей. Хороший сервис — Sentry, есть клиенты для всех языков, включая браузерный JS.
  • Мониторинг производительности. APM снимет трейсы самых долгих запросов прямо с продакшена, нарисует графики скорости и подскажет узкие места, которые приводят к тормозам. Для каждого фреймворка нужен свой APM, для Джанго я использую Datadog. Еще есть New Relic и куча других.
  • Облачный хостинг. Если на вашем проекте есть жужжащая железяка с сисадмином в комплекте — смело избавляйтесь. Дешевле и проще взять ресурсы в аренду и исключить человеческий фактор, чем владеть коробкой, которая не приносит денег. Идите в Azure или хотя бы в Digital Ocean.

Что-то забыл? Пишите в комменты. Интересуетесь автоматизацией? Начните с free-for-dev.

Как корпоративный чат убивает продуктивность

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

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

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

Корпоративный чат — это уведомления

Любой групповой чат, включая Слэк с его настройками — это бесконечная куча уведомлений: небрежно постав­ленные задачи валятся вперемежку с котиками и сообщениями о сборках в Трэвисе. Даже если отключить уведом­ления, Слэк не отпускает — раз в 10 минут вы с постоянством куриль­щика открываете чат и проверяете новые сообщения.

Слэк — не первый, так работает фейсбук, Первый канал и Дарья Донцова

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

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

40 загаженных инбоксов

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

e-mail vs. skype

В корпоративном Слэке завели 40 комнат для разных предметов обсуж­дения: брифы, редактура, новые статьи, мониторинг соцсетей. Предполагается, что люди читают только те каналы, которые им важны. Угадайте, как проис­ходит на самом деле? Правильно, участники чата постоянно разгребают 40 папок входящих, 5 из которых — с котик­ами, а еще 20 не нужны для работы.

Небрежность

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

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

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

Одна задача — много исполнителей

В психологии есть понятие эффекта свидетеля — когда толпа людей видит нечто плохое, и никто не вмеши­вается, потому что ждет, что вмешается сосед. Эффект свидетеля ожидает вашу задачку в любом чате.

Эффект свидетеля

Хороший менеджер декомпозирует задачи на кусочки. Кусочек задачи — один шаг одного исполнителя. Такие задачи проще сделывать — нет стимула размазывать ответственность («Ой, а дизайнеры не нарисовали», «Ой, тут пусть сисадмины выкатывают»). Декомпозированную задачу на одного исполнителя уже незачем кидать в чат — нафига отвлекать 30 других человек?

Синхронность

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

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

Корпоративный чатик — это восьмичасовое собрание 30 человек без четкой повестки

Кому-то удобнее работать помидорками, кому-то — циклами по 2 часа. Кто-то работает из круглосуточной шоколадницы или живет в Магадане. Это не важно, когда команда общается асинхронно. Чтобы добиваться результатов, достаточно пересекаться на 15 минут раз в пару дней.

Если команда слаженно работает только сидя в одном помещении или комнате чата — что-то не в порядке. Скорее всего ребята не умеют общаться, и пора усилить команду администратором.

Вывод

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

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