25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
А я доделал!
В общей сложности потратил часов 20, зато получил код, который ещё очень долго не потребует никакого обслуживания, потому что самая сложная технология в нём — это sentry, которую через пару месяцев я тоже выпилю. Даже линтеров, кроме prettier, нет!
Самым непривычным было заставить себя говнокодить — я в шести местах скопировал один и тот же код для пейджинации, и в трёх местах сделал почти одинаковое хождение в бекенд. Зато этот код сможет починить кто угодно даже после ядерного апокалипсиса. А функциональность туда добавлять никому не нужно — как показывают прошедшие 10 лет, скорее я придумаю что ещё оттуда убрать, чем добавлю что-то новое.
Смешно, что производительность сайта по Lighthouse выросла до 100 баллов — достаточно было просто отказаться от SPA. Ещё смешнее, что в два раза упало время до первого байта, хотя ни объём данных, ни способ хождения в API никак не поменялись. Кажется, Тонский прав и мы все идём куда-то не туда.
Джуны и GPT-ассистенты
Всё чаще встречаю джунов, которые плотно сидят на GPT-ассистентах, типа Copilot chat. Спрашиваешь доброго робота «как добавить JS в Джанго-алминку?» и получаешь готовый код, который скорее всего даже заработает. Сразу чувствуешь, что будущее наступило.
Только вот будущее это — не для вас, увы. Довольно мало ценности в том, чтобы переводить просьбы бизнеса в вопросы роботу — в какой-то момент такой посредник, как вы, станет просто не нужен.
Профессионального роста от такого программирования тоже немного. Самое главное, что должен делать джун — это учиться: разбираться, как устроены библиотеки и как мыслят их авторы, учить языки, учиться учиться а конце концов. В общем, планомерно нарабатывать свои 10 000 часов за счёт работодателя.
Час, потраченный на изучение документации — это час, вложенный в ваш профессионализм. Час, потраченный на попытки починить GPT-код — это просто час, который вы продали работодателю, не получив ничего, кроме денег.
Доверяйте машине только те активности, которые не прокачивают лично вас — нагенерить тестов, крудов или семпловых данных. А для всего остального — читайте старую добрую документацию и скорее становитесь мидлами.
Генераторы статичных сайтов не нужны
Очень хочется ответить на комментарии «почему ты не взял static site generator типа Jekyll, это же так просто?».
Статичный сайт — это НЕ просто. Это настолько сложно, что блог с ним становится обузой.
Во-первых, генераторы статичных сайтов не удовлетворяют требованиям из предыдущего поста — в них очень много движущихся частей. Мне в любом случае нужно как-то закидывать туда свои шаблоны — а значит ставить среду разработки, которая наверняка устареет через пару лет. Нужно сохранить текущую структуру урлов — а генераторы статичных сайтов в вынуждены делать негибкие роутеры, по которым можно построить всю структуру сайта в момент генерации. В конце концов, результат работы статического генератора нужно куда-то выложить и настроить CI.
В решении каждой проблемы по отдельности есть чемпионы. Jekyll можно обновить одним коммитом из интерфейса гитхаба, а у hugo среда разработки c нулём зависимостей. Но чаще генераторы создают свои специфичные проблемы — типа hexo, у которого в API сложнее разобраться, чем в API нормального банка.
Но главное даже не в сложности. А в том, ради чего люди вообще ведут блог. Мне блог нужен, чтобы туда писать, а не пробовать новые инженерные идеи. Я хочу, увидев опечатку на сайте, открыть с телефона админку и поправить её. Хочу верстать в две колонки и перетаскивать картинки мышкой. Хочу дать доступ к блогу другим авторам, чтобы они выкладывали свои тексты у меня — мы так публикуем анонсы fands, пока не сделали нормальный сайт. Всё это очень сложно сделать в статичных генераторах — by design.
Статичный сайт никак не делает блог лучше, а скорее даже наоборот, усложняет жизнь за счёт своего оверхеда. Так же как React не ускоряет вёрстку HTML, а RabbitMQ не улучшает структуры данных. Если отбросить самолюбие автора, останется всего одна проблема, которую решают генераторы статичных сайтов — как переложить сложность со времени эксплуатации на время сборки. И я не могу представить себе проект, где такая проблема существует.
#вопрос Понравилось, как ты выступал на SaintTeamLeadConf 2024. Расскажи, как ты готовишься к публичным выступлениям?
Вообще мне кажется, самое главное в публичных выступлениях — это хороший тренер. Своего могу порекомендовать — это Венера Шакирова, @oh_venera. Но вопрос задали всё-таки мне, поэтому попробую ответить, как это делаю я.
Подготовку начинаю примерно так же, как к лонгридам в школе — как только принято решение о том, что выступление будет, начинаю жить с темой в голове. Буквально — завожу в Bear заметочку, и всякий раз, когда мне приходит любая мысль по теме — я её моментально записываю. Важно записывать вообще всё, что приходит в голову — тезисы, метафоры, идеи структуры. Пока носишь такие вещи в голове — они все кажутся очень красивыми и логичными. А когда записываешь и возвращаешься к ним через день-два — смотришь совсем другими, критическими, глазами.
Через 2—3 недели, когда набирается достаточно «руды» — можно начинать наговаривать. Важно ни в коем случае не писать себе текст, а именно говорить — письменная речь отличается от устной примерно как китайский язык от румынского. Во-первых, когда говоришь, совсем по-другому работает мышление. Во-вторых — стройный текст никогда не будет звучать хорошо если его просто озвучить, как и стройная и приятная речь, будучи записанной, скорее всего превратится в кашу. Чтобы понять о чём я, почитайте любую транскрипцию подкаста (вот первый попавшийся): текст кажется странным, много слов, которые кажутся лишними и мусорными, хотя в речи, наверняка, звучали норм.
Наговаривание — процесс итеративный. Я записываю выступление в CleanShot, и прослушиваю, добавляя мысли, которые нравятся и выкидывая те, которые не нравятся. Выкидывать — важнее: я люблю делать короткие выступления, мне нравится оказывать уважение зрителям, не тратя их время на то, чтобы донести мысль, которую я просто недостаточно поджал.
Идеально провести 10-15 таких итераций на один доклад, но в реальной жизни получается немного меньше: всё же садиться и болтать на камеру — довольно тяжело, это занимает кучу времени и не получается заниматься этим нигде, кроме тихого кабинета.
Ну а подача, интонации и жесты просто приходят со временем. У меня начало что-то получаться где-то в районе пятого выступления, подготовленного таким образом — я начал осознавать, что у меня получается лучше, а что — хуже, начал следить за дыханием и телом, приходить на доклад с правильным настроем.
Это был традиционный #вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Рабочее молчание
Текст — это основа моей работы. По большому счёту всё, что я делаю — это текст. Поэтому мне важно, чтобы всё, что я пишу, достигало адресатов. Чтобы сообщения читали внимательно и в трезвом состоянии ума. Хочу, чтобы даже посты в этот канал читали вдумчиво.
Для этого я внимательно слежу за соотношением сигнала к шуму во всём, что пишу. К примеру я не сижу в рабочих чатах потому, что там высокий уровень шума — то, что я туда напишу, может в этом шуме потеряться. В почте и задачнике я избегаю сообщений, которые не несут смысла — чтобы если кому-то пришло сообщения с именем Fedor Borshev в отправителях, они знали, что там нет ничего не значащего «спасибо».
Соотношение сигнала и шума важно не только в личной коммуникации. К примеру любой руководитель, который уменьшит в собственной команде количество шума и добавит количество сигнала — получит более вдумчивых и внимательных сотрудников. Думаю со мной согласятся все, кто когд-нибудь сидел в рабочем чате, где решают личные вопросы, а важные уведомления и новости сыпятся вперемешку с сообщениями от ботов по поводу заваленного CI в пуллреквесте от джуна.
Рабочее молчание гораздо ценнее, чем рабочее общение — когда люди не тратят силы на разгребание шума в поисках сигнала, сил на полезные дела остаётся гораздо больше.
Среди программистов принято гордится сложностью своих решений — типа поставил Кафку и рассказываешь об этом на конференции, не упоминая ни слова о том, какую бизнес-проблему ты ей решил. А вы видели где-нибудь ещё профессию, в которой принято гордиться сложностью своих произведений? Может писатели, которые гордятся, какую непонятную книгу написали? Или туристы, которые гордятся тем, что тащат в рюкзаке 10 лишних килограммов? Наверное с ходу могу вспомнить только автомобильных инженеров — те тоже любят делать трёхцилиндровые двигатели, сенсорные переключатели и двери без ручек.
Я догадываюсь, откуда это происходит — помню, когда мне было 13 лет, мой преподаватель по информатике показал, какую сложную программу на 50 экранов он написал. Конечно я захотел так же, и потом долго думал, что чем круче программист, тем более сложные штуки он делает. К тому же 50 экранами гордится гораздо легче, чем 3, которые решают ту же задачу.
Хочется, чтобы книги и вайтишные курсы с самого начала объясняли будущим джунам, что профессия наша — сервисная, и для успеха надо не наворачивать дополнительной сложности, а наоборот, решать запросы бизнеса с минимально возможным оверхедом. И что умные технологии надо учить не для того, чтобы хвастаться в резюме, а чтобы уметь их не притаскивать, когда не надо.
Старею, похоже
Лучший Курс По Питону от Никиты Соболева
Редко публикую здесь чужой контент, но всё, что делает Никита Соболев вокруг питона точно стоит упоминания. Никита начал делать фундаментальный курс — выкладывает на ютуб видосики, где до косточки разбирает одну конкретную тему. К примеру есть отдельное видео про bool и отдельное про int, и даже видос на 25 минут про плюс. Каждый видосик разбит на 3 части — для джунов, мидлов и синьёров.
Сейчас Никита снял всего 4 выпуска, и я очень хочу, чтобы он не останавливался: мне, как владельцу галеры, очень приятно было бы принимать на работу джунов, которые относятся к языку с такой же любовью и обстоятельностью, как это делает Никита в своих видосах.
В общем переходите по ссылкам и подписывайтесь на канал, а лучше — ещё и на бусти, там есть тариф за 100 рублей в месяц.
Ласт-колл на Анализ Систем
В четверг начинаем обучение на третьем потоке «Анализа Систем» — фундмаментального курса о том, как принимать архитектурные решения, слушая при этом бизнес.
Я много уже писал о нём, поэтому не буду повторятся, просто поскролльте вверх. Если сомневаетесь — прочитайте программу и отзывы студентов.
А давайте поговорим об этом?
В четверг, в 16:00 MSK, говорим с Антоном про роль архитекторов в компаниях, и о том, что проектирование — это про бизнес, а не про втыкание кешей и кафок.
Подробной программы нет — просто соберёмся в телеге. Заодно расскажем, чего ждать на третьем потоке Анализа Систем, зачем на него идти, а зачем — нет, и поотвечаем на вопросы.
Ненавижу Metabase
Мы в школе активно используем Metabase — и для управленческой отчётности, и для операционки: взаиморасчётов с экпертами, проверки домашки и ещё кучи ad-hoc задач. Прежде, чем писать код для полноценных интерфейсов, всегда пробуем решить проблему на Metabase.
Но вот как этот инструмент сделан для администратора — это просто отвратительно. К примеру их команда тратит кучу сил на то, чтобы данные можно было ковырять без знания SQL. Идея крутая — типа дадим пользователям все данные, а они уже сами себе соберут дешборды. Но вот реализация просто отвратительная — все эти инструменты не работают даже на нашем простом сетапе.
К примеру, хочу отдать юзерам данные по покупкам, в этих данных должна быть довольно тривиальная штука — деньги, которые к нам реально пришли от покупки — за минусом комиссий эквайринга и налогов в стране, из которой он сделан. Вроде бы для этого есть Модели — такие материализованные вьюхи, куда можно зашить всю логику, а потом уже использовать их.
Но эти модели не работают! Может быть один раз данные из них получить и можно, но вот построить из них более или менее полезный дешборд уже не получится. Данные в моделях нельзя нормально фильтровать, с ними не получается писать SQL: итоговые запросы получаются настолько корявыми, что когда они падают, нет никакого способа их отладить. То есть у ребят получились материализованные вьюхи, которые толком не работают, да ещё и материализуются где-то вне БД, то есть не контролируются миграциями.
Кажется, что выходить с уровня БД на уровень приложения и описывать модельки на языке метабейза стоило бы ради довольно полезной функциональноси, которую умеют все крутые BI — джоинов из двух БД одновременно. Но этого похоже не будет никогда.
В итоге так мы и пишем SQL-запросы, выводя их результаты в дешборды. Получается грустно — у нас нет нормального data lake, и мы делаем выборки просто с продовой базы, а значит не можем делать серьёзные изменения в структуре данных, не сломав всю аналитику. Раз в год я пытаюсь заюзать фишки метабейза, которые позволяют избавиться от этой зависимости, трачу на это 3–4 часа и бросаю.
Может посоветуете замену, которая подходит маленьким ребятам, которые пока не доросли до выделенных ETL-пайплайнов? Или уже доросли и пора делать?
Творческая безопасность
Мы с Марьяной в прошлую пятницу выпустили последний урок «Стать Тимлидом 2.0». Пост гордости напишу чуть позже, когда отрфеклексируем вместе, а пока хочу рассказать об очень важной концепции, которую я нащупал, пока писал курс.
Когда человек делает творческую работу — он часто в себе не уверен: боится ошибиться, переживает что о нём подумают окружающие, или просто по привычке — потому что так в школе научили. Тимлидский курс для меня — это именно такая работа: приходится вытаскивать наружу кучу идей, которые носил раньше в голове, и которые почти не с кем сверить. И единственное, что мне позволило спокойно и ритмично писать курс все два месяца — это творческая безопасность.
Каждый раз, передавая свою часть работы Марьяне, я был уверен, что она воспримет её максимально внимательно, в трезвом состоянии ума и точно никогда не притащит каких-то личных переживаний — к примеру о том, что я скинул обновления в её выходной, или что нас послезавтра дедлайн. Если Марьяна будет несогласна со мной — она подробно напишет с чем именно и почему: мне не придётся с ней созваниваться и клещами вытаскивать, что на самом деле ей не нравится.
Оказывается, когда в голове нет переживаний по поводу безопасности — пишется гораздо легче. Если бы я не чувствовал безопасности — я был бы осторожнее в суждениях, вместо собственных концепций старался бы взять готовые и всячески спрятать их содержание за формой. Чего только не сделаешь, чтобы не получить неприятную оценку!
Такую же творческую безопасность я стараюсь поддерживать и в своих командах — никогда не общаться пассивно-агрессивно; писать максимально развёрнуто; не критиковать идеи, а предлагать улучшения, и т.д. Получается не всегда (даже у нас не все умеют в асинхронную коммуникацию), но об этом напишу как-нибудь отдельно.
Кажется, задача любого руководителя в творческой команде — создавать максимально безопасную среду для творчества. Безопасная среда приводит к выдающемуся результату. Привычно-опасная среда — к обычному, или вообще к его отсутствию.
Google → Kagi
Недавно прошло два месяца с тех пор, как я не искал ничего в Гугле. Перед уходом я каждый месяц натыкался в нём на какую-нибудь новую хрень — то подсунут ссылки на Дзен или другой SEO-мусор вместо результатов; то нагенерят таких ответов через GPT, что мозги от одного взгляда на них разжижаются.
Раньше я несколько раз пробовал DuckDuckGo, но уходил примерно через день. А недавно попробовал Kagi, и на нём и остался.
— SEO-мусора почти нет, а если что-то вылезает — можно вручную забанить.
— Саммарайзер работает отлично и на русском, и на английском. Особенно кайфово прогонять через него всякие бухгалтерские и юридические статьи.
— Фильтры (они называется lenses). Можно искать только среди научных статей, или только в рамках small web — авторских блогов живых людей.
А ещё я чувствую уверенность, что мою выдачу никогда не наполнят рекламой и не подсунут туда AI-результаты. Ребята берут подписку за свои услуги, а значит мой поиск — это не товар, а позиция про AI у них простая: он может только улучшать ответы, но ни в коем случае не давать их сам.
Конечно есть и косяки — путает Грузию и Джорджию (даже когда ищешь что-то в Тбилиси), невозможно настроить саджесты на iOS. В остальном — база, как гугль лет 15 назад. И всего за 12 баксов.
Мы с Марьяной недавно закончили самый важный для меня кусок Стать Тимлидом 2.0 — урок о том, как договариваться с бизнесом.
Для меня этот урок важен потому, что почти все знания в нём — мои личные. Другие знания из курса я по большей части получал извне — говорил с умными людьми, слушал выступления, читал в книгах и адаптировал к практике. А вот о том, как строить отношения с бизнесом, у нас в индустрии говорить почему-то не принято. За всю жизнь я нормально говорил об этом только с одним человеком (Али, спасибо, если читаешь).
CTO, который не понимает, о чём болит голова у CEO — это плохой CTO. Стартап с тимилдом, который просто пишет хороший код, закроется гораздо раньше, чем с чуваком, которые ещё и понимает проблемы бизнеса. Даже программисты, которые дружат с бизнесом, живут лучше чем обычные — они получают более интересные задачи и меньше контроля.
Конечно, другие дисциплины курса тоже важны — мало просто дружит, надо ещё выполнять обещания, расти когда это нужно, договариваться с коллегами и подрядчиками и не забывать о личной продуктивности. Но урок о дружбе с бизнесом для меня — главный водораздел, сдав его я уже горжусь курсом.
Вписаться на курс можно до 16:00 завтрашнего дня — потом мы закрываем запись, потому что не хотим продавать вам чувство вины за то, что не успеваете за потоком делать домашку.
Запрыгнуть в последний вагон →
Профессиональные блоги
Кажется это первая такая подборка на канале, но почему бы и нет. Расказываю, что ещё стоит почитать в телеге.
@mspiridonov, Максим Спиридонов, основатель Нетологии. Заявляет, что пишет о бизнесе, фактически — обо всём важном. К примеру страшный пост про дофаминовую культуру и тиктокизацию
@zamesin, Иван Замесин, основатель Меты. Пишет о продуктах, узурпирует Jobs to be Done в телеге, сделал тренинг об управлении продуктами на 46 (!) потоков, ведёт подкаст. Очень зацепил пост про болезни, которые заставляют нас выключаться из работы, прямо про меня.
@kutergin_on_fire, Денис Кутергин, основатель Юду. Пишет об управлении и бизнесе, ведёт ютуб-шоу «Основатели». Гляньте про идеальный формат отношений в семье или о том, почему люди боятся нанимать сильных сотрудников.
@bezaspera, Арина Хромова, основатель Careerspace. Пишет об HR, поиске работы и найме, даёт советы о LinkedIn, есть платный гайд по нему. Посмотрите на большую подборку материалов по релокации.
@disruptors_official, Алексей Подклетнов. Уже упоминал его здесь — пишет обо всём происходящем в больших технологиях, айти и бизнесе, добавляет личное мнение — к примеру о недвижимости в Китае. Хотите первым узнать про новый прорывной продукт, но не читать тонну новостей — идите к нему.
@betternotworse, Егор Данилов, бывший CPO в Юле и директор по продукту Ivi. Читать имеет смысл если вы имеете хоть какое-то отношение к продуктовой разработке. Восхищаюсь количеством мыслей и тем, как ёмко он их выражает. Начните со списка его любимых постов и не отрывайтесь пару часов.
@startupoftheday, Александр Горный, Ex-директор по стратегии Mail.ru, сейчас ведёт несколько своих бизнесов. Вряд ли вы ещё его не читаете, но всё же — на канале крутой формат: 1 пост — 1 стартап. Без воды рассказывает про бизнес-модели. Посмотрите на Коронавирус как стартап.
@aioftheday, тоже Александр Горный: новостной канал про AI. К примеру новость о том, что в магазинах Amazon без касс на самом деле в камеры смотрела 1000 индусов.
@RationalAnswer, Павел Комаровский. Канал про деньги и инвестиции. Читаю его раз в месяц, чтобы понимать, что в мире происходит с инвестициями. В тайне надеялся вернуть через него веру в отечественных брокеров — пока не смог. Почитайте про сравнение кредитки и подушки безопасности или почему при бурном росте китайской экономики акции не растут.
Выложили с Саматом большой рассказ о том, как помогали (и не помогли) сети клиник Чайка перезапустить разработку.
Не все отношения клиента и заказчика в аутсорсе заканчиваются победой — но это не повод о них не рассказывать, тем более мы гордимся обоими сторонами команды — и нашей, и Чайкой
Пару месяцев назад я выкладывал сюда список профессиональных блогов в телеге — в нём было много не профессиональных блогеров, а людей, у которых стоит поучиться новому.
Вот что с тех пор они написали:
— Арина Хромова рассказала, сколько зарабатывают российские топы (спойлер — дофига, надо было вкатываться в MBA вместо айтишечки).
— Алексей Подклетнов рассказал, как чувак заработал денег на том, что заспамил спотифай 24 000 песен про чистку зубов, поход в магазин или про колумниста New York Times.
— Максим Спиридонов — про простой фреймворк, с помощью которого можно увольнять слабых людей.
— Денис Кутергин обидно (но честно) рассказал, что хороший селлер на маркетплейсах выстраивает ВЭД, логистику и финансы, исследует рынки и закупает трафик, а плохой — ругает вайлдберрис за повышение комиссии.
— Ваня Замесин — про семейную терапию. Подпишусь под каждым словом. Почему-то у о семейной терапии принято говорить так же, как лет 10 назад говорили о личной — примерно никак.
— Павел Комаровский — о том, надо ли страховать жизнь.
— Александр Горный рассказал грустную историю, как могут выглядеть продажи кибербезопасности. Хоть там и нет ни одного имени реального человека — легко поверить.
— Он же в другом своём канале рассказал, как из макдональдса убрали AI-помощника, потому что он рекомендовал людям добавить бекон в мороженое.
— Егор Данилов рассказал, как он работая в Юле боролся с мошенниками, покупая у них по 500 рублей инструкции, как скамить лохов (респект за ижевское образование).
#вопрос Как доказать в цифрах, что хорошие инженерные практики полезны для бизнеса?
Я знаю, что хорошие инженерные практики, вроде автоматического тестирования, актуальной документации и код-ревью, облегчают жизнь разработчикам. Так же я верю, что они делают разработку быстрее, то есть, несут прямую выгоду бизнесу. Но вот как построить метрику, которая покажет прирост производительности (или пространство для этого прироста) — не знаю. Можно ли это вообще как-то измерить? Или тут только и остаётся, что оперировать таким эфемерными вещами, как комфорт разработчиков и привлекательность для кандидатов?
———
Увы, я не знаю ни одной метрики, которая помогла бы за одну (или пять) встреч договориться с бизнесом про инженерные практики. Конечно можно порассуждать о time2market и velocity, QA-метриках или SLA, но прямой связи вы не докажете. А если с вами начнут спорить — вы ещё и навредите себе или попадёте в аналитический паралич, пытаясь измерить то, что не важно.
Чтобы договорится с бизнесом об инженерных практиках, придётся выстраивать с ним отношения. Представьте себе главного инженера на стройке — вряд ли он доказывает инвесторам, что рабочие должны носить каски. Ваша цель — стать таким же инженером: вам должны верить.
Верить обычно начинают людям, которые показывают результаты и хорошо умеют слушать. Каких от вас ждут результатов — лучше узнать у руководителя. Скорее всего это закрытые задачи или те самые метрики. Чтобы достичь метрик, изменения возможно, придётся «явочным порядком» — не ждать, пока вам дадут добро на внедрение практик, а придумывать, как ускориться прямо сейчас. В общем сначала — доверие, а потом практики.
Ну а чтобы научиться слушать бизнес — приходите к нам на Стать Тимлидом, там целый курс про это.
Это был традиционный #вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Как и любой уважающий себя дед, я веду стандалон-бложек. Начал лет 10 назад — и с тех пор раз 5 его переписывал.
Сначала — по-программистски, чтобы статичный сайт, облачный хостинг, красивый код и всё такое. В какой-то момент понял, что переусложнил себе жизнь: всё-таки время, которое я могу выделить на блог, лучше тратить на новые посты, а не на настройку и дописывание. Последняя моя итерация — ghost.org и простой фронтенд на nuxt.js. Живу с этой конструкцией с 2019 года, раз в 3 месяца выделяя 20 минут, чтобы обновить зависимости и не копить техдолг. Зависимостей у меня много — я тогда ещё не расстался с программированием и нагородил кучу ненужной фигни: От purgecss до промышленных линтеров. Потихоньку выпиливаю, но получается плохо: вход рубль, выход — два.
Недавно в очередной раз сел обновлять зависимости и решил посидеть подольше — пора бы уже слезать с библиотек, половину из которых за 5 лет просто диприкейтнули. И застрял на 3 часа! За 5 лет без фронтенда, я вообще перестал понимать, что там происходит — не понимаю, как работает новый nuxt, не умею в Typescript, не понимаю как теперь принято дружить линтеры с prettier (и надо ли). Я даже не знаю, чем сейчас принято ставить пакеты! npm? pnpm? Может yarn успел набрать популярность в третий раз?
В общем я решил переписать блог ещё раз, но теперь с простым требованием — чтобы я мог с ним жить, даже когда совсем разучусь программировать. Чтобы через 10 лет иметь возможность его хотя бы запустить, не разбираясь, что фронтендеры за эти 10 лет придумали. Если не самому — то хотя бы отдать на доработку зелёному джуну с вайтишных курсов.
Понадобилось всего 10 лет, чтобы понять, насколько Бирман был прав со своей Эгеей, написанной на ПХП и плоских функциях-утилитах, эх.
Выбрал вот такие технологии:
— Бек оставлю прежний, на ghost.js
— Фронт напишу на express.js — он вряд ли серьёзно поменяет API даже после ядерного апокалипсиса. И SSR будет из коробки. Питон не хочу, чтобы не добавлять технологий, а штатный фронт ghost не хочу, потому что авторы над ним активно работают — а значит он станет совсем другим уже через 2-3 года.
— В качестве шаблонизатора возьму nunjucks. Синтаксис — проверенная временем копия jinja2, проект довольно зрелый, то есть вряд ли туда будут добавлять много фич, и при этом не забросят, потому что Mozilla.
— CSS оставлю старый, на bulma. Препроцессор — SASS. JS весь с фронта выпилю, он для блога не нужен.
Код буду писать максимально дубовый, с копипастой и кучей if: такое всё равно будет легче прочитать, чем раскиданный по компонентам код на непонятных библиотеках.
Половину я уже написал, вот думаю — стоит ли вас звать на стрим, где в напишу вторую половину? Планирую заняться этим в пятницу, в 17:00 MSK. Наберётся 200 человек — починю OBS и устрою стрим.
Мы с клиентом запустили стартап. Он помогает малым локальным бизнесам — кофейням, барбершопам и другим — зарабатывать по модели, которую применяют Amazon и Яндекс.
Сделали мы это с помощью технологии PWA — создали практически полноценное мобильное приложение — с оффлайном, пуш уведомлениями и иконкой на рабочем столе, используя только веб технологии! А при запуске чуть не попали в замес борьбы Apple с Евросоюзом.
В новой статье делимся, как у нас получилось успеть всё это за 6 месяцев при том, что требования постоянно менялись (стартап!)
Хотите запустить проект с нами? Пишите в личку @samatg или оставляйте заявку на сайте.
Хвастаюсь! Это первые отзывы после недели обучения на третьем потоке «Анализа Систем».
Как обычно, каждый новый поток приносит кучу новых задач в беклог — и по контенту, и по LMS. Но приятные отзывы помогают их делать :-)
Невозвратные билеты
Давно догадывался, что с невозвратными авиабилетами что-то не так, а сейчас посчитал и офигел.
Стыдно сказать, но за последние три года, периодически пользуясь невозвратными билетами на самолёты и бронированиями отелей, я потерял гораздо больше, чем 20% от всех затрат на отели и самолёты, которые в принципе совершил. И это не говоря о ситуациях, когда я вынужден был подстраивать свои планы под бронь только потому, что было жалко вернуть за неё деньги.
Разница между обычным авиабилетом и невозвратным — как между обычным опционом и бинарным. В первом случае мы покупаем право совершить перелёт, а во втором — обязанность. Вне зависимости от того, понадобится перелёт или нет — отказаться от него стоит столько же, сколько мы за него заплатили. Купил невозвратный билет за 100 тысяч? Опоздать в аэропорт стоит 100 тысяч. Заболеть стоить 100 тысяч. Опоздать на стыковочный рейс по вине другой авиакомпании — тоже 100 тысяч. Можно, конечно, как-то побороться и вернуть хотя бы часть денег, но это точно не то, чем хочется заниматься в деловой поездке или отпуске.
Так что меняю правила покупки билетов:
— Никогда не покупать невозвратных тарифов.
— Билеты туда и обратно брать в разных бронированиях.
— Не пользоваться агрегаторами для покупки билетов.
— Не летать лоукостерами.
Рассказать о вакансии в баре
Удивительно, но очень многих людей охватывает ступор, когда перед нами встаёт простая задача — текстом рассказать о компании, в которой мы работаем. В итоге получаются вымученные, ничего не рассказывающие вакансии из воды.
Первая проблема — безликие, ничего не говорящие утверждения, типа «бекенд на node.js», «проптех для США». Проптех может оказаться как скучной CRM для риелторов, так и экосистемой, которая закрывает все потребности от выбора и покупки квартиры до обещания с арендатором, да ещё и с высокой нагрузкой от доски объявлений. Представьте сами, куда вам больше хочется откликнуться — на безымянный бек на ноде или подробный рассказ с версиями TS, процентами тестового покрытия и парой слов о способе коммуникации сервисов?
Вторая проблема — шаблоны, которые люди копируют друг у друга, все эти «дружные коллективы». Это же такие же пустые фразы: для кого-то дружный коллектив — это команда, которая дружелюбно даёт обратную связь, для другого эти слова могут означать еженедельные походы в бар, для третьего дружелюбная команда — это там, где не спрашивают за пропущенные дедлайны.
При этом, если человек, который в вакансиях пишет «динамично развивающийся», сядет за столиком в баре и начнёт рассказывать о компании своему товарищу — рассказ получится совсем другим: с подробностями (и без нарушения NDA), вкусностями, плюсами и минусами. То есть нормальный текст.
Так получается потому, что вакансию воспринимают как заклинание, которое нужно кастануть, чтобы получить кандидатов. Я так в школе писал сочинения — если накастовать в тетрадке заклинания из сборника «100500 сочинений», то учитель отстанет.
Так вот, вакансия — это не школьное сочинение, и GPT тут не помогает. Самый хороший способ написать нешаблонную вакансию — это по прежнему сесть рядом с товарищем в баре и записать всё, что вы хотите ему рассказать. В итоге получится простой рассказ о компании на человеческом языке, который заметно увеличит конверсию.
Количество подписчиков == оборот бизнеса
Задумался тут, что количество подписчиков в телеге — это как оборот у бизнеса. Почему-то предприниматели, когда рассказывают о своём бизнесе, обязательно меряются оборотами, но никто не говорит о маржинальности и прибыли.
Допустим у кого-то бизнес с оборотом 500 миллионов рублей в год, из которых 200 уходит на закупку товаров, 200 на зарплаты, а 95 — на обслуживание кредитов. Получается внушительная цифра, но вот прибыли не много. Или возьмём бизнес в 10 раз меньше — 50 миллионов в год, о при этом затрат у него только 10 миллионов. Второй бизнес хоть и выглядит скромнее, но гораздо более прибыльный. Я-то уж точно выберу второй.
Так же и с количеством подписчиков в телеге. Есть каналы с десятками тысяч людей, которых читает от силы 1000 человек. И наоборот, бывают каналы по 2000 человек, где просмотров больше, чем подписчиков. Среди SMM-щиков этот показатель называется уровнем вовлечённости — средний процент просмотров относительно общего количество подписчиков.
Но на самом деле уровень вовлечённости — тоже не самый полезный показатель. Гораздо важнее смотреть, насколько канал решает задачи, которые перед ним поставил автор. Через эту призму уровень вовлечённости и абсолютные цифры просмотров становятся важны только для брендовых каналов или медиа — там важны охваты и продажа рекламы. А для простых ребят, которые ведут канал, чтобы высказаться, получить новые контакты или полезные комментарии, гораздо важнее качество аудитории: насколько людям интересно читать и отвечать.
Если канал предлагает какой-то продукт — нужно смотреть, какому проценту аудитории этот продукт может быть полезен. К примеру ютуберы с миллионными каналами зарабатывают с рекламы вместо своих продуктов потому, что их миллионы — это гетерогенная масса случайных людей, из которых не получается выделить когорту, достаточную, чтобы собрать ценный продукт, который приносит деньги.
Сравните две крайности — у Тонского маленький канал с супер-интересными срачами в комментах, а у Лебедева — гигантская площадка медийного уровня, но вот услуги студии он там давно не продаёт.
System Design на собеседованиях в большие компании наносит больше вреда, чем пользы. Алгоритмы хотя бы не заставляют делать ничего плохого — от того, что ты научился на бумажке находить пересекающиеся интервалы или обходить графы, ты хотя бы бизнесу не навредишь.
А вот программист, который профессионально умеет городить сложные системы на ровном месте — навредит, особенно когда ему ещё на этапе собеседования показывают, что компания именно этого от него и ждёт.
Системы с собеседований никак не связаны с реальными бизнес-требованиями: ведь собирать их и осмысливать явно дольше, чем длится время собеседования. Да и ценность хорошего архитектора не в том, чтобы делать сложные вещи, а в том, чтобы придумывать простые, когда бизнес настаивает на сложных.
Мы запускаем третий поток курса «Анализ систем», который как раз об этом — как собирать бизнес-требования и делать максимально простые системы, которые их выполняют. Для этого мы много говорим о стратегическом анализе бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций, писать документацию. Изначально мы задумывали курс ради четвёртого урока, в котором мы дали пошаговые рекомендации по распилу монолитов, но сейчас поняли, что гораздо важнее мета-навык — умение слушать бизнес и не делать лишнего.
Стартуем 13 июня, учимся 5 недель. Учиться рекомендуем в тусовке — наблюдая за чужими домашками, вы вынесете из курса гораздо больше знаний, чем если просто прочитаете материалы. До вечера четверга действует промокод SAD10 на 10% скидки.
Если вы принимаете даже самые маленькие решения по организации кода или взаимодействию систем в организации — ждём вас на курсе. Если хоть чуть-чуть общаетесь с бизнесом — тоже. Джунам на курс рановато. Если сильно верите в себя — берите не выше самостоятельного тарифа.
#вопрос Насколько вы часто пользуетесь электронной почтой? Кажется, что этот инструмент уже рудимент, покрытый десятками непрочитанных писем у миллионов пользователей.
Почта — мой основной рабочий инструмент уже лет 15. Я исповедую пустой инбокс, и настроил всё так, что мне туда падают все рабочие уведомления: из гитхаба, бейскемпа, и даже из банка.
Самое главное для меня в почте — это то, что она аггрегирует в одном месте вообще всё, что надо сделать. Не нужно проверять десяток чатов и открывать 3 задачника, чтобы посмотреть, что меня ждёт. А удаляя обработанные письма, я вообще достигаю кристальной чистоты: в этом канале нет вообще ничего лишнего — если я ответил на письмо или сделал задачу, я его никогда больше не увижу.
Конечно, многие люди действительно относятся к почте, как к помойке — хранят в инбоксе по 20 000 пустых писем от маркетплейсов, сервисов и госуслуг, а для рабочего общения предпочитают рабочие чатики. Раньше я жёстко топил против рабочих чатов и даже пытался их запрещать в своей компании. Сейчас успокоился — если человек хочет работать с загаженным сознанием — не мне его отговаривать.
Единственное, что я сейчас делаю — создаю среду, дружественную для таких, как я — плачу за бейскемп с его супер-удобным Hey (не почтой) и разделением синхронной а асинхронной коммуникации через Campfire, и за гитхаб, который позволяет гибко настраивать потоки уведомлений. Ну и периодически напоминаю, что срочно отвечать никому ни на что не нужно.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
#вопрос Расскажи, какие технологии и знания помогли уйти в собственный бизнес?
Кажется это уже третий или четвёртый вопрос на тему перехода из работы по найму в собственный бизнес. Я не чувствую здесь серьёзной экспертизы и слабо понимаю, кому и как мой опыт может пригодиться — поэтому это точно последний ответ, простите.
Знания хардовых технологий вроде python/js мне не помогли совсем — я очень мало написал коммерческого кода для клиентов: может быть за всё время потратил несколько недель. Причём, если бы умения писать код у меня не было — я бы обошёлся и без них. Возможно помогло понимание devops и любовь к DevEx — с самого начала существования аутсорса мы делали программистам удобно: юзали удобные хостинги вроде heroku\netlify (сейчас перешли на vercel), много вкладывались во внутреннюю разработку. За счёт этого достигли довольно высокой для аутсорса рентабельности — программисты у нас работают действительно эффективно.
Больше всего наверное помог просто жизненный опыт — умение слышать бизнес и понимать желания программистов, умение отличать хороших исполнителей от плохих. Из нетехнических навыков здорово помогла общая продуктивность: приходилось делать много неочевидных, скучных, но очень важных задач, вроде общения с бухгалтерией и банками, финансового планирования и учёта.
Самый неочевидный навык, который мне помог в аутсорсе — умение письменно выражать свои мысли. Использую его постоянно — от внутренних регламентов до публичных анонсов наших проектов (хотя последние пишут уже сами ребята). Без умения писать точно было бы гораздо сложнее.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
The winner takes it all или почему я убежал из венчура
Одна из причин, по которой я решил уйти из венчурного стартапа и в будущем не связываться с инвестициями в свои проекты — мысль Талеба из (кажется) «Шкуры на кону».
Есть профессии, в которых существует огромный разрыв между успехом и неуспехом. К примеру — творческие: известных музыкантов, скульпторов и актёров намного меньше, чем безызвестных, причём известность — это МНОГО денег, а неизвестность — очень мало. То есть победитель забирает всё — или ты станешь звездой, или умрёшь нищим (с гораздо большей вероятностью).
Сравните с условными айтишниками: если ты умеешь писать код и хоть чуть-чуть разговаривать с людьми — будешь ещё долго зарабатывать приличные деньги. Почти невозможно вложить силы в изучение технологии и остаться не у дел, в отличие от тех же актёров.
Фаундеры в венчурных проектах ближе к артистам — как только ты берёшь инвестиции, ты вступаешь в гонку за ВСЕМ: или твой проект растёт по экспоненте, или ты проигрываешь. В венчуре невозможен проект, который просто неторопливо развивается: бизнес не растёт — идёшь делать следующий.
Мне гораздо комфортнее линейная зависимость — когда я никому не обязан строить САМУЮ БОЛЬШУЮ ШКОЛУ и САМУЮ ПЛАВУЧУЮ ГАЛЕРУ: то, что я построю, принесёт мне столько денег и счастья, на сколько хорошо я сделал свою работу. И даже если сделал я совсем чуть-чуть, мои результаты никогда не умножатся на ноль просто из-за законов жанра.
#вопрос Сложно ли тебе было начать регулярно писать в дневник?
Не сложно. Чтобы помочь себе регулярно писать в дневник, стоит отбросить долгосрочные большие цели (запишу свою жизнь, напишу книгу, будет что передать потомкам и т.д) и сфокусироваться на краткосрочных.
Краткосрочно дневник работает как лекарство. Если у меня болит голова, и я знаю, что есть таблетка, которая вылечит головную боль — глупо это таблетку не выпить. В случае с дневником всё так же, только вместо головной боли — накопленный шум.
Дневник помогает посмотреть на прошедший день намного сложнее, чем «фух, наконец-то». И в процессе, когда я смотрю — в голове становится тише: выгружаются все накопленные переживания, незаписанные идеи и планы. Если в дне не хватило похвалы — я себя похвалю. Если произошли события, которые ещё долго не потеряют важность — запишу их во всех подробностях.
Писать в дневник — это не путь и не повинность, и даже не акт дисциплины, это — потребность. Поищите, какая потребность могла бы быть у вас?
Если сходу не находите — включите дисциплину на пару недел: раз в день садитесь на 10 минут перед белым листом и рассказывайте обо всём, что пришло в голову. Скорее всего потребность сама подтянется, ну или вы поймёте, что дневник вам пока не нужен.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
WiFi в общественных местах
Никогда не понимал людей, которые рассчитывают на вайфай в общественных местах. Дело даже не в надёжности, а в том, что в общественном месте хорошего сети не может быть в принципе.
Быстрый WiFi даже на 20 человек — это довольно дорогая штука: нужно обеспечить нормальное покрытие по всему помещению; нужно купить хорошее оборудование, чтобы один клиент с китайским фичерфоном не затормозил всю сеть своим клиентом из 99 года; нужно заплатить провайдеру кучу денег за нормальный канал, а интегратору — за то, что где-то сидит дежурный оператор, который приедет, когда это всё сломается.
Даже если средняя кофейня пойдёт на все эти затраты, максимум чего она добьётся — увеличения количества удалёнщиков, которые берут один фильтр-кофе за 150 рублей и сидят с ним весь день. Точно так же хороший WiFi не выгоден и аэропортам — люди выбирают их по цене билета и времени рейса, но никак не по качеству связи. Наверное, единственные учреждения, которым хороший вайфай может принести деньги — это развлекательные, типа стадионов, которые одновременно испытывают проблемы с сотовой связью и зависят от количества фоточек в инстаграме.
Кажется гораздо проще заплатить за дорогой тариф у сотового оператора, и платить так в каждой новой стране, которую вы посещаете. Наверное есть и исключения, вроде Канады с исторически дорогими тарифами, но в большинстве стран это совершенно не дорого.
Если вы используете интернет для работы, то за первый же день ваша покупка отобьётся. Если для развлечения — почему не бы не потратить на себя пару тысяч рублей?
10 книг по управлению проектами
Недавно в дискуссии (не в первый раз) натолкнулся на утверждение, что все книги по управлению рассказывают одинаковые вещи про софтскиллы, и по этому нет смысла читать больше одной.
Во-первых, это довольно категоричное обобщение, а с категоричными обобщениями в принципе плохо соглашаться. Во-вторых, я с ходу вспомнил 10 книг об управлении, в которых речь идёт не о софт-скиллах с повторением одинаковых мантр, а о конкретных, основанных на чём-то кроме личного опыта автора, теориях, которые действительно помогают в управлении людьми.
Вот мой список:
1. Ицхак Адизес —«Как преодолеть кризисы менедмента». О том как разные люди решают одну и ту же управленческую задачу разными способами в зависимости от изначального набора скиллов. И о том, что на разных этапах роста организации наборы скиллов и требования к людям тоже разные.
2. Питер Друкер — «Классические работы по менеджменту». Упрощённый сборник трудов самого умного менеджера в мире. Читать, чтобы понять роль управленца в организации.
3. Майкл Джордж — «Бережливое производство и 6 сигм в сфере услуг». Довольно простые книги о том, что KPI любого процесса — это стабильность и управляемость. И о том, как это измерить.
4. Нассим Талеб — «Антихрупкость». По каким принципам организации приспосабливаются к хаосу. И что вообще такое хаос и случайность.
5. Фредерик Лалу — «Открывая организации будущего». Как строить бирюзовые организации, чем они отличаются от консервативных управленческих моделей. Вечно актуально.
6. Александр Прохоров — «Русская модель управления». Чтобы прочитав предыдущие две книги не забыть, где живёшь.
7. Уильям Детмер — «Теория Ограничений Голдрадта». Набор упражнений и практик по теории ограничений. Если хочется лёгкого — перед ней прочитать оригиналы Голдрадта — «Цель», «Цель-2» и «Выбор».
8. Авинаш Диксит — «Теория игр». Здорово прокачивает стратегическое мышление.
9. Лоуренс Лич — «Вовремя и в рамках бюджета». Если выбирать единственную книгу по промышленному управлению проектами, то эту.
10. Клейтон Крисетсен — «Дилемма Инноватора». Из названия может показаться, что это книга для CEO крупных корпораций, но на самом деле она про то, чем маленькие компании отличаются от больших в области маркетинга.
——
Уверен, это далеко не всё. Если есть что посоветовать — кидайте в комменты, только не ставьте ссылки, а то антиспам-бот зарежет