25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
Придумыватель и делатель
Есть (была?) такая опенсорсная прошивка для карманных фонариков — Anduril. Штука очень крутая в инженерном плане — позволяет при помощи одной кнопки управлять любыми аспектами работы фонаря — переключать режимы переключения (!) яркости, ставить таймер засыпания, крутить терморегуляцию и настраивать цвет светодиода на кнопке.
Правда, у неё есть серьёзная беда — понять что-либо в ней невозможно, не прочитав огромную и невнятную инструкцию. То есть вроде бы и круто, но в реальной жизни — полезно только паре гиков (про muggle mode знаю).
Такие продукты обычно и получаются у хороших инженеров — крутая, может быть опенсорсная реализация, и полный ноль в пользовательских качествах. Так происходит потому, что почти невозможно совместить в человеческом мозге два режима деятельности — придумывания и реализации. Приходит в голову идея новой фичи, а ты не успеваешь даже подумать насколько она вообще нужна пользователям — сразу включается инженер и начинает думать про реализацию: что поменять в проекте, чтобы фичу было удобнее делать.
Сам я постоянно натыкаюсь на такую проблему в школе — до сих пор пишу сам некоторые куски, связаные с админкой бекофиса, где мы управляет возвратами, b2b-сделками и материалами уроков, и постоянно ловлю себя на том, что начинаю писать код, который совершенно не нужен команде.
Когда одновременно пишете код и принимаете решения, нужно научиться отличать себя-придумывателя от себя-делателя. Придумывателю категорически нельзя давать в руки никакие инструменты, чтобы не начинал работать. Делателю — не давать задачи с сомнительной пользой, а то он настругает кода, который потом не выпилить.
Форма, функция и красота
В «Коммуникации Систем» мы говорим о понятиях system form и system function. Форма — это как система выглядит: на какие модули разбита, с какими данными работает. Функция — то, что система делает: как реагирует на ввод, что отдаёт на вывод.
Для меня форма и функция выходят далеко за рамки айтишечки и даже проектирования систем. Это, скорее, про красоту. Вещи, в которых форма подчинена функции — красивы. Вещи, в которых функция размыта, а форма сложна — некрасивы и неприятны.
К примеру макбуки, Dell бизнес-серий, дорогие thinkpad — красивы: дают много возможностей владельцу и не отвлекают формой. Игровые ноутбуки и всякие дешёвые асусы — некрасиво, потому что их главная функция — блистать на полке в магазине. Есть и исключение — Framework: вроде бы и красивые штуки, но вот функция, которую они выполняют, — быть ремонтопригодный в домашних условиях, — вряд ли понадобится кому-то в здравом уме.
А сколько же на улице некрасивых машин! Дорогие немцы, в большинстве своём — некрасивы: функции размыты, а форма требует постоянного обслуживания. Исключение — разве что Майбахи, заточенные под перевозку одного пассажира, или BMW M-серии, сделаные для кольца: с такими функциями можно и хрупкую форму потерпеть. Маленькие SUV, которыми забит рынок — некрасивы: форма как у дешёвых ноутбуков, пригодна только стоять в автосалоне и говорить неискушённому потребителю «не думай, купи меня, я сгожусь на любой случай жизни».
У меня чувство прекрасного отдыхает на утилитарных пикапах вроде Toyota Tundra или том, что в штатах называют «траками»: они много возят, когда надо — быстро едут, а простое шасси и атмосферный мотор будут хоть 20 лет выполнять свою функцию. Очень красивы велосипеды на которых ездят курьеры: быстрые, лёгкие, ничего лишнего.
Глядя на форму, можно определить функцию, которую туда закладывает автор. Так, по названию хорошего класса в коде понятно, что он делает, а по первому экрану приложения видно, чего от него хотели авторы.
Форма эволюционирует вместе с функцией. К примеру Медиум когда-то был отличным средством для публикации лонгридов, а в процессе эволюции превратился в пейвольную помойку — очевидно, новая форма стала более выгодна владельцам. Или взять любой продукт Яндекса — почти везде его функция со временем перестаёт интересовать владельцев. Так навигатор превратился в тормозные «карты», а сервисы доставки еды и такси превратились непонятно во что: «экосистема» это что-то на шейрхолдерском, а не на пользовательском.
Когда проектируете что угодно — архитектуру системы, пользовательский опыт, пост в тг-канал — сначала подчиняйте форму функции, а потом уже думайте об украшениях.
---
О проектировании рабочей среды программистов говорим в курсе «Без Ерунды». Поток стартует 31 июля.
eslint-config-fans
Наши фронтендеры релизнули свой конфиг для eslint.
Я обычно не верю во внутренние инструменты, которые публикуют аутсорсы — их кайфово делать, но очень тяжело поддерживать. Нашему шаблону django уже 5 лет, и каждое крупное обновление — это целый проект со сложным обсуждением и торговлей за ресурсы.
Конечная ценность у внутренних инструментов тоже сомнительна. Вкладываться в них было бы полезно, если бы аутсорс работал как конвейер: к примеру клёво иметь хороший стриминг данных в elastic/meilisearch, когда релизишь по 5 ecom-стартапов с фасеточным поиском за месяц. В реальности такого нет — любую работу, которую можно настолько ускорить, давно уже делают не людьми, а сервисами. А живым людям остаётся медленный, штучный проект, который никакими шаблонами не ускоришь.
Релизы отечественных коллег я вообще обхожу стороной — код там обычно такой, который и ожидаешь от аутсорса: запутанный и безответственный. Золотые исключения — Evil Martians (правда не знаю, насколько они сейчас отечественные) и wemake.services (не знаю, насколько они сейчас аутсорс).
Для меня единственная мотивация делать внутренние инструменты — это простое «потому что могу». Ну и желание делать свою работу хорошо. Мне нравится руководить аутсорсом, в котором есть шаблоны, которые транслируют наши подходы — и на бекенде, и на фронтенде.
Кароч, насыпьте звёздочек ребятам — https://github.com/fandsdev/eslint-config-fans
Ждать, пока выплывет
В онбординге людей есть две крайности. Первая — обложить инструкциями и гайдами, приставить бадди и вообще всячески сопровождать. Вторая — «бросить в воду»: оставить человека одного и ждать, что он сам научиться решать задачи и задавать вопросы.
В FANS я тяготею ко второй. Это специфика remote-first—компаний: если человек с самого начала приучается общаться с бадди, он и потом будет искать себе «бадди» и назначать по созвону на каждый вопрос.
Наша специфика тоже есть: мы как аутсорс делаем ставку на самостоятельных программистов, которые могут работать автономно, иногда напрямую с клиентом. Такой человек уж точно должен уметь решать задачи в новых средах.
Конечно, бросание в воду не снимает ответственности с руководителя. К примеру, так же как и в детском саду, нужно выпиливать из компании знания, требующие передачи, а те, что не удалось выпилить — превращать в инструкции. Точно так же нельзя оставлять человека в полном одиночестве — так даже у самого самостоятельного в мире человека поедет крыша.
Конечно, при жёстком онбординге есть риск потерять каких-то людей, которые могли бы стать самостоятельными когда-нибудь потом. Но кажется лучше ошибиться и потерять хорошего человека, чем не ошибиться, но взять балласт.
Sold out на «Коммуникации систем»
Обычно мы закрываем запись в день начала обучения. Сейчас закрываем раньше — на выходных мы набрали столько, сколько хотели. Возьмём больше — придётся жертвовать качеством.
Обычно продажи закрывают без предупреждения, но мы так никогда раньше не делали. Поэтому закрывать одним днём будет нечестно. Если хотели запрыгнуть в последний вагон — до вечера ещё можно купить. Если вас будет слишком много — закроем раньше. Следующий поток будет в конце года, до этого можно будет купить самостоятельный тариф.
У меня нет цели обострить этим постом FOMO или ещё как-то нарастить продажи — нам хватит. В будущем о солдаутах будем предупреждать раньше и со счётчиком.
Спасибо вам за доверие! Надеюсь, оправдаем
Иногда надо заплатить побольше
Есть много услуг, в которых плохое качество — это стандарт:
— Недвижимость с огромным количеством риэлторов-бездельников
— Ремонт и стройка, где принято обманывать с ценой и сроками
— Массовые сервисы для бизнеса — регистрация юрлиц, бухгалтерия.
— Визовая поддержка — на массовых кейсах вроде краткосрочных шенгенов принято делать свою работу едва ли не хуже, чем на стройке.
— Аутсорс-разработка. Ну тут всё понятно, кек.
Находишь на таком рынке поставщика, а он тебя обманывает. Идёшь к другому — он тоже обманывает. На третий раз решаешь, что «так принято», вздыхаешь и миришься с дерьмом.
Несмотря на принцип не работать с мудаками, когда я ушёл в свой бизнес, я на это забил. Нужно было сразу получить много разных услуг, и не было сил разбираться — вот и привык. Терял на этом кучу времени. Классический кейс — поиск бухгалтера в центральной Азии. Было даже хуже, чем я привык — один бухгалтер в какой-то момент пропал настолько, что не брал трубку несколько месяцев, а потом даже перестал выставлять счета (надеюсь, у него всё хорошо).
Когда мне это совсем надоело, включилась сила воли — и я нанял бухгалтера на х3 от рынка, с которым сразу договорился, что если тот начнёт меня игнорить и не выполнять обещания, то мы с ним расстанемся. До сих пор всё хорошо.
Кажется, сработал простой принцип — чем услуга более дорогая, тем менее она массовая. А значит каждый клиент стоит гораздо дороже. То есть моя угроза расстаться с бухгалтером, которому я плачу х3, стоит в три раза дороже, чем такая же угроза от среднерыночного клиента.
К сожалению, в совсем массовых услугах, вроде недвижимости и стройки, не работает и это — поток людей, которые обращаются к риэлторам «чтобы всё было надёжно» и мирятся с прорабами-мудаками, не иссякнет никогда. А вот в более штучных услугах — вполне работает.
Правда, предлагают такого мало: чтобы найти исполнителя, который готов оказывать качественную услугу, надо включать голову и долго-долго искать.
——
Ещё можно оплатить по безналу «Коммуникацию Систем» — обновлённую «Асинхронную Архитектуру» с Антоном Давыдовым. Стартуем 28 мая
В четверг, в 16:00 MSK будем с Антоном Давыдовым отвечать на вопросы о «Коммуникации Систем». Расскажем чего ждать на курсе, как будет проходить обучение и что поменяли со времён «Асинхронной Архитектуры» (спойлер: всё).
Встречаемся прямо здесь 15 мая в 16:00 MSK, будет видео-стрим. Записи не будет.
———
А ещё сегодня вроде как значимо поднимаются цены, но на сайте до сих пор не поменяли, так что го покупать, если хотите сэкономить
Не сделать страшнее, чем ошибиться
Бывают люди, которые ошибаться не любят меньше, чем не выполнять обещания. Программисты не улучшают код в проекте, потому что боятся критики; менеджеры не пинают подрядчика, потому что боятся, что он уйдёт; руководители не принимают решений, потому что боятся ошибиться.
Если вы из таких, хочу напомнить простой принцип, который работает не только в предпринимательстве, но и в работе по найму: пока не сделаешь — не узнаешь, прав ты или нет. Лучше выложить ПР и узнать, что он не ок, чем держать в себе желание что-то изменить и страдать от плохого кода. Лучше поставить ультиматум подрядчику, чем терпеть дерьмо.
Если вы не управляете ядерным реактором, ошибки — это нормальная часть рабочего процесса. Совершаете ошибки — работа идёт. Не делаете ничего, потому что боитесь критики — работа стоит. Не помню, когда последний раз увольнял человека за ошибки. А вот за то, что не делает то, что должен, я увольняю довольно часто.
—
Набираем на первый поток «Коммуникации Систем» — обновлённую «Асинхронную Архитектуру» с Антоном Давыдовым
Коммуникация Систем: переписали «Асинхронную Архитектуру»
С Антоном Давыдовым мы начали работать ещё 2021 году, превратив его воркшоп о коммуникациях внутри Event-Driven систем в продукт, который так и назвали «Асинхронная Архитектура».
Прошло время, Антон вырос как эксперт и накопил материала о проектировании, и мы сделали с ним наш текущий флагман — «Анализ Систем». Курс получился крутым и ценным, и с «Асинхронной Архитектурой» почти не пересекался. Тем не менее в линейке образовался существенный пробел — в курсе «Анализ систем» мы говорим о разных архитектурных стилях, почти не касаясь коммуникации в них, а в «Асинхронной архитектуре» говорим о коммуникациях, но только для одного архитектурного стиля — Event Driven.
Наконец-то мы решили эту проблему и запускаем новый курс с Антоном — «Коммуникация систем». Он включает в себя сжатые и переработанные материалы из «Асинхронной Архитектуры» и добавляет кучу полезных инструментов, которые помогают проектировать коммуникации между разными частями сложных систем.
На курсе учимся строить модели данных, проводить Event Strorming, определять размеры событий, много говорим об эволюции и тестировании. Кароч, это продолжение «Анализа Систем». Как и в «Анализе систем» мы учим сначала думать, а потом делать, но на этот раз в разрезе коммуникаций частей системы между собой.
Материалы полезны тем, кто работает внутри монолитов, и тем, кто работает с распределёнными системами и планирует свои монолиты разобрать.
Стартуем 28 мая. Учимся 7 недель (интенсивно — 5).
Записаться на курс, прочитать пробный урок и всё такое →
До конца выходных действует промокод LEADYOURSELFKS на 10% скидки.
Если уже были на «Асинхронной архитектуре» и хотите на обновленную версию — пишите на support@tough-dev.school, дадим скидку.
Ищем авторов в Школу Сильных Программистов
Люблю профессионалов. Вот говоришь с человеком и понимаешь, что у него всё хорошо — и есть чему поучиться, и рассказывает интересно, и опыт крутой. Но вот никто не учится, кроме разве что 2–3 коллег, которым повезло быть рядом. Школу я когда-то начал строить именно из этого: хотелось делиться людьми, чьими знаниями я восхищаюсь.
Сейчас расширяю нетворк. Если коллеги на работе благодарят вас за то, как растут рядом с вами, если у вас есть профессиональные знания, которые жалко относить в мейнстримные школы — напишите мне: возможно мы договоримся о новом образовательном проекте.
К вашим знаниями мы добавим отработанные механизмы обучения взрослых, которые обеспечивают высокую доходимость (на текущем потоке «Стать Тимлидом» домашку после трёх недель делает ~70% учеников) и супер-лояльную аудиторию.
Нам не важно где вы работаете, не важно сколько у вас подписчиков. Важно, что у вас есть знания, которые помогают программистам становиться сильнее. Если сами делиться знаниями пока не хотите, но знаете крутого эксперта, чьими знаниями хотели бы поделиться с окружающим миром — перешлите этот пост ему.
В Школе два трека — хардовый и софтовый. Софтовый трек помогает разработчикам становиться зрелыми менеджерами. В хардовом треке у нас есть семейство архитектурных курсов с Антоном и питоний курс с Никитой Соболевым. У нас немного продуктов, но над каждым мы работаем очень крафтово — продумываем образовательные механики, допиливаем LMS и уделяем много времени тому, чтобы сделать сложное понятным.
Что хотим добавить:
— универсальный курс по тестированию: не про синтаксис и либы, а про подходы
— что-то по Go для middle+ ребят: пока не уверены, что существуют знания лучше, чем в книгах, но почему бы нет.
— любые темы, которые облегчают жизнь разработчику и делают его полезнее для бизнеса.
Точно НЕ хотим: AI, крипту и другие хайповые истории: нам важно, чтобы знания были полезными и через несколько лет.
Напишите пару слов о себе и своей любимой области знаний на fedor@tough-dev.school. Если из вашего рассказа поймём, что нам интересно — ответим.
#вопрос Работаю менеджером в аутсорсе (не программисты), и чувствую себя передастом. Проекты планируются централизовано, а я просто хожу на встречи с командой и клиентом и записываю, что происходит. Как расти?
Ваша роль сейчас — посредник: как риэлтор на рынке недвижимости, или дилер на авторынке. На посредническом рынке растут через наращивание ценности. Риэлтор учится анализировать потребности клиента и продавца, быстро искать подходящую недвижимость (и подходящих покупателей), снимать юиридческие риски. Автодилер предлагает программы рассрочки и трейд-ина, не забывая при этом вовремя платить производителю, настраивает гарантийное обслуживание, строит новые центры поближе к покупателю.
Оба посредника работают над тем, чтобы облегчить жизнь всем участникам процесса: хороший риэлтор работает для обоих сторон сделки, хороший дилер — для автозавода и для покупателя.
Вы — посредник между клиентом и командой. Позадавайте вопросы: как вы можете сделать жизнь команды легче? А жизнь клиента?
Допустим вы найдёте, что клиента беспокоит, что ему приходится объяснять свой бизнес-контекст каждому новому участнику команды. Почему бы вам не забрать эту задачу на себя? Или команду беспокоит, что клиент не знает, что хочет, и каждую неделю меняет планы. Почему бы не разобраться в том, почему это происходит, и не помочь клиенту выстроить более долгосрочное планирование? Ваших руководителей, которые планируют проекты, наверняка беспокоит стабильный кешфлоу. Почему бы не сфокусироваться на стабильности платежей, выстраивая такие отношения с клиентом, где он сам первый рвётся скинуть вам 100%-предоплату?
Увеличите ценность — получите и профессиональный рост в процессе и карьерный рост в результате.
P.S. Присылайте любую рабочую или личную ситуацию на fborshev@pm.me — разберём и придумаем, что делать. Ответ (анонимно) опубликуем здесь.
Стать Тимлидом 3 — ласт-колл
Напоминаю, что завтра стартует третий поток «Стать Тимлидом». Если вы купили тариф с обратной связью, приходите на встречу-знакомство в 16:00 MSK.
«Стать Тимлидом» учит решать задачи, которые встают перед каждым самостоятельным программистом (и не обязательно тимлидом):
— Как не просрать (или починить) отношения с бизнесом?
— Как понять, что они хотят, если они каждый раз хотят нового?
— Что делать, когда коллеги не тянут, а в команде бардак?
— Как отличить хороших программистов от плохих
— Где найти время на развитие, когда вокруг пожар?
Оплатить от работодателя успеете (если напишете прямо сейчас), или можно оплатить картой любого банка мира или в рассрочку. Чтобы компенсировать затраты на работе — напишите в сапорт, дадим полный комплект документов. Тем кто в РФ — поможем с налоговым вычетом.
Не сливаться с проблем
Постоянно вижу как люди (включая меня) сливаются с жизненных проблем. Живут с лишним весом, ходят на нелюбимую работу, платят ипотеку по 70% дохода, поддерживают дисфункциональные отношения. Сливаться — вполне человеческий механизм защиты, развитый с древних времён: вряд ли можно было бы спокойно прожить, переживая о количество тигров за дверью пещеры.
Сливаются по-разному — кто-то отвлекается на хобби, кто-то прибегает к компьютерным играм, алкоголю или наркотикам. Но есть место, где с жизненных проблем сливаться не получается — это предпринимательство. Чтобы бизнес рос, предприниматель, наоборот, бегает в постоянном поиске — а с чего бы мне не слиться сегодня? Какую неудобную проблему решить? В венчурных фондах есть даже специальные люди, задача которых — тыкать начинающих CEO: а что у тебя с продажами? Как там продакт-маркет фит, сколько гипотез проверил на этой неделе? Как думаешь уменьшать бёрн-рейт? А с отваливающимися клиентами как работаешь?
Просто отключать механизм сливания — нельзя. Начнёшь слишком сильно тревожиться — через два года сгоришь и пойдёшь работать моряком, водителем троллейбуса, или ещё кем поспокойнее. Приходится подбирать более здоровые механизмы — стратсессии, фреймворки для анализа рисков, те самые трекеры из фондов.
У каждого бизнеса и каждого предпринимателя эти механизмы свои. У меня последнее время остался самый тупой — это беклог: сажусь анализировать риски и по итогам составляю беклог для сотрудников, или хотя бы для собственного Things. Проснулся в 5 утра с тревогой про заблокированные счета — идёшь писать беклог. Переживаешь за короткий runway — ищешь способы ускорить поток денег. Не хватает людей — проверяешь, что там с наймом у команды.
А какие у вас механизмы?
———
Первый шаг к предпринимательсту у программистов — это тимлидство. «Стать Тимлидом» стартует уже в следующую среду. На курсе даём скиллы, нужные всем, кто руководит разработкой.
Дедлайны в трекере не нужны
В любом таск-трекере у задачи есть поле с дедлайном. Если его заполнить — трекер начинает напоминать о задаче: вот неделя осталась, вот уже завтра, вот уже на два дня проёбано. Иногда с дедлайнами выстраивают красивые календари: типа вчера вот эту задачу проебём, завтра вон те 10 проебём.
Не могу вспомнить ни одного случая, когда это поле приносило пользу. Зачем дедлайн программисту, если у него спринт и все задачи с одним дедлайном, либо канбан, где WIP-лимиты, либо бизнес которому надо вчера? Зачем дедлайн менеджеру, если при постановке задачи дедлайн с ним никто не согласовывает?
Получается поле есть, совершает какие-то действия, создаёт какую-то уверенность («вот же, дедлайн установили»), а пользы не приносит. Подозреваю, что это какой-то глобальный заговор владельцев таск-трекеров. А может просто таск-трекер без дедлайна в задачах никто не купит — это ж несерьёзно как-то.
Переубедите меня?
Стать Тимлидом
В последнее время из разных мест слышу, как тяжело менеджерам без технического бекграунда становится искать работу, связанную с управлением программистами. Думаю, это неплохо — клёво, когда руководитель приносит ценность в проект, а не просто следит, как бы чего не вышло.
Думаю, следующие в очереди на ненужность — программисты без менеджерского опыта. Когда-нибудь на собеседованиях вместо литкода начнут ковырять проактивность, рефлексивность и умение отвечать за результат — умения, которые в отличие от вращения деревьев, нужны каждый день.
Когда я в 19 году уходил из ГдеМатериала, я оставил 10 человек без руководителя. Не было даже тимлида. Очень гордился тем, как, прощаясь с командой, сказал, что каждый из них сам вполне может быть себе CTO. Хотя большой моей заслуги в этом и нет (просто ребята золотые), до сих пор идеал программиста для меня — это сотрудник, который сам себе если уж не CTO, то тимлид: сам договорится с бизнесом, поучаствует в собеседовании, а если дадут нерадивого коллегу — спокойно и ненавязчиво организует его время.
Из этого убеждения в 20 году у нас с Марьяной и появился курс «Стать Тимлидом» — мы собирали в одном месте пачку софтскиллов, нужную, чтобы выполнять работу без внешних костылей. С тех пор курс мы полностью переписали, но идея осталась прежней — отучившись 5 недель действительно можно разобраться чего не хватает, чтобы стать тимлидом, если не для крутой команды, то для себя — уж точно. Курс построен вокруг типичных лидерских вопросов: как договариваться с людьми, как быть, когда ребята не тянут, как поддерживать порядок; при этом не работая за всех круглые сутки.
Основная часть курса — это 5-недельный интенсив. За это время вы получите набор знаний, который выручит, когда нужно будет взять ответственность или провернуть что-то сложное на работе.
Смотреть программу →
Вторая, и самая важная, часть, происходит после курса — вы уходите применять знания, а сталкиваясь с проблемами, возвращаетесь в LMS. Материалы построены вокруг вопросов, с которыми рано или поздно сталкивается любой тимилд: начнёте нанимать — вернётесь к разделу про найм; получите доступ к бизнесу — перечитаете, как выстраивать с ним отношения; унаследуете хаос в процессах — перечитаете блок про управление проектами.
Стартуем 19 марта. По промокоду LEADYOURSELF действует 10% скидка до конца выходных.
Гениальная подписка на pico.sh
Делать подписки сложно. Помимо очевидного (и очень сложного с учетом современного комплаенса) хранения токенов авторизации карт, надо обрабатывать еще кучу нештатных ситуаций: смену тарифов, частичные возраты (после смены тарифа тоже), проблемы с картами, нормальный путь для отваливающихся пользователей и т.д. Даже готовые биллинги вроде страйпа и paddle не делают эту задачу простой.
Гениальный способ продавать подписку нашли ребята из pico.sh — это такой набор консольных сервисов для программистов: туннели, pastebin, простой блог, RSS-to-email. Они продают только годовую подписку (она дешёвая), и вообще не заморачиваются с продлением: если пользователю через год будет надо — он опять купит.
Наверное, так у них гораздо меньше платящих клиентов, которые забыли, что они клиенты но приносят прибыль (не знаю, как это называется на продуктовом). Но зато без рекурентных платежей интеграция со страйпом занимает десяток строк, а за год, если захотят, заработают себе и на нормальный биллинг.
—
31 июля запускаем «Без Ерунды» — курс о Developer Experience. Приходите, чтобы понять откуда вообще берётся программистская неэффективность.
Вайб-управление
Я тут недавно задумался, а сколько же управленческого долга создаёт ChatGPT? С техническим долгом всё понятно — кажется даже самые упоротые школостартаперы поняли, что на одном вайбкодинге далеко не уедешь. А вот что с вайб-управлением?
Менеджеры любят простые решения. Легко, к примеру, сгрузить на LLM комплаенс — он даёт прекрасные и простые ответы о законах и налогах, как будто и не нужны становятся бухглатеры и юристы с их сложностями и огромными ценниками. Через LLM можно написать очень подробное и умно выглядящее ТЗ, попросить ужать до одной строки длинное клиентское письмо, изучить новый рынок, сделать SWOT-анализ и сформулировать туду-лист после встречи.
Чтобы устоять перед решением, которое выглядит умно и обосновано, нужно очень много ответственности, которой у менеджера в запаре может и не быть. Понятно, что компании в неподходящих юрисдикациях никто открывать не будет — это как принимать лекарства на основе диагноза из ChatGPT. Но вот просрать какие-нибудь налоги, потерять договорённости с клиентом или слить в трубу время программистов — вполне легко.
Конечно мы рано или поздно придём к ответственному использованию AI, и слепо верить ChatGPT станет так же странно, как сейчас странно слепо верить SEO-помойкам из поиска гугла.
Но пока это умение у себя отрастили далеко не все.
—
31 июля запускаем «Без Ерунды» — курс о Developer Experience. Приходите, чтобы понять откуда вообще берётся программистская неэффективность.
Один из сложных челленджей в школе — это соблюдать баланс между тем, чтобы тупо следовать запросам аудитории (и получать условный скиллбокс) и тем, чтобы делать нишевые курсы на 19 участников.
К примеру, когда мы делали «Без Ерунды» (это курс о DevEx), один из самых частых запросов звучал так — научите меня мерить командную эффективность (а ещё лучше — расскажите про DORA). Звучит вроде бы понятно, только вот я, повидав кучу команд и управляя собственным аутсорсом, могу смело утверждать, что это DORA — это метрики тщеславия: на них клёво дрочить клёво, когда они есть, но пользы бизнесу они не приносят.
Лучше не расходовать энергию на vanity-метрики, а научиться одной штуке — находить в ежедневной рабочей рутине говно. Эта штука подвластна всем: руководителю — на уровне команды, обычному программисту — на уровне dev-скриптов и собственного календаря. Конечно, измеримый результат нельзя игнорировать: если закрыть глаза на время сборки проекта, время прогона тестов или количество дефектов — получится фигня.
Но вашу работу будут оценивать только по TTM. И DevEx — как раз про это.
Теперь про курс. Мы запускаем второй поток — на этот раз с домашкой. Будем рефлексировать вместе — как и на других наших курсах, вы будете проверять домашки друг-друга. Я тоже буду рядом — буду давать общую обратную связь тем, кто на тарифе «в тусовке».
Ещё есть новость: вместе со мной домашки будет обсуждать Толя Буров. У Толи очень редкий скиллсет: он смешивает опыт дизайнера-проектировщика, программиста и лингвиста. С Толей я познакомился очень давно, когда ещё работал в Студии Лебедева. С тех пор Толя вместе с Максимом Ильяховым сделал Главред и запустил стартап Таймстрайп — органайзер личных дел, который в 100 раз лучше ноушена.
На курсе 4 лонгрида, стартуем 31 июля, учимся 5 недель (интенсивные — 4).
Записаться, посмотреть программу, отзывы и все такое →
До конца выходных работает промокод LEADYOURSELFDX на 10%. Оплатить можно из любой точки мира, в том числе и по безналу.
Если хотите оплатить от юрлица — пишите Зое на почту support@tough-dev.school. Она сделает так, чтобы ваши бухгалтеры и кураторы обучения были в восторге от того, как мы классно оформляем все доки.
Вчера стартовали «Коммуникацию систем», а я не пришёл на первую встречу — не было времени, одновременно редачу материалы и пишу код в LMS.
Колеги скидывают скриншоты из чата, познакомлюсь с ребятами хоть так. Смотрите, какие все крутые!
У нас в «ФАНС» новый кейс — за 3 месяца сделали LMS для «Синхронизации».
Лично для меня повод гордиться — в количестве человек. В поминальнике 11 человек от нас, 8 от клиента и ещё 2 от дизайн-студии. Итого 21!
Проект такого объёма за такой срок в ИТ-аутсорсе — большая редкость: средний бизнес со средним подрядчиком за 3 месяца успеет только собрать требования и подписать ТЗ. Время уходит на согласования, споры и взаимные продавливания, и чем больше людей с обоих сторон — тем дольше этот этап будет длиться. Конечно, если подрядчик знакомый — всё происходит чуть легче за счёт взаимного доверия. Но я не знаю ни одного исполнителя на рынке, который доведёт такой проект, да ещё и с легаси, с нуля до прода меньше, чем за полгода.
Мы смогли — благодаря продуктовой экспертизе со стороны Синхро (Таня, я ни о ком ещё не слышал столько хороших отзывов от команды❤️) и благодаря нашим крутым ребятам.
Хотите так же — пишите Самату, @samatg
В общем не делайте как я — вчера были какие-то проблемы с интернетом, и решили провести в открытом зуме. Совсем уже и забыл что есть боты-спамеры и просто хаджекатели встреч.
Вот запись, этап борьбы со спамерами вырезан: ютуб / рутуб
#вопрос
Мне 38, в программировании 12 лет. До сих пор не определилась, чего хочу от карьеры, по разным градациям до сих пор midlevel.
Благодаря твоим постам и вводному уроку курса «Стать тимлидом» утвердилась в том, что в манагеры я не хочу точно. Но и быть “просто кодером” будто уже не солидно что ли.
Мне нравится писать код, улучшать сервисы, оптимизировать, выносить функционал из монолита, редизайнить, переносить на более эффективный стек (из последнего nodejs -> golang, проекты веду сама) – те это всё вокруг code quality, performance, scalability, maintainability, техдолг и иже с ними.
Это кажется нужным и полезным, и это то, что мне нравится делать. Но это не выглядит особенно востребованным и тем, за что ценят и хорошо платят. И уж тем более — не зовут синьёром. Хочется продолжать делать то, что нравится, и при этом иметь возможность делать на этом больше денег.
Зарегистрировала юрлицо, думала, может этим и заняться в порядке аутсорса?
Какой бы совет относительно дальнейшей карьеры ты бы мог дать? Куда посмотреть?
——
Судя по тому, что ты читала вводный урок «Стать Тимлидом», ты отличаешь профессиональный рост от карьерного, и задаёшь вопрос именно о карьерном и материальном росте. Вариант стать гуру-синьёром-архитектором, который планирует просидеть до 60 лет на большой зарплате в условном Яндексе, для тебя тоже не подходит: иначе ты бы искала как туда попасть, и спрашивала бы об этом не у меня. Карьеру руководителя ты тоже отвергаешь. Понимаю и разделяю.
В таком случае остаётся осознать грустный факт — просто сидеть в роли мидла-исполнителя дальше не получится: это кайфово, но не приносит денег, а все достижения в твоей работе чего-то стоят только внутри компании, в рамках которой ты к ним пришла.
Чтобы самостоятельно управлять тем, что делаешь и присваивать эти достижения, надо менять что-то в неайтишной части твоих скиллов — защищать идеи, продавать свою экспертизу, учиться размышлять как продакт-менеджер и предприниматель.
Вовсе не обязательно для этого открывать юрлицо и идти в аутсорс (я вообще этого никому не советую). Можно пойти в продуктовую сторону, а там где не хватает собственной экспертизы — поискать партнёров, которые согласны мириться с вашими слабыми сторонами. К примеру — найти сильного b2b-продавца с экспертизой в условной банковской сфере и запустить вместе какой-нибудь супер-новый сервис скоринга для банков. Или, если любишь code quality — подумай о продукте на эту тему: насколько я понимаю, на отечественном рынке до сих пор царит вакуум. Венчур это или нет — пофиг (я — за не-венчур).
Это был традиционный ответ по понедельникам. Прислайте профессиональные вопросы на fborshev@pm.me.
Продукты для совместной работы и молчание
Я считаю, что молчание в работе ценнее, чем общение. Обидно, что продакт-менеджеры компаний, которые владеют средствами рабочей коммуникации, моё мнение не разделяют.
— Гитхаб присылает ВСЕ обновления от пулл-реквеста, в котором у тебя что-то спросили.
— Ноушен, хоть и присылает обновления дайджестами, делает их абсолютно нечитаемыми.
— Хабр.карьера присылает отдельное письмо о каждом новом отклике на вакансию.
— Сентри по умолчанию уведомляет о каждой новой ошибке (вроде в последнее время стало лучше, но у меня так)
— Слак, хоть и сделал развесистую систему настройки уведомлений, всё равно присылает всё не по делу.
Причины этого мне понятны — у владельцев этих продуктов есть KPI, пресловутый engagement. Если юзер часто заходит в таск-трекер — продакт получает премию, а CPO — бюджет, чтобы встроить в продукт соцсеть и ленту. Юзер заходит редко — значит продакт не молодец.
Я знаю только один продукт, который заботится о тишине своих пользователей — это бейскемп:
— Если отписаться от треда, то его автор никогда случайно тебя не подпишет обратно — интерфейс подписки спрятан за несколькими кликами.
— Есть система, которая поощряет людей вообще не писать комментов — это бусты. Уведомления от них приходят только автору сообщения, группируются в дайджесты
— Если написать что-то в проектный чат, то пользователь получит уведомление только один раз
— Есть специальный Focus Mode, когда система вообще перестаёт присылать уведомления.
Знаете ещё инструменты для совместной работы, которые берегут внимание? Напишите в комментах.
Нечестное преимущество
Когда-то читал анкету одного венчурного фонда, и там был хороший вопрос — «опишите, какое у вас есть нечестное преимущество перед конкурентами». То есть почему у вас получится, а у них нет. Слово «нечестное» резануло слух — как это нечестное? Это ж бизнес, а не мошенничество. А потом я как понял.
Когда ребёнок в школе не может с первого раза написать закорючку или сделать фигню из пластилина, его учат — постарайся, напрягись, тогда всё получится. В институте то же самое — чтобы сдать сессию, надо не спать ночами и зубрить. На работе тоже принято себя превозмогать — оттуда культ энергетиков и мемы про пятницу.
В бизнесе этот поход не работает. Бизнес — это про масштабирование: не когда ты бесконечно совершенствуешься делать одну конкретную фигню (поделка из пластилина/сессия/код на расте), а когда строишь организацию, которая делает эту фигню в разных вариантах бесконечное количество раз. Если фигня делается сложно — бизнес получается грустный.
Пример грустного и сложного бизнеса — пункт выдачи WB/Ozon. Открываешь, и попадаешь в рабство: следишь, чтобы сотрудники приходили вовремя, ищешь замену уволенным, борешься со всякими мутными схемами, разбираешься в постоянно обновляемых требованиях и штрафах сюзерена. Получается усложнённая форма самозанятости. Может быть и выгодная (не знаком с экономикой), но явно не масштабируемая. Конечно можно по-школьному: усердно поработать, и в итоге получить хороший пункт выдачи, который знают все в округе. Но это будет всего лишь пункт выдачи. Богатством\успехом, вопреки нарративам, это не пахнет. На квартиру внутри МКАД точно не накопишь.
Гораздо веселее изобрести как взломать систему. Не следить вручную за одним пунктом выдачи, а открыть десяток разных, переиспользуя одну инфраструктуру для найма, бухгалтерии и антифрода. Не крафтить самую крутую в мире команду разработки, которая впятером может затащить любой проект, но раз в полгода попадает в кассовый разрыв из-за длинного цикла сделки, а придумать, как собирать десятки таких команд под одной крышей (моя мечта, да). Не таксовать с утра до вечера, придумать, как получить большой лизинговый контракт, чтобы открыть свой таксопарк.
Смысл бизнеса — в своём уникальном способе прийти к масштабу. Если уникального способа нет — будешь просто работать по 20 часов в день.
Шаблон 1:1
Мы c Марьяной пока готовились к новому потоку «Стать Тимлидом» (запрыгнуть уже не получится), выделили важную штуку, на которую многие тимлиды забивают — 1:1.
Кто-то попробовал пару раз, получилось неловко и забил. Кто-то — даже официально: типа нет смысла тратить силы на эти пустые вопросы, надо работу работать.
Если вы из таких — дайте ещё один шанс встречам 1:1. Это — важная точка роста. Для вас — обратная связь о команде, компании и лично вас. Для коллеги — забота и место, где можно спокойно поднять проблемы, которые HR-ам нести вроде рано.
Посмотрите шаблон 1:1, который мы сделали специально для тех, кто не знает как начать. Тем, кто хочет пополнить свой инструментарий — тоже поможет.
Полюбил вайб-кодинг
Я тут опять потихоньку пишу код и недавно заценил агентский режим, который стал появляться в LLM-ассистентах.
Вообще у меня с AI в программировании всё с самого начала складывалось плохо — уж слишком много внимания они требовали. Подсказки в коде выглядели впечатляюще, но сколько бы я ни давал им шансов, в конце они оказывались просто спамом. Чтобы найти в них что-то полезное, приходилось потратить больше внимания, чем ушло бы на то, чтобы самому это полезное написать.
Разговоры тоже как-то не зашли — после того, как минут 30 я дебажил простой тест, в котором LLM просто использовал неправильное название свойства (что-то на уровне title вместо name, сразу и не раглядишь).
Ну и совсем я забил, когда весь мой, с таким трудом нагороженный, сетап начал постоянно разваливаться, просто потому что слишком уж много людей пытаются принести пользу человечеству и коммитят говно прямо в мастер моих плагинов.
Недавно, наконец-то, смог получить МНОГО пользы от AI — установил себе Claude Code CLI. Кайф в том, что не нужно никаких интеграций — он просто живёт в соседнем терминале и делает всё, что я попрошу. Такой усердный джун, который к тому же, внимательнее меня читает документацию: и тесты напишет, и кодмод любой сложности проведёт, и выжимку из документации сделает. Причём код, который он пишет, реально похож на мой!
Поручаю ему мелкие задачи, которые тяжело делать без IDE — переписать код и тесты после рефакторинга класса, разнести код по модулям/функциям. Самый кайф испытал, когда недавно попросил его написать рекурсивный SQL-запрос для обхода дерева, прямо в Django ORM. Думал долго, взял с меня полтора доллара, но таки написал! Я бы такое делал часа два, в лучшем случае (как любой нормальный бекендер, я в SQL не умею).
Кажется, агентский режим — лучшее, что случилось с AI-ассистентами в программировании.
В зерокоде появились легаси-инструменты
4 года назад (ужас!) писал, что считаю зерокод техдолгом с самого момента создания. За 4 года ситуация не изменилась — разбираться с созданным другим человеком (или самим собой полгода назад назад) зерокодом всё так же сложно.
Недавно убивал пару внутренних сервисов в пользу зерокода и поржал, осознав, что в индустрии появились целые легаси-фреймворки. К примеру zapier. Штука, которая на старте казалась чудом, сейчас выглядит как тормозной захламлённый интерфейс из двухтысячных, который постоянно пытается мне что-то продать, показывая людей из фотостоков (не AI! фотостоки!). Документация — говно (так и не понял, как нормально шарить креденшелы между проектами). AI-зеркодер лучше бы даже не выкладывали вообще — за 30 минут не смог из него извлечь ничего осмысленного.
И это бывший лидер индустрии! Получается нехилая такая скорость устаревания — совсем чуть-чуть дольше, чем средний JS-фреймворк.
Я в итоге остановился на n8n (наверное есть и лучше), но вот что подумал — а сколько же людей вынуждены до сих пор работать в zapier? Интероперабельности же нет by design — если назерокодил что-то в говноинтерфейсе — в нём и сиди всю жизнь, пока не перепишешь на новый тул. Сочувствую зерокодерам.
Контроль — это костыль
Этот пост — реклама курса «Стать Тимлидом». Как всегда — полезная: прочитайте, если как и я, боитесь ошибок и лечите это гипер-контролем
Тут Марьяна рассказывает, как на горнолыжном склоне училась не бояться собственных ошибок. Это действительно очень полезный навык: страх ошибки на работе может парализовать так же, как и на склоне — так, что с места не сдвинешься.
У меня, при переходе в управление, страх ошибок был немного другим (хотя и синдром самозванца тоже приходил). Дело в том, что на склоне, как и в программировании, всё довольно бинарно: упал — ошибка, доехал до конца — молодец. А в управлении от этой бинарности не остаётся и следа: о том, что ты испортил отношения с бизнесом начинаешь понимать через месяц после первой встречи, на которой всё пошло не так. Что команда без тебя начала говнокодить, можешь узнать только когда бизнес-задачи уже встанут колом. Обратная связь если и приходит, то очень медленно.
Сначала пытался справиться со страхом очевидными способами — уведомления на почту, выдуманные KPI, напоминалки, чтобы проверить, что эти уведомления пришли. В общем пытался всё контролировать. Как можете догадаться — довольно безрезультатно.
В какой-то момент я всё-таки дошёл, что контролировать я могу исключительно себя. Вряд ли я заставлю бизнес на себя не обижаться — зато если сфокусируюсь на своём собственном поведении, начну их слушать, превращать проблемы в таски и помогать команде эти таски закрыть, то скорее всего всё будет хорошо. Кароче, ушёл качать скиллы.
Помогло — вернулось чувство контроля, появились силы на профессиональный рост. Когда вырос — перенёс этот подход на предпринимательство, где определённости ещё меньше: опираюсь на скиллы и качаю те, которых не хватает.
———
Если тоже замучил страх ошибок — приходите к нам на «Стать Тимлидом». В безопасной среде прокачиваем ключевые навыки, нужные ответственным программистам — работу с командой, найм, управление проектами и умение общаться с бизнесом.
Где начинали — там и общайтесь
Типичная ситуация: у компании есть трекер задач, слак и ещё личная телега у сотрудников. Изобилие коммуникаций приходит к тому, что ни в одном месте нет ни одной завершённой. Заходишь в трекер и видишь, что задачу двигают уже три спринта. Пытаешься понять в чём дело — а последний раз по ней писали что-то как раз те самые три спринта назад.
Или ищешь ссылку, которую коллега давал по задаче. Вроде общались в слаке, всё обыскал и ничего не нашёл. А она была в комментах к трекеру, потому что вспомнили о ней на планировании спринта. Или наоборот, в личной телеге, потому что говорили о ней после работы.
Кароч, если не получается удалить лишние средства общения, поддерживайте хотя бы консистентность:
— Если задача стоит в трекере, старайтесь общаться там же.
— Наоборот, если начали в слаке — не обманывайте себя, что уйдёте оттуда, сделайте хотя бы удобный тредик.
— Если начали в трекере, а в процессе работы переехали куда-то ещё — дублируйте в трекер хотя бы ключевые договорённости.
Сэкономите кучу времени на поиске информации, не говоря уж о том, что перестанете выглядеть наружу как кучка молчунов.
---
Напоминаю, что идёт набор на «Стать Тимлидом», где мы рассказываем, как завоёвывать доверие у коллег и бизнеса, в том числе и такими мелкими хаками
Кастомный воркфлоу не нужен
Я тут недавно решил поменять монитор — честно служивший 8 лет LG UltraFine поменял на Apple Studio Display. Оказалось довольно трудозатратно — поменялось очень много паттерном использования.
Старый монитор был довольно маленьким — 21“ хватало только, чтобы воспроизводить привычный экран ноутбука. Работа за ним по сути ничем не отличалась от ноута — всегда было открыто 2–3 спейса с одним окном, максимум — с двумя. На 27“ фигни входит гораздо больше, поэтому я решил заняться её организацией — вспомнил любимый линуксовый dwm и тайлинг в целом.
Оказывается в macOS есть куча инструментов, чтобы управлять тайлингом — юникс-вейный yabai, фреймворк для скриптования Hammerspoon, или Aerospace как решение всё-в-одном. Можно сделать клёвый статус-бар на SketchyBar или настроить любые хоткеи через shkd, Karabiber или BTT. Можно даже сделать всё то же самое, просто накупив программ в AppStore!
Беду с этими инструментами я осознал ближе к десятой помидорке, которую на них потратил — огромный порог входа и совершенно непрогнозируемая стоимость поддержки. Получается настолько же сложно, как какая-нибудь средненькая среда разработки, вместе с IDE, CI и таскраннером.
Правда, когда занимаешься DevEx на рабочем проекте — ты получаешь прогнозируемый выхлоп в виде того же TTM. А вот выхлоп от автоматического тайлинга я спрогнозировать не могу, хоть и проработал на нём больше 5 лет. Кажется, в итоге я сделаю гораздо больше работы, если 3 лишних минуты в день буду возить мышкой, чем если буду раз в месяц тратить по паре часов на починку фичей, которые отвалились из-за очередного обновления.
Программисты вообще любят всё настраивать — от цветов в консоли до статусов в жире. И если цвета вредят разве что зрению, то статусы и другие кастомные воркфлоу жрут вполне измеримое время. Я программист уже не настоящий (надеюсь), так что посижу на встроенном UI.