25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
«Стать тимлидом 2.0»: будет, но не в декабре. Плюс история о том, как строить контент в курсе
Каждый год, с момента появления Школы сильных программистов, мы с Федей открываем продажи на новый наш курс. В позапрошлом году был «Самому не проще», в прошлом «Есть минутка», в этом должен был быть «Стать тимлидом 2.0». Но в этом декабре мы не откроем запись на новый поток.
История такая: с тимлидского курса у нас началась школа и его полюбили очень многие. Мы провели 4 потока в течение пары лет и закрыли его, несмотря на прибыльность и потрясающие отзывы. Мы почувствовали, что перестали заряжаться, проводя его. Но энергия эксперта в курсе очень важна — поэтому решили, что надо отложить и дать время отлежаться.
Все это время, каждую неделю нам писали люди и спрашивали, «когда-когда будет курс, очень надо». И этой осенью, заново перечитав контент, поняли, как сильно мы выросли и что теперь хотим совершенно по-другому сделать курс. Раньше было так: есть 5 недель, в течении которых, человек получает знания из разных дисциплин. Например, на первой неделе — он учится вести переговоры, на второй — нанимать/увольнять, на третьей — разбираться с процессами и т.д. И это вполне рабочая схема.
Но, в жизни все не так. Это устаревшая модель: так мы учились в институте или школе, а потом сложно было это все уложить в голове и тем более применить. Когда ты становишься тимлидом, никто не ждет, пока ты пройдешь очередную дисциплину и начнешь ее реализовывать. У тебя команда, с которой нужно что-то делать: то с тебя спрашивают какие-то решения, то зовут на встречи, что требуют стратегию. А ты вчера то вообще то код писал или картинки рисовал и никого не трогал.
И именно с этой позиции мы решили строить курс. Ты решаешь определенные задачи и повышаешь уровень сложности. Эту схему мы частично протестировали на «Анализе систем», который принес нам премию Digital Learning, а сейчас поняли как дальше эту идею развивать. Мне кажется, это именно то, что поможет быстрее онбордится и брать ответственность в новой роли, а для прокачанных — позволит быстрее находить слабые места.
Посмотрев на текущий контент под этим углом, мы поняли, что нам нужно переделать примерно все) А еще появились темы, на которые хочется поговорить, потому что как же без них) И даже уже собрали список типовых спикеров для ланчей. Еще хочется другую практику — где вы сможете выгулять все темные стороны тимлида и посмотреть на свою роль с других углов.
В общем, по законам продаж, я должна была поставить ссылку на запись, чтобы срубить бабла в декабре, но мы обсудили с Федей, что не хотим переделывать курс под давлением. Хоть и новый лендос уже почти готов (он такоооой красивезный получается, на мой взгляд, лучший лендос школы в исполнении нашего дизайнера).
Поэтому поставлю ссылку на вейтлист в старом лендосе, пока на новом не прикручена форма сбора емейлов. Записывайтесь, если ждете запуск и хотите получить лучшие условия. Запуск планируем примерно на февраль.
В этот раз у меня есть мысль сделать ограниченное количество участников, чтобы лучше проработать разные кейсы.
#фичи_курсов
Так, советую ещё один канал — Дизраптор. Хоть в канале и много новостей, читать его интересно — автор не перепечатывает тексты из более быстрых изданий, а делает домашку: к каждой новости добавляет своё мнение — посмотрите про зумеров и алкоголь, к примеру.
Кроме новостей автор пишет лонгриды — посмотрите про китайский подход к инновациям или про абсурдные продукты, которые выстрелили.
Получается такой виси.ру, но имени одного человека а не кучи разных авторов, которые пытаются нагнать себе трафик. Ну и без корпоративных блогов.
В общем если хотите быть в курсе актуальной движухи, но не читать десятки новостей — рекомендую @disruptors_official.
Это не реклама, но я должен указать ИНН 772821456016 erid LjN8KGm4t
#вопрос Расскажи, как ты общаешься с людьми, которые приходят с заявлением об увольнении? Отговариваешь?
Конечно нет! Если разговор начинается с решения уволиться, то единственно верное продолжение — это обсудить детали: дату ухода и список дел, который к ней нужно завершить. Конечно, в процессе разговора я пытаюсь узнать о причинах — чаще всего честно рассказывают, почему компания перестала подходить (переезд\смена нагрузки\стека\жизненных приоритетов), иногда сигнализируют о важных проблемах в компании.
К уходу людей нужно относиться, как самурай к смерти — любое сотрудничество рано или поздно заканчивается, и я должен быть к этому готовым: и морально, и с точки зрения операционной деятельности. Когда я готов к увольнению сотрудника, разговор строится легко — я не злюсь, готов придумывать максимально комфортные обоим сторонам способы расставания. Комфорт здесь вообще очень важен — люди доверяют рекомендациям, и если сотрудник уходит довольным, то он вполне может порекомендовать себе замену, да ещё и хорошо продать этой замене нашу компанию.
Были у меня и плохие расставания — пару раз я, как опытный социопат, избегал разговора об увольнении: просто принимал заявление и отпускал — не видел ценности в разговоре или был занят другими критичными вещами. Немного жалею о них — когда несколько лет проработал с человеком бок о бок, можно поговорить об этом хотя бы полчаса.
Это был традиционный ответ на вопрос по понедельникам. Задавайте свои на fborshev@pm.me
iPad как устройство для одиночества
В августе я доработался до DoS — не мог не только начинать новые вещи, но и просто отвечать на запросы. Чтобы вернуться в нормальное состояние решил недельку побездельничать на море, и тут же встала проблема — а какие устройства с собой брать?
Обычно я вожу с собой тот же макбук, на котором работаю дома в clamshell mode — так у меня всегда с собой привычная рабочая среда, просто с небольшим монитором. Но в этот раз я боялся, что опять вернусь к работе — и вся поездка пойдёт насмарку. Не брать с собой ничего тоже нельзя — а что, если мне захочется поработать с текстом? Телефон для этого не подходит — даже большой экран айфона довольно сильно замедляет редактирование. Потупить в ютуб тоже хотелось, и телефон для этого тоже подходит слабо.
В итоге в последний день перед отъездом купил себе недорогой айпад с клавиатурой. Поставил на него IA Writer, Bear, Obsidian и приложение ютуба. Почту с телегой ставить не стал, чтобы под рукой не было вообще никаких средств коммуникации. Сработало отлично — я на неделю отключился от работы, при этом у меня оставлось удобное устройство для творчества и отдыха.
С тех пор айпад так и работает — туплю в него когда устал, а когда силы есть — пишу тексты и длинные таски. Самый кайф — пойти куда-нибудь, взяв с собой только айпад: так у меня нет никакого шанса поработать или уйти в разговоры с кем-то — я могу только производить, но не потреблять.
Кажется, это можно использовать как паттерн: если часто прокрастинируете и тратите время на одну активность вместо другой, к примеру тупите в ютуб вместо работы — попробуйте разделить эти активности по устройствам. К примеру оставить работу на ноутбуке, а ютуб на планшете. Если сел за ноутбук — там только работа. Сел за айпад — там только тупняк.
#вопрос Должны ли только программисты руководить программистами? Или менеджерам тоже можно?
Отвечу как Антон Давыдов — это зависит.
В первую очередь — от бизнеса, для которого работает команда. Если трое опытных программистов пилят какой-нибудь плагин для постгреса — руководитель с технологическим бекграундом наверное подойдёт лучше. Если десяток программистов гребёт на маленькой аутсорс-галере — там конечно нужен менеджер: кто-то должен вести коммуникацию с заказчиком, выставлять счета и получать по ним деньги.
А ещё выбор менеджера зависит от людей в команде. Есть программисты, которые презирают не-технарей в ИТ и не готовы с ними работать (зря!). Есть менеджеры, которым настолько неинтересно погружаться в программистское задроство, что они с большей радостью возьмут руководство какими-нибудь дизайнерами.
Если расскажете чуть подробнее про бизнес и команду — буду рад дополнить свой ответ.
Это был ответ на традиционный вопрос по понедельникам. Задавайте свои на 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.
Электронный документооборот
Ещё 5 лет ни одна компания в России просто не могла работать без бумаги: нужно было хранить кипу договоров, счетов и актов с клиентами и подрядчиками. С сотрудниками приходилось подписывать НДА, договоры и приказы, умножая всё это на два, если в компании приняты странные методы оформления, типа ГПХ или оплаты на ИП. Компании покрупнее держали у себя в штате курьеров, помельче — платили условной Достависте.
В 2023 году нет никакого смысла подписывать хотя бы один рабочий документ на бумаге. Дальше сервисы Контура, но наверняка есть аналоги:
— Диадок для работы с подрядчиками и ИП
— Контур.Сайн для работы с физлицами и самозанятыми
— Контур.КЭДО для кадровой документации, всяких приказов и заявлений на отпуск
И всё это с приемлемым API, которое легко встраивается в любую информационную систему — интеграция Бейскемпа с Диадоком, к примеру, заняла пару дней.
На бумаге работаем только с олдфагами — большими компаниями, которые ещё не победили юристов у себя внутри. При этом расходы на таких клиентов гораздо выше, чем на ЭДО — нужно платить курьерам, как-то организовывать передачу документов, проверять что курьеры их не потеряли, а клиент не забыл отправить обратно, хранить это всё в архиве.
Я совсем перестал находить силы на лайвкодинг — почти не пишу код, а когда и пишу, то делаю это урывками.
Если кто-нибудь соскучился — ребята с PiterPy выложили два часа, которые я записал прошлой осенью: в реальном времени показал, как начинать проект на Django, на который потом придут джуны и всё поймут.
Вот — первая и вторая часть.
mysql-backup-s3
Я тут запилил новый инструмент — в дополнение к такой же тулзе про постгрес, сделал докер-образ для периодического бекапа MySQL в облако (мы юзаем backblaze).
Самый типичный юзкейс — когда у вас нет сложной инфраструктуры с физическими бекапами, сложными планами и вендорами с SLA, а бекапить данные из БД надо. Просто берём образ, втыкаем его в любимый оркестратор и получаем рабочий бекап. Образ весит всего 70 метров, понятно настраивается, поддерживает вебхуки для мониторинга бекапов.
Буду благодарен, если потестите у себя и напишете что-нибудь в issues — https://github.com/f213/mysql-backup-s3
После работы в ГдеМатериале я чётко решил, что венчурная история — не для меня. Бутстрапный бизнес «на свои» с понятными результатами в обозримой перспективе мне кажется гораздо более выгодным и интересным, чем стартап с призрачным шансом что-то поменять во вселенной (ну или хотя бы заработать ОЧЕНЬ МНОГО денег). Отчитываться тоже гораздо приятнее перед самим собой, чем перед дядьками из венчурных фондов, насколько бы умнее меня они ни были.
Однако прожитый в стартапе опыт заставляет меня с уважением относиться к людям, которые осознанно выбрали эту дорогу. В рамках дружеского пиара хочу порекомендовать канал Кирилла Куликова — фаундера стартапа Beau из портфеля Y Combinator. Если хотите кучу личного страстного опыта — проматывайте на самый верх и читайте всё подряд: материалы, как и здесь, почти все — вне времени.
В последний год Кирилл много пишет про эмиграцию — начиная с оценки своего потенциала и заканчивая рассуждениями о востребованности русских мужчин за границей. Ещё Кирилл, как и я, — фанат пустого инбокса, и довольно неоднозначно относится к ноу-код решениям.
В общем подписыватесь — @kyrillic.
Это не реклама, но я должен указать ИНН 027410486358 erid LjN8KMURB
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