Вчера стартовали «Коммуникацию систем», а я не пришёл на первую встречу — не было времени, одновременно редачу материалы и пишу код в LMS.
Колеги скидывают скриншоты из чата, познакомлюсь с ребятами хоть так. Смотрите, какие все крутые!
Колеги скидывают скриншоты из чата, познакомлюсь с ребятами хоть так. Смотрите, какие все крутые!
Ждать, пока выплывет
В онбординге людей есть две крайности. Первая — обложить инструкциями и гайдами, приставить бадди и вообще всячески сопровождать. Вторая — «бросить в воду»: оставить человека одного и ждать, что он сам научиться решать задачи и задавать вопросы.
В FANS я тяготею ко второй. Это специфика remote-first—компаний: если человек с самого начала приучается общаться с бадди, он и потом будет искать себе «бадди» и назначать по созвону на каждый вопрос.
Наша специфика тоже есть: мы как аутсорс делаем ставку на самостоятельных программистов, которые могут работать автономно, иногда напрямую с клиентом. Такой человек уж точно должен уметь решать задачи в новых средах.
Конечно, бросание в воду не снимает ответственности с руководителя. К примеру, так же как и в детском саду, нужно выпиливать из компании знания, требующие передачи, а те, что не удалось выпилить — превращать в инструкции. Точно так же нельзя оставлять человека в полном одиночестве — так даже у самого самостоятельного в мире человека поедет крыша.
Конечно, при жёстком онбординге есть риск потерять каких-то людей, которые могли бы стать самостоятельными когда-нибудь потом. Но кажется лучше ошибиться и потерять хорошего человека, чем не ошибиться, но взять балласт.
В онбординге людей есть две крайности. Первая — обложить инструкциями и гайдами, приставить бадди и вообще всячески сопровождать. Вторая — «бросить в воду»: оставить человека одного и ждать, что он сам научиться решать задачи и задавать вопросы.
В FANS я тяготею ко второй. Это специфика remote-first—компаний: если человек с самого начала приучается общаться с бадди, он и потом будет искать себе «бадди» и назначать по созвону на каждый вопрос.
Наша специфика тоже есть: мы как аутсорс делаем ставку на самостоятельных программистов, которые могут работать автономно, иногда напрямую с клиентом. Такой человек уж точно должен уметь решать задачи в новых средах.
Конечно, бросание в воду не снимает ответственности с руководителя. К примеру, так же как и в детском саду, нужно выпиливать из компании знания, требующие передачи, а те, что не удалось выпилить — превращать в инструкции. Точно так же нельзя оставлять человека в полном одиночестве — так даже у самого самостоятельного в мире человека поедет крыша.
Конечно, при жёстком онбординге есть риск потерять каких-то людей, которые могли бы стать самостоятельными когда-нибудь потом. Но кажется лучше ошибиться и потерять хорошего человека, чем не ошибиться, но взять балласт.
Один из сложных челленджей в школе — это соблюдать баланс между тем, чтобы тупо следовать запросам аудитории (и получать условный скиллбокс) и тем, чтобы делать нишевые курсы на 19 участников.
К примеру, когда мы делали «Без Ерунды» (это курс о DevEx), один из самых частых запросов звучал так — научите меня мерить командную эффективность (а ещё лучше — расскажите про DORA). Звучит вроде бы понятно, только вот я, повидав кучу команд и управляя собственным аутсорсом, могу смело утверждать, что это DORA — это метрики тщеславия:на них клёво дрочить клёво, когда они есть, но пользы бизнесу они не приносят.
Лучше не расходовать энергию на vanity-метрики, а научиться одной штуке — находить в ежедневной рабочей рутине говно. Эта штука подвластна всем: руководителю — на уровне команды, обычному программисту — на уровне dev-скриптов и собственного календаря. Конечно, измеримый результат нельзя игнорировать: если закрыть глаза на время сборки проекта, время прогона тестов или количество дефектов — получится фигня.
Но вашу работу будут оценивать только по TTM. И DevEx — как раз про это.
Теперь про курс. Мы запускаем второй поток — на этот раз с домашкой. Будем рефлексировать вместе — как и на других наших курсах, вы будете проверять домашки друг-друга. Я тоже буду рядом — буду давать общую обратную связь тем, кто на тарифе «в тусовке».
Ещё есть новость: вместе со мной домашки будет обсуждать Толя Буров. У Толи очень редкий скиллсет: он смешивает опыт дизайнера-проектировщика, программиста и лингвиста. С Толей я познакомился очень давно, когда ещё работал в Студии Лебедева. С тех пор Толя вместе с Максимом Ильяховым сделал Главред и запустил стартап Таймстрайп — органайзер личных дел, который в 100 раз лучше ноушена.
На курсе 4 лонгрида, стартуем 31 июля, учимся 5 недель (интенсивные — 4).
Записаться, посмотреть программу, отзывы и все такое →
До конца выходных работает промокод
Если хотите оплатить от юрлица — пишите Зое на почту support@tough-dev.school. Она сделает так, чтобы ваши бухгалтеры и кураторы обучения были в восторге от того, как мы классно оформляем все доки.
К примеру, когда мы делали «Без Ерунды» (это курс о DevEx), один из самых частых запросов звучал так — научите меня мерить командную эффективность (а ещё лучше — расскажите про DORA). Звучит вроде бы понятно, только вот я, повидав кучу команд и управляя собственным аутсорсом, могу смело утверждать, что это DORA — это метрики тщеславия:
Лучше не расходовать энергию на vanity-метрики, а научиться одной штуке — находить в ежедневной рабочей рутине говно. Эта штука подвластна всем: руководителю — на уровне команды, обычному программисту — на уровне dev-скриптов и собственного календаря. Конечно, измеримый результат нельзя игнорировать: если закрыть глаза на время сборки проекта, время прогона тестов или количество дефектов — получится фигня.
Но вашу работу будут оценивать только по TTM. И DevEx — как раз про это.
Теперь про курс. Мы запускаем второй поток — на этот раз с домашкой. Будем рефлексировать вместе — как и на других наших курсах, вы будете проверять домашки друг-друга. Я тоже буду рядом — буду давать общую обратную связь тем, кто на тарифе «в тусовке».
Ещё есть новость: вместе со мной домашки будет обсуждать Толя Буров. У Толи очень редкий скиллсет: он смешивает опыт дизайнера-проектировщика, программиста и лингвиста. С Толей я познакомился очень давно, когда ещё работал в Студии Лебедева. С тех пор Толя вместе с Максимом Ильяховым сделал Главред и запустил стартап Таймстрайп — органайзер личных дел, который в 100 раз лучше ноушена.
На курсе 4 лонгрида, стартуем 31 июля, учимся 5 недель (интенсивные — 4).
Записаться, посмотреть программу, отзывы и все такое →
До конца выходных работает промокод
LEADYOURSELFDX на 10%. Оплатить можно из любой точки мира, в том числе и по безналу. Если хотите оплатить от юрлица — пишите Зое на почту support@tough-dev.school. Она сделает так, чтобы ваши бухгалтеры и кураторы обучения были в восторге от того, как мы классно оформляем все доки.
eslint-config-fans
Наши фронтендеры релизнули свой конфиг для eslint.
Я обычно не верю во внутренние инструменты, которые публикуют аутсорсы — их кайфово делать, но очень тяжело поддерживать. Нашему шаблону django уже 5 лет, и каждое крупное обновление — это целый проект со сложным обсуждением и торговлей за ресурсы.
Конечная ценность у внутренних инструментов тоже сомнительна. Вкладываться в них было бы полезно, если бы аутсорс работал как конвейер: к примеру клёво иметь хороший стриминг данных в elastic/meilisearch, когда релизишь по 5 ecom-стартапов с фасеточным поиском за месяц. В реальности такого нет — любую работу, которую можно настолько ускорить, давно уже делают не людьми, а сервисами. А живым людям остаётся медленный, штучный проект, который никакими шаблонами не ускоришь.
Релизы отечественных коллег я вообще обхожу стороной — код там обычно такой, который и ожидаешь от аутсорса: запутанный и безответственный. Золотые исключения — Evil Martians (правда не знаю, насколько они сейчас отечественные) и wemake.services (не знаю, насколько они сейчас аутсорс).
Для меня единственная мотивация делать внутренние инструменты — это простое «потому что могу». Ну и желание делать свою работу хорошо. Мне нравится руководить аутсорсом, в котором есть шаблоны, которые транслируют наши подходы — и на бекенде, и на фронтенде.
Кароч, насыпьте звёздочек ребятам — https://github.com/fandsdev/eslint-config-fans
Наши фронтендеры релизнули свой конфиг для eslint.
Я обычно не верю во внутренние инструменты, которые публикуют аутсорсы — их кайфово делать, но очень тяжело поддерживать. Нашему шаблону django уже 5 лет, и каждое крупное обновление — это целый проект со сложным обсуждением и торговлей за ресурсы.
Конечная ценность у внутренних инструментов тоже сомнительна. Вкладываться в них было бы полезно, если бы аутсорс работал как конвейер: к примеру клёво иметь хороший стриминг данных в elastic/meilisearch, когда релизишь по 5 ecom-стартапов с фасеточным поиском за месяц. В реальности такого нет — любую работу, которую можно настолько ускорить, давно уже делают не людьми, а сервисами. А живым людям остаётся медленный, штучный проект, который никакими шаблонами не ускоришь.
Релизы отечественных коллег я вообще обхожу стороной — код там обычно такой, который и ожидаешь от аутсорса: запутанный и безответственный. Золотые исключения — Evil Martians (правда не знаю, насколько они сейчас отечественные) и wemake.services (не знаю, насколько они сейчас аутсорс).
Для меня единственная мотивация делать внутренние инструменты — это простое «потому что могу». Ну и желание делать свою работу хорошо. Мне нравится руководить аутсорсом, в котором есть шаблоны, которые транслируют наши подходы — и на бекенде, и на фронтенде.
Кароч, насыпьте звёздочек ребятам — https://github.com/fandsdev/eslint-config-fans
Вайб-управление
Я тут недавно задумался, а сколько же управленческого долга создаёт ChatGPT? С техническим долгом всё понятно — кажется даже самые упоротые школостартаперы поняли, что на одном вайбкодинге далеко не уедешь. А вот что с вайб-управлением?
Менеджеры любят простые решения. Легко, к примеру, сгрузить на LLM комплаенс — он даёт прекрасные и простые ответы о законах и налогах, как будто и не нужны становятся бухглатеры и юристы с их сложностями и огромными ценниками. Через LLM можно написать очень подробное и умно выглядящее ТЗ, попросить ужать до одной строки длинное клиентское письмо, изучить новый рынок, сделать SWOT-анализ и сформулировать туду-лист после встречи.
Чтобы устоять перед решением, которое выглядит умно и обосновано, нужно очень много ответственности, которой у менеджера в запаре может и не быть. Понятно, что компании в неподходящих юрисдикациях никто открывать не будет — это как принимать лекарства на основе диагноза из ChatGPT. Но вот просрать какие-нибудь налоги, потерять договорённости с клиентом или слить в трубу время программистов — вполне легко.
Конечно мы рано или поздно придём к ответственному использованию AI, и слепо верить ChatGPT станет так же странно, как сейчас странно слепо верить SEO-помойкам из поиска гугла.
Но пока это умение у себя отрастили далеко не все.
Я тут недавно задумался, а сколько же управленческого долга создаёт ChatGPT? С техническим долгом всё понятно — кажется даже самые упоротые школостартаперы поняли, что на одном вайбкодинге далеко не уедешь. А вот что с вайб-управлением?
Менеджеры любят простые решения. Легко, к примеру, сгрузить на LLM комплаенс — он даёт прекрасные и простые ответы о законах и налогах, как будто и не нужны становятся бухглатеры и юристы с их сложностями и огромными ценниками. Через LLM можно написать очень подробное и умно выглядящее ТЗ, попросить ужать до одной строки длинное клиентское письмо, изучить новый рынок, сделать SWOT-анализ и сформулировать туду-лист после встречи.
Чтобы устоять перед решением, которое выглядит умно и обосновано, нужно очень много ответственности, которой у менеджера в запаре может и не быть. Понятно, что компании в неподходящих юрисдикациях никто открывать не будет — это как принимать лекарства на основе диагноза из ChatGPT. Но вот просрать какие-нибудь налоги, потерять договорённости с клиентом или слить в трубу время программистов — вполне легко.
Конечно мы рано или поздно придём к ответственному использованию AI, и слепо верить ChatGPT станет так же странно, как сейчас странно слепо верить SEO-помойкам из поиска гугла.
Но пока это умение у себя отрастили далеко не все.
Форма, функция и красота
В «Коммуникации Систем» мы говорим о понятиях system form и system function. Форма — это как система выглядит: на какие модули разбита, с какими данными работает. Функция — то, что система делает: как реагирует на ввод, что отдаёт на вывод.
Для меня форма и функция выходят далеко за рамки айтишечки и даже проектирования систем. Это, скорее, про красоту. Вещи, в которых форма подчинена функции — красивы. Вещи, в которых функция размыта, а форма сложна — некрасивы и неприятны.
К примеру макбуки, Dell бизнес-серий, дорогие thinkpad — красивы: дают много возможностей владельцу и не отвлекают формой. Игровые ноутбуки и всякие дешёвые асусы — некрасиво, потому что их главная функция — блистать на полке в магазине. Есть и исключение — Framework: вроде бы и красивые штуки, но вот функция, которую они выполняют, — быть ремонтопригодный в домашних условиях, — вряд ли понадобится кому-то в здравом уме.
А сколько же на улице некрасивых машин! Дорогие немцы, в большинстве своём — некрасивы: функции размыты, а форма требует постоянного обслуживания. Исключение — разве что Майбахи, заточенные под перевозку одного пассажира, или BMW M-серии, сделаные для кольца: с такими функциями можно и хрупкую форму потерпеть. Маленькие SUV, которыми забит рынок — некрасивы: форма как у дешёвых ноутбуков, пригодна только стоять в автосалоне и говорить неискушённому потребителю «не думай, купи меня, я сгожусь на любой случай жизни».
У меня чувство прекрасного отдыхает на утилитарных пикапах вроде Toyota Tundra или том, что в штатах называют «траками»: они много возят, когда надо — быстро едут, а простое шасси и атмосферный мотор будут хоть 20 лет выполнять свою функцию. Очень красивы велосипеды на которых ездят курьеры: быстрые, лёгкие, ничего лишнего.
Глядя на форму, можно определить функцию, которую туда закладывает автор. Так, по названию хорошего класса в коде понятно, что он делает, а по первому экрану приложения видно, чего от него хотели авторы.
Форма эволюционирует вместе с функцией. К примеру Медиум когда-то был отличным средством для публикации лонгридов, а в процессе эволюции превратился в пейвольную помойку — очевидно, новая форма стала более выгодна владельцам. Или взять любой продукт Яндекса — почти везде его функция со временем перестаёт интересовать владельцев. Так навигатор превратился в тормозные «карты», а сервисы доставки еды и такси превратились непонятно во что: «экосистема» это что-то на шейрхолдерском, а не на пользовательском.
Когда проектируете что угодно — архитектуру системы, пользовательский опыт, пост в тг-канал — сначала подчиняйте форму функции, а потом уже думайте об украшениях.
В «Коммуникации Систем» мы говорим о понятиях system form и system function. Форма — это как система выглядит: на какие модули разбита, с какими данными работает. Функция — то, что система делает: как реагирует на ввод, что отдаёт на вывод.
Для меня форма и функция выходят далеко за рамки айтишечки и даже проектирования систем. Это, скорее, про красоту. Вещи, в которых форма подчинена функции — красивы. Вещи, в которых функция размыта, а форма сложна — некрасивы и неприятны.
К примеру макбуки, Dell бизнес-серий, дорогие thinkpad — красивы: дают много возможностей владельцу и не отвлекают формой. Игровые ноутбуки и всякие дешёвые асусы — некрасиво, потому что их главная функция — блистать на полке в магазине. Есть и исключение — Framework: вроде бы и красивые штуки, но вот функция, которую они выполняют, — быть ремонтопригодный в домашних условиях, — вряд ли понадобится кому-то в здравом уме.
А сколько же на улице некрасивых машин! Дорогие немцы, в большинстве своём — некрасивы: функции размыты, а форма требует постоянного обслуживания. Исключение — разве что Майбахи, заточенные под перевозку одного пассажира, или BMW M-серии, сделаные для кольца: с такими функциями можно и хрупкую форму потерпеть. Маленькие SUV, которыми забит рынок — некрасивы: форма как у дешёвых ноутбуков, пригодна только стоять в автосалоне и говорить неискушённому потребителю «не думай, купи меня, я сгожусь на любой случай жизни».
У меня чувство прекрасного отдыхает на утилитарных пикапах вроде Toyota Tundra или том, что в штатах называют «траками»: они много возят, когда надо — быстро едут, а простое шасси и атмосферный мотор будут хоть 20 лет выполнять свою функцию. Очень красивы велосипеды на которых ездят курьеры: быстрые, лёгкие, ничего лишнего.
Глядя на форму, можно определить функцию, которую туда закладывает автор. Так, по названию хорошего класса в коде понятно, что он делает, а по первому экрану приложения видно, чего от него хотели авторы.
Форма эволюционирует вместе с функцией. К примеру Медиум когда-то был отличным средством для публикации лонгридов, а в процессе эволюции превратился в пейвольную помойку — очевидно, новая форма стала более выгодна владельцам. Или взять любой продукт Яндекса — почти везде его функция со временем перестаёт интересовать владельцев. Так навигатор превратился в тормозные «карты», а сервисы доставки еды и такси превратились непонятно во что: «экосистема» это что-то на шейрхолдерском, а не на пользовательском.
Когда проектируете что угодно — архитектуру системы, пользовательский опыт, пост в тг-канал — сначала подчиняйте форму функции, а потом уже думайте об украшениях.
Гениальная подписка на pico.sh
Делать подписки сложно. Помимо очевидного (и очень сложного с учетом современного комплаенса) хранения токенов авторизации карт, надо обрабатывать еще кучу нештатных ситуаций: смену тарифов, частичные возраты (после смены тарифа тоже), проблемы с картами, нормальный путь для отваливающихся пользователей и т.д. Даже готовые биллинги вроде страйпа и paddle не делают эту задачу простой.
Гениальный способ продавать подписку нашли ребята из pico.sh — это такой набор консольных сервисов для программистов: туннели, pastebin, простой блог, RSS-to-email. Они продают только годовую подписку (она дешёвая), и вообще не заморачиваются с продлением: если пользователю через год будет надо — он опять купит.
Наверное, так у них гораздо меньше платящих клиентов, которые забыли, что они клиенты но приносят прибыль (не знаю, как это называется на продуктовом). Но зато без рекурентных платежей интеграция со страйпом занимает десяток строк, а за год, если захотят, заработают себе и на нормальный биллинг.
Делать подписки сложно. Помимо очевидного (и очень сложного с учетом современного комплаенса) хранения токенов авторизации карт, надо обрабатывать еще кучу нештатных ситуаций: смену тарифов, частичные возраты (после смены тарифа тоже), проблемы с картами, нормальный путь для отваливающихся пользователей и т.д. Даже готовые биллинги вроде страйпа и paddle не делают эту задачу простой.
Гениальный способ продавать подписку нашли ребята из pico.sh — это такой набор консольных сервисов для программистов: туннели, pastebin, простой блог, RSS-to-email. Они продают только годовую подписку (она дешёвая), и вообще не заморачиваются с продлением: если пользователю через год будет надо — он опять купит.
Наверное, так у них гораздо меньше платящих клиентов, которые забыли, что они клиенты но приносят прибыль (не знаю, как это называется на продуктовом). Но зато без рекурентных платежей интеграция со страйпом занимает десяток строк, а за год, если захотят, заработают себе и на нормальный биллинг.
Придумыватель и делатель
Есть (была?) такая опенсорсная прошивка для карманных фонариков — Anduril. Штука очень крутая в инженерном плане — позволяет при помощи одной кнопки управлять любыми аспектами работы фонаря — переключать режимы переключения (!) яркости, ставить таймер засыпания, крутить терморегуляцию и настраивать цвет светодиода на кнопке.
Правда, у неё есть серьёзная беда — понять что-либо в ней невозможно, не прочитав огромную и невнятную инструкцию. То есть вроде бы и круто, но в реальной жизни — полезно только паре гиков (про muggle mode знаю).
Такие продукты обычно и получаются у хороших инженеров — крутая, может быть опенсорсная реализация, и полный ноль в пользовательских качествах. Так происходит потому, что почти невозможно совместить в человеческом мозге два режима деятельности — придумывания и реализации. Приходит в голову идея новой фичи, а ты не успеваешь даже подумать насколько она вообще нужна пользователям — сразу включается инженер и начинает думать про реализацию: что поменять в проекте, чтобы фичу было удобнее делать.
Сам я постоянно натыкаюсь на такую проблему в школе — до сих пор пишу сам некоторые куски, связаные с админкой бекофиса, где мы управляет возвратами, b2b-сделками и материалами уроков, и постоянно ловлю себя на том, что начинаю писать код, который совершенно не нужен команде.
Когда одновременно пишете код и принимаете решения, нужно научиться отличать себя-придумывателя от себя-делателя. Придумывателю категорически нельзя давать в руки никакие инструменты, чтобы не начинал работать. Делателю — не давать задачи с сомнительной пользой, а то он настругает кода, который потом не выпилить.
Есть (была?) такая опенсорсная прошивка для карманных фонариков — Anduril. Штука очень крутая в инженерном плане — позволяет при помощи одной кнопки управлять любыми аспектами работы фонаря — переключать режимы переключения (!) яркости, ставить таймер засыпания, крутить терморегуляцию и настраивать цвет светодиода на кнопке.
Правда, у неё есть серьёзная беда — понять что-либо в ней невозможно, не прочитав огромную и невнятную инструкцию. То есть вроде бы и круто, но в реальной жизни — полезно только паре гиков (про muggle mode знаю).
Такие продукты обычно и получаются у хороших инженеров — крутая, может быть опенсорсная реализация, и полный ноль в пользовательских качествах. Так происходит потому, что почти невозможно совместить в человеческом мозге два режима деятельности — придумывания и реализации. Приходит в голову идея новой фичи, а ты не успеваешь даже подумать насколько она вообще нужна пользователям — сразу включается инженер и начинает думать про реализацию: что поменять в проекте, чтобы фичу было удобнее делать.
Сам я постоянно натыкаюсь на такую проблему в школе — до сих пор пишу сам некоторые куски, связаные с админкой бекофиса, где мы управляет возвратами, b2b-сделками и материалами уроков, и постоянно ловлю себя на том, что начинаю писать код, который совершенно не нужен команде.
Когда одновременно пишете код и принимаете решения, нужно научиться отличать себя-придумывателя от себя-делателя. Придумывателю категорически нельзя давать в руки никакие инструменты, чтобы не начинал работать. Делателю — не давать задачи с сомнительной пользой, а то он настругает кода, который потом не выпилить.
#вопрос Как выстраивать культуру в компании, если ты аутсорс? Все твои сотрудники живут культурами других компаний.
Не соглашусь с вашим тезисом. Когда сотрудники живут культурами других компаний — это аутстаф. А аутсорс — это как раз компания, в которую приходят за культурой.
Крупные компании обращаются в дизайн-агентства, когда ищут нового и яркого результата: в их культуре удобно красить кнопки, а инновации и крутые редизайны тонут в согласованиях.
К нам в FANS обращаются, когда нужен результат быстрее рынка, или когда потеряли коммуникацию с собственной разработкой, которая медленно пилит фичи — и неважно почему: из-за горы говнокода или неумения разговаривать с бизнесом. Вообще это важное ноу-хау в нашей компании — искать и поддерживать людей, способных сохранить культуру в дикой среде, в которой принято проёбывать обещания и не отвечать, пока не назначишь митинг.
Так что культуру в аутсорсе надо выстраивать так же, как и в любой другой компании — наймом, онбордингом и увольнениями.
Не соглашусь с вашим тезисом. Когда сотрудники живут культурами других компаний — это аутстаф. А аутсорс — это как раз компания, в которую приходят за культурой.
Крупные компании обращаются в дизайн-агентства, когда ищут нового и яркого результата: в их культуре удобно красить кнопки, а инновации и крутые редизайны тонут в согласованиях.
К нам в FANS обращаются, когда нужен результат быстрее рынка, или когда потеряли коммуникацию с собственной разработкой, которая медленно пилит фичи — и неважно почему: из-за горы говнокода или неумения разговаривать с бизнесом. Вообще это важное ноу-хау в нашей компании — искать и поддерживать людей, способных сохранить культуру в дикой среде, в которой принято проёбывать обещания и не отвечать, пока не назначишь митинг.
Так что культуру в аутсорсе надо выстраивать так же, как и в любой другой компании — наймом, онбордингом и увольнениями.
Ласт колл на «Без ерунды»
Завтра стартует второй поток «Без Ерунды». Мы сильно поменяли механику курса — раньше это были просто письма, а теперь это — тренажёр насмотренности на ерунду.
Мне всегда было грустно, когда крутые инженеры, которые умеют делать красивые решения, упираются в барьеры, под которые у них не заточен мозг. Когда всё творчество разбивается о тонны бойлерплейта, несколько встреч в день и даже шум в офисе — когда добираешься до кода, сил на красоту и качество уже нет. В общем об плохой Developer Experience.
Я занимался DevEx ещё когда у него не было названия — начал с ГдеМатериала, где было мало денег на команду, но надо было писать много кода. Продолжаю и теперь — для FANS это не только преимущество на рынке труда, но и способ удерживать высокую цену — мы дорого берём, но доставляем за эти деньги намного больше результата, чем принято на рынке и клиенты это ценят: мы предсказуемы и на нас можно положиться.
В рамках курса мы помогаем чинить DevEx, даже если у вас нет власти, — научитесь находить решаемые проблемы в потоке ежедневной рутины, а мы дадим кучу рекомендаций, как их решать (если не в текстах лонгридов, то в чатике и от других студентов на проверке домашки).
В курсе 4 недели. Первый — про JTBD и как с его помощью отличать важные проблемы от неважных. Второй — про инженерные процессы, третий — про внимание, четвёртый — про работу с бизнес-заказчиком. Подтянув эти направления у себя (или в своей команде) можно гораздо меньше уставать на работе, а делать — гораздо больше.
Смотреть программу и отзывы →
Чтобы понять о чём мы — посмотрите на лендосе бесплатный чеклист для поиска ерунды. Как раз успеете сегодня принять решение и прыгнуть в последний вагон — начинаем завтра в 16:00.
Завтра стартует второй поток «Без Ерунды». Мы сильно поменяли механику курса — раньше это были просто письма, а теперь это — тренажёр насмотренности на ерунду.
Мне всегда было грустно, когда крутые инженеры, которые умеют делать красивые решения, упираются в барьеры, под которые у них не заточен мозг. Когда всё творчество разбивается о тонны бойлерплейта, несколько встреч в день и даже шум в офисе — когда добираешься до кода, сил на красоту и качество уже нет. В общем об плохой Developer Experience.
Я занимался DevEx ещё когда у него не было названия — начал с ГдеМатериала, где было мало денег на команду, но надо было писать много кода. Продолжаю и теперь — для FANS это не только преимущество на рынке труда, но и способ удерживать высокую цену — мы дорого берём, но доставляем за эти деньги намного больше результата, чем принято на рынке и клиенты это ценят: мы предсказуемы и на нас можно положиться.
В рамках курса мы помогаем чинить DevEx, даже если у вас нет власти, — научитесь находить решаемые проблемы в потоке ежедневной рутины, а мы дадим кучу рекомендаций, как их решать (если не в текстах лонгридов, то в чатике и от других студентов на проверке домашки).
В курсе 4 недели. Первый — про JTBD и как с его помощью отличать важные проблемы от неважных. Второй — про инженерные процессы, третий — про внимание, четвёртый — про работу с бизнес-заказчиком. Подтянув эти направления у себя (или в своей команде) можно гораздо меньше уставать на работе, а делать — гораздо больше.
Смотреть программу и отзывы →
Чтобы понять о чём мы — посмотрите на лендосе бесплатный чеклист для поиска ерунды. Как раз успеете сегодня принять решение и прыгнуть в последний вагон — начинаем завтра в 16:00.
Ненавижу СМС-аутентификацию
Ненавижу сервисы, которые используют СМС в качестве обязательного второго фактора. Дело даже не в том, что это небезопасно (хотя это и небезопасно) — просто я очень редко держу телефон в руках. Ещё хуже, когда находишься в роуминге — я давно использую Airalo, но вот чтобы авторизоваться в каком-нибудь особо странном сервисе — приходится разбираться с сетями и настройками дата-роуминга.
Особенно этой фигнёй грешат отечественные разработчики — видимо не могут объяснить своим менеджерам пользу пасскеев и TOTP, вот и издеваются над юзерами. Иногда находят компромисс — подключают в качестве второго фактора вход через какой-нибудь мейл.ру. Да я, блин, не знаю ни одного живого человека (ладно, одного знаю), у которого есть аккаунт на мейл.ру.
Или садишься купить какую-нибудь ненужную фигню на озоне, пытаешься залогиниться, а они такие «ура, мы вам уже звоним». Чуваки, я не знаю, где лежит мой телефон! Да и звонок на нём давно отключен. У меня есть 1password/keychain, почему вы заставляете меня отрывать жопу от дивана?
Список ненависти:
— Аэрофлот (короткая сессия, неотключаемые СМС)
— Boosty (короткая сессия, вход только через СМС или какие-то странные сети)
— Все криптобиржи
— Озон
— Авито
Даже Cбер и Госуслуги позволяет нормально логиниться, не используя телефон. Почему авито с озоном не могут?
Ненавижу сервисы, которые используют СМС в качестве обязательного второго фактора. Дело даже не в том, что это небезопасно (хотя это и небезопасно) — просто я очень редко держу телефон в руках. Ещё хуже, когда находишься в роуминге — я давно использую Airalo, но вот чтобы авторизоваться в каком-нибудь особо странном сервисе — приходится разбираться с сетями и настройками дата-роуминга.
Особенно этой фигнёй грешат отечественные разработчики — видимо не могут объяснить своим менеджерам пользу пасскеев и TOTP, вот и издеваются над юзерами. Иногда находят компромисс — подключают в качестве второго фактора вход через какой-нибудь мейл.ру. Да я, блин, не знаю ни одного живого человека (ладно, одного знаю), у которого есть аккаунт на мейл.ру.
Или садишься купить какую-нибудь ненужную фигню на озоне, пытаешься залогиниться, а они такие «ура, мы вам уже звоним». Чуваки, я не знаю, где лежит мой телефон! Да и звонок на нём давно отключен. У меня есть 1password/keychain, почему вы заставляете меня отрывать жопу от дивана?
Список ненависти:
— Аэрофлот (короткая сессия, неотключаемые СМС)
— Boosty (короткая сессия, вход только через СМС или какие-то странные сети)
— Все криптобиржи
— Озон
— Авито
Даже Cбер и Госуслуги позволяет нормально логиниться, не используя телефон. Почему авито с озоном не могут?
Резать косты
Когда в компании начинаются проблемы с деньгами, большинство менеджеров, которых я знаю (включая меня) прямо-таки тянет «срезать косты»: разобраться, на что компания тратит деньги и как это уменьшить.
Активность это, как мне кажется, довольно бесполезная. Чтобы серьёзно уменьшить расходы, надо лезть не в оптимизацию текущих, а в смену бизнес-модели. Грубо говоря, как ни меняй поставщиков мяса в шаурмячной, до тех пор пока ты не изобретёшь растительную шаурму или не придумаешь, как продавать свой продукт не платя зарплату мастеру-шаурмье — ничего не изменится.
Самый большой минус в резке костов — это самообман. Допустим, я придумал, как сэкономить 500 баксов на SaaS-ах, перенеся часть к себе — и (кроме геморроя в эксплуатации), получаю чувство, что прожил день не зря: это ж половина месячной аренды квартиры! Чувство, к сожалению, ложное — тяжело представить бизнес, для которого плюс-минус 500 баксов имеют решающее значение.
Единственный смысл, который может быть в резке костов — рекреационный. Когда работаешь над сложными или новыми вещами — не знаешь, когда получишь от них выхлоп, да и получишь ли вообще: легко устать и сдаться. А выделил полдня в конце недели на мелкие оптимизации, глянул на уменьшившиеся расходы — и уже не так и тяжело.
Наверное, выжимать копейки из расходов имеет смысл в больших устоявшихся бизнесах. Шаурмячная от смены поставщика мяса ничего не выиграет, а вот макдональдс, в силу масштаба — вполне. Но у меня макдональдса нет, так что буду как и в личных финансах — стараться больше заработать, а не меньше потратить.
Когда в компании начинаются проблемы с деньгами, большинство менеджеров, которых я знаю (включая меня) прямо-таки тянет «срезать косты»: разобраться, на что компания тратит деньги и как это уменьшить.
Активность это, как мне кажется, довольно бесполезная. Чтобы серьёзно уменьшить расходы, надо лезть не в оптимизацию текущих, а в смену бизнес-модели. Грубо говоря, как ни меняй поставщиков мяса в шаурмячной, до тех пор пока ты не изобретёшь растительную шаурму или не придумаешь, как продавать свой продукт не платя зарплату мастеру-шаурмье — ничего не изменится.
Самый большой минус в резке костов — это самообман. Допустим, я придумал, как сэкономить 500 баксов на SaaS-ах, перенеся часть к себе — и (кроме геморроя в эксплуатации), получаю чувство, что прожил день не зря: это ж половина месячной аренды квартиры! Чувство, к сожалению, ложное — тяжело представить бизнес, для которого плюс-минус 500 баксов имеют решающее значение.
Единственный смысл, который может быть в резке костов — рекреационный. Когда работаешь над сложными или новыми вещами — не знаешь, когда получишь от них выхлоп, да и получишь ли вообще: легко устать и сдаться. А выделил полдня в конце недели на мелкие оптимизации, глянул на уменьшившиеся расходы — и уже не так и тяжело.
Наверное, выжимать копейки из расходов имеет смысл в больших устоявшихся бизнесах. Шаурмячная от смены поставщика мяса ничего не выиграет, а вот макдональдс, в силу масштаба — вполне. Но у меня макдональдса нет, так что буду как и в личных финансах — стараться больше заработать, а не меньше потратить.
Публиковать идеи
В студии Лебедева существует очень крутая штука — «мозг». Это место, куда дизайнеры выкладывают свои идеи, которые каждый может посмотреть.
Смысл этой штуки совсем не в том, чтобы мериться количеством идей, и даже не в том, чтобы получить условный патент на своё гениальное изобретение. Смысл в том, чтобы у дизайнеров в голове оставалось меньше идей.
Пока идея сидит в голове, она занимает место. Автору идея может казаться бесконечно гениальной, жрать кучу энергии на свою полировку, поддержку и восхищение. Но пока идея в голове — новая на её место не придёт. Как только идея обретает завершённость — картинкой в «мозге», постом в телегу, задачей сотрудникам — на её место приходит новая. Так работает человеческое сознание.
Конечно, процесс публикации идеи должен быть сложным — иначе все идеи осядут в заметах и тудулистах в виде сырого говна. В момент публикации идею полируют, додумывают, или вообще выкидывают. Поэтому в «мозге» есть минимальная социальная составляющая — картинки видят другие. Сырое говно туда не выложишь. Из-за этой социальной составляющей, кстати, телеграм-канал на 50 человек лучше, чем заметочник, который даже вы сами перечитывать не будете.
Кароч, не носите идеи в голове. Начинайте их описывать, думайте кому и как показать. А то рискуете всю жизнь просидеть с единственной гениальной, но никому не известной идеей.
В студии Лебедева существует очень крутая штука — «мозг». Это место, куда дизайнеры выкладывают свои идеи, которые каждый может посмотреть.
Смысл этой штуки совсем не в том, чтобы мериться количеством идей, и даже не в том, чтобы получить условный патент на своё гениальное изобретение. Смысл в том, чтобы у дизайнеров в голове оставалось меньше идей.
Пока идея сидит в голове, она занимает место. Автору идея может казаться бесконечно гениальной, жрать кучу энергии на свою полировку, поддержку и восхищение. Но пока идея в голове — новая на её место не придёт. Как только идея обретает завершённость — картинкой в «мозге», постом в телегу, задачей сотрудникам — на её место приходит новая. Так работает человеческое сознание.
Конечно, процесс публикации идеи должен быть сложным — иначе все идеи осядут в заметах и тудулистах в виде сырого говна. В момент публикации идею полируют, додумывают, или вообще выкидывают. Поэтому в «мозге» есть минимальная социальная составляющая — картинки видят другие. Сырое говно туда не выложишь. Из-за этой социальной составляющей, кстати, телеграм-канал на 50 человек лучше, чем заметочник, который даже вы сами перечитывать не будете.
Кароч, не носите идеи в голове. Начинайте их описывать, думайте кому и как показать. А то рискуете всю жизнь просидеть с единственной гениальной, но никому не известной идеей.
Новый поток «Анализа Систем»
Сделать простую архитектуру — сложно: надо слушать бизнес и игнорировать зуд к CV-driven-development. Сделать что-то простое, когда все привыкли к существующему коду и его сложности — почти невозможно: кто хоть раз пытался разбирать старые монолиты, тот хорошо меня поймёт.
Так что либо долго учим теорию и устраиваем скучные воркшопы, либо движемся по накатанному пути: делаем какую-то архитектуру (может делать даже CEO в Perplexity, сильно хуже не будет) и быстро нанимаем кучу программистов, которые решают её проблемы вместо того, чтобы пилить фичи для продукта.
Если гипотеза выстреливает, а CEO не успевает разориться — нанимаем сотни программистов и загоняем их в офис, если нет — закрываемся и начинаем заново. Радости мало.
С гипотезами наша школа не помогает, а вот делать архитектуру так, чтобы пилить код для бизнеса, а не для программистских проблем — вполне да. У нас есть два архитектурных курса: «Анализ Систем» и «Коммуникация систем» как раз об этом.
«Анализ систем» о том, как проектировать систему под требования бизнеса, а не под набор технологий с конфы: как выбирать архитектурный стиль; слушать бизнес при помощи Event Storming, думать при помощи DDD и документировать решения при помощи ADR. База для тех, кто хочет строить устойчивые системы.
Сейчас открыли запись на новый поток, учиться будем, 5 недель, начиная с 6 октября. Учебная нагрузка — примерно 10 часов в неделю. Это довольно интенсивный курс, поэтому если возьмете на работе отпуск хотя бы на один день в неделю — будет проще затаскивать.
Если хотите после курса внедрить то, чему научились — лучше идти в тарифы «тусовка» или «вип». Кроме большей практики — получите много насмотренности, проверяя чужие домашки.
До вечера воскресенья 14 сентября действует промокод
Курс о «Коммуникации систем» — это продолжение «Анализа систем» и в нем разбираем глубже именно асинхронные коммуникации.
Обучение на нем запустим в начале следующего года. Если не хотите пропустить — лучше оставить заявку в вейтлисте и мы расскажем, когда запустим.
Сделать простую архитектуру — сложно: надо слушать бизнес и игнорировать зуд к CV-driven-development. Сделать что-то простое, когда все привыкли к существующему коду и его сложности — почти невозможно: кто хоть раз пытался разбирать старые монолиты, тот хорошо меня поймёт.
Так что либо долго учим теорию и устраиваем скучные воркшопы, либо движемся по накатанному пути: делаем какую-то архитектуру (может делать даже CEO в Perplexity, сильно хуже не будет) и быстро нанимаем кучу программистов, которые решают её проблемы вместо того, чтобы пилить фичи для продукта.
Если гипотеза выстреливает, а CEO не успевает разориться — нанимаем сотни программистов и загоняем их в офис, если нет — закрываемся и начинаем заново. Радости мало.
С гипотезами наша школа не помогает, а вот делать архитектуру так, чтобы пилить код для бизнеса, а не для программистских проблем — вполне да. У нас есть два архитектурных курса: «Анализ Систем» и «Коммуникация систем» как раз об этом.
«Анализ систем» о том, как проектировать систему под требования бизнеса, а не под набор технологий с конфы: как выбирать архитектурный стиль; слушать бизнес при помощи Event Storming, думать при помощи DDD и документировать решения при помощи ADR. База для тех, кто хочет строить устойчивые системы.
Сейчас открыли запись на новый поток, учиться будем, 5 недель, начиная с 6 октября. Учебная нагрузка — примерно 10 часов в неделю. Это довольно интенсивный курс, поэтому если возьмете на работе отпуск хотя бы на один день в неделю — будет проще затаскивать.
Если хотите после курса внедрить то, чему научились — лучше идти в тарифы «тусовка» или «вип». Кроме большей практики — получите много насмотренности, проверяя чужие домашки.
До вечера воскресенья 14 сентября действует промокод
FIVECATS5 на 10% скидки. Следующий поток не раньше весны 26 года. Смотреть программу и отзывы.Курс о «Коммуникации систем» — это продолжение «Анализа систем» и в нем разбираем глубже именно асинхронные коммуникации.
Обучение на нем запустим в начале следующего года. Если не хотите пропустить — лучше оставить заявку в вейтлисте и мы расскажем, когда запустим.
Говорить только о будущем
Не люблю говорить о прошлом: кто и почему проебал задачу, откуда взялись управленческие и технические долги, почему планы не сбываются, почему сделка не закрылась.
Люблю говорить о будущем — как сделать, чтобы похожие задачи не проёбывались, как расплатиться с долгами, как построить систему, в которой планы сбываются а сделки закрываются.
Разговоры о прошлом непродуктивны. Понятно почему — гораздо проще обвинить коллегу в том, что всё плохо, чем придумать, как это исправить. Как доброжелательно ни задавай вопросы, всё равно у людей (включая меня) запускается какой-то механизм защиты. Конструктива с таким механизмом не будет.
В следующий раз попробуйте вместо разбора полётов в команде устроить нормальное ретро — о том, что хотите поменять, а не о том, кто виноват.
Не люблю говорить о прошлом: кто и почему проебал задачу, откуда взялись управленческие и технические долги, почему планы не сбываются, почему сделка не закрылась.
Люблю говорить о будущем — как сделать, чтобы похожие задачи не проёбывались, как расплатиться с долгами, как построить систему, в которой планы сбываются а сделки закрываются.
Разговоры о прошлом непродуктивны. Понятно почему — гораздо проще обвинить коллегу в том, что всё плохо, чем придумать, как это исправить. Как доброжелательно ни задавай вопросы, всё равно у людей (включая меня) запускается какой-то механизм защиты. Конструктива с таким механизмом не будет.
В следующий раз попробуйте вместо разбора полётов в команде устроить нормальное ретро — о том, что хотите поменять, а не о том, кто виноват.
Сгорел чердак
Что только у меня не случалось с SaaS в последнее время. Кто-то банил, кто-то отжимал данные (привет, mailchimp!), кто-то не забанил, но просто перестал нормально работать.
Недавно получил ещё один удар — сгорел (в смысле огнём) сервис «облачного хранения» Чердак. Идея простая — вместо того, чтобы самому париться с хранением, можно просто вызвать интеллигентных муверов, которые заберут ненужные вещи и потом вернут их по кнопке в приложении. У меня так хранились вещи, которые нельзя или жалко продать. Большинство — восстановить не получится: к примеру архив документов или коллекционный кейс от бас-гитары, которых совсем немного выпустили 20 лет назад и больше выпускать не будут.
Задумался — а если бы я не аутсорсил склад, а снял/купил бы кладовку или гараж — не было бы это надёжнее? С точки зрения рисков — не думаю. Но вот чувства контроля точно было бы больше.
Конечно, количество херни, которая случилась за последние пять лет, никак не влияет на количество херни, которая случится в следующие пять лет. Но предпочитать SaaS-ы собственным огородикам становится всё сложнее. Старею, наверное.
———
Владельцам сервиса, конечно, сочувствую и желаю сил — видно, как они просирают публичную коммуникацию, но кажется невозможным её не просрать в условиях, когда за одну ночь потерял весь бизнес, а впереди вместо нового бизнеса — только очень долгие попытки исправить проблемы, оставшиеся от старого.
Что только у меня не случалось с SaaS в последнее время. Кто-то банил, кто-то отжимал данные (привет, mailchimp!), кто-то не забанил, но просто перестал нормально работать.
Недавно получил ещё один удар — сгорел (в смысле огнём) сервис «облачного хранения» Чердак. Идея простая — вместо того, чтобы самому париться с хранением, можно просто вызвать интеллигентных муверов, которые заберут ненужные вещи и потом вернут их по кнопке в приложении. У меня так хранились вещи, которые нельзя или жалко продать. Большинство — восстановить не получится: к примеру архив документов или коллекционный кейс от бас-гитары, которых совсем немного выпустили 20 лет назад и больше выпускать не будут.
Задумался — а если бы я не аутсорсил склад, а снял/купил бы кладовку или гараж — не было бы это надёжнее? С точки зрения рисков — не думаю. Но вот чувства контроля точно было бы больше.
Конечно, количество херни, которая случилась за последние пять лет, никак не влияет на количество херни, которая случится в следующие пять лет. Но предпочитать SaaS-ы собственным огородикам становится всё сложнее. Старею, наверное.
———
Владельцам сервиса, конечно, сочувствую и желаю сил — видно, как они просирают публичную коммуникацию, но кажется невозможным её не просрать в условиях, когда за одну ночь потерял весь бизнес, а впереди вместо нового бизнеса — только очень долгие попытки исправить проблемы, оставшиеся от старого.
Вебинар на вечную тему: как писать хороший код
Я серьёзно: ПР синьёра можно отличить от ПР джуна, даже не зная языка программирования. Код синьёра читается как текст в книге: вот юзер-стори, вот обращение к спрятанной сложности, вон там — бойлерплейт, который вообще вынесли из ПР. У джуна такого нет — хорошо, если задача решена и лапши нет.
Сложность — это не только про понятно/непонятно: это ещё и про увеличенный расход когнитивного ресурса, про медленный TTM и количество (неисправляемых) багов.
К сожалению, не существует простого способа ограничить сложность — никакой линтер не заметит, когда get_bank() возвращает почту, и никакая фитнес-функция не задетектит ненужное наслоение абстракций. Поэтому я очень давно мечтал сделать об этом курс.
Когда несколько месяцев назад мне написал Толя Буров и предложил ровно это — сделать курс о простом коде, — я сразу же согласился: я видел проекты, которые делал Толя, и восхищаюсь его умением раскладывать сложность по полочкам.
Курс мы пока не запускаем (хотя материала и много) — а запускаем платный вебинар, на котором расскажем часть материалов из курса. Если соберём аудиторию и вебинар окажется полезным — сделаем полноценный курс.
Расскажем, чем простой код отличается от сложного, откуда вообще берётся сложность, как её измерить и спрятать. Для меня самая мякотка — это материалы, которые Толя принёс из своего лингвистического образования — о языке программировании как способе коммуникации с людьми, о нейминге и о частях речи.
Полезно будет всем уровням: крепким джунам — чтобы научиться писать простой код, мидлам — чтобы осознать принципы, которые пока ещё не сформулировались, синьёрам и тимлидам — чтобы научиться эти принципы доносить до своей команды.
Вебинар пройдёт 15 октября в 17:00 MSK. На случай, если вам хочется заплатить денег и никогда его не посмотреть — будет запись. Цены совсем небольшие — 7к в самостоятельном тарифе и 10к в тусовке — с чатиком участников и Q&A с Толей.
Промокод
Смотреть программу и отзывы →
Я серьёзно: ПР синьёра можно отличить от ПР джуна, даже не зная языка программирования. Код синьёра читается как текст в книге: вот юзер-стори, вот обращение к спрятанной сложности, вон там — бойлерплейт, который вообще вынесли из ПР. У джуна такого нет — хорошо, если задача решена и лапши нет.
Сложность — это не только про понятно/непонятно: это ещё и про увеличенный расход когнитивного ресурса, про медленный TTM и количество (неисправляемых) багов.
К сожалению, не существует простого способа ограничить сложность — никакой линтер не заметит, когда get_bank() возвращает почту, и никакая фитнес-функция не задетектит ненужное наслоение абстракций. Поэтому я очень давно мечтал сделать об этом курс.
Когда несколько месяцев назад мне написал Толя Буров и предложил ровно это — сделать курс о простом коде, — я сразу же согласился: я видел проекты, которые делал Толя, и восхищаюсь его умением раскладывать сложность по полочкам.
Курс мы пока не запускаем (хотя материала и много) — а запускаем платный вебинар, на котором расскажем часть материалов из курса. Если соберём аудиторию и вебинар окажется полезным — сделаем полноценный курс.
Расскажем, чем простой код отличается от сложного, откуда вообще берётся сложность, как её измерить и спрятать. Для меня самая мякотка — это материалы, которые Толя принёс из своего лингвистического образования — о языке программировании как способе коммуникации с людьми, о нейминге и о частях речи.
Полезно будет всем уровням: крепким джунам — чтобы научиться писать простой код, мидлам — чтобы осознать принципы, которые пока ещё не сформулировались, синьёрам и тимлидам — чтобы научиться эти принципы доносить до своей команды.
Вебинар пройдёт 15 октября в 17:00 MSK. На случай, если вам хочется заплатить денег и никогда его не посмотреть — будет запись. Цены совсем небольшие — 7к в самостоятельном тарифе и 10к в тусовке — с чатиком участников и Q&A с Толей.
Промокод
LINTING10 даёт 10% скидки до вечера среды, 24 сентября.Смотреть программу и отзывы →
На прошлой неделе в очередной раз обновлял свой конфиг neovim и порадовался, насколько сильно он похудел за 10 лет.
Раньше, чтобы редактор нормально поддерживал язык программирования, надо было искать несколько плагинов от разных авторов, настраивать их так, чтобы не конфликтовали друг с другом, а если что-то не работает — читать странный код на отвратительном viml. Если работает, но тормозит — скорее всего вообще ничего не сделать, потому что разобраться, что происходит под капотом, просто нереально.
Сейчас все сложные вещи в конфиге — это «подключи мне такой-то LSP» и «вот пара хоткеев, с которыми не могу расстаться». Остальное — это темы, подсветки и мелкие твики, которые экономят пару минут в неделю. И всё это на lua — магическом языке который я знаю, хотя пишу на нём раз в год по 5 минут. Видно, какую огромную работу проделали авторы neovim, за 10 лет разложив всю сложность легаси-редактора по коробочкам и спрятав её от пользователей.
Обожаю, когда во главе продукта стоят люди, которые ставят себе целью бороться со сложностью, а не пилить больше фич. В программировании — это вообще огромная редкость: мне сложно представить разработанный в 2020-х веб-фреймворк, по простоте достигающий джанги или рельсы.
Хороший антипример сложности — это llm-фреймворки. Все соревнуются в лендосах и количестве фич на них, но про программистов, которые будут это разворачивать, не думают совершенно. Чтобы написать код на джанге, надо пройти часовой туториал (сейчас наверное уже меньше). Что нужно сделать, чтобы написать код на актуальном llm-фреймворке, я вообще не знаю — так и не смог с ними справится, перешёл на чистый httpx.
Думаю со мной согласятся все, кто хоть раз пытался сделать что-нибудь на langgraph с его абстракциями от абстракций или развернуть у себя какой-нибудь dify с его 500 переменными окружения.
Вот бы клёво было научиться ставить как KPI для продакт-менеджеров и программистов не количество выкаченного кода, а его простоту со всех сторон — и для юзеров, и для разработчиков.
---
Пятый поток «Анализа систем» с Антоном Давыдовым стартует 6 октября в 16:00 MSK.
---
Вебинар «Простой код» с Толей Буровым — 15 октября в 17:00 MSK
---
Не забывайте, что на всех курсах можно учиться бесплатно за счёт работодателя — на лендосах даём советы, как этого добиться.
Раньше, чтобы редактор нормально поддерживал язык программирования, надо было искать несколько плагинов от разных авторов, настраивать их так, чтобы не конфликтовали друг с другом, а если что-то не работает — читать странный код на отвратительном viml. Если работает, но тормозит — скорее всего вообще ничего не сделать, потому что разобраться, что происходит под капотом, просто нереально.
Сейчас все сложные вещи в конфиге — это «подключи мне такой-то LSP» и «вот пара хоткеев, с которыми не могу расстаться». Остальное — это темы, подсветки и мелкие твики, которые экономят пару минут в неделю. И всё это на lua — магическом языке который я знаю, хотя пишу на нём раз в год по 5 минут. Видно, какую огромную работу проделали авторы neovim, за 10 лет разложив всю сложность легаси-редактора по коробочкам и спрятав её от пользователей.
Обожаю, когда во главе продукта стоят люди, которые ставят себе целью бороться со сложностью, а не пилить больше фич. В программировании — это вообще огромная редкость: мне сложно представить разработанный в 2020-х веб-фреймворк, по простоте достигающий джанги или рельсы.
Хороший антипример сложности — это llm-фреймворки. Все соревнуются в лендосах и количестве фич на них, но про программистов, которые будут это разворачивать, не думают совершенно. Чтобы написать код на джанге, надо пройти часовой туториал (сейчас наверное уже меньше). Что нужно сделать, чтобы написать код на актуальном llm-фреймворке, я вообще не знаю — так и не смог с ними справится, перешёл на чистый httpx.
Думаю со мной согласятся все, кто хоть раз пытался сделать что-нибудь на langgraph с его абстракциями от абстракций или развернуть у себя какой-нибудь dify с его 500 переменными окружения.
Вот бы клёво было научиться ставить как KPI для продакт-менеджеров и программистов не количество выкаченного кода, а его простоту со всех сторон — и для юзеров, и для разработчиков.
---
Пятый поток «Анализа систем» с Антоном Давыдовым стартует 6 октября в 16:00 MSK.
---
Вебинар «Простой код» с Толей Буровым — 15 октября в 17:00 MSK
---
Не забывайте, что на всех курсах можно учиться бесплатно за счёт работодателя — на лендосах даём советы, как этого добиться.
Не писать тесты с LLM
Со всех сторон слышу, как люди генерят тесты при помощи LLM. Чуваки, так делать нельзя! Это видимость тестирования, прямо как assertion-free testing.
Когда кожаный мешок пишет тесты (не важно до кода или после), он работает не над ними, а над кодом, который тестирует. Обрабатывает edge-кейсы, которые не пришли бы в голову, если бы он не сел писать тесты. Улучшает testability — раскладывает код по коробочкам, уменьшает связность, добавляет DI если надо. В конце концов, человек создаёт фреймворк для тестов — фикстуры для бизнес-сущностей, моки, которые потом можно переиспользовать.
Всё это делает тесты не только более надёжными, но и читаемыми. AI так не умеет — он делает код, очень похожий на тесты. Даже если он будет соблюдать формальную читаемость на основе ваших примеров — думать за вас он, увы, не будет.
Кароч, не пишите тесты через LLM. Если скучно — подумайте лучше, как создать себе фреймворк, который сделает это нескучным.
Со всех сторон слышу, как люди генерят тесты при помощи LLM. Чуваки, так делать нельзя! Это видимость тестирования, прямо как assertion-free testing.
Когда кожаный мешок пишет тесты (не важно до кода или после), он работает не над ними, а над кодом, который тестирует. Обрабатывает edge-кейсы, которые не пришли бы в голову, если бы он не сел писать тесты. Улучшает testability — раскладывает код по коробочкам, уменьшает связность, добавляет DI если надо. В конце концов, человек создаёт фреймворк для тестов — фикстуры для бизнес-сущностей, моки, которые потом можно переиспользовать.
Всё это делает тесты не только более надёжными, но и читаемыми. AI так не умеет — он делает код, очень похожий на тесты. Даже если он будет соблюдать формальную читаемость на основе ваших примеров — думать за вас он, увы, не будет.
Кароч, не пишите тесты через LLM. Если скучно — подумайте лучше, как создать себе фреймворк, который сделает это нескучным.
Ответственность за AI-код
«Слушай, у меня в мышке сел аккумулятор, поэтому мой ПР удаляет не GDPR-данные, а половину живой базы». Звучит как бред, да?
Если заменить севший аккумулятор на claude/gpt/что там ещё?
Конечно такой треш увидеть сложно даже у джунов, но вот подход «ой, это не я, это ai накосячил, сорян» встречается даже у синьёрных товарищей: и в коде, и в требованиях, и в документации.
Друзья, если под коммитом стоит ваше имя — это сделали вы, а не какая-то внеземная сущность с названием «AI». И вина за проблемы — тоже ваша. Смотрите, что подписываете.
«Слушай, у меня в мышке сел аккумулятор, поэтому мой ПР удаляет не GDPR-данные, а половину живой базы». Звучит как бред, да?
Если заменить севший аккумулятор на claude/gpt/что там ещё?
Конечно такой треш увидеть сложно даже у джунов, но вот подход «ой, это не я, это ai накосячил, сорян» встречается даже у синьёрных товарищей: и в коде, и в требованиях, и в документации.
Друзья, если под коммитом стоит ваше имя — это сделали вы, а не какая-то внеземная сущность с названием «AI». И вина за проблемы — тоже ваша. Смотрите, что подписываете.