25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
Два новых выступления
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%, не отвлекаясь на чужие проблемы. У пилотов есть «стерильная кабина» — в кабине самолёта запрещено разговариавать о чём-то кроме полёта. У меня вместо стерильной кабины — умение не ввязываться: не допускать в локус внимания ничего, что не имеет отношения к задачам, какими бы они ни были в данный момент.
Возможность не ввязываться — важнейший смысл асинхронной коммуникации. Сложно не посмотреть на новый проект хотя бы одним глазком, когда тебя поймали с ним в переговорке. И наоборот, гораздо легче думать о важном в продуктивное время и с осознанным письмом.
Несколько лет я веду список, который так и называется — «проекты, в которые я ввязался». Сверяюсь с этим списком во время еженедельного обзора, и когда удаётся что-то из него выкинуть или хотя бы делегировать — считаю себя молодцом.
#вопрос Где вы с Саматом взяли первых клиентов для аутсорса?
Я вроде собирался больше не отвечать на бизнес-вопросы про аутсорс, но чё-т опять не могу молчать.
Отвечу кратко — аутсорс вам начинать не стоит. Это очень неблагодарный бизнес с низкой маржой и высокой конкуренцией. Конечно не продажи на вайлдберис, но радости тоже мало.
1. Из-за низкой маржи образуется пропасть между начинающими, которые до конца жизни будут делать сайты для автомоек и лидерами, которые прочно сидят на больших контрактах и потихоньку превращаются в интеграторов. Если вы не знаете, как попасть в подрядчики к условному ВК — всю жизнь останетесь в красном океане маленьких региональных аутсорсеров.
2. На рынке (особенно в красном океане) все привыкли к кабальным контрактам — когда вы подписываетесь под результат в мире клиента, но никак не фиксируете объём работ («ТЗ» не в счёт, его не юристы пишут). Time&Material заходит очень тяжело, чтобы его продавать, нужно иметь репутацию на рынке. На автомойках репутацию не наберёшь. Есть вариант с аутстафом, но у аутстаферов маржа ещё ниже, а от больших контрактов они зависят ещё больше.
3. Низкая маржа и кабальные контракты ведут к плохому качеству. Чаще всего долгосрочные проекты превращаются в гору дерьма, которая растекается раз в месяц и пахнет так, что заказчик просит включить в договор штрафы за сорванные сроки и падения прода. Управлять джунами, которы обложились говнокодом — штука безысходная: нужно или иметь железные нервы, или совсем не иметь совести и человеколюбия.
4. Не-джунов брать негде. Рынок пылесосят Яндекс, ВК и Сбер. Вы никогда не сможете конкурировать с ними за условия труда.
Нам с Саматом удалось взломать эту модель просто потому, что у Самата был огромный нетворк, а у меня умение очень быстро и эффективно писать код (первые 3 проекта я писал сам). А ещё мы вместе не ссали использовать странные модели вроде асинхронной коммуникации и четырёхдневной рабочей недели. Мы всё ещё очень далеки от лидеров рынка, и у нас нет стратегии, как туда попасть — есть только примерные попытки.
Написал это и думаю, что такое можно сказать про любой развивающийся бизнес. Но в своём мнении я честен — лучше поищите что-нибудь более благодарное.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Как дела
Давно не писал сюда не рассказывал как дела. А у меня на самом деле предпринимательская жизнь бьёт ключом:
— Дописали с Марьяной курс «Без ерунды». Сегодня выходит последний лонгрид, скоро откроем продажи для тех, кто не пришёл на поток. Теперь снова могу писать в канал и не бояться прокрастинировать лонгрид!
— Впервые в жизни подал в суд на заказчика! Судимся уже три месяца. Подробности напишу, когда станут публичными.
— Напоролись с Саматом на классический кейс с револютом — без объяснения причин заблокировали счета, карты и API ключи. Сапорт тоже по классике игнорит. Перетаскиваем контракты на новые реквизиты.
— В аутсорсе у нас появился COO (Настя, привет!). Тревожно и восторженно отдавать управление производством. Восторженно — потому что это путь к дальнейшему росту. Тревожно — потому что как же оно без меня-то, а? Пойду «Самому не проще» перечитаю.
Конфликт творцов и продюсеров
Почти в любой творческой работе есть два лагеря — творцы и продюсеры. Творцы что-то производят, а продюсеры сидят рядом и смотрят, чтобы произведение претендовало на коммерческий успех. Иногда продюсер включается в творческий процесс, иногда ограничивается тем, что просто задаёт направление. Иногда в парах творец-продюсер люди меняются местами: сегодня я пишу, а ты смотришь, завтра ты пишешь, а я смотрю. Иногда продюсеров называют по-другому: к примеру у дизайнеров роль продюсера часто играет арт-директор, у программистов — продакт или QA, а в книжном деле — издатель.
Находясь в позиции творца, принято не любить продюсеров. Типа ты такой изобретаешь что-то прорывное, вот-вот скажешь новое слово для всего человечества. А продюсер приходит с умным видом и командует — «вон то удали, вот тут переделай».
Не любить продюсеров — большая ошибка.
Даже самый авангардный художник-концептуалист хочет, чтобы его работу увидел и похвалил кто-нибудь, кроме мамы. А для этого надо не забывать про рынок — кто, в каких условиях, и для чего будет эту работу смотреть. Можно играть по правилам рынка, можно эти правила ломать, но их нельзя игнорировать: никто не будет читать неинтересную книгу, написанную плохим языком, не станет делать покупки на лендосе без внятного предложения, не станет смотреть невидимые картины, нарисованные невидимыми красками в голове автора.
Когда творишь что-то новое, о конечном потребителе думать тяжело — либо творчество превращается в попытки забрать спрос, либо совсем отрывается от реальной жизни. В итоге такого творчества получаются посредственные вещи: у музыкантов получается кальянный реп, у маркетологов — скидки, а у ИТ-школ — курс «Учим питон за полчаса». Творить и продавать — это два разных состояния мозга, которые не пересекаются так же, как творческая работа не пересекается с тупняком в инстаграме.
Не забывайте о продюсировании своей работы. Не воспринимайте продюсера как злого начальника — это ваш помощник, не меньше вас заинтересованный в том, чтобы сделать качественный продукт.
Ласт-колл на «Без ерунды» — курс о DevEx, который состоит только из диалогов
Есть знания, которые хорошо передаются через любые барьеры — к примеру техническая документация, которую можно читать хоть на телефоне. Есть знания, которые, наоборот, передаются только через личное общение — обычно это телесные навыки, типа спорта (кто хоть раз пробовал удалённого фитнес-тренера, тот меня поймёт), игра на музыкальных инструментах.
А есть знания, которые лучше всего передаются через обычные разговоры — очно в офисе или по зуму. Работаешь рядом с человеком и тренируешь мозги делать так, как делает он — сначала копируешь, потом развиваешь свой стиль. Такое хорошо работает в руководстве, в управлении людьми, в стратегическом мышлении. Последнее — вообще кайф: мне кажется, что Теория Ограничений так хорошо отпечаталась у меня в голове именно потому, что Голдрадт её подал в виде кусочка жизни обычных людей, которые ты проживаешь вместе с ними во всех трёх «Целях».
Мы с Марьяной замахнулись на похожий формат — весь курс о DevEx получается в виде разговора двух главных героев. Сергей и его падаван Настя говорят с людьми вокруг — программистами и безопасниками, представителями бизнеса, CTO. В диалогах они решают одну большую задачу — привести команду программистов из состояния, в котором они ничего не релизят, потому что весь день занимаются фигнёй в состояние, в котором бизнес доволен происходящим.
За 4 письма герои через призму DevEx применяют все инструменты, которые нужны управленцам — раскладывают работу команды через JTBD, чинят онбординг и передачу знаний, разруливают проблемы с продуктивностью и, наконец, чинят коммуникацию с бизнесом. По дороге — практикуются переговорах и стратегии.
Получается лёгкий курс, с огромным объёмом полезных знаний. Первое письмо — в эту пятницу, всего их 4, раз в неделю. Пока мы только пишем курс, цена совсем небольшая — потом будет намного дороже.
Смотреть программу →
Опять про DevEx
Кароч, мы тут сделали курс по Developer Experience. В посте рассказываю, зачем мы его сделали, чем он отличается от прошлогоднего (маленького) вебинара, и зову купить билеты. Они недорогие — хотим, чтобы наши письма были как аптечка, доступны каждому.
В ИТ-тусовочке складывается очень узкое понимание понятия Developer Experience. Типа чтобы стать специалистом по DevEx, достаточно написать пару скриптов для команды, поправить конфигу таскраннера и заменить Elastic APM на Datadog. Получается так же, как стало с DevOps — когда целую систему взаимодействия между разработкой и эксплуатацией превратили в новое название для системного администрирования, потеряв по дороге большую часть смысла.
DevEx — это не (только) про инструменты, это — про повышение эффективности разработки. То есть про то, как уменьшенить когнитивную нагрузку, создать комфортную рабочую среду и безопасный контекст. Что-то вроде современной гигиены труда, помноженной на грамотное управление творческими людьми. Опыт в DevEx (может быть даже несформулированный) — это то, чем отличаются управленцы, вышедшие из разработки. Если обычные менеджеры в случае проблем склонны нанимать больше программистов, то управленцы из разработки — наоборот, создавать более удобную среду, в которой меньшее количество программистов делает ту же работу.
Вот об это и наш курс — как работать быстрее, но не растить команду. Курс получился довольно коротким и лёгким — всего 4 письма за 4 недели. Говорим о JTBD, когнитивной нагрузке и онбординге, разбираем, чем удобные инструменты отличаются от неудобных. Последний модуль — о современных Agile-ритуалах: как подчинить разработку требованиям бизнеса, не жертвуя удобством программистов. Писали его для тимлидов, CTO, менеджеров и синьёров. Мидлам и околопрограммистам — если хотите больше понимать, что происходит вокруг или расти в управление. Джунам смысла нет.
Смотреть программу →
Если были на прошлогоднем вебинаре — смысл есть: материал полностью новый, его больше, и подан он более вдумчиво и легко.. Стартуем 15 ноября (это уже через 2 недели). Учимся 4 недели. До 7 ноября действует промокод CRUNCH на 10% скидки.
А давайте встретимся в Алмате?
В понедельник, 21 октября, проводим открытый митап с CTO kolesa.kz Николаем Киндяковым. Повестки нет — хотим просто собраться в офлайне и поразгонять на тему конфликта бизнеса и разработки, поотвечать на вопросы или позадавать их вам.
Встречаемся по адресу ул. Шевченко 155/6, в понедельник, в 18:30 UTC+5. Если хотите прийти — заранее зарегистрируйтесь
А помогите нам получить премию
Мы подали «Анализ систем» ещё на одну премию — School of Education. Результаты оцениваются по итогам голосования, но там нужно не просто нажать кнопку, а написать содержательный отзыв на 100 слов. Если вам понравился курс — потратьте 3 минут на отзыв (или хотя бы на промт).
Для всех, кто оставит голос, мы сделаем с Антоном Давыдовым факультатив на какую-то тему, которая касается курса — присылайте скрины на support@tough-dev.school, а мы напишем в ответ, как только определимся с датой и темой.
OpenWRT и сисадминство
Я давно расстался с сисадминской привычкой сисадминить всё вокруг себя — выбираю iOS вместо Android и мак вместо линукса, езжу на свежей Toyota вместо старой BMW и предпочитаю готовые инструменты собственным огородикам (даже в последние 2 года). Понимаю, что контроль за инструментами — это не только возможность, но и обязанность: когда сломается BMW — её надо починить, а в линуксе нужно будет периодически чинить отвалившийся WiFi или сканер отпечатков пальцев.
После 12 сентября, когда сразу куча зарубежных сервисов перестали работать из России, пришлось перерешивать одну из таких проблем, которую я считал закрыто. Уже лет 7 у меня дома стоит замечательный роутер Amplifi, который за всё это время ни разу не завис и позволял мне не думать о качестве приёма внутри квартиры. Но, увы, промышленность не выпускает роутеров, которые умеют заворачивать в shadowsocks, выборочные маршруты, а теперь без этого комфортно работать не получается. Поэтому пришлось переходить на OpenWRT.
Пока ждал роутер (выбрал Mikrotik Hex) — в голову лезли вьетанские флешбеки сисадминские мысли:
— А давай воткнём в роутер SD-карту, чтобы можно было установить питон и обновлять маршруты автоматически?
— Если не SD-карту, то давай хотя бы скрипт перепишем на micropython.
— О, а ещё есть старый LTE-модем. Давай сделаем второй интернет, на случай если откажет первый?
— А в списке пакетов есть ещё cloudflared! Клёво будет ходить на роутер, даже когда он переключится на запасной интернет!
— И ещё надо сделать автовыбор эндпоинтов для VPN — чтобы переключаться с одного на другой, если они начнут отказывать.
— О, может ещё тем для luci поставить?
К счастью, здравый смысл победил — всей этой хернёй я заниматься не стал. Особенно смешны были мысли про второй интернет — за последние 4 года даунтайм моего домашнего провайдера составил 15 минут.
Жалею конечно, что пришлось отказаться от старого проверенного решения, но выбора у меня, кажется, не было. Ну и горжусь, что смог не насисадминить лишнего даже с OpenWRT, которая буквально подталкивает к этому.
Как хорошо оценивать задачи
Когда речь идёт о хорошей оценке задач, многие представляют себе эксперта-сметчика с годами наработанной интуицией, который обложился доверительными интервалами и матмоделями, оценил в жизни 100 проектов и может за пару часов погрузиться в кодовую базу любого проекта.
Наверное где-то такие люди и существуют, но я их ни разу не видел и ставлю под сомнение их тотальную необходимость. Конечно где-то есть проекты, которые можно сделать только с чёткой и точной оценкой, но среднему бизнесу (если это не аутсорс по фиксированной цене) от прорграммиста нужна не оценка, а предсказуемость.
Как в стройке — содрал старые обои, и выясняется, что стены кривые. Закупил ламинат — понимаешь, что стяжку надо переделывать. Опытный прораб сначала проверит качество стяжки, а потом уже поедет в Леруа за материалом. А плохой — умолчит, положит как-нибудь так, а когда замки не закроются или пол начнёт скрипеть — будет делать вид, что так и должно быть.
Применительно к программированию это значит две вещи. Первая — постоянно искать, где сейчас самая большая зона неопределённости и пытаться её снять. Делаем интеграцию с новым сервисом — сначала накидываем вручную запрос на основе данных из системы, а потом уже пишем оболочку. Меняем модель данных — сначала проводим миграцию на продовых (или максимально близких к ним) данных, а потом уже дописываем код под неё. Пишем код неделю в отрыве от команды — сначала мёрджим мастер. И т.д.
Вторая — быть прозрачным. Видим риск, который не получается снять за 5 минут — сигналим бизнесу. Прошло 50% времени и не сделали 50% работы — сигналим бизнесу. Всё вроде бы идёт хорошо, но интуиция подсказывает, что будут проблемы — сигналим бизнесу.
В большинстве своём даже такая минимальная прозрачность успокоит бизнес и создаст вам репутацию надёжного исполнителя. А матмодели оставьте людям, которые делают самолёты.
Затаскивать проекты, а не людей
Клёво затаскивать проекты. Запускать обещанное в срок, выстраивать для этого понятные планы и чёткую коммуникацию. Выбивать команде самые удобные инструменты. Договариваться с заказчиком, придумывать как срезать углы или наоборот, сделать больше работы, принеся больше пользы.
Неклёво затаскивать людей. Не работать вместе над общим делом, а всей командой обходить неумение кого-то одного писать код или выполнять обещания — перераспределять нагрузку, какделировать несамостоятельных, выкидывать работу не потому, что неважно, а потому, что не успеваем.
Когда затаскиваешь проекты — растёшь. Учишься делать это эффективнее, чужими руками, а потом и руками тех, кто сам делает это чужими руками.
Когда затаскиваешь людей — ты просто тратишь время на то, чтобы принести результат.
Готовые комплекты вещей
Самое смешное бытовое открытие прошлого года — это готовые комплекты вещей. К примеру, комплект проводов и зарядок для поездки. Раньше нужно было подумать, какие устройства я с собой беру (нужен ли lightning? а зарядка для часов?), посмотреть, отыскать всё это, проверить чтобы все провода были совместимы со всеми устройствами, а после поездки — вернуть на место. Сейчас достаточно взять маленькую сумку с зарядками, которая всегда собрана.
Или наушники. Раньше нужно было не забыть наушники, когда идёшь в кофейню, отыскать их перед походом в спортзал, и проследить, чтобы они не сели во время зум-созвона. Сейчас достаточно взять наушники для встреч (самые лёгкие и без шумоподавления, которое не нужно дома), в дороге — достать походные наушники, а в спортзале — взять спортивные, которые так и живут в спортивной сумке.
Дошёл до этого после идеи с айпадом для одиночества. Вы не представляете, сколько времени, а главное — энергии я стал экономить, когда перестал собирать электронику в поездки.
В комментах к посту про список проектов, куда я ввязался, задали интересный #вопрос — как фокусироваться и при этом оставлять пространство для slack-time. То есть времени где можно расфокусироваться и проявлять любознательность или просто пофаниться?
Я конечно тот ещё эксперт по тайм-менедменту, но попробую ответить как это устроено у меня. Время любознательности и развлечения — это вообще главное время в дне. Для меня возможность поизучать что-то новое и приятное — это награда, к которой я иду через другие дела. Новое и приятное может быть каким угодно — новые либы\языки, перестановка в кабинете или способы открытия LLC в США.
Я довольно зависимый человек, и если сажусь за что-то дофаминово-любознательное, мне тяжело останавливаться. Поэтому стараюсь не планировать такие вещи на утро — иначе рискую целый день проковыряться в чём-то несрочном, но безумно интересном.
Конечно же, изучение новых вещей — это такой же проект, в который я ввязался. И на еженедельном обзоре я ограничиваю количество таких проектов так же, как и всех остальных.
Хочется добавить, что главное в любой науке о продуктивности — это всё-таки не писать планы и не пытаться с лицом Льва Толстого за ними следовать, а прислушиваться к себе. Если я с утра понимаю, что сегодня день расфокуса — стараюсь не насиловать себя, а заниматься интересным.
Кстати, вопросы лучше всего задавать на fborshev@pm.me. Ответы выкладываю по понедельникам.
Скиллы и над-скиллы
Это — ласт-колл на 4 поток нашего флагманского курса «Анализ Систем».
Когда я собеседую программистов, я редко смотрю на хард-скиллы, которые они рекламируют в резюме. Что толку, если программист знает десяток фреймворков, если он не умеет подбирать тот, который подходит задаче? Гораздо важнее не скилы, а «над-скиллы»: насколько программист интересуется происходящим в индустрии, как умеет сравнивать инструменты друг с другом, умеет ли вообще задавать вопросы?
То же самое и со знаниями: можно несколько лет читать про DDD и не научиться разбивать систему на элементы и уж тем более, делать это в сооветствии с потребностями бизнеса.
«Анализ Систем», мы делали как раз для того, чтобы не складывать в резюме аббревиатуры (хотя они тоже будут), а чтобы прокачивать над-скиллы. Вместе с Ибрагимом и котом-критиком вы будете решать большие архитектурные задачи, получить которые в реальной жизни довольно сложно, не имея опыта. Обратную связь на свои решения тоже можно не ждать по несколько лет, а получить сразу.
Стартуем 16 января, учимся 5 недель. Учебная нагрузка — примерно 10 часов в неделю (у кого-то сильно больше, но точно не меньше) — мы рекомендуем брать отпуск на работе как минимум на один день каждую неделю обучения. Если хотите серьёзного буста в над-скиллах — берите тариф «в тусовке». К слову, «Долями» подняли нам лимиты, и теперь оплачивать тариф «в тусовке» частями могут не только клиенты Т-банка, но и все другие. От юрлица и из-за рубежа тоже можно.
Следующий поток будет не раньше лета
Группа про социальную тревогу
Немного нестандартное для канала объявление — мои хорошие друзья набирают психологическую группу, посвящённую социальной тревоге. Приглашают всех, кто напрягается от смоллтока, боится выступлений и разговоров с начальством, кому встреча с незнакомыми людьми может испортить вечеринку, а необходимость звонить в банк заставляет поменять банк.
Кто не знает, психологическая группа — это способ сэкономить на психотерапевте и почувствовать себя неодиноким за счёт товарищей с такими же проблемами.
Группа расчитана на год, максимум 12 человек. Стоимость — 4000 рублей за занятие, проходят раз в две недели, онлайн. Чтобы пройти собеседование — запишитесь здесь, ребята вам напишут.
Команда ценнее клиента
За небольшую историю нашего аутсорса мы несколько раз отказывались от денежных клиентов, которые подходили по стеку и задачам. Иногда на этапе продажи, а иногда — уже в процессе работы. И я говорю не об этике — даркнетчики и скамеры к нам даже не обращаются из-за ценового порога.
Дело в том, что бывают клиенты, которые вредят команде. Начиная от тематик, которые никто не хочет иметь в резюме (к примеру оборонка, которую не любили и до 22 года), и заканчивая токсичной коммуникацией и кривой постановкой задач. Вообще найм команды и HR — сама важная, после продаж, компетенция в аутсорсе. Нам эта компетенция важна больше, чем другим — из-за асинхронной коммуникации. Из 20 программистов, которые умеют писать хороший код, найдётся от силы двое, которые умеют ещё при этом выполнять обещания, и 1 из них ещё будет не готов к работе в аутсорсе несмотря на все наши условия.
У меня нет точных цифр, сколько стоит потеря одного сильного программиста, но явно больше стандартной таксы кадровых агентств — 2–3 месячных зарплат. И это я ещё не говорю о стоимости создания неизмеримых факторов, вроде комфортной и дружелюбной среды с понятными задачами — приходится вкладываться, чтобы конкурировать с бигтехом.
Так что выбирая между командой и клиентом, я выбираю команду.
Наверное в этом можно услышать, что находясь в клиентском бизнесе, я плюю на клиентов, но нет — клиентам же нужна команда профессионалов, а не джунов за еду. А чтобы удержать профессионалов, нужно создавать им комфортные условия, в том числе и комфортных клиентов.
Анализ Систем — 4
В школе появился флагман. Его берут в образовательные премии, половина запросов в сапорт — «когда откроете поток?», а постоянные b2b-клиенты разбирают ВИП-тариф ещё до официального запуска. Думаю так получилось потому, что в курсе сошлось всё вместе — знания Антона, которые он собирал несколько лет, наше с Марьяной желание сделать радикально новый образовательный опыт, и редактура прекрасного Тимура Зарудного. Ну и ещё наверное потому, что system design — горячая и актуальная тема, хотя курс и не совсем про это.
Мы уже анонсировали новый поток в почте, но напишу и здесь. Обучение стартует 16 января, покупать лучше сейчас: во-первых это дешевле, во-вторых — в декабре работодатели проще компенсируют расходы на обучение, потому что у всех остаются излишки бюджетов под конец года. Налоговый вычет, кому надо, тоже можно получить этим годом.
На курсе мы говорим о стратегическом анализе бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций между сервисами. Про ADR и документацию тоже говорим. Самая любимая тема — распил монолитов: ему посвящён четвёртый урок. Ради него мы когда-то затеяли курс, но потом получилось то, что получилось — интересная история Ибрагима и его кота, вдумчивое изучение которой даёт мета-навык — умение слушать бизнес и не кодить лишнего.
Стартуем 16 января, учимся 5 недель. Учебная нагрузка — примерно 10 часов в неделю — мы рекомендуем брать отпуск на работе как минимум на один день каждую неделю обучения. Учиться лучше в тусовке — наблюдая за чужими домашками, вы вынесете из курса гораздо больше знаний, чем если просто прочитаете материалы. До вечера пятницы 13 декабря действует промокод IBRAHIMSCAT на 10% скидки. Следующий поток не раньше лета.
Смотреть программу и отзывы →
И мы туда же (чёрная пятница)
Вот уже четвёртый год радуюсь, сколько новых учеников знакомятся с нашими курсами на чёрную пятницу. Наверное больше ребят приходит только через пиратов, но те, увы, статистики не публикуют.
Если вы ещё у нас не учились и сомневаетесь — в ближайшие три дня можно купить любой наш курс кроме «Анализа Систем» и «Без Ерунды» со скидкой 25%. Промокод BLACKFF, выбирать тут.
P.S. Кстати, если приобрели наш курс у пиратов, и он вам помог — можно тоже что-нибудь купить, нам будет приятно.
Режим саджестов в ноушене
Ноушен недавно выкатил странный режим саджестов — когда ты не просто правишь какой-то текст, а предлагаешь к нему изменения. Потом коллега их смотрит и принимает. Ну или не принимает, или делает новые саджесты. По-моему, эта штука противоречит всей идее совместного редактирования текстов.
Дело в том, что их режим саджества — копия старого режима саджеста из Ворда: он построен вокруг букв, слов или абзацев. А когда люди пишут тексты вместе, они правят не буквы, а смыслы. Когда мы с Марьяной пишем лонгриды в школе, мне совершенно всё равно, какие слова в тексте она меняет. Гораздо важнее, как она обогащает смыслы — чем делает текст полезнее для учеников, насколько легче стало его воспринимать, насколько короче сформулировала мысль. А режим редактирования мне рассказывает, что Марьяна добавила слово «когда» после буквы «а». Как будто с высокоуровневого фреймворка на C перешёл, чесслово.
В Ворде можно хотя бы переключиться в режим итогового текста — смотреть не на правки, а на их результат, без ужасной цветной разметки. А в ноушене такого режима, я вынужден одновременно читать два, смешанных друг с другом, текста, и при помощи цвета декодировать, какой из них актуальный. При редактировании то же самое — я вроде бы что-то удаляю, а оно не удаляется, а краснеет. Ужас.
Наверное этот полезно для юристов, у которых докапываться до букв — это основная работа. Но вряд ли среди пользователей ноушена много юристов: юристам им с вордом ок. Продактам notion конечно виднее, но с моей позиции их фича выглядит довольно странно — даже обычная история редактирования в текущем виде выглядит полезнее. Ну и уж точно я никому не буду присылать текст в режиме изменений.
Опора для коллег
Важная функция руководителя — быть опорой для коллег. Когда прод лежит, а сроки горят — тимлид должен приносить в команду спокойствие, а не тревогу. Когда прибыль падает, и CEO топчет ногами — COO должен поддерживать коллег, а не грозить всех уволить. Когда инвесторы отказываются от раунда, CEO должен верить в будущее, а не пропадать из офиса с бутылкой.
Собственник бизнеса имеет право на свою прибыль именно потому, что обязан оставаться спокойным и трезвым в любой ситуации. Даже когда когда корабль тонет и бизнес разоряется — команда должна видеть уверенного капитана, чтобы спокойно вычёрпывать воду.
Самое сложное в том, что надо не просто демонстрировать спокойствие и искриться улыбкой, а действительно быть таким внутри, иначе люди быстро распознают хуйню и станет только хуже. Это довольно сложная работа — чтобы выполнять её в собственных бизнесах, мне понадобилось 10 лет ежедневного руководства командами и 5 лет психотерапии. До сих пор есть, куда расти.
Мой идеал спокойствия — Людвиг Быстроновский, арт-директор, с которым я когда-то давно работал в студии. Судя по его рассказам (посмотрите его цикл лекций о шторме) — человек довольно взрывной внутри. Несмотря на это, всегда когда у меня случался полный пиздец (а в клиентской работе полные пиздецы случаются раз в неделю), если на проекте был Людвиг — я успокаивался гораздо быстрее. Он не применял никаких специальных инструментов — просто спокойно разговаривал о проблемах. Наверное это работало где-то на уровне химии и языка тела, не знаю. Часто мне даже не надо было с ним разговаривать — я садился писать ему письмо и, даже не дописав, понимал что делать. Сейчас я стараюсь быть таким же для своих коллег — давать уверенность и спокойствие, что бы ни происходило в бизнесе.
Так вот, к чему это я: если начали руководить даже двумя людьми — учитесь приносить им спокойствие. Тревоги им и без вас достаточно.
Firefox!
Я тут внезапно перешёл на сабж и ничего не случилось.
С самого первого дня на маке я юзал Сафари — мне очень нравилась скорость и интерфейс без лишних кнопочек. Ради этих двух вещей я почти 10 лет мирился с некорректным рендерингом некоторых сайтов, невнятными адблокерами (сначала опенсорсный Ka-Block, потом вообще 1Blocker), и корявыми расширениями, вроде Cascadea для юзерстилей или глючного 1password.
Последний и стал причиной перехода — в какой-то момент создатели 1password вынудили меня перейти с 7 на 8 версию (говно на электроне). Поскольку деваться было некуда, и лучше сделать это заранее, чем ловить глюки от разных версий, основное рабочее место я тоже перевёл на 1password 8. После танцев с бубном завелось всё, кроме плагина для Safari — он ужасно глючил. Так я и перешёл на Firefox, который решил последние мои проблемы: у него расширение работает как часы (насколько это применимо к говну на электроне). Выбрал его из-за приватности — в нём гораздо легче отключить гугловую телеметрию и другие плюшки вроде автохода в гугл.
Firefox тут же напомнил про забытые за 10 лет возможности — вроде нормального адблокера вместо 1blocker или работающего Consent-O-Matic вместо корявых решений для Safari. Зарабоали даже штуки, аналогов которых для Сафари я просто не знал — вроде SponsorBlock и DeArrow для ютуба. Работает всё так же быстро, как раньше, и даже интерфейс удалось сделать (почти) таким же чистым.
Теперь у меня два основных браузера — FF для сёрфинга и Brave, когда надо поковыряться в потрохах чьего-нибудь фронтенда или поработать с Metamask.
Учиться у редакторов и дизайнеров
Каким бы отменным вкусом ни обладал дизайнер, в профессии он не будет стоить ничего, если этот дизайнер не умеет смотреть на макеты глазами конечного пользователя. У редакторов так же — хоть изучи наизусть весь словарь Даля и прочитай всю русскую классику — если ты пишешь тексты непонятно для кого непонятно о чём — ты никому не нужен.
А вот программистов этому не учат. Не в смысле делать хорошие тексты и интерфейсы (хотя и не помешало бы), а в смысле смотреть глазами потребителя их кода — другого программиста в будущем. Открываешь модуль — а в нём 3 класса, 5 функций и ещё сколько-то кода выполняется при импорте. Почему они все вместе? Что делает модуль? Непонятно. Или читаешь функцию — а там 50 строк, 10 if и поди пойми, зачем она вообще существует.
О коде нужно думать как редактор или дизайнер. Цикломатическая сложность, чистота по дяде Бобу или <любая ваша метрика> — это базовая гигиена, как отсутствие грамматических ошибок в тексте у редактора. Гораздо важнее высокий уровень — как будущие программисты будет решать свои задачи в нашей кодовой базе. Если надо будет пилить новую бизнес-логику, поймут ли они, в каком формате у нас это принято делать — сервисыные объекты\контролелры\микросервисы? Сколько времени будущие программисты будут разбираться, как у нас прокидываются настройки из рантайма? Если надо будет что-то делать с БД, поймут ли как у нас работают миграции схемы?
Читать о продуктивности вместо того, чтобы делать дела
Пришёл я недавно к Антону комментить статью про Obsidian — я потихоньку делаю лонгрид о том, как использовать его в качестве личного дневника, и очень заинтересовался паттернами Антона.
Довольно обидно стало, когда Антон, вместе с благодарностью за коммент, рассказал, что эта статья — самая комментируемая у него него за последнее время. Обидно — потому, что я знаю у себя привычку к такого рода прократстинации — вместо того, чтобы пойти и сделать работу, потратить время на то, чтобы сделать эту работу на 2% *эффективнее* — как тот линуксоид, который за 2 часа напишет скрипт, который за 5 минут сделает то, что юзер руками делал бы час.
В профессиональной деятельности я эту привычку вроде бы обуздал. Предпринимательство вынуждает фокусироваться на важном и откидывать любую деятельность, которая не имеет отношения к результату — иначе я просто разорюсь. Ну а 20 лет в программировании не позволяют мыслить совсем уж поверхностно — всё-таки создавать долги я ненавижу на уровне условных рефлексов.
В личном плане всё хуже. Кроме Обсидиана, есть ещё классические примеры — вроде покупки абонемента в спортзал вместо занятий спортом. Или вот недавно потратил 4 часа на выбор струн для бас-гитары, пока не сообразил, что занимаюсь хернёй — если бы я это время просто играл мажорные гаммы — продвинулся бы гораздо дальше.
Знаю точно, что я не один страдаю привычкой к полировке продуктивности — статистика из канала Антона это просто ещё одно подтверждение. И, к сожалению, не знаю универсального рецепта, как справиться с этой привычкой. Пока самое действенное средство — это тот самый личный дневник: когда садишься вечером и вспоминаешь, на что потратил день, занятия хернёй становятся очень заметны. Главное не стесняться себе в этом признаться.
#вопрос не расту на работе, уже джва года ничего не происходит — ни обязанностей не прибавляется, ни зарплаты. Подумываю уволиться. Что делать?
———
Сочувствую! Я и сам был в такой ситуации — топтался на месте и понимал, что никому мой рост не нужен, и боссам достаточно, чтобы я просто ходил на работу и закрывал привычные обязанности. Сейчас, когда я сам дошёл до этапа босса, я их понимаю — мне бы бизнесом заниматься, а не следить, чтобы каждому было интересно. Я, конечно, стараюсь это делать — но это, увы, далеко не первым приоритетом.
Предположу, что самый очевидный шаг — поговорить с тимлидом/боссом и попросить новых обязанностей, — вы уже выполнили, и результата не получили.
Следующий шаг — принять факт, что никто вас вперёд толкать не будет. Хотите делать больше и интереснее — ищите как. Я тогда занялся ростом самостоятельно — построил план роста на год: выучить питон и джангу, потренироваться в общении с людьми через random coffee и личные встречи с предпринимателями. Всё это прекрасно уложилось в рабочее расписание — я вложился, настроил дела так, чтобы работали с минимальным участием и честно пошёл заниматься своими делами.
Увольнялся я бы только в третью очередь — только после того, как исчерпал все другие возможности. Дело в том, что ваше текущее состояние — отличный способ потренировать проактивность: когда вы не ждёте, что желаемое сваливается на вас с неба (или приходит вместе с новой работой), а добиваетесь этого сами. Это отличный навык, который пригождается в любом деле, и не только на работе.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Мы сами виноваты в говнокоде
Этот пост — ласт-колл на второй поток «Стать Тимлидом 2.0». 18 сентября в 16:00 MSK — встреча потока, где мы все знакомимся. Ещё можно успеть купить за свои деньги, а потом вернуть на работе по чеку.
Большинство программистов, которые беспросветно сидят на легаси, обвиняют в этом свой бизнес. Типа мы бы и написали хороший код, да злые дядьки не дают — диктуют правила, давят сроками, не выделяют время на техдолг. Это не так.
Бизнес, каким бы он ни был — довольно прагматичная система, которая умеет принимать решения. Если заставить бизнес выбирать между наймом людей или стагнацией — он выберет найм людей. Когда понадобится выбрать одного подрядчика из 10 доступных на рынке — бизнес опишет требования и выберет самого подходящего.
Так почему же между работающей системой и вставшей колом разработкой, которая сама не может разобраться в своей сложности, бизнес часто выбирает второе, да ещё насильно заставляет программистов говнокодить сверху? Да потому, что он им не доверяет.
Представьте, что у вас дома прорвало канализацию. Приходит сантехник, говорит «изян», и пропадает. Вызываете другого — тот жалуется на первого, обещает всё исправить и тоже пропадает. А из трубы-то льётся! Где-то после третьей итерации вы уже сами пойдёте перекладывать трубы хоть во всём доме — и пофиг, насколько эти трубы будут соответствовать правилам и стандартам: вам бы от запаха избавиться. Так и бизнес пишет руками программистов — просто, чтобы перестало литься.
Легаси — это следствие пропасти между бизнесом и разработкой. Отсутствие этой пропасти — не гарантия чистого кода, но если разработка умеет говорить с бизнесом, то качество кодовой базы будет ограничено только профессионализмом программистов. Наш курс — как раз про то, как сузить эту пропасть, и приблизить программистов к бизнесу: научиться разговаривать с «той стороной», брать ответственность за сроки и решать проблемы с командой.
Приходите