audience statistics FEDOR BORSHEV

Since the beginning of the war, more than 2000 civilians have been killed by Russian missiles, according to official data. Help us protect Ukrainians from missiles - provide max military assisstance to Ukraine #Ukraine. #StandWithUkraine

Как хорошо оценивать задачи Когда речь идёт о хорошей оценке задач, многие представляют себе эксперта-сметчика с годами наработанной интуицией, который обложился доверительными интервалами и матмоделями, оценил в жизни 100 проектов и может за пару часов погрузиться в кодовую базу любого проекта. Наверное где-то такие люди и существуют, но я их ни разу не видел и ставлю под сомнение их тотальную необходимость. Конечно где-то есть проекты, которые можно сделать только с чёткой и точной оценкой, но среднему бизнесу (если это не аутсорс по фиксированной цене) от прорграммиста нужна не оценка, а предсказуемость. Как в стройке — содрал старые обои, и выясняется, что стены кривые. Закупил ламинат — понимаешь, что стяжку надо переделывать. Опытный прораб сначала проверит качество стяжки, а потом уже поедет в Леруа за материалом. А плохой — умолчит, положит как-нибудь так, а когда замки не закроются или пол начнёт скрипеть — будет делать вид, что так и должно быть. Применительно к программированию это значит две вещи. Первая — постоянно искать, где сейчас самая большая зона неопределённости и пытаться её снять. Делаем интеграцию с новым сервисом — сначала накидываем вручную запрос на основе данных из системы, а потом уже пишем оболочку. Меняем модель данных — сначала проводим миграцию на продовых (или максимально близких к ним) данных, а потом уже дописываем код под неё. Пишем код неделю в отрыве от команды — сначала мёрджим мастер. И т.д. Вторая — быть прозрачным. Видим риск, который не получается снять за 5 минут — сигналим бизнесу. Прошло 50% времени и не сделали 50% работы — сигналим бизнесу. Всё вроде бы идёт хорошо, но интуиция подсказывает, что будут проблемы — сигналим бизнесу. В большинстве своём даже такая минимальная прозрачность успокоит бизнес и создаст вам репутацию надёжного исполнителя. А матмодели оставьте людям, которые делают самолёты.

Мы сами виноваты в говнокоде Этот пост — ласт-колл на второй поток «Стать Тимлидом 2.0». 18 сентября в 16:00 MSK — встреча потока, где мы все знакомимся. Ещё можно успеть купить за свои деньги, а потом вернуть на работе по чеку. Большинство программистов, которые беспросветно сидят на легаси, обвиняют в этом свой бизнес. Типа мы бы и написали хороший код, да злые дядьки не дают — диктуют правила, давят сроками, не выделяют время на техдолг. Это не так. Бизнес, каким бы он ни был — довольно прагматичная система, которая умеет принимать решения. Если заставить бизнес выбирать между наймом людей или стагнацией — он выберет найм людей. Когда понадобится выбрать одного подрядчика из 10 доступных на рынке — бизнес опишет требования и выберет самого подходящего. Так почему же между работающей системой и вставшей колом разработкой, которая сама не может разобраться в своей сложности, бизнес часто выбирает второе, да ещё насильно заставляет программистов говнокодить сверху? Да потому, что он им не доверяет. Представьте, что у вас дома прорвало канализацию. Приходит сантехник, говорит «изян», и пропадает. Вызываете другого — тот жалуется на первого, обещает всё исправить и тоже пропадает. А из трубы-то льётся! Где-то после третьей итерации вы уже сами пойдёте перекладывать трубы хоть во всём доме — и пофиг, насколько эти трубы будут соответствовать правилам и стандартам: вам бы от запаха избавиться. Так и бизнес пишет руками программистов — просто, чтобы перестало литься. Легаси — это следствие пропасти между бизнесом и разработкой. Отсутствие этой пропасти — не гарантия чистого кода, но если разработка умеет говорить с бизнесом, то качество кодовой базы будет ограничено только профессионализмом программистов. Наш курс — как раз про то, как сузить эту пропасть, и приблизить программистов к бизнесу: научиться разговаривать с «той стороной», брать ответственность за сроки и решать проблемы с командой. Приходите

Не как у других: почему любят наши курсы Каждый второй человек, который приобрел курс в нашей Школе сильных программистов, в течение полугода покупает что-то еще. И большая часть из них приобретает в среднем 3-4 курса. Это высокий показатель, учитывая, что у нас нет широкого ассортимента курсов. Когда я спрашиваю, почему они возвращаются, чаще всего слышу: «Это полезно» и «У вас не так, как у других». Полезность понятна, но вот что именно они имеют в виду под «не так, как у других», расшифровать сложно. В прошлом году, участвуя в премии Digital Learning (об этом я писала здесь), я четко осознала наши отличия: подход, дизайн, тон общения. Тогда я подумала: «Вот в чем мы другие». Я даже сказала Феде: «Мы настолько отличаемся, что либо возьмем первое место, либо останемся за бортом». И мы победили. Однако меня не покидала мысль: разве только внешний вид и стиль могут объяснить, почему люди к нам возвращаются снова и снова, доверяя нам? На прошлой неделе я выступала перед аудиторией, состоящей в основном из людей, которые занимаются созданием образовательных продуктов. Рассказывая о нашей школе, о том, как и что мы делаем, я, кажется, поняла причину. Готовясь к выступлению, я осознала: мы погружаемся в контекст каждого ученика, и это влияет на процесс создания курсов. Сейчас поясню. На мой взгляд, многие курсы на рынке напоминают сложные академические книги. Ты читаешь — и страдаешь. Материал часто подан так, будто его слушатель должен обладать невероятной силой воли, чтобы абстрагироваться от всего и полностью погрузиться в обучение. Но курс не учитывает, что ты мог целый день писать код, провести стратегическую сессию или, устав, прийти домой, чтобы продолжать учиться. И если материал подан сложно, уже через 10 минут ты выдыхаешься. Или другой пример: на этой неделе ты активно вовлечен в обучение, но на следующей — отпуск или завал на работе, и вернуться к курсу уже не получается. И это не говоря о множестве других жизненных обстоятельств. При этом большинство из нас не учили эффективно учиться ни в школе, ни институте. Хоть много всего давно уже рассказали ученые. Взять хотя бы моего любимого Мортимера Адлера «Как читать книги» или супер полезный курс на курсере от Барбары Оакли. Мы же всё это стараемся учитывать: как в содержании курсов, так и в том, как они устроены, и в дополнительных материалах. Заранее даем ответы на вопросы, которые ученикам может быть неловко или страшно задать. Помогаем построить образовательный трек и создать безопасную среду, где можно ошибаться, пробовать и не чувствовать вину за то, что не дошел до конца курса. С нами людям комфортно. Поэтому около 70% наших студентов выполняют домашние задания и доходят до финала курсов, а затем возвращаются снова. Даже если курс сложный, требует много времени и усилий, люди готовы работать по ночам или брать отпуск, чтобы всё успеть. Я очень рада, что у нас так получается, и верю, что в будущем мы станем ещё лучше. Мы постоянно ищем новые способы сделать процесс обучения проще и эффективнее. Кроме того, что постоянно копаем тему обучения взрослых и залезаем даже в нейробилогию, привлекаем редакторов, чтобы становиться понятнее — я перманетно ищу возможность дотянуться до какой-то мировой звезды в индустрии. Из недавнего, пытаюсь попасть на закрытую лекцию Барбары Оакли, которая внезапно будет в Тбилиси этой осенью. Мой вывод такой: многие образовательные программы устроены так, будто их ученики — это суперлюди, которые могут без усталости и безошибочно двигаться к цели. Они требуют от нас полной самоотдачи, не учитывая реальных жизненных обстоятельств. Мы, напротив, показываем реальную картину: не требуем невозможного, а создаем условия, в которых человек сможет вносить реальные изменения в свою жизнь и работу. Двигаясь шаг за шагом, и в итоге — добиваться ощутимых результатов. Очень рада, что это сформулировала — под этим углом буду более сфокусированно смотреть в текущем потоке «Стать тимлидом». #фичи_курсов

Не мириться с плохими програмистами Удивительно, как круто бизнесы научились мириться с плохими программистами. Когда программисты не тянут, бизнес загоняет их в офис, вводит больше процедур и менеджеров, выстраивает большой HR-отдел, чтобы ещё быстрее нанимать. Но никогда не увольняет. На уровне компании очень тяжело проверять, насколько хорошо работает конкретный программист. С менеджерами понятнее: выполнил KPI или нет. С дизайнерами и редакторами понятнее — есть макеты/текст или их нет; стыдно за них, или норм. А вот с программистами пойди пойми, что он там наговнокодил, и почему сроки сорвал — потому что кодовая база говно, или потому что работать не умеет. Вот и делает бизнес то, что умеет — нанимает новых программистов. И избегает того, что не понимает — не увольняет слабых. В принципе, правильно — бизнесу ему надо деньги зарабатывать, а не программистов считать. Лучше больше заработать, чем меньше потратить. В таких компаниях забота об уровне программистов ложится на плечи энтузиастов-тимлидов, которые на месте видят производительность каждого. И хорошо, если у них хватает воли и ответственности увольнять бездельников и растить крутышей. Ну а там где энтузиастов нет, или у них не хватает сил — вполне спокойно удерживаются «мультиджоберы», которые спокойно справляются с двумя параллельными работами — явный признак того, что в индустрии что-то глобально не так. Я (почти) научился не мириться с плохими программистами в своих бизнесах. Но хочется что-нибудь сделать с этим глобально — как-то поменять окружающую среду, чтобы она перестала поощрять посредственность. Увы, не могу придумать ничего лучше, чем бухтеть про это в канале

Не имей 100 друзей, а займись делом Все важные задачи в жизни я решал в одиночку — поменять работу, жениться/развестись/жениться, вложить деньги, запустить бизнес, начать писать в телегу, открыть зарубежную компанию, много чего ещё. У меня никогда не получалось делегировать такие вещи друзьям или близким людям — только исполнителям за деньги. С привычкой делегировать задачи исполнителям, а не друзьям, мне очень повезло. Друзья, которые бескорыстно решают проблемы, создают взаимные обязательства. На сколько бы ни были такие обязательства гибкими и свободными — всё равно придётся решать проблемы этих людей, когда они появятся. Нельзя получить консультацию и не оказать консультацию самому, когда понадобится. Нельзя постоянно спрашивать у друга советов, где отдохнуть или куда вложить деньги, а самому не брать трубку. Нельзя взять денег на бизнес, а потом не решать этим бизнесом проблемы того, кто этих денег дал. История с взаимопомощью работала в первобытных крестьянских обществах: сегодня мы все ухаживаем за твоим полем, завтра — за моим. Сегодня я чиню твой трактор, завтра ты достаёшь им мою машину из грязи. В современном городском обществе это неактуально — машину починит сервис помощи на дорогах, денег даст банк, ментальные проблемы решит психотерапевт, а за профессиональной консультацией лучше сходить к эксперту. Конечно никто не отменял рекреационного эффекта от дружеской взаимопомощи — человек всё-таки существо социальное. Но если перестаёшь строить свою жизнь вокруг друзей — освобождается очень много времени для действительно важных вещей, которые делаются в одиночку.

Хард-скиллы или влияние? Мы открываем запись на второй поток обновленного курса «Стать тимлидом». Это — самый главный курс в школе, потому что он — не про знания, а про возможности. В начале карьеры мне казалось, что руководящие посты достаются самым умным. Типа шаришь круче всех за линукс — становишься главным сисадмином. Контрибьютишь в Laravel — начинаешь руководить ПХП-никами. Поэтому всё своё развитие я долго концентрировал вокруг хард-скиллов. В итоге потерял много времени и вообще чуть не бросил профессию. В какой-то момент я осознал, что чтобы применять хард-скиллы полученные тысячами жопочасов, нужно качать софт-скиллы. Нет никакой разницы, какую крутую архитектуру ты умеешь строить, если твоя работа — перекладывать JSON. Всем пофиг, как клёво ты понимаешь продукт, если тебя не зовут на встречи, где принимают решения. То есть лучше остаться без знаний, чем без возможностей. Имея возможности — получишь и знания. А имея знания, но не имея возможностей — так и будешь перекладывать JSON. Поэтому в курсе мы много говорим о том, как брать ответственность за происходящее вокруг. Ну и решать проблемы, которые с этой ответственностью приходят: — Определить круг обязанностей и понять, что бизнес от тебя хочет. — Выстроить отношения с бизнесом, чтобы тебя слушали. — Наводить порядок в команде, увольнять тех кто не справляется и нанимать новых. — Ну и находить на всё это время не за счёт друзей и семьи. Раньше я думал, что курс нужен только тем, кто собирается развиваться по менеджерскому треку, но как минимум половина писем полезны тем, кто твёрдо решил стать синьёр-помидором. Потому что они — про возможности. Поэтому, вопреки законам маркетинга, зову всех: если идёте по менеджерскому пути — берите «в тусовке» или выше. Если идёте по синьёр-помидорному пути или работаете в смежной профессии — берите самостоятельный тариф, вам его хватит. Стартуем 18 сентября, учимся 5 недель. До вечера воскресенья (25 августа) действует промокод

ST2F

на 10% скидки. Оплатить можно любой картой мира, как и по счету — если планируете учиться за счет компании. Посмотреть программу →

В любой непонятной ситуации пишу бекенд Как ни бросай программировать, а инженерный бекграунд до сих пор даёт о себе знать. Недавно сдавал отчёт по «всеобщему декларированию» в Казахстане. Открыл инструкцию, дочитал до пункта, что это можно сделать через кабинет налогоплательщика, в который нужно войти через ЭЦП — и полез настраивать. 3 (три!) часа продирался через проблемы, одинаковые для всего суверенного софта софта, что в России, что в Азии, что в Европе — адовый UI, отсутствие документации, полное отсутствие сообщений об ошибок и непобходимость перезагружать компьютер. В итоге разобрался, полез дальше читать инструкцию и понял, что этого всего можно было и не делать — оказывается отчётность можно сдавать через eGov (это госуслуги), или вообще через Kaspi (суперапп, одновременно банк, маркетпелйс и госуслуги, аналогов в России нет). То есть три часа я потратил зря — вся эти ЭЦП была никоу не нужна! А это были не просто три часа, а три часа напряжённой работы, после которой стоило бы сделать перерыв еще на три часа, а ещё лучше — поспать. Мораль простая — Федя, когда оказываешься посередине сложной инженерной задачи, вспомни пожалуйста, как кто ты её решаешь? Если как программист или сисадмин — немедленно остановись, скорее всего рядом есть кто-то, кто сделает это лучше и дешевле тебя. Ну а если ты решаешь инженерные задачи как предприниматель, точно ли ты хороший предприниматель?

Мне сложно осуждать таких программистов — я и сам ненавижу работать с плохим кодом. И в fands мы легаси не берём, если не видим способа быстро спрятать его в коробочку абстракций. Но кажется, если бы у владельцев бизнеса был инструмент, который мешает программистам городить новые абстракции поверх старых, а заставляет их чинить то, что есть, стоимость владения такими решениями была бы существенно меньше. И пусть код в них был бы намного скучнее — зато он закрывал бы бизнес-задачи, а люди, которые им управляют, были бы счастливее за счёт отсутствия на работе авралов, вызванных очередным джуном, который не понял очередную абстракцию. Иногда мне кажется, что для этого нужен CTO уровня ДХХ. Иногда кажется, что достаточно просто любить свою работу. Ой, опять пора таблетки от Альцгеймера пить, побегу, простите.

Дедовский пост про Линукс Недавно ковырял настройки сети в свежей Ubuntu и грустил — с точки зрения Developer Experience Линукс окончательно скатился до уровня современного фронтенда. Вот пара вещей, с которыми я столкнулся только за один день: —

netplan

, хоть и конфируется на YAML не принимает файлы .yml, только .yaml. Кладёшь .yml — получаешь неработающую сеть. — Директория

/etc/if-up.d/

, в которую раньше можно было складывать скрипты, запускающиеся про поднятии интерфейса, всё ещё существует, но не работает — скрипты не запускаются. —

netplan try

— классная штука, которая пробует новые сетевые настройки, и при обрыве соединения откатывает их назад — не откатывает настройки назад. В 22 убунте откатывала, в 24 — перестала —

systemctl

при неудачной попытке запустить сервис не выдаёт ошибку, а говорит «читайте журнал через journalctl».

journalctl

на одно сообщение об ошибке показывает 10 строчек бойлерпдейта, одинакового для всех сервисов. Почему бы сразу не показать мне нужную строчку из

systemctl

? Не знаю. И это я ещё не говорю о менее зрелых с точки зрения DevEx инструментах, вроде Wireguard, у которого есть две утилиты, которые парсят один и тот же конфиг, с одинаковым названием и структурой, но в разных форматах:

 wg 

понимает только простой конфиг, а

 wg-quick 

— расширенный, и если скормить

 wg 

конфиг от

 wg-quick,

то

 wg 

молча упадёт, сказав что у него ошибка в конфиге, и ни словом не упомянув о двух форматах. К такому говну мы пришли путём, характерным не только для опенсорса, но и для программистского мышления в целом. Сейчас допью таблетки от Альцгеймера и расскажу историю. Сначала был

 ifconfig

, который в одну команду конфигурировал сетевой интерфейс. Чтобы сохранять настройки после перезагрузки, его запускали из /etc/rc.local. Кому надо было гарантировать порядок и названия интерфейсов — колдовали с modprobe. Жили так довольно долго: где-то, например во FreeBSD, это писали в

 /etc/rc.conf,

где-то, например в мини-дистрах для специальных задач, вообще никакого стандарта не было. Потом пришёл кто-то, кому это не нравилось, и изобрёл

 /etc/network/interfaces.

Сисадмины выучили ещё один DSL (благо в те времена таких языков было немного, и все они были маленькими), а автор с радостью решил несуществующую у реальных юзеров проблему — теперь все настройки сети хранились в одном месте. Правда не совсем удачно — другим программистам было тяжело парсить этот DSL, потому что настройки могли лежать в /etc/network/interfaces.d, скрипты после поднятия интерфейсов запускались непойми откуда, а как сохранять порядок интерфейсов — было вообще непонятно. У юзеров этих проблем не было — у них болело, чтобы radioethernet, который недавно переименовали в WiFi, работал без необходимости вкуривать в wpa_supplicant, который с

 /etc/network/interfaces 

никак не взаимодействовал. Но кто же их спрашивает-то. Здесь бы нам всем остановиться, добавить в стандарт вайфай, и протащить его в другие дистры (или затащить в дебиан стандарт из других дистров). Лет за 10 и пару мажорных апдейтов такую штуку можно было бы довести до рабочего состояния — чтобы и WiFi через GUI конфигурировать, и на серверах было понятно, что куда писать. Но старые абстракции чинить никому не хочется — лучше нагородить новых поверх. Так появился

 NetworkManager.

У него тоже нашлись несуществующие, но при этом нерешаемые проблемы — и появился

 systemd-networkd.

На удивление, и у него нашлись нерешаемые проблемы, к тому же

 NetworkManager 

почему-то отказался умирать, поэтому пришлось изобретать ещё одну абстракцию поверх их обоих —

 netplan.

Вероятно, я пропустил пару абстракций, потому что уже лет 10 не слежу за линуксом, но суть ясна — программисты, вместо того, чтобы засучить рукава и чинить то, что сами наговнокодили, предпочитают объявлять это всепрощающим словом «легаси» (и от кого же вы это унаследовали?) и делают поверх абстракцию. Абстракция течёт, превращается в легаси, и поверх неё пишут ещё одну абстракцию. И во всём этом процессе никто не думает про опыт пользователей — главное, это написать всё заново и «чисто».

#вопрос Расскажи, как ты пользуешься чеклистами? Для себя или в команде? Приведи самые удачные примеры. В чистом виде чеклистов у меня немного — в основном это довольно простые и повторяющиеся вещи: сборы в поездки, выдача и удаление доступов, всякие денежные операции, которые пока не получилось автоматизировать или делегировать. Командные чеклисты есть у нас в школе — это, к примеру, запуск новых потоков курсов, но это тоже довольно банальная штука. Свои чеклисты я храню в Bear по тегу «чеклисты» и открываю, когда попадаю в соответствующую ситуацию, школьные — лежат у нас в бейскемпе. Гораздо больше у меня «памяток» — это когда я беру и собираю в одну заметку вещи, которые могут понадобится в повторяемом сценарии. К примеру у меня есть памятка «домашка», которую я открываю в конце каждого курса в школе, когда мы выписываем дипломы — там и порядок действий, и вещи, которые могут понадобится: к примеру сниппеты SQL-запросов (да, мы это до сих пор не автоматизировали). SQL — вообще довольно богатая тема: у меня около 10 заметок с разными сниппетами, собранными по теме: храню там шаблоны запросов, которые пока не доехали до дешбордов, вроде «посчитать количество платных учеников в школе за последний месяц» и т.д. Конечно, гораздо лучше, когда чеклисты реализует не человек, а машина. К примеру клёво не держать чеклист со списком серверов, чтобы удалить доступ уволенного сотрудника, а добавить его в условный

 retired_guys.yml.

Или не заполнять каждый раз форму в банке для перевода денег, а найти банк, который не требует такой формы. Последнее — больной пример из жизни: самый большой чеклист в моём в Bear был посвящён тому, как заполнять формы в казахстанском банке ЦентрКредит. Интерфейсы у них были родом из начала 2000-х, и всё это осложнялось тем, что они периодически не работали. Дать доступ кому-то, чтобы делали это за меня, я не смог. Интегрировать их с условной 1c, чтобы она туда всё выгружала — тоже не осилил. Так и сидел с километровым чеклистом. В какой-то момент вся эта кривизна меня настолько достала, что я купил билет в Алмату и поменял ЦентрКредит на Jusan. Вернулся домой и сразу же удалил нафиг тот позорный чеклист, и теперь экономлю по полтора часа в месяц. Кажется, самый главный скилл, связанный с чеклистами — это умение находить у себя повторяющиеся сценарии, которые можно этими чеклистами покрыть. И не стесняться тратить время на них, а ещё лучше — вообще избавляться от таких операций. Это был традиционный #вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Управлять своим временем В жизни я несколько раз менял направление деятельности — был программистом, менеджером, CTO и наконец, предпринимателем. Единственный скилл, который я пронёс через все эти роли (и вынужден был каждый раз его улучшать) — это управление собственным временем. Я говорю не только о мифической «продуктивности» — скорее о том, распределять свои 24 часа, чтобы выполнять все взятые обязательстваa: перед собой, своим здоровьем и бизнесом, перед семьёй и друзьями. Жутко бешусь (и сразу увольняю из своих компаний) людей, которые сознательно отказываются от этого скилла. Увы, наша индустрия буквально подталкивает к тому, чтобы делегировать управление временем. Почему-то у нас принято выстраивать отношения с программистами, как с представителями реагирующих профессий, вроде пожарных или врачей скорой помощи — сажать менеджера/диспетчера, чтобы он отвечал за эффективное распределение их времени. Бывает, этого диспетчера прячут за слова об удалёнке или свободном графике — но суть остаётся: над программистом всегда стоит человек, который тем или иным образом распределяет его время. Так вот, этот человек будет постоянно говорить вам «делай работу», но никогда не скажет «напиши продукт уровня nginx» или «потестируй гипотезу для своего продукта». А когда вы начнёте делать что-то подобное без санкции — доброго менеджера рядом не будет. Придётся самостоятельно выбирать что делать, а что — нет, отличать сигнал от шума, поддерживать трезвое сознание и твёрдую волю. И если вы привыкли жить в уютной среде и делегировать эти жизненно важные функции руководителю — ваш гениальный личный проект в лучшем случае разобъётся о нехватку времени или выбор фреймворка, а в худшем — никогда не запустится, потому что вы бесконечно будете заниматься его разработкой, не умея отличать процесс от результата. Глупо тратить по 8 часов в день, выполняя приказания доброго менеджера. Гораздо умнее использовать эти 8 часов, чтобы прокачивать уровень ответственности — так будет доволен и работодатель, и вы, когда от него уйдёте.

А я доделал! В общей сложности потратил часов 20, зато получил код, который ещё очень долго не потребует никакого обслуживания, потому что самая сложная технология в нём — это sentry, которую через пару месяцев я тоже выпилю. Даже линтеров, кроме prettier, нет! Самым непривычным было заставить себя говнокодить — я в шести местах скопировал один и тот же код для пейджинации, и в трёх местах сделал почти одинаковое хождение в бекенд. Зато этот код сможет починить кто угодно даже после ядерного апокалипсиса. А функциональность туда добавлять никому не нужно — как показывают прошедшие 10 лет, скорее я придумаю что ещё оттуда убрать, чем добавлю что-то новое. Смешно, что производительность сайта по Lighthouse выросла до 100 баллов — достаточно было просто отказаться от SPA. Ещё смешнее, что в два раза упало время до первого байта, хотя ни объём данных, ни способ хождения в API никак не поменялись. Кажется, Тонский прав и мы все идём куда-то не туда.

Пару месяцев назад я выкладывал сюда список профессиональных блогов в телеге — в нём было много не профессиональных блогеров, а людей, у которых стоит поучиться новому. Вот что с тех пор они написали: — Арина Хромова рассказала, сколько зарабатывают российские топы (спойлер — дофига, надо было вкатываться в MBA вместо айтишечки). — Алексей Подклетнов рассказал, как чувак заработал денег на том, что заспамил спотифай 24 000 песен про чистку зубов, поход в магазин или про колумниста New York Times. — Максим Спиридонов — про простой фреймворк, с помощью которого можно увольнять слабых людей. — Денис Кутергин обидно (но честно) рассказал, что хороший селлер на маркетплейсах выстраивает ВЭД, логистику и финансы, исследует рынки и закупает трафик, а плохой — ругает вайлдберрис за повышение комиссии. — Ваня Замесин — про семейную терапию. Подпишусь под каждым словом. Почему-то у о семейной терапии принято говорить так же, как лет 10 назад говорили о личной — примерно никак. — Павел Комаровский — о том, надо ли страховать жизнь. — Александр Горный рассказал грустную историю, как могут выглядеть продажи кибербезопасности. Хоть там и нет ни одного имени реального человека — легко поверить. — Он же в другом своём канале рассказал, как из макдональдса убрали AI-помощника, потому что он рекомендовал людям добавить бекон в мороженое. — Егор Данилов рассказал, как он работая в Юле боролся с мошенниками, покупая у них по 500 рублей инструкции, как скамить лохов (респект за ижевское образование).

Джуны и GPT-ассистенты Всё чаще встречаю джунов, которые плотно сидят на GPT-ассистентах, типа Copilot chat. Спрашиваешь доброго робота «как добавить JS в Джанго-алминку?» и получаешь готовый код, который скорее всего даже заработает. Сразу чувствуешь, что будущее наступило. Только вот будущее это — не для вас, увы. Довольно мало ценности в том, чтобы переводить просьбы бизнеса в вопросы роботу — в какой-то момент такой посредник, как вы, станет просто не нужен. Профессионального роста от такого программирования тоже немного. Самое главное, что должен делать джун — это учиться: разбираться, как устроены библиотеки и как мыслят их авторы, учить языки, учиться учиться а конце концов. В общем, планомерно нарабатывать свои 10 000 часов за счёт работодателя. Час, потраченный на изучение документации — это час, вложенный в ваш профессионализм. Час, потраченный на попытки починить GPT-код — это просто час, который вы продали работодателю, не получив ничего, кроме денег. Доверяйте машине только те активности, которые не прокачивают лично вас — нагенерить тестов, крудов или семпловых данных. А для всего остального — читайте старую добрую документацию и скорее становитесь мидлами.

#вопрос Как доказать в цифрах, что хорошие инженерные практики полезны для бизнеса? Я знаю, что хорошие инженерные практики, вроде автоматического тестирования, актуальной документации и код-ревью, облегчают жизнь разработчикам. Так же я верю, что они делают разработку быстрее, то есть, несут прямую выгоду бизнесу. Но вот как построить метрику, которая покажет прирост производительности (или пространство для этого прироста) — не знаю. Можно ли это вообще как-то измерить? Или тут только и остаётся, что оперировать таким эфемерными вещами, как комфорт разработчиков и привлекательность для кандидатов? ——— Увы, я не знаю ни одной метрики, которая помогла бы за одну (или пять) встреч договориться с бизнесом про инженерные практики. Конечно можно порассуждать о time2market и velocity, QA-метриках или SLA, но прямой связи вы не докажете. А если с вами начнут спорить — вы ещё и навредите себе или попадёте в аналитический паралич, пытаясь измерить то, что не важно. Чтобы договорится с бизнесом об инженерных практиках, придётся выстраивать с ним отношения. Представьте себе главного инженера на стройке — вряд ли он доказывает инвесторам, что рабочие должны носить каски. Ваша цель — стать таким же инженером: вам должны верить. Верить обычно начинают людям, которые показывают результаты и хорошо умеют слушать. Каких от вас ждут результатов — лучше узнать у руководителя. Скорее всего это закрытые задачи или те самые метрики. Чтобы достичь метрик, изменения возможно, придётся «явочным порядком» — не ждать, пока вам дадут добро на внедрение практик, а придумывать, как ускориться прямо сейчас. В общем сначала — доверие, а потом практики. Ну а чтобы научиться слушать бизнес — приходите к нам на Стать Тимлидом, там целый курс про это. Это был традиционный #вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Генераторы статичных сайтов не нужны Очень хочется ответить на комментарии «почему ты не взял static site generator типа Jekyll, это же так просто?». Статичный сайт — это НЕ просто. Это настолько сложно, что блог с ним становится обузой. Во-первых, генераторы статичных сайтов не удовлетворяют требованиям из предыдущего поста — в них очень много движущихся частей. Мне в любом случае нужно как-то закидывать туда свои шаблоны — а значит ставить среду разработки, которая наверняка устареет через пару лет. Нужно сохранить текущую структуру урлов — а генераторы статичных сайтов в вынуждены делать негибкие роутеры, по которым можно построить всю структуру сайта в момент генерации. В конце концов, результат работы статического генератора нужно куда-то выложить и настроить CI. В решении каждой проблемы по отдельности есть чемпионы. Jekyll можно обновить одним коммитом из интерфейса гитхаба, а у hugo среда разработки c нулём зависимостей. Но чаще генераторы создают свои специфичные проблемы — типа hexo, у которого в API сложнее разобраться, чем в API нормального банка. Но главное даже не в сложности. А в том, ради чего люди вообще ведут блог. Мне блог нужен, чтобы туда писать, а не пробовать новые инженерные идеи. Я хочу, увидев опечатку на сайте, открыть с телефона админку и поправить её. Хочу верстать в две колонки и перетаскивать картинки мышкой. Хочу дать доступ к блогу другим авторам, чтобы они выкладывали свои тексты у меня — мы так публикуем анонсы fands, пока не сделали нормальный сайт. Всё это очень сложно сделать в статичных генераторах — by design. Статичный сайт никак не делает блог лучше, а скорее даже наоборот, усложняет жизнь за счёт своего оверхеда. Так же как React не ускоряет вёрстку HTML, а RabbitMQ не улучшает структуры данных. Если отбросить самолюбие автора, останется всего одна проблема, которую решают генераторы статичных сайтов — как переложить сложность со времени эксплуатации на время сборки. И я не могу представить себе проект, где такая проблема существует.

Как и любой уважающий себя дед, я веду стандалон-бложек. Начал лет 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 и устрою стрим.

#вопрос Понравилось, как ты выступал на SaintTeamLeadConf 2024. Расскажи, как ты готовишься к публичным выступлениям? Вообще мне кажется, самое главное в публичных выступлениях — это хороший тренер. Своего могу порекомендовать — это Венера Шакирова, @oh_venera. Но вопрос задали всё-таки мне, поэтому попробую ответить, как это делаю я. Подготовку начинаю примерно так же, как к лонгридам в школе — как только принято решение о том, что выступление будет, начинаю жить с темой в голове. Буквально — завожу в Bear заметочку, и всякий раз, когда мне приходит любая мысль по теме — я её моментально записываю. Важно записывать вообще всё, что приходит в голову — тезисы, метафоры, идеи структуры. Пока носишь такие вещи в голове — они все кажутся очень красивыми и логичными. А когда записываешь и возвращаешься к ним через день-два — смотришь совсем другими, критическими, глазами. Через 2—3 недели, когда набирается достаточно «руды» — можно начинать наговаривать. Важно ни в коем случае не писать себе текст, а именно говорить — письменная речь отличается от устной примерно как китайский язык от румынского. Во-первых, когда говоришь, совсем по-другому работает мышление. Во-вторых — стройный текст никогда не будет звучать хорошо если его просто озвучить, как и стройная и приятная речь, будучи записанной, скорее всего превратится в кашу. Чтобы понять о чём я, почитайте любую транскрипцию подкаста (вот первый попавшийся): текст кажется странным, много слов, которые кажутся лишними и мусорными, хотя в речи, наверняка, звучали норм. Наговаривание — процесс итеративный. Я записываю выступление в CleanShot, и прослушиваю, добавляя мысли, которые нравятся и выкидывая те, которые не нравятся. Выкидывать — важнее: я люблю делать короткие выступления, мне нравится оказывать уважение зрителям, не тратя их время на то, чтобы донести мысль, которую я просто недостаточно поджал. Идеально провести 10-15 таких итераций на один доклад, но в реальной жизни получается немного меньше: всё же садиться и болтать на камеру — довольно тяжело, это занимает кучу времени и не получается заниматься этим нигде, кроме тихого кабинета. Ну а подача, интонации и жесты просто приходят со временем. У меня начало что-то получаться где-то в районе пятого выступления, подготовленного таким образом — я начал осознавать, что у меня получается лучше, а что — хуже, начал следить за дыханием и телом, приходить на доклад с правильным настроем. Это был традиционный #вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Мы с клиентом запустили стартап. Он помогает малым локальным бизнесам — кофейням, барбершопам и другим — зарабатывать по модели, которую применяют Amazon и Яндекс. Сделали мы это с помощью технологии PWA — создали практически полноценное мобильное приложение — с оффлайном, пуш уведомлениями и иконкой на рабочем столе, используя только веб технологии! А при запуске чуть не попали в замес борьбы Apple с Евросоюзом. В новой статье делимся, как у нас получилось успеть всё это за 6 месяцев при том, что требования постоянно менялись (стартап!) Хотите запустить проект с нами? Пишите в личку @samatg или оставляйте заявку на сайте.

Рабочее молчание Текст — это основа моей работы. По большому счёту всё, что я делаю — это текст. Поэтому мне важно, чтобы всё, что я пишу, достигало адресатов. Чтобы сообщения читали внимательно и в трезвом состоянии ума. Хочу, чтобы даже посты в этот канал читали вдумчиво. Для этого я внимательно слежу за соотношением сигнала к шуму во всём, что пишу. К примеру я не сижу в рабочих чатах потому, что там высокий уровень шума — то, что я туда напишу, может в этом шуме потеряться. В почте и задачнике я избегаю сообщений, которые не несут смысла — чтобы если кому-то пришло сообщения с именем Fedor Borshev в отправителях, они знали, что там нет ничего не значащего «спасибо». Соотношение сигнала и шума важно не только в личной коммуникации. К примеру любой руководитель, который уменьшит в собственной команде количество шума и добавит количество сигнала — получит более вдумчивых и внимательных сотрудников. Думаю со мной согласятся все, кто когд-нибудь сидел в рабочем чате, где решают личные вопросы, а важные уведомления и новости сыпятся вперемешку с сообщениями от ботов по поводу заваленного CI в пуллреквесте от джуна. Рабочее молчание гораздо ценнее, чем рабочее общение — когда люди не тратят силы на разгребание шума в поисках сигнала, сил на полезные дела остаётся гораздо больше.

Хвастаюсь! Это первые отзывы после недели обучения на третьем потоке «Анализа Систем». Как обычно, каждый новый поток приносит кучу новых задач в беклог — и по контенту, и по LMS. Но приятные отзывы помогают их делать :-)

Среди программистов принято гордится сложностью своих решений — типа поставил Кафку и рассказываешь об этом на конференции, не упоминая ни слова о том, какую бизнес-проблему ты ей решил. А вы видели где-нибудь ещё профессию, в которой принято гордиться сложностью своих произведений? Может писатели, которые гордятся, какую непонятную книгу написали? Или туристы, которые гордятся тем, что тащат в рюкзаке 10 лишних килограммов? Наверное с ходу могу вспомнить только автомобильных инженеров — те тоже любят делать трёхцилиндровые двигатели, сенсорные переключатели и двери без ручек. Я догадываюсь, откуда это происходит — помню, когда мне было 13 лет, мой преподаватель по информатике показал, какую сложную программу на 50 экранов он написал. Конечно я захотел так же, и потом долго думал, что чем круче программист, тем более сложные штуки он делает. К тому же 50 экранами гордится гораздо легче, чем 3, которые решают ту же задачу. Хочется, чтобы книги и вайтишные курсы с самого начала объясняли будущим джунам, что профессия наша — сервисная, и для успеха надо не наворачивать дополнительной сложности, а наоборот, решать запросы бизнеса с минимально возможной сложностью. И что умные технологии надо учить не для того, чтобы хвастаться в резюме, а чтобы уметь их не притаскивать, когда не надо. Старею, похоже

Невозвратные билеты Давно догадывался, что с невозвратными авиабилетами что-то не так, а сейчас посчитал и офигел. Стыдно сказать, но за последние три года, периодически пользуясь невозвратными билетами на самолёты и бронированиями отелей, я потерял гораздо больше, чем 20% от всех затрат на отели и самолёты, которые в принципе совершил. И это не говоря о ситуациях, когда я вынужден был подстраивать свои планы под бронь только потому, что было жалко вернуть за неё деньги. Разница между обычным авиабилетом и невозвратным — как между обычным опционом и бинарным. В первом случае мы покупаем право совершить перелёт, а во втором — обязанность. Вне зависимости от того, понадобится перелёт или нет — отказаться от него стоит столько же, сколько мы за него заплатили. Купил невозвратный билет за 100 тысяч? Опоздать в аэропорт стоит 100 тысяч. Заболеть стоить 100 тысяч. Опоздать на стыковочный рейс по вине другой авиакомпании — тоже 100 тысяч. Можно, конечно, как-то побороться и вернуть хотя бы часть денег, но это точно не то, чем хочется заниматься в деловой поездке или отпуске. Так что меняю правила покупки билетов: — Никогда не покупать невозвратных тарифов. — Билеты туда и обратно брать в разных бронированиях. — Не пользоваться агрегаторами для покупки билетов. — Не летать лоукостерами.

Лучший Курс По Питону от Никиты Соболева Редко публикую здесь чужой контент, но всё, что делает Никита Соболев вокруг питона точно стоит упоминания. Никита начал делать фундаментальный курс — выкладывает на ютуб видосики, где до косточки разбирает одну конкретную тему. К примеру есть отдельное видео про bool и отдельное про int, и даже видос на 25 минут про плюс. Каждый видосик разбит на 3 части — для джунов, мидлов и синьёров. Сейчас Никита снял всего 4 выпуска, и я очень хочу, чтобы он не останавливался: мне, как владельцу галеры, очень приятно было бы принимать на работу джунов, которые относятся к языку с такой же любовью и обстоятельностью, как это делает Никита в своих видосах. В общем переходите по ссылкам и подписывайтесь на канал, а лучше — ещё и на бусти, там есть тариф за 100 рублей в месяц.

Рассказать о вакансии в баре Удивительно, но очень многих людей охватывает ступор, когда перед нами встаёт простая задача — текстом рассказать о компании, в которой мы работаем. В итоге получаются вымученные, ничего не рассказывающие вакансии из воды. Первая проблема — безликие, ничего не говорящие утверждения, типа «бекенд на node.js», «проптех для США». Проптех может оказаться как скучной CRM для риелторов, так и экосистемой, которая закрывает все потребности от выбора и покупки квартиры до обещания с арендатором, да ещё и с высокой нагрузкой от доски объявлений. Представьте сами, куда вам больше хочется откликнуться — на безымянный бек на ноде или подробный рассказ с версиями TS, процентами тестового покрытия и парой слов о способе коммуникации сервисов? Вторая проблема — шаблоны, которые люди копируют друг у друга, все эти «дружные коллективы». Это же такие же пустые фразы: для кого-то дружный коллектив — это команда, которая дружелюбно даёт обратную связь, для другого эти слова могут означать еженедельные походы в бар, для третьего дружелюбная команда — это там, где не спрашивают за пропущенные дедлайны. При этом, если человек, который в вакансиях пишет «динамично развивающийся», сядет за столиком в баре и начнёт рассказывать о компании своему товарищу — рассказ получится совсем другим: с подробностями (и без нарушения NDA), вкусностями, плюсами и минусами. То есть нормальный текст. Так получается потому, что вакансию воспринимают как заклинание, которое нужно кастануть, чтобы получить кандидатов. Я так в школе писал сочинения — если накастовать в тетрадке заклинания из сборника «100500 сочинений», то учитель отстанет. Так вот, вакансия — это не школьное сочинение, и GPT тут не помогает. Самый хороший способ написать нешаблонную вакансию — это по прежнему сесть рядом с товарищем в баре и записать всё, что вы хотите ему рассказать. В итоге получится простой рассказ о компании на человеческом языке, который заметно увеличит конверсию.

Ласт-колл на Анализ Систем В четверг начинаем обучение на третьем потоке «Анализа Систем» — фундмаментального курса о том, как принимать архитектурные решения, слушая при этом бизнес. Я много уже писал о нём, поэтому не буду повторятся, просто поскролльте вверх. Если сомневаетесь — прочитайте программу и отзывы студентов.

Количество подписчиков == оборот бизнеса Задумался тут, что количество подписчиков в телеге — это как оборот у бизнеса. Почему-то предприниматели, когда рассказывают о своём бизнесе, обязательно меряются оборотами, но никто не говорит о маржинальности и прибыли. Допустим у кого-то бизнес с оборотом 500 миллионов рублей в год, из которых 200 уходит на закупку товаров, 200 на зарплаты, а 95 — на обслуживание кредитов. Получается внушительная цифра, но вот прибыли не много. Или возьмём бизнес в 10 раз меньше — 50 миллионов в год, о при этом затрат у него только 10 миллионов. Второй бизнес хоть и выглядит скромнее, но гораздо более прибыльный. Я-то уж точно выберу второй. Так же и с количеством подписчиков в телеге. Есть каналы с десятками тысяч людей, которых читает от силы 1000 человек. И наоборот, бывают каналы по 2000 человек, где просмотров больше, чем подписчиков. Среди SMM-щиков этот показатель называется уровнем вовлечённости — средний процент просмотров относительно общего количество подписчиков. Но на самом деле уровень вовлечённости — тоже не самый полезный показатель. Гораздо важнее смотреть, насколько канал решает задачи, которые перед ним поставил автор. Через эту призму уровень вовлечённости и абсолютные цифры просмотров становятся важны только для брендовых каналов или медиа — там важны охваты и продажа рекламы. А для простых ребят, которые ведут канал, чтобы высказаться, получить новые контакты или полезные комментарии, гораздо важнее качество аудитории: насколько людям интересно читать и отвечать. Если канал предлагает какой-то продукт — нужно смотреть, какому проценту аудитории этот продукт может быть полезен. К примеру ютуберы с миллионными каналами зарабатывают с рекламы вместо своих продуктов потому, что их миллионы — это гетерогенная масса случайных людей, из которых не получается выделить когорту, достаточную, чтобы собрать ценный продукт, который приносит деньги. Сравните две крайности — у Тонского маленький канал с супер-интересными срачами в комментах, а у Лебедева — гигантская площадка медийного уровня, но вот услуги студии он там давно не продаёт.

А давайте поговорим об этом? В четверг, в 16:00 MSK, говорим с Антоном про роль архитекторов в компаниях, и о том, что проектирование — это про бизнес, а не про втыкание кешей и кафок. Подробной программы нет — просто соберёмся в телеге. Заодно расскажем, чего ждать на третьем потоке Анализа Систем, зачем на него идти, а зачем — нет, и поотвечаем на вопросы.

System Design на собеседованиях в большие компании наносит больше вреда, чем пользы. Алгоритмы хотя бы не заставляют делать ничего плохого — от того, что ты научился на бумажке находить пересекающиеся интервалы или обходить графы, ты хотя бы бизнесу не навредишь. А вот программист, который профессионально умеет городить сложные системы на ровном месте — навредит, особенно когда ему ещё на этапе собеседования показывают, что компания именно этого от него и ждёт. Системы с собеседований никак не связаны с реальными бизнес-требованиями: ведь собирать их и осмысливать явно дольше, чем длится время собеседования. Да и ценность хорошего архитектора не в том, чтобы делать сложные вещи, а в том, чтобы придумывать простые, когда бизнес настаивает на сложных. Мы запускаем третий поток курса «Анализ систем», который как раз об этом — как собирать бизнес-требования и делать максимально простые системы, которые их выполняют. Для этого мы много говорим о стратегическом анализе бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций, писать документацию. Изначально мы задумывали курс ради четвёртого урока, в котором мы дали пошаговые рекомендации по распилу монолитов, но сейчас поняли, что гораздо важнее мета-навык — умение слушать бизнес и не делать лишнего. Стартуем 13 июня, учимся 5 недель. Учиться рекомендуем в тусовке — наблюдая за чужими домашками, вы вынесете из курса гораздо больше знаний, чем если просто прочитаете материалы. До вечера четверга действует промокод

SAD10

на 10% скидки. Если вы принимаете даже самые маленькие решения по организации кода или взаимодействию систем в организации — ждём вас на курсе. Если хоть чуть-чуть общаетесь с бизнесом — тоже. Джунам на курс рановато. Если сильно верите в себя — берите не выше самостоятельного тарифа.