25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
В четверг, в 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% скидка до конца выходных.
Два новых выступления
1) Как не превратиться из хорошего программиста в плохого менеджера: рассказываю о двух профессиональных путях — «лидерах» и «хакерах»: https://www.youtube.com/watch?v=XWs-Iwe8wuc
2) Ищем, куда девается время программистов: как при помощи анализа пользовательских сценариев можно находить места, в которых программистам неудобно: https://www.youtube.com/watch?v=rZvtwKShR7U
Императивный и декларативный бизнес
Вообще этот пост — реклама курса о Developer Experience, который мы доработали по итогам обратной связи от живого потока и теперь открыли продажи. Но вообще — это часть моего (внутреннего пока) исследования о том, какие ещё концепции из программирования можно притащить в управление бизнесом. На этот раз хочу поговорить о декларативном и императивном программировании.
Своим первым отделом я начал руководить, страшно подумать, 15 лет назад. И первым моим шагом, конечно же, была разработка регламентов. Даже не задумывался, зачем (KPI мне никто не ставил) — просто делал, потому что так принято. И пофиг, что в отделе 5 человек, а во всей компании — 15: я начал писать страшные бумаги, что-то вроде «если приходит срочная задача, то постановщик должен лично подойти к исполнителю». Довольно похоже на первый код, который пишут джуны: «if user.has_access_to_action() then perform_action()»
У этих регламентов есть одна общая проблема с джуновым кодом — все случаи жизни if-ами не покроешь. Если попытаешься — выйдет длинная портянка, которую ни один нормальный человек читать не будет. Чтобы решать проблемы в императивном коде, давно придумали целый арсенал — от дяди Боба до YAML.
А вот с людьми абстракций не наделаешь: фреймворков, чтобы залезать в голову и управлять каждым шагом исполнителя, пока не изобрели. И тут есть два диаметрально разных подхода: можно назвать их конвейерный и стапельный.
В конвейерном подходе всё как в коде: инструкции прячутся за механизмы, которые вроде как обеспечивают их выполнение. Прежде, чем ставить рабочего к конвейеру, его прогоняют через обучение и экзамен. Результат работы постоянно проверяют, самого рабочего — тоже. Периодически меняют инструкции, людей переаттестуют или вообще заменяют на роботов. Такой подход работает при массовом выпуске — на автомобильных заводах, к примеру.
Стапельный подход — более штучный. Мы не пытаемся прописать каждый шаг исполнителя, а дизайним среду, в которой исполнитель будет выполнять то, что нужно. Работает со штучными производствами. В автомобилях, к примеру — в тюнинг-ателье, где каждый автомобиль уникален.
В разработке (думаю и в любой другой творческой работе) действует только штучный подход. Чтобы люди хорошо закрывали клиентские задачи, им нужна удобная среда — доверие, нормальные инженерные практики, минимальная коммуникация, свободное время, много автоматизации, а в идеале ещё и мало контроля. Создавая такую среду в аутсорсе, мы делаем то самое тюнинг-ателье, которое сегодня обшивает потолок майбаха алькантарой, а завтра вкорячивает 37” колеса на джип.
Грустно смотреть на коллег, которые этого не понимают, и вместо линтеров делают стандарты разработки, а вместо асинхронной коммуникации — дейли-митинги и контроль времени.
---
Собственно курс о среде для штучного производства называется «Без Ерунды», состоит из четырёх писем — о доверии, инженерных процессах, внимании и работе с клиентом. Если вы покупали курс раньше — все обновления уже у вас в LMS. Если сомневаетесь — гляньте отзывы из вложения
Перестал вести учёт расходов
С 2015 года я вёл учёт личных расходов — каждый понедельник садился, открывал банковскую выписку и разносил все платежи за прошлую неделю по категориям — еда и хозяйство, одежда, развлечения и т.д. Иногда пропускал неделю, один раз — пропустил целых три. В 2024 году, спустя ровно 9 лет после начала, я перестал это делать.
Базовый принцип «лучше больше зарабатывать, чем меньше тратить» я понял году в 2017, но продолжал вести расходы. А недавно понял, что не принял ни одного решения на основе данных о расходах. Что толку знать, что каждый месяц я трачу на жильё 1500 евро, если принимая решение об ипотеке, я и так могу легко посчитать стоимость всех арендных платежей? Что изменится от того, что в прошлом месяце я потратил на еду 700 евро вместо 400? Зачем знать, сколько обходится автомобиль, если идиоту понятно, что такси в Москве стоит дешевле?
Если я не принимаю решений, то смысла в этих расчётах нет. Разве что в процессе: садишься записывать расходы, и как бы 20 минут напоминаешь себе — все траты предсказуемы, ни одна копейка не уйдёт без твоего ведома. Как мантра.
Но это же неправда! Завтра могут заболеть родственники, центробанк может опустить ставку, я захочу сделать идиотски дорогой подарок супруге, сосед сверху зальёт квартиру, или я сам залью квартиру соседу снизу. Контроля над этим у меня нет.
Получается, что записывать расходы — это работать с прошлым. Так что лучше я буду 20 минут работать с будущим — к примеру начну тратить это время на более качественное планирование недели. Или просто подольше сидеть в кресле и ничего не делать.
Coupling и cohesion в бизнесе
Наверное самая полезная концепция, которую я принёс из программирования в бизнес — это каплинг и кохежн. Бизнес — это такая же система, которая состоит из разных подсистем, связанных по некоему API (чат в вацапе — это тоже API, просто кривое).
Так вот, когда менеджер по продажам, чтобы выставить счёт, должен сходить в бухгалтерию — это высокий каплинг. Для пары счетов в месяц ещё норм, для пары счетов в день — уже очень много. Кохежн тоже есть — если, к примеру, поручить бухгалтерии самой расчитывать зарлптау, получая на вход только данные о зарплате и всякие кадровые документы — получается вполне изолированная система, сконцентрированная только на выполнении своей ответственности.
Зум-встречи на 8 человек, многоступенчатый документооборот, финдир, который требует рапорта на каждую трату — это тоже высокий каплинг: когда кто-нибудь из этой цепочки начинает вести себя неэффективно, ломается вся цепочка.
Чаще всего высокий каплинг возникает в финансах и взаимодействии с государством: поленился подстроить процессы бухгалтерии под возможности встроенной в эквайринг интеграции с ОФД — и ловишь бесконечное количество проблем с потерянными и неправильными чеками от кастомного решения. Или завязал управленческую отчётность на интерфейс конкретного банка — и всё, не можешь его поменять даже когда он попал под санкции.
Каплинг и кохежн — такие же важные метрики, как рентабельность или стабильность кешфлоу. Жаль только, измерить их не так просто.
Сервисы: netdata
В 22 году перед аутсорсом встала техническая проблема — существенная часть клиентов больше не могла использовать datadog. У нас на него было завязано практически всё — и мониторинг хостов, APM, и даже алёрты работали напрямую через него. Отказывались от него грустно, у каждого проекта по своему — где-то продолжали платить, где-то переходили на клиентскую графану, где-то — пробовали APM из Sentry (говно) и uptrace.dev (норм).
Всё это время я страдал — чем гетерогеннее стек у наших клиентов, тем хуже каждый экземпляр настроен. Когда все в компании знают, как готовить Датадог или условную Графану — она у всех клиентов будет хорошая. А если каждый раз настраивать всё с нуля — результат будет дорогой и обычный.
Уже почти решился городить собственный инсталл графаны, но вовремя остановился, наткнувшись на netdata. Самый главный плюс для меня — не надо ничего держать в своей инфраструктуре: только агент на тачках.
— Удобно как у датадога — агент сам видит всё, установленное на тачке — докер, постгрес, редис и т.д.
— Чего не подхватилось само — можно конфигурировать через централизованный интерфейс. Это лучше датадога, в котором приходится прокидывать yaml внутрь докер-контейнеров, чтобы прописать недефолтный доступ к постгресу.
— Готовые дешборды на всё. Думать не надо.
— Можно прокидывать метрики через стандартное API прометеуса. Я, к примеру, быстро добавил мониторинг температуры для пары андроид-устройств, которые лежат у меня на полке.
APM пока нету, но для мониторинга хостов это кажется недорогим и удобным решением, так что мы переходим. Напишу здесь ещё через 3–4 месяца, как зайдёт.
Проекты, в которые я ввязался
Важнейший скилл, который я никогда не перестану качать — это умение не ввязываться в лишнее. Не начинать проектов с непонятной целью, не отвечать на неинтересные предложения, не делать сложного, когда есть простое, не брать кредитов, не иметь дверного звонка и уведомлений на телефоне.
Вместе с отсутствием управленческих долгов, это даёт возможность концентрироваться. Не важно, чему я решил посвятить день — настроить отчётность в компании, провести его с семьёй или просто погулять по городу — я хочу делать это на 100%, не отвлекаясь на чужие проблемы. У пилотов есть «стерильная кабина» — в кабине самолёта запрещено разговариавать о чём-то кроме полёта. У меня вместо стерильной кабины — умение не ввязываться: не допускать в локус внимания ничего, что не имеет отношения к задачам, какими бы они ни были в данный момент.
Возможность не ввязываться — важнейший смысл асинхронной коммуникации. Сложно не посмотреть на новый проект хотя бы одним глазком, когда тебя поймали с ним в переговорке. И наоборот, гораздо легче думать о важном в продуктивное время и с осознанным письмом.
Несколько лет я веду список, который так и называется — «проекты, в которые я ввязался». Сверяюсь с этим списком во время еженедельного обзора, и когда удаётся что-то из него выкинуть или хотя бы делегировать — считаю себя молодцом.
#вопрос
Мне 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.
Затаскивать проекты, а не людей
Клёво затаскивать проекты. Запускать обещанное в срок, выстраивать для этого понятные планы и чёткую коммуникацию. Выбивать команде самые удобные инструменты. Договариваться с заказчиком, придумывать как срезать углы или наоборот, сделать больше работы, принеся больше пользы.
Неклёво затаскивать людей. Не работать вместе над общим делом, а всей командой обходить неумение кого-то одного писать код или выполнять обещания — перераспределять нагрузку, какделировать несамостоятельных, выкидывать работу не потому, что неважно, а потому, что не успеваем.
Когда затаскиваешь проекты — растёшь. Учишься делать это эффективнее, чужими руками, а потом и руками тех, кто сам делает это чужими руками.
Когда затаскиваешь людей — ты просто тратишь время на то, чтобы принести результат.
Готовые комплекты вещей
Самое смешное бытовое открытие прошлого года — это готовые комплекты вещей. К примеру, комплект проводов и зарядок для поездки. Раньше нужно было подумать, какие устройства я с собой беру (нужен ли lightning? а зарядка для часов?), посмотреть, отыскать всё это, проверить чтобы все провода были совместимы со всеми устройствами, а после поездки — вернуть на место. Сейчас достаточно взять маленькую сумку с зарядками, которая всегда собрана.
Или наушники. Раньше нужно было не забыть наушники, когда идёшь в кофейню, отыскать их перед походом в спортзал, и проследить, чтобы они не сели во время зум-созвона. Сейчас достаточно взять наушники для встреч (самые лёгкие и без шумоподавления, которое не нужно дома), в дороге — достать походные наушники, а в спортзале — взять спортивные, которые так и живут в спортивной сумке.
Дошёл до этого после идеи с айпадом для одиночества. Вы не представляете, сколько времени, а главное — энергии я стал экономить, когда перестал собирать электронику в поездки.
В комментах к посту про список проектов, куда я ввязался, задали интересный #вопрос — как фокусироваться и при этом оставлять пространство для slack-time. То есть времени где можно расфокусироваться и проявлять любознательность или просто пофаниться?
Я конечно тот ещё эксперт по тайм-менедменту, но попробую ответить как это устроено у меня. Время любознательности и развлечения — это вообще главное время в дне. Для меня возможность поизучать что-то новое и приятное — это награда, к которой я иду через другие дела. Новое и приятное может быть каким угодно — новые либы\языки, перестановка в кабинете или способы открытия LLC в США.
Я довольно зависимый человек, и если сажусь за что-то дофаминово-любознательное, мне тяжело останавливаться. Поэтому стараюсь не планировать такие вещи на утро — иначе рискую целый день проковыряться в чём-то несрочном, но безумно интересном.
Конечно же, изучение новых вещей — это такой же проект, в который я ввязался. И на еженедельном обзоре я ограничиваю количество таких проектов так же, как и всех остальных.
Хочется добавить, что главное в любой науке о продуктивности — это всё-таки не писать планы и не пытаться с лицом Льва Толстого за ними следовать, а прислушиваться к себе. Если я с утра понимаю, что сегодня день расфокуса — стараюсь не насиловать себя, а заниматься интересным.
Кстати, вопросы лучше всего задавать на fborshev@pm.me. Ответы выкладываю по понедельникам.
Скиллы и над-скиллы
Это — ласт-колл на 4 поток нашего флагманского курса «Анализ Систем».
Когда я собеседую программистов, я редко смотрю на хард-скиллы, которые они рекламируют в резюме. Что толку, если программист знает десяток фреймворков, если он не умеет подбирать тот, который подходит задаче? Гораздо важнее не скилы, а «над-скиллы»: насколько программист интересуется происходящим в индустрии, как умеет сравнивать инструменты друг с другом, умеет ли вообще задавать вопросы?
То же самое и со знаниями: можно несколько лет читать про DDD и не научиться разбивать систему на элементы и уж тем более, делать это в сооветствии с потребностями бизнеса.
«Анализ Систем», мы делали как раз для того, чтобы не складывать в резюме аббревиатуры (хотя они тоже будут), а чтобы прокачивать над-скиллы. Вместе с Ибрагимом и котом-критиком вы будете решать большие архитектурные задачи, получить которые в реальной жизни довольно сложно, не имея опыта. Обратную связь на свои решения тоже можно не ждать по несколько лет, а получить сразу.
Стартуем 16 января, учимся 5 недель. Учебная нагрузка — примерно 10 часов в неделю (у кого-то сильно больше, но точно не меньше) — мы рекомендуем брать отпуск на работе как минимум на один день каждую неделю обучения. Если хотите серьёзного буста в над-скиллах — берите тариф «в тусовке». К слову, «Долями» подняли нам лимиты, и теперь оплачивать тариф «в тусовке» частями могут не только клиенты Т-банка, но и все другие. От юрлица и из-за рубежа тоже можно.
Следующий поток будет не раньше лета
Группа про социальную тревогу
Немного нестандартное для канала объявление — мои хорошие друзья набирают психологическую группу, посвящённую социальной тревоге. Приглашают всех, кто напрягается от смоллтока, боится выступлений и разговоров с начальством, кому встреча с незнакомыми людьми может испортить вечеринку, а необходимость звонить в банк заставляет поменять банк.
Кто не знает, психологическая группа — это способ сэкономить на психотерапевте и почувствовать себя неодиноким за счёт товарищей с такими же проблемами.
Группа расчитана на год, максимум 12 человек. Стоимость — 4000 рублей за занятие, проходят раз в две недели, онлайн. Чтобы пройти собеседование — запишитесь здесь, ребята вам напишут.
Команда ценнее клиента
За небольшую историю нашего аутсорса мы несколько раз отказывались от денежных клиентов, которые подходили по стеку и задачам. Иногда на этапе продажи, а иногда — уже в процессе работы. И я говорю не об этике — даркнетчики и скамеры к нам даже не обращаются из-за ценового порога.
Дело в том, что бывают клиенты, которые вредят команде. Начиная от тематик, которые никто не хочет иметь в резюме (к примеру оборонка, которую не любили и до 22 года), и заканчивая токсичной коммуникацией и кривой постановкой задач. Вообще найм команды и HR — сама важная, после продаж, компетенция в аутсорсе. Нам эта компетенция важна больше, чем другим — из-за асинхронной коммуникации. Из 20 программистов, которые умеют писать хороший код, найдётся от силы двое, которые умеют ещё при этом выполнять обещания, и 1 из них ещё будет не готов к работе в аутсорсе несмотря на все наши условия.
У меня нет точных цифр, сколько стоит потеря одного сильного программиста, но явно больше стандартной таксы кадровых агентств — 2–3 месячных зарплат. И это я ещё не говорю о стоимости создания неизмеримых факторов, вроде комфортной и дружелюбной среды с понятными задачами — приходится вкладываться, чтобы конкурировать с бигтехом.
Так что выбирая между командой и клиентом, я выбираю команду.
Наверное в этом можно услышать, что находясь в клиентском бизнесе, я плюю на клиентов, но нет — клиентам же нужна команда профессионалов, а не джунов за еду. А чтобы удержать профессионалов, нужно создавать им комфортные условия, в том числе и комфортных клиентов.