Выступление с Saint Teamlead Conf 2024 — рассказываю о двух профессиональных путях. В бюро их называют «Маги» и «Полководцы», мы в школе используем метафоры «Хакеры» и «Лидеры»:

Клёво затаскивать проекты. Запускать обещанное в срок, выстраивать для этого понятные планы и чёткую коммуникацию. Выбивать команде самые удобные инструменты. Договариваться с заказчиком, придумывать как срезать углы или наоборот, сделать больше работы, принеся больше пользы.

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

Когда затаскиваешь проекты — растёшь. Учишься делать это эффективнее, чужими руками, а потом и руками тех, кто сам делает это чужими руками.

Когда затаскиваешь людей — просто тратишь время на то, чтобы принести результат.

С 2015 года я вёл учёт личных расходов — каждый понедельник садился, открывал банковскую выписку и разносил все платежи за прошлую неделю по категориям — еда и хозяйство, одежда, развлечения и т.д. Иногда пропускал неделю, один раз — пропустил целых три. В 2024 году, спустя ровно 9 лет после начала, я перестал это делать.

Причина в том, что я за 9 лет не принял ни одного решения на основе данных о расходах. Что толку знать, что каждый месяц я трачу на жильё 1500 евро, если принимая решение об ипотеке, я и так могу легко посчитать стоимость всех арендных платежей? Что изменится от того, что в прошлом месяце я потратил на еду 700 евро вместо 400? Зачем знать, сколько обходится автомобиль, если идиоту понятно, что такси в Москве стоит дешевле?

Если я не принимаю решений, то смысла в этих расчётах нет. Разве что в процессе: садишься записывать расходы, и как бы 20 минут напоминаешь себе — все траты предсказуемы, ни одна копейка не уйдёт без твоего ведома. Как мантра.

Но это же неправда! Завтра могут заболеть родственники, центробанк может опустить ставку, я захочу сделать идиотски дорогой подарок супруге, сосед сверху зальёт квартиру, или я сам залью квартиру соседу снизу. Контроля над этим у меня нет.

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

В октябре 2024 года прочитал в Алматы короткий вводный доклад о том, чем полезен DevEx, и как он вообще работает. Если никогда не слышали — посмотрите, если слышали — посмотрите школьный курс.

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

• netplan, хоть и конфируется на YAML, не принимает файлы .yml — только .yaml. Кладёшь .yml — получаешь неработающую сеть.
• Директория /etc/if-up.d/, в которую раньше можно было складывать скрипты, запускающиеся про поднятии интерфейса, всё ещё существует, но не работает — скрипты не запускаются.
• netplan try — классная штука, которая пробует новые сетевые настройки, и при обрыве соединения откатывает их назад — не откатывает настройки назад. В Ubuntu 22.04 откатывала, в 24.04 — перестала.
• systemctl при неудачной попытке запустить сервис не выдаёт ошибку, а говорит «читайте журнал через journalctl». journalctl на одно сообщение об ошибке показывает 10 строчек бойлерпдейта, одинакового для всех сервисов. Почему бы в момент ошибки не показать мне нужную строчку из systemctl? Не знаю.

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

К такому состоянию дел мы пришли путём, характерным не только для опенсорса, но и для программистского мышления в целом — вместо того, чтобы чинить неработающие вещи, мы любим прятать их за фасадами абстракций. Давайте посмотрим, к чему это приводит, на примере развития способов настройки сети в Ubuntu/Debian.

Когда-то давно сеть настраивали командой ifconfig, которая, кстати, до сих пор живёт во всех дистрибутивах линукса. Как настоящий unix-way инструмент, ifconfig умеет делать хорошо только одну вещь — настраивать сетевой интерфейс. Чтобы настройки интерфейсов не терялись после перезагрузки, его запускали из /etc/rc.local. Если кому-то надо было гарантировать порядок и названия интерфейсов — колдовали с modprobe. Жили так довольно долго: где-то, например во FreeBSD, настройки ifconfig писали в /etc/rc.conf, где-то, например в мини-дистрах для специальных задач, вообще никакого стандарта не было.

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

Здесь бы нам всем остановиться, добавить в /etc/network/interfaces WiFi, и протащить его в другие дистры (или затащить в Debian стандарт из других дистров). За 10 лет и пару мажорных апдейтов такую штуку можно было бы довести до рабочего состояния — чтобы и WiFi через GUI конфигурировать, и на серверах было понятно, что куда писать. Но старые абстракции чинить никому не хочется — лучше нагородить новых поверх. Так появился NetworkManager. У него тоже нашлись несуществующие, но при этом нерешаемые проблемы — и появился systemd-networkd. На удивление, и у него нашлись нерешаемые проблемы, к тому же NetworkManager почему-то отказался умирать, поэтому пришлось изобретать ещё одну абстракцию поверх их обоих — netplan.

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

Мне сложно осуждать таких программистов — я и сам ненавижу работать с плохим кодом. И в fands мы легаси не берём, если не видим способа быстро спрятать его в коробочку абстракций.

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