FEDOR BORSHEV
24.6K subscribers
36 photos
1 video
4 files
674 links
Рассказываю, как руководить программистами

fborshev@pm.me / borshev.com

Реклама не продаётся
Download Telegram
​​Рациональная фантастика

Редко читаю (а тем более советую) художку, но мимо этой серии пройти невозможно. Трилогия называется «Воспоминания о прошлом земли», написал ее китаец Лю Цысинь.

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

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

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

Похоже всю серию на русском так и не выпустили, так что гуглите английскую The Remembrance of Earth's Past.
Процесс → результат

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

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

Перефокусироваться с процесса на результат — тяжело: это связано с индивидуальными особенностями личности. Мне в свое время помогали простые вопросы про бизнес:
— Зачем я вообще делаю эту задачу? Кто ожидает от нее результат? Как этот результат выглядит?
— Как бизнес получал бы результат, если бы меня не было? Как бы я мог бы им в этом помочь?
— Если бы я мог потратить на эту задачу всего 30 минут, какими бы ее частями я пожертвовал, чтобы бизнесу было наименее больно?
— Какая самая сложная часть задачи? Что можно изменить в постановке, чтобы избавиться от нее?

Если вы — процессник, и будете задавать себе такие вопросы про каждую полученную задачу, то со временем научитесь ставить задачи лучше, чем бизнес, и вас начнут ценить как синьора. А говнокодить все равно не начнете.
​​Сервис: netlify.com

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

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

Нетлифай закрывает вопрос полностью — в нем есть CI (который не надо настраивать!), быстрый хостинг на амазоне, автоматический DNS и деплой-превью. Если остается желание, то в каждую часть процесса можно влезть и что-нибудь покрутить — сделать домен верхнего уровня, настроить редиректы или проксирование, докрутить CI.

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

И все это бесплатно.
Старая заметка о том, почему слэк (и другие чатики) не добавляют продуктивности, а наоборот, крадут. Со времени написания заметки слэк получил 600 миллионов долларов инвестиций, стал в два раза жирнее, но не прибавил ни капельке пользы.

Скиньте эту ссылку прямо сейчас в свой рабочий слек — https://borshev.com/slack-productivity/
Продолжение вчерашней темы. В слеке не работает важнейшее правило электронного общения: одно сообщение — один вопрос. Почитайте Тему вот:
Наиболее эффективная коммуникация

У всех людей разные привычки и возможности общения. Я для себя открыл наиболее эффективный способ общения: одно дело в одном сообщении.

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

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

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

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

- Это поэтому ты так много успеваешь? А ты сам придумал этот лайфхак? А как мне научиться делать как ты?
- ...
Стейджинг → деплой превью

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

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

Расскажу про наш сетап. Про первую часть я уже писал в заметке про нетлифай — это автоматическая публикация веток фронтенда на поддоменах. На каждый ПР у нас появляется ссылка вида deploy-preview--<feature>--<project>.netlify.com.

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

У нас это специальная машина на селектеле, на которой через docker-compose крутится минимальная инфраструктура, отключенная от внешних интеграций. Образы постоянно обновляются через ночные сборки в CI, включая полную копию рабочей базы.

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

Конечно, деплой-превью никогда не заменит человеческого общения — скорее это просто удобное средство для презентаций. Но про это я расскажу как-нибудь отдельно.
​​Сервис: datadoghq.com

Сегодня расскажу о важной штуке — Application Performance Monitor, или APM. APM нужна программистам, чтобы анализировать скорость работы кода прямо в продакшене.

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

Датадог — один из трех доступных на рынке APM для питона (есть еще new relic и obeat). Кроме APM, содержит в себе еще развитую систему мониторинга серверов — снимает метрики с железа и контейнеров, шлет уведомления, и интегрируется с тоннами систем.

Цены у него не очень демократичные, но для коробочного решения, полностью закрывающего проблему мониторинга доступности и производительности — вполне ок.
НЕ ЗАВИСАЙ

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

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

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

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

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

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

За половину стоимости нормального ВПС можно купить аккаунт у любого крупного провайдера ВПН, вроде PureVPN или NordVPN. Мой любимый — NordVPN: в добавок к удобному способу соединения, вы получаете ещё набор расширений для браузеров и быстрые SOCKS-прокси. Прокси удобно прописывать в телеграмме, чтобы приложение на телефоне работало даже без ВПН.

Скорость на платных ВПН почти не падает — можно смело заворачивать весь канал туда. Разница будет видна только если начинаете качать что-нибудь крупное.
Бирман вот пишет про правильных верстальщиков — https://ilyabirman.ru/meanwhile/all/plohoy-i-horoshiy-verstalschiki/.

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

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

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

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

Для нас в mtrl.ai было еще два ограничения — неудобно ставить задачи, которые касаются нескольких репозиториев (к примеру одна фича затрагивает несколько микросервисов), и очень хотелось показывать статусы задач для бизнеса.

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

Для второй задачи — прозрачности — мы просто подключили гитхаб к трелло, где до этого хранили беклог. Раз в неделю при планировании спринта перетаскиваем выполненные задачи в колонку Done, а новые — в колонку WIP. Каждая карточка в трелло ссылается на задачу в гитхабе, так что если вы авторизованы в обоих системах, проверка статусов занимает 3 минуты.

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

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

Терминал. Зависал. От данных.

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

Терминал, который зависает, если вывести много текста? База данных, в которой нет реляционности? Бекенд на языке, который может работать только в один поток? Пожалуйста!

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

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

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

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

Полностью — тут.

Если вы начинаете систематизировать происходящее внутри вашей команды, возьмите вики Ивелума за основу.
​​Сервис: Google Tag Manager

Если вы вдруг работаете с вебом, и до сих пор не знаете про Google Tag Manager — эта заметка для вас. GTM — это фундаментальный инструмент для управления интеграциями с внешними системами.

Вот представьте ситуацию, вы — маркетолог, подключаете новый канал (к примеру Фейсбук), а он требует установки какого-то кода на сайт (к примеру Фейсбук-пикселя). Если у вас на сайте нет ГТМ — приходится идти к айтишникам, а у них еще 100 задач, спринт и вообще не до вас. Если ГТМ установлен — вы просто идете в его интерфейс, копируете код и все моментально появляется на сайте.

Или вы — аналитик, для проверки новой гипотезы хотите измерить количество нажатий на определенную кнопку. В ГТМ вы просто создаете новое событие, и данные сами собой записываются в Google Analytics (или куда там вам надо).

GTM — полностью бесплатный сервис, имеет в комплекте пачку готовых интеграций и позволяет легко устанавливать свои. Из минусов — только Material design и традиционная для Гугла отвратительная документация. Альтернативы есть, но какие-то невнятные и платные.

tagmanager.google.com
Две пробные недели

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

Получается, что ребятам не нужно увольняться с текущего места работы, чтобы проверить себя на совместимость с нашими требованиями. Никаких сложных решений: не срослось, так не срослось.

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

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

Мы предельно упростили процесс выхода на эти две недели — достаточно прислать скан подписанного НДА. Сразу после этого на почту падает приглашение в нашу команду на гитхабе (все общение там) и пара пристрелочных задач.

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

#работамечты
Как я подбираю книги

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

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

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

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

От «Организаций будущего» я ожидал описания оргструктур по Друкеру, и бросил, распознав книгу о холакратии — организации без менеджеров, которую безуспешно пытался внедрить Тони Шей в Запосе. «Чеклист» Атула Гаванде я выбросил после пассажа о том, как автор, управляя Боингом-777 «переключился на нейтраль и стал ждать очереди на взлет».

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

Грустная новость: закрывается Opbeat — гибрид Sentry и New Relic для энтузиастов. Гибрид — потому что умел мониторить производительность приложений и фиксировать ошибки. Для энтузиастов — потому что имел офигенный бесплатный тариф, которого хватало для небольших проектов.

Закрытие прошло как-то странно, не было ни постов в блоге, ни уведомлений — просто пришел Final Reminder. На замену предлагают Elastic APM, который тянет за собой целый огород из всех продуктов Эластика, а вместо нормальной SaaS версии предлагает жутко энтерпрайзный Elastic Cloud.

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

Цели Эластика я не очень понимаю. Кому мешала SaaS-версия? Почему никто не тестировал другие тарифы или модели монетизации?

А пока ждем, когда провайдеры hosted ELK подтянут к себе новую функциональность, и юзаем Датадог и Сентри.
Сергей Шабалин рассказывает о прекрасном правиле: никогда не говори «я же говорил». Для удаленной команды и долгосрочных отношений — вообще мастхев.

http://shabalinsergey.ru/all/ne-govorit-ya-uzhe-govoril/
​​Пацан сказал → пацан сделал

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

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

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

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

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