25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
#вопрос Должны ли только программисты руководить программистами? Или менеджерам тоже можно?
Отвечу как Антон Давыдов — это зависит.
В первую очередь — от бизнеса, для которого работает команда. Если трое опытных программистов пилят какой-нибудь плагин для постгреса — руководитель с технологическим бекграундом наверное подойдёт лучше. Если десяток программистов гребёт на маленькой аутсорс-галере — там конечно нужен менеджер: кто-то должен вести коммуникацию с заказчиком, выставлять счета и получать по ним деньги.
А ещё выбор менеджера зависит от людей в команде. Есть программисты, которые презирают не-технарей в ИТ и не готовы с ними работать (зря!). Есть менеджеры, которым настолько неинтересно погружаться в программистское задроство, что они с большей радостью возьмут руководство какими-нибудь дизайнерами.
Если расскажете чуть подробнее про бизнес и команду — буду рад дополнить свой ответ.
Это был ответ на традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Чёрная пятница 2
В прошлом году мы первый раз запустили в школе чёрную пятницу. Сработало хорошо — много новых учеников познакомились с нашими курсами, а мы смогли инвестировать в LMS и другие внутренние проекты.
В этом году повторяем историю — если вы ещё ни разу у нас не учились или просто давно засматриваетесь на самостоятельный тариф какого-либо курса — 23-24 ноября мы даём скидку 25% по промокоду FEDYAMARKETOLOG.
Что можно купить:
— «Асинхронная архитектура» — о том, как строить распределённые сервисы. Для тех, кому интересно разобраться с коммуникацией внутри больших систем.
— «Тестирование в Python» — если пишете коммерческий код и хотите сделать его надёжнее.
— «Вы приняты» — мини-курс для тех, кто планирует искать работу за рубежом и нет времени, чтобы собирать информацию по крупицам.
— «Стать Тимлидом» — фундаментальный курс про софт-скиллы для программистов. Даже если не хотите становиться тимлидом — поможет владеть собой и обстоятельствами.
— «Есть минутка» — наш флагман про коммуникации. Разбираем как не умереть от миллиона чатов, бесполезных встреч и бесконечного бардака в работе, сохранив отношения с коллегами.
— «Самому не проще» — мини-курс для тех, у кого возникают сложности с делегированием. Курс прошло 200 человек, судя по отзывам, многие научились делегировать.
— «Профессиональный рост: меня и команды» — курс от Васи Половнёва, ведущего разработчика Бюро Горбунова для тех, кто системно подходит к развитию навыков.
На «Анализ Систем скидка не действует — мы совсем недавно запустили поток и это было бы нечестно по отношению к тем, кто купил самостоятельный тариф.
P.S. От юрлица тоже можно — напишите нам в чат, дадим скидку если покупаете больше 5 билетов
Анализ систем — ласт-колл на второй поток
Завтра стартует обучение на втором потоке «Анализа Систем». Будет 5 недель обучения, четыре итерации проектирования сложной системы для будущего единорога, много DDD и разных архитектурных стилей, а в конце — распиливание монолита.
Ещё можно запрыгнуть в последний вагон — после этого потока мы возьмём время на отдых и новые курсы. Следующие потоки курсов по проектированию будем набирать ближе к лету.
От юрлица быстрее всего будет оплатить картой (уточните у бухгалтерии). Самостоятельно можно любой картой мира, или в рассрочку, если вы в РФ.
Смотреть программу и отзывы →
Почему нам досталось 1 место. Часть 2.
1/ Мы год писали контент и пытались решить задачку, как сложный академический талмуд, который у нас получался на старте — превратить в что-то с посильной сложностью, интересным и не в три тома. И несмотря на то, что курс довольно объемный по контенту, больше, чем мы хотели, но он затягивает. Мы смогли это сделать за счет того, что вместо того, чтобы вывалить на человека всю сложность, наслаивали сложность — 4 недели проектировали систему и с недели в неделю, специально давали ошибиться ученикам, чтобы далее они осознали сложность.
2/ Домашка. Ее сделали 83% учеников, это лучшее что я видела на рынке. Обычно показатель от 5 до 20%. Немногие и доходимостью в просмотре лекций могут похвастаться. А у нас практика на таком уровне. Опять за счет сквозной истории: 4 раза ребята переделывали одну и ту же систему, наращивая сложность.
3/ Шеринг опыта и поддержка. Мы попросили учеников проверять домашку друг друга, научили давать обратную связь и подсвечивать не только точки роста, но и то, что классно получилось. И это стало точкой вдохновения и источником инфы. И это кроме бурлящего чата, где Антон отвечал на каждый вопрос и непонимание. NPS = 9,15.
4/ Мы дали возможность ученикам заякориться и расслабиться. У нас был сторителинг (героев сгенерировал нам Midjourney). Главный герой проходил путь проектирования сложной системы, очень приближенной к жизни. У него были взлеты и падения, постоянно менялись вводные, люди не выходили на связь. Через эти истории ученикам было проще коммуницировать: то и дело в чате появлялись в формулировки в духе «Я не понял кусок, где Ибрагим (главный герой) разговаривал с заказчиком и…». Это проще, чем «в 2 лонгриде, второй половине… » А еще мы добавляли моменты, где надо было выпустить пар, когда все достало.
За неделю до объявления результатов премии, мы открыли запись на второй поток. Стартуем 15 ноября, закончим в январе. Будет перерыв на зимние каникулы. Подробности на сайте. Вдруг вам надо поучиться или подсмотреть формат.
#фичи_курсов
Refresh token не нужны
Одна вещь, которую я не понимаю, работая с JWT много лет — нахрена там вообще нужны два вида токенов. По-программистки, конечно звучит, круто — типа злоумышленник украл access token, сервер его инвалидирует, а юзер ничего не замечает, т.к. у него есть refresh token, с помощью которого он получает новый access token. В реальной жизни это не важно — кража access-token приводит к полной компрометации всех отношений между клиентом и сервером, и безопасность refresh token сразу же теряет значение.
Представьте, что злоумышленник через MITM украл access token к онлайн-почте. Какая разница, что он не знает refresh token, который мы так усердно прячем, если он первым же запросом, пока всякие алёрты не сработали, просто забирает все письма с сервера в поисках паролей и приватных данных?
Если злоумышленника обнаружили — сервер в любом случае должен будет инвалидировать оба токена: он не знает, насколько скомпрометировали машину юзера. Неважно где мы прячем refresh token — в LocalStorage или HTTP-only куках: может юзеру установили модуль ядра, который крадёт токены напрямую через файловую систему.
Ну а стандартный паттерн, когда access-token протух, и браузер восстанавливает его через refresh-token — вообще фигня: это ничем не безопаснее, чем просто длинно живущий токен.
Переубедите меня?
#вопрос Нужно ли проводить перфоманс-ревью?
Мы — аутсорс, 130+ человек. Наняли специального HR, купили платформу автоматизации для проведения опросов, наняли инженера её сопровождать.
А я не вижу профита. Руководители знают про своих ребят — повышают зарплаты; выслушивают боли, иногда ходят к ним, иногда они сами приходят. Без формализма.
Может был опыт, где отказались от этого и ничего не изменилось, а затраты сократились или наоборот?
––––––
Начну с дисклеймера — я никогда не руководил компаниями такого размера, поэтому мои рассуждения стоят не слишком много. Наверное, читать их имеет смысл только, чтобы посмотреть, что руководитель компании на 30 человек думает о компании на 130 человек.
Во-первых, круто, что вы не следуете карго-культу! Все компании (и команды внутри одной компании) — разные: кому-то инструмент нужен, а кому-то — только мешает. Если перфоманс-ревью поднимает эффективность в условномм Яндексе — это совсем не значит, что оно будет полезно вам.
Сам я не сторонник формального перфоманс-ревью. Иногда сам запрашиваю обратную связь у команды — выясняю, что ребята думают про новичков. У менеджеров узнаю, на кого в команде они могут опереться, а кто не создаёт ощущения надёжности. У программистов спрашиваю, что они думают про код товарищей. Но всё это происходит не формально, раз в полгода, а тогда, когда для этого есть основания (или раз в полгода :-).
В вашей ситуации я бы послушал руководителей подразделений — а надо ли оно им? Может у них действительно всё хорошо, выстроены механизмы обратной связи. Скорее всего они ещё поспрашивают тимлидов «в полях», и всё это вместе даст более подробную картину.
Это был традиционный вопрос по понедельникам. Задать свой — fborshev@pm.me
Положительная обратная связь в продуктивности
У гуру тайменеджмента есть мантра — «съедать по утрам лягушку». Идея в том, что утро нужно начинать с какой-нибудь особо неприятной задачи — типа пока есть силы, ты её сделаешь, а дальше уже сам факт сделанности тебе придаст новых сил. Получается положительная обратная связь: чем больше сделал — тем больше сделаешь ещё.
Такая обратная связь работает не только в личной продуктивности, но и в командной. Студия Лебедева, к примеру, тратит силы на детальный анонс каждого, даже самого маленького проектика у себя на сайте, — и это даёт им огромную производительность. Люди видят, какие крутые вещи делает команда, частью которой они себя чувствуют — и делают ещё более крутые вещи.
Рассказывать о проектах довольно тяжело: нужно найти время на написание, убедиться, что мы не рассказываем ничего лишнего, согласовать это внутри себя и с клиентом. Испытал это всё на своей шкуре — мы с Саматом уже полгода (!) не можем рассказать об итогах своей работы с сетью клиник «Чайка», хотя я потратил на это кучу часов.
Верю, что в долгосрочной перспективе такие анонсы полезны — не только для качества жизни, но и для найма. При прочих равных, выбирая между нами и компанией, которая прячет свои работы, выберут нас.
Если руководите компанией — рассказывайте о каждом своём, даже самом маленьком успехе — тогда успехов станет больше. Если пилите пет-проекты — прямо сейчас соберите себе сайт-портфолио: удивитесь, насколько лучше и продуктивнее вы начнёте себя чувствовать.
#вопрос Расскажи, как борешься с выгоранием?
Я борюсь с выгоранием примерно так же, как с наркотиками или неразборчивыми связями — не ввязываюсь в это.
Допускаю, что существует форма усталости, после которой нужно приходить в себя полгода или год, но я такую усталость позволить себе не могу — у меня есть семья, партнёры и планы на будущее, и я не хочу чтобы они все ждали, пока я буду приходить в себя неизвестное количество времени.
Конечно, я периодически устаю до полного опустошения и даже впадаю в отчаяние — но при этом в организме работает предохранитель: я просто перестаю работать и отдыхаю. Буквально недавно я устал настолько, что пролежал целый день в тёмной комнате, не в силах встать с кровати — и на следующий день, как всегда и бывает, проснулся отдохнувшим и придумал решения всех проблем, которые ещё вчера казались неразрешимыми.
Надеюсь, если я продолжу внимательно слушать свой организм — не выгорю до пенсии.
Это был традиционный вопрос по понедельникам. Задать свой — fborshev@pm.me
Выложили подробный рассказ о том, как силами нашего с Саматом аутсорса построили новую LMS для школы (да, один мой бизнес — клиент у другого).
Описывали весь процесс — бизнес-требования, постановку задачи, выбор технологий, особенности кода и тестирования. Там же внутри статьи — ссылка на код: разработка с самого начала была открытой.
Читать ->
Хьюстон, у нас проблемы
Моё любимое средство контроля менеджеров — это регулярные встречи: раз в неделю по важным проектам, раз в 2-4 недели по менее важным. Просто встречаемся и рассказываем, что произошло, у кого о чём болит голова.
Удивительное наблюдение — когда менеджер несколько таких встреч подряд говорит, что на проекте нет проблем, всё хорошо и вообще всё готово на 73%. то скорее всего через месяц-два что-то серьёзно выстрелит. И наоборот — когда менеджер строит рассказ вокруг проблем и того, как он их решает, то какими бы сложными эти проблемы ни были, скорее всего проект запустится хорошо.
Возможно, где-то существуют менеджеры, которые умеют не тревожится по работе, говорят «риски» вместо «проблемы» и при всём этом умеют не проёбывать проекты, но я таких не встречал ни разу. Если менеджеры того типа, который встречаю я, не говорят о проблемах — значит они их скорее всего игнорируют.
Если мне выпадает работать с таким менеджером — я фокусирую его на проблемах, прохожусь по всем областям проекта: как себя чувствует команда? Какие проблемы видят ребята? Выполняем ли мы обещания и когда в последний раз переписывали план? Насколько доволен заказчик? Как быстро отвечает нам? Актуален ли наш проект для него?
Если менеджер умудряется просрать проект после всех моих вопросов и сигналов от команды — скорее всего он не очень восприимчив к действительности и просто не сможет вести наши проекты.
Ещё один смысл работать в маленькой компании
Недавно DHH запустил крутую штуку — mrsk (читается «мёрск»). Принимает на вход докер-контейнер, и в за одну команду собирает с ним прод на удалённой тачке по ssh: без кубернетиса, сварма и другой фигни. Потом этой же командой деплоит обновления. Название — офигенное: mrsk — отсылка к компании Maersk, крупному датскому оператору морских перевозок (DHH и сам датчанин). Типа Maersk доставляет контейнеры и mrsk доставляет контейнеры.
Так вот, mrsk переименовали! Судя по всему из-за нарушения торговой марки.
Так и представляю себе переговорку Maersk, где собрались PR-директор, директор по бренду, юрист по торговым маркам, начальник отдела коммуникаций и ещё десяток человек. Все умным видом обсуждают, насколько повредит это бренду и как побыстрее протащить бумагу с досудебным запросом к DHH через все ветви корпоративного согласования. И никто из них наверняка не стал доказывать коллегам, что это прикольно, что это никак не навредит брендингу.
Такие обсуждения в переговорках не ведут. Пёстрая компания из переговорки может договориться только до компромисса. Хотя каждый человек в отдельности скорее всего понимает смысла прикола, топить за него против коллег не станет — такой тяжёлый труд не стоит непонятного вознаграждения.
Гораздо легче прикольные идеи появляются и доводятся до запуска в маленьких компаниях. Просто в силу размера — там легче принять решение, проще достучаться до людей, которые могут что-то изменить, проще объяснить коллегам. Именно по этому в студию Лебедева часто обращаются финансовые учреждения — так гораздо проще привлечь молодую команду из ребят с незамутнённым взглядом, которые не променяют новизну на дизайн-систему, а «ценности бренда» будут воспринимать как тесные рамки, а не как руководство к действию.
Это одна из причин, почему ребята из нашей команды выбрали fands, а не условный сбертех: мы более живые, и путь от идеи до прода обычно никто не преграждает, кроме деда-Феди, который топит за Django.
Почему у нас нет соглашения о непереманивании
В кровавом аутсорсе и аутстафе принято с каждым новым клиентом, помимо договора об услугах, заключать ещё и NSA: non-solicitation agreement или соглашение о непереманивании. Типа, если сотрудник из аутсорса\аутстафа переходит на сторону клиента — клиент платит большой штраф.
Даже если отбросить юридические моменты (уверен, способы обойти эту фигню всем очевидны), такой договор мне кажется ущербным. Во-первых, это выглядит как форма крепостного права — я, как работодатель, ограничиваю волю другого человека работать там, где он хочет.
Во-вторых, сотрудники работают в компании явно не потому, что им запретили уходить. Кто-то работает потому, что ему нравится график. Кто-то ценит проекты, коллег, или индивидуальные договорённости по оформлению и зарплате. В fands, уверен, есть ребята которые ценят анонсы — когда-то я унёс из студии прекрасную традицию писать имена сотрудников под рассказом о каждом проекте. Ну или нашу открытую разработку.
Заключая с клиентом соглашение о непереманивании, я расписываюсь, что построил компанию, люди из которой не уходят просто потому, что их не зовут. И вместо того, чтобы починить проблему, я трачу силы на возведение вокруг неё забора — получается нечестно не только по отношению к сотрудникам, но и к себе.
Напомню, что завтра в 19:00 MSK будет первый, бесплатный, вебинар курса «Тестирование в Python». Обсуждая курс с учениками, мы услышали сомнение — оказывается мидлы и синьёры сомневались что курс им будет интересен и полезен. Типа наши темы лучше подойдут для джунов. Про ложную уверенность в себе у мидлов\синьёров я ещё расскажу попозже, а сейчас хочу напомнить, что наш курс — совсем не для джунов.
Джуны — это ребята, которые далеко не всегда умеют отличить хороший код от плохого. Грубо говоря, уже понимают про цикломатическую сложность (функция, которая не входит в экран по ширине — плохая функция), но ещё не понимают про coupling\cohesion, правильный нейминг, могут не ценить KISS.
Наш рассказ о том, как писать хороший код в тестах скорее всего плохо ляжет на базу, в которой ребята ещё не умеют писать хороший код в приложении. Может что-то и получится, но лучше бы всё-таки приходить мидлам\синьёрам.
Так что если вы джун — подумайте ещё раз, и точно не лезьте дальше самостоятельного тарифа. А если синьёр-помидор — бросайте гордыню и приходите послушать Никиту, будет полезно.
Сервисы: 1Password + GitHub Actions
Меня давно бесило, как хранятся секреты для Actions в гитхабе — чтобы добавить доступ к кластеру для CI\CD, нужно быть админом репозитория, или вообще организации в целом. Менять эти секреты хуже некуда — если 20 разных репозиториев содержат один и тот же приватный ключик, то для его ротации админ должен зайти в 20 проектов.
Недавно нашёл решение — оказывается 1password умеет транслировать секреты прямо внутрь Actions: достаточно прописать один токен в гитхаб, и всё управление секретами переезжает в привычный и подходящий для этого 1password. Получаем всё, к чему привыкли с обычными паролями — гибкие пермишены, логи изменений, и даже логи доступа к секретам.
В простом случае, чтобы раскатать новый сервис в новое место, разработчику вообще не нужен доступ никуда — он просто использует внутри Actions все, что сам же положил в 1password.
Конечно возникает проблема с безопасностью сервисного токена 1password, но ничего не мешает сделать десяток таких токенов для разных групп доступа — все они будут управляться в одном месте.
Только тесты и спасают
Несмотря на энергию, с которой я топлю за чистый код, за последние несколько лет мои команды сделали парочку довольно стыдных проектов — с непонятной архитектурой, ненужными или протекшими абстракциями, грязью в функциях. Сами ребята были нипричём — все проблемы вылезали из-за плохого общения с бизнесом: мы плохо планировали фичи, меняли планы на ходу и делали всё то, с чем каждый сталкивается постоянно, когда работает реальную работу, а не слушает доклады с конференций.
Горжусь, что несмотря на проблемы, проекты оставались управляемыми — мы пилили фичи, успевали в сроки, не нарушали обещаний. Выезжали, в основном, на тестах — когда все точки интеграции, бизнес-истории и ручки API покрыты тестами, у команды остаётся время, чтобы поразбираться с наверченными проблемами: что легко — починить, что сложно — попрятать или задокументировать.
Для меня, как для CTO, тесты остаются самой важной точкой контроля — если тесты есть и стабильно пишутся, значит проект не сдохнет от первой же проблемы с бизнесом. И наоборот — когда тестов нет и разработка постоянно катит говно — проблемы с бизнесом полезут сами и довольно быстро потопят проект.
Если вы пишете на Python и почему-то не попали на прошлый поток нашего с Никитой Соболевым курса «Тестирование в Python» — приходите 6 сентября в 19.00 по Мск на бесплатный вебинар, где мы поговорим о базовых вещах — либах, подходах и правилах. Даже если не пойдете дальше на курс — все равно получите пользу.
Вебинар начинает второй поток курса, обучение на котором стартует 11 сентября. Курс научит вас делать тесты, которые будут жить и помогать проекту — понятные и быстрые.
Последняя неделя целиком посвящена внедрению тестов в реальную жизнь — как прививать хорошие практики коллегам и сделать так, чтобы на тесты не забивали, как только вы от них отворачиваетесь.
Зарегистрироваться на вебинар →
Запись вебинара получат те, кто пойдут на курс, остальные смогут послушать и задать вопросы только в лайве.
Ну а если сомнений нет, то покупайте сразу весь. Сэкономите денег — после 6 сентября мы повышаем цены. Курс можно оплатить любой картой мира, от юрлица из любой страны или частями, используя сервис Долями.
Less is more
Удивительно, насколько менеджеры любят решать проблемы умножением сущностей вместо их уменьшения. Медленно идёт проект? Добавим людей! Сомневаемся, что продукт полезен аудитории? Добавим фичей! Программисты катят в прод фигню? Сделаем ручное тестирование!
Гораздо проще добавить на проект человека, чем найти проблему в коммуникации и, наоборот, удалить парочку лишних. К тому же не придётся принимать дополнительную ответственность — попробуй объяснить бизнесу, что команда из 5 человек работает быстрее, чем команда из 8.
Рабочий коллектив тоже одобряет увеличение энтропии — ни одного менеджера ещё не уволили за то, что он выбил на проект дополнительные ресурсы.
Или представьте себе тусовку владельцев бизнеса, где кто-нибудь жалуется, что не может найти правильного CPO? Конечно он получит сочувствие — каждый руководитель хоть раз был в похожй ситуации. А если честно рассказать, что не понимаешь, как управлять своим продуктом, не можешь уделить время анализу глубоких метрик и найти время на разговоры с пользователями? Скорее всего просто не поймут.
Менеджер, который бегает за всеми, чтобы запилить больше фич, выглядит человеком, болеющим за продукт. А менеджера, который предлагает фокусироваться на одной фиче, которая действительно нужна пользователям, и не тратить силы на остальные, оценят разве что в нескольких стартапах.
Кажется, что не делать вещи может быть гораздо ценнее, чем делать.
Day One → Obisdian
Несколько месяцев назад я решил отказаться от Day One, которым пользовался 5 лет для ведения дневника. Причин было несколько:
— Невозможные тормоза. Дело тут даже не в электроне, или на чём он там написан: кажется это просто плохой софт. Удивляюсь, откуда у их разработчиков берётся энергия, чтобы писать столько кода, чтобы тормозило даже на новом макбуке, где давно уже даже ноушен летает.
— Фокус на метаданных. Day One с самого начала обвешивает привычку писать дневник всякими ненужными вещами, которые не представляют интереса уже через ден — предлагает логать погоду, место и даже музыку, которую вы слушаете. Чтобы ненужных данных было ещё больше, Day One даже ломает паттерн, привычный людям уже несколько сотен лет — вместо обычных ежедневных заметок, вас заставляют писать по одному посту на каждое событие. Добавил фотку — пост, записал мысль — ещё пост.
— Переусложнённый формат хранеиня. Возможно следствие предыдущего пункта, но внутри у Day One довольно сложный формат хранения данных. Вроде бы и маркдаун, но он зарыт внутри довольно сложного JSON, который непонятно как парсить. То есть вроде бы я и владею собственными данными, но вот считать их без Day One я скорее всего не смогу. А если и смогу сегодня — никто не гарантирует, что я смогу повторить это через 10 лет, когда формат переживёт ещё 3 инкарнации, а контента в дневнике станет в 4 раза больше.
В итоге перешёл на Obsidian с синхронизацией через iCloud. Из его интерфейса легко удалось убрать всё лишнее — отключить штатные плагины вроде Canvas или записи аудио, попрятать ненужные детали интерфейса при помощи Hider.
Пару дней я помучился с переносом данных (немного пришлось поиграться с массовой заменой и дописать этот скрипт), зато сразу же стал писать в дневник гораздо больше — теперь не надо думать, как назвать пост, какие поставить теги: просто открываю приложение и пишу, прямо в момент когда пришла мысль. Вечером подвожу итоги — ставлю теги, форматирую, выделяю части текста в отдельные заметки, если это имеет смысл для будущего поиска.
Самое главное — теперь я уверен, что полностью владею своими данными — пачку маркдаун-файлов можно будет открыть хоть на квантовом компьютере.
GraphQL и тесты
Будучи разработчиком, я не любил GraphQL с самого его появления — из-за ноды, привязки к Apollo, отсутствия APM (если не покупать подписку у Apollo) и сложного, вложенного языка запросов. В принципе до сих пор ничего изменилось, но в этом посте я хочу отдельнло поговорить о своей любимой теме – тестировании.
GraphQL замечательно умеет делать одну вещь: вытаскивать данные с сервера в произвольном формате, удобном в каждый конкретный момент. «Выгрузи мне все книги — название, количество страниц, пару интересных цитат и автора, а у каждого автора покажи ФИО, фотографию и список популярных произведений» — это типичный запрос для GraphQL, с которым он справляется идеально. В REST для такой специфичной выборки пришлось бы писать отдельный эндпоинт, следить за ним и поддерживать. А тут даже кода писать не надо — один раз описал схему данных, и всё работает из коробки.
Минус в том, что вместо понятного набора эндпоинтов с заранее определённым поведением, мы получаем один эндпоинт на все наши данные. Тестировать такой эндпоинт очень больно. Первая проблема – контракт между бекендом и фронтендом: раньше мы могли написать батарею юнит-тестов, которые проверяют все возможные запросы, аутентификацию и авторизацию, а затем копипастить их для разных эндпоинтов, добавляя локальную специфику. Тесты для GraphQL так не могут — мы же не знаем, что у нас запросят в каждый конкретный момент, а значит не можем написать тесты, которые отражают реальность. Остаётся только делать тесты для типичных запросов, и надеяться, что когда фронт или бек что-то поменяет, программисты сами договорятся и друг-другу ничего не сломают.
Сложно тестировать не только контракты, но и прозводительность. Раньше мы для каждого эндпоинта могли предсказать количество тяжёлых запросов с джоинами, и даже ограничить их количество в тестах или в рантайме (по ссылкам питон, в вашем стеке будут другие инструменты). Теперь мы каждый раз не знаем, что у нас запросят, а значит можно выгрузить хоть всю базу за один запрос.
Конечно, есть бизнесы, которые выигрывают от умения отдавать по 20 сущностей на один запрос, и делают это своей core-ценностью — к примеру облачные BaaS или высокоуровневые headless CMS вроде Sanity. Но если вам надо просто отдавать на фронт десяток известных сущностей, даже если вы планируете добавить в будущем ещё пару десятков — скорее всего GraphQL обойдётся вам намного дороже чем обычный REST, потому что с самого старта вам придётся тратить намного больше сил на тесты.
Получили премию Digital Learning 2023. Часть 1.
Я ни разу не рассказывала на канале о нашем курсе-флагмане «Анализ систем» , в котором качаем навыки проектирования сложных систем. Потому что летом мы подали заявку на премию Digital Learning 2023, в номинации «Онлайн-курс» и мне хотелось дождаться результатов, чтобы подтвердить свои гипотезы успеха.
И вот в эту пятницу, была церемония, после которой, Федя прислал мне фотку с заветным первым местом в номинации «Онлайн программа»(сайт премии, еще не обновился). Я до сих пор в шоке и не могу подобрать слов, потому что основная часть участников — это большие компании с гигантскими ресурсами. Мы, малыши, обошли Сбер, МТС, РТК и других. Радуюсь вдвойне, в буткемп, который делала Ира Никулина под моим присмотром тоже забрал первое место в номинации «Смешанные программы». Ира, еще раз поздравляю вас! А команде — еще раз спасибо за то, что так вложились!
Я не рассчитывала на победу, но искренне согласна с ней, потому что курс у нас и правда крутой был. Далее расскажу почему 👇
Анализ систем: объявляем второй поток
В чатике выпускникнов школы примерно раз в неделю спрашивают, когда же будет второй поток «Анализа систем». Мы и сами хотели запустить скорее, но нужно время — нам отдохнуть, а контенту — отлежаться, чтобы на свежую голову можно было внести замечания, набранные на первом потоке. Наконец-то мы готовы — стартуем 15 ноября.
Основная механика та же — 5 уроков, построенных вокруг кругов профессионализма — каждый новый урок учит решать ту же задачу, что и предыдущий, но на новом уровне и для бизнеса с новым скейлом, с учётом предыдущих ошибок.
На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций, писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков.
Смотреть программу →
Оплатить можно любой картой мира или в рассрочку через «Долями». От юрлица тоже можно — пишите в чатик на сайте. До вечера воскресенья действует промокод M1KH41L на 10% скидки.
Невторкинг переоценён
Недавно задумался, что всю жизнь обхожусь без неворкинга в его привычном понятии — не тусуюсь на конференциях (выступил и домой), не хожу на афтепати, почти никогда не встречаюсь с кем-то без конечной цели, чтобы просто попить кофе. За весь свой опыт, все интересные предложения я получал либо от незнакомых мне людей, либо делал их сам — людям, с которыми не был знаком лично.
Освободившееся время я предпочитаю тратить на что-то более результативное — лучше напишу пост в блог или лонгрид, сделаю что-то полезное в бизнесе, займусь пет-проектом или хобби.
Связи, которые люди установят со мной, поизучав портфолио в блоге, будут явно сильнее и полезнее, чем связи, которые установятся просто потому, что мы оказались в одно время в одном месте.
Да, без нетворикнга не работает биздев — если вы продаёте b2b товары или услуги, и не придумали как взломать систему, то вкладывать кучу времени в знакомства с почти нулевым результатом — это ваша святая обязанность.
Ещё невторкинг — это в том числе и рекреационная активность: общаясь с людьми, можно отдыхать. Но в большинстве случаев между пополнением списка контактов в телеге и сидением в одиночестве, я выберу одиночество.
Снёс хром
Спешу поделиться радостью — месяц назад я наконец-то снёс хром и до сих пор не установил обратно. Последней каплей стало всплывающее окно, где мне рассказали, как безопасно теперь гугль будет записывать адреса сайтов, по которым я хожу — типа, чтобы понимать контекст, какую рекламу мне крутить.
Скрывать мне особо нечего, и я никогда не парился по поводу доступа корпораций к моим личным данным — но вот просто так согласиться, что разработчик браузера будет куда-то к себе записывать все страницы, которые я через него смотрю, я не смог.
Оставил Сафари как основной браузер, firefox как запасной и чистый Brave без профиля для web3. Конечно никуда не делся chromium-gost, но это моя специфика — вряд ли много кто вынужден использовать https-аунтификацию по отечественным сертификатам.
Кажется, на рынке браузеров всё не так уж и плохо: кроме того, что я перечислил есть ещё Opera и Vivaldi, которые хоть и работают на движке хрома, пока не настолько обнаглели как гугль.
А что ещё есть нормального?
Ласт-колл, больше напоминать не будем. Вебинар о developer experience будет уже завтра. Приходите, чтобы понять как системно избавляться от ерунды на работе. Если хотите разобрать свою собственную ерунду — лучше на тариф «с друзьями» .
Старт завтра в 19:00 MSK, ещё можно успеть оплатить от компании, если написать в чат на сайте и забронировать место.
Программистов должно быть мало
Я всегда топлю за то, что найм программистов — это последний способ решения проблем в разработке. Больше программистов == больше ФОТ и офис, излишняя коммуникация и микросервисы. Кажется, эту очевидную вещь понимает любой инженер, но не понимает бизнес — странно, да?
Причина простая: количество программистов — это параметр, которым бизнес, в отличие от других, способен управлять. Бизнес не предскажет, что изменится, если внедрить нормальный gitflow с тестами, отказаться от скрама и дейликов, и инвестировать время в инженерные практики. А вот если нанять программистов — что-нибудь уж точно изменится. Ну а если изменится не в лучшую сторону — можно и обратно уволить.
В fands мы договариваемся с клиентами о git flow и отсутствии ручного тестирования, ищем способы купить нормальные инструменты разработки и не заставляем людей ходить на дейли-митинги. Думаю, это одна из основных причин, по которым нам удаётся сохранить маржинальность выше той, что я вижу на рынке: при одинаковом количестве программистов, наши работают гораздо эффективнее.
По большому счёту, всё, что мы делаем — это системно работаем над Developer Experience: как UX-дизайнеры проходим весь путь программиста, от найма на работу и до периодической публикации на прод, и постоянно устраняем препятствия к продуктивности. Об этой штуке я уже пару лет говорю в каждом своём публичном выступлении и часто пишу здесь. DevEx — ключевая дисциплина для команд, занимающихся разработкой, гораздо важнее HR-бренда и печенек.
Рефлексируя над своей заботой о DevEx, я понял, что материала набралось как минимум на целый вебинар. Так что 11 октября в 19:00 MSK собираемся в зуме — расскажу обо всех наработках, которые позволяют сделать программистам удобно. Приходите, если вы — тимлид\техлид\CTO, ведёте джунов или просто хотите научиться делать удобно хотя бы самому себе.
Вебинар платный (но совсем не дорогой). Программа, детали и куча пеп тут.
Сделать с новостью ничего
Наблюдаю за суетой вокруг сторис в телеграме (кто не знает, теперь их можно постить от имени каналов, но только если подписчики за это проголосуют), вижу как многие забывают самую выигрышную стратегию, которую знает любой дед программист — делать с новостями ничего.
У нас постоянно выходят новые фреймворки, каждый из которых прямо сейчас перевернёт представление человечества о разработке. Появляются новые способы коммуникации между сервисами, новые базы данных, способы деплоя и языки программирования. Начнёшь реагировать хотя бы на 1% от таких новостей — превратишься в пионера, который ставит технологии выше бизнеса. Новизна новизной, а фичи надо пилить прямо сейчас.
Умные дядьки в реальном мире тоже так поступают: быстро на новости реагируют сами ньюсмейкеры, ну или те, у кого такое реагирование — core-часть бизнеса. Вторые — это либо медиа (новость-спецпроект-давай-давай), либо маститые ребята вроде Контура: если правительство завтра введёт маркировку навоза на свинофермах, окажется, что Контур уже два года пилил код, чтобы стать Оператором Навозных Данных.
А большинство «розничных» чуваков, которые прочитали новость на vc и пытаются срочно что-то с ней сделать, ведут себя так же глупо, как розничные инвесторы, которые продают на плохих новостях и покупают на хороших — просто играют в лотерею, забывая о вещах, которые важны прямо сейчас.
#вопрос расскажи про теорию ограничений в IT разработке. Пользуешься ли ты ей в работе? И каково твое мнение о ней? Стоит ли применять?
Да, использую и всем советую. Расскажу подробнее.
Как и любая другая теория для менеджеров, сама по себе теория ограничений не даёт конкретных рекомендаций — она скорее учит оценивать вещи под новым углом. Смысл теории ограничений в том, что любой системе, чтобы выполнять свою цель (к примеру зарабатывать больше денег или выдавать больше фич), мешает всего одно ограничение — и укрепление других ограничений не приведёт к улучшению системы в целом. Как с цепью: цепь может выдержать столько веса, сколько может выдержать её самое слабое звено. И как не укрепляй более крепкие звенья — цепь крепче не станет.
В базовом применении мы все используем теорию ограничений, когда, к примеру, не нанимаем на работу бекендеров, если в бизнесе не хватает фронтендеров, или не притаскиваем новые линтеры в кодовую базу проекта, у которого горят сроки. Смысл книг Голдардта как раз в том, чтобы научить менеджера находить такие перекосы — часто они бывают довольно неочевидными.
Если не читали Годрадта — обязательно почитайте Цель и Цель-2: читаются они легко и с гарантией заставляют под новым углом смотреть на решение вроде бы привычных управленческих проблем.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Синьёры и тесты
Помимо самостоятельности и умения закрывать бизнес-задачи, синьёр отличается от мидла ещё и тем, что повидал много говна. Джанговские синьёры знают, что нельзя даже близко подходить к GenericRelations, vue-синьёры успели пообновлять nuxt.js на проде и поэтому делают SSR сами.
Давая бизнес-задачу такому синьёру, можно быть уверенным, что он если проект и провалится, то не из-за технологий: скорее всего фреймворки и подходы будут если не самыми лучшими в индустрии, то уж точно общепринятыми.
К сожалению, такая взрослость обычно не касается тестов. Много синьёрных тест-сьютов на моей памяти превращались в длинную и запутанную кашу, пусть и разбитую на функции\тесты. Базовую задачу такой тест-сьют конечно выполнит — если программист что-то сломает, о проблеме ему всё-таки сообщат. Но вот качество такого сообщения оставит желать лучшего. Как звучит бизнес-история, которая сломалась? В каком контексте она выполняется? Точно ли она теперь сломана для бизнеса?
Чтобы тесты сохраняли ответы на все эти вопросы, тесты должны быть понятно названы и хорошо сгруппированы, состоять из короткого сетапа, который прячет всю сложность от конечного разработчика, понятного действия, которое выражено на языке бизнеса, и читаемого асёрта, из которого ясно, что было в голове у автора. Поддерживать такой порядок на протяжении всей жизни проекта — сложная работа, на которую легко забить: тесты пишутся, покрытие не падает — и ладно, пофиг что тесты не читаемые.
Лучше всего эту проблему решают технологии: если с самого начала жизни проекта показывать команде удобно построенный фреймворк для тестов, из которого понятно, как тестировать новые бизнес-требования, прятать сложность, делать тестовые фабрики и вообще писать лаконичный код — скорее всего тесты будут нормальными и без сложного код-ревью.
Ну а если ваши синьёры пишут на питоне — приводите их к нам на второй поток «Тестирования в Python». Сегодня вечером — первая встреча-знакомство, ещё можно запрыгнуть.
#вопрос Бесят деды на работе. Предлагаю им новые технологии — а они давят авторитетом и блокируют, как будто им ничего нового и не нужно. Что делать?
Во-первых, сочувствую вам — всегда тяжело, когда интересную работу, которую вы сделали с большой мотивацией, умножают на ноль люди, у которых есть власть. Опускаются руки, хочется больше ничего не делать или наоборот, идти и делать свой бизнес, где никто ничему не помешает.
В любом случае, посоветую вам смириться с тем, что сложные задачи, на которых можно одновременно отрабатывать навыки и получать за это деньги, всегда идут в комплекте с требовательными тимлидами, дедами, синьёр-помидорами, представителями бизнеса которые ничего не понимают в ИТ и собственниками бизнеса, которые обладают неограниченной властью в любой компании. И есть всего два варианта — либо встраиваться в эту систему и учиться договариваться, либо пилить пет-проекты, надеясь стать прийти к one-man software business.
Если выбираете первый вариант — учитесь договариваться с дедами. За один пост мне сложно дать нормальный ответ как это делать — мы с Марьяной вообще обсуждаем целый курс с условным названием «как продавать свою идею». Если вкратце — вы не продадите дедам того, что они сами не хотят.
Хотите новый фреймворк — выясните какие проблемы есть у дедов в текущем. Решает ли их ваш фреймворк? Если да — продемонстрируйте, как красиво и круто он это делает, заинтересуйте их.
Деды — ребята консервативные, но обычно за этим консерватизмом стоит не старческая уверенность в своём опыте, а довольно большой опыт, которым глупо пренебрегать. Пример: я на правах деда топлю за Джангу в нашей компании, но когда у меня заболит производительность, которую можно будет вылечить через asyncio, или мне понадобится десятками штамповать простые сервисы на похожем шасси — я с радостью поддамся уговорам про FastAPI.
Так что удачи вам на нелёгком пути поиска невыдуманных проблем!
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
#вопрос Что думаешь об No-code платформах вроде Zapier, Appwrite, Nocodb? Пробовал ли их использовать и можно ли их использовать на продакшене?
За два года моё мнение сильно не поменялось, я по-прежнему считаю, что no-code — это техдолг. И по-прежнему продолжаю затаскивать no-code решения к нам в школу — мы всё ещё не завели отдельную разработку, поэтому все свободные силы тратим на подключение систем, которые позволяют пилить фичи без разработчиков. Это полноценная, довольно сложная работа. Архитектурно вся система должна соблюдать баланс: с одной стороны не зависеть от вендора, а с другой — не писать много кода на своей стороне.
К примеру, мы интегрировались с сервисом рассылок dashamail так, чтобы весь таргетинг был у нас: мы генерим теги для пользователей на основе своих данных, а в dashamail прокидываем только контакты подписчиков. Таким образом, мы можем собирать произвольные сегменты для рассылок, но при этом можем за несколько дней заменить дашу на любой другой сервис.
Сейчас интегрируемся с AmoCRM, чтобы в одном информационном пространстве собрать информацию о сделках по корпоративному обучению и о студентах, которые приходят напрямую. Здесь тоже есть хитрость — приходится нормализовать данные на своей стороне, переводя их к максимально универсальным сущностям, чтобы не зависеть от AmoCRM как от вендора. К примеру у нас на каждую попытку купить курс, создаётся новый заказ, и если прокидывать эти данные как есть — сломается прогноз продаж: ведь из 10 переданных заказов ни при каких условиях не будет оплачено больше одного, а AmoCRM будет думать, что оплатить могут все.
Увы, наш случай — довольно редкий. Чтобы наш no-code работал и менеджеры могли мышкой натыкивать нужный workflow, приходится делать много подкапотной работы, которую в обычных условиях малого бизнеса делать некому — фаундер не станет думать о каплинге и идемпотентности, а программист не станет разбираться в бизнесе.
Так что в большинстве случаев, no-code — это техдолг.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Удостоверение тимлида
Постоянно встречаюсь с программистами, которые вроде бы хотят возглавить проект или команду, но чего-то ждут. Вроде и турбина под хвостом имеется, и умение общаться с людьми уже на достаточном уровне, и даже запрос на ответственность в команде есть: приходи и забирай. Но они ждут. Формально ждут разрешения на руководство, типа придёт босс и выдаст удостоверение тимлида. Неформально — просто боятся.
Так, увы, не работает. Если руководитель сам к вам пришёл с ведром ответственности в руке — скорее всего его уже всё очень сильно допекло, и вашу кандидатуру он выбрал не потому, что вы больше других достойны, а потому что меньше других недостойны.
Если хотите взять ответственность — берите, а не ждите, что вам её принесут. Это и есть самая сложная часть профессионального роста — научиться брать столько ответственности, сколько по силам. Сначала — ответственность за себя: научитесь делать что наобещали. Потом — ответственность за своё окружение: если бекендер не даёт вам нужную ручку в API — научитесь не бегать к менеджеру или ждать дейлика, а разбираться в причинах и помогать их исправить. Потом — за проект: если вы лучше других знаете, что за чем лучше делать — почему бы не применить это знание на практике? Можете взять ещё больше — отлично: в любой команде нужно заниматься джунами, общаться с бизнесом, пропихивать исправления техдолга, договариваться с соседними отделами.
Если всё это делать потихоньку, постоянно увеличивая нагрузку, когда вам принесут удостверение тимлида, вы уже не будете в нём нуждаться. А самое главное — так станете не вынужденным руководителем, которого поставили потому что никого другого не смогли, а настоящим: со своим уникальным набором скиллов, который будет работать в любой другой компании, в том числе и вашей.