FEDOR BORSHEV

Ласт-колл на «Без ерунды» — курс о DevEx, который состоит только из диалогов

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

А есть знания, которые лучше всего передаются через обычные разговоры — очно в офисе или по зуму. Работаешь рядом с человеком и тренируешь мозги делать так, как делает он — сначала копируешь, потом развиваешь свой стиль. Такое хорошо работает в руководстве, в управлении людьми, в стратегическом мышлении. Последнее — вообще кайф: мне кажется, что Теория Ограничений так хорошо отпечаталась у меня в голове именно потому, что Голдрадт её подал в виде кусочка жизни обычных людей, которые ты проживаешь вместе с ними во всех трёх «Целях».

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

За 4 письма герои через призму DevEx применяют все инструменты, которые нужны управленцам — раскладывают работу команды через JTBD, чинят онбординг и передачу знаний, разруливают проблемы с продуктивностью и, наконец, чинят коммуникацию с бизнесом. По дороге — практикуются переговорах и стратегии.

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

Смотреть программу →

Опора для коллег

Важная функция руководителя — быть опорой для коллег. Когда прод лежит, а сроки горят — тимлид должен приносить в команду спокойствие, а не тревогу. Когда прибыль падает, и CEO топчет ногами — COO должен поддерживать коллег, а не грозить всех уволить. Когда инвесторы отказываются от раунда, CEO должен верить в будущее, а не пропадать из офиса с бутылкой.

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

Самое сложное в том, что надо не просто демонстрировать спокойствие и искриться улыбкой, а действительно быть таким внутри, иначе люди быстро распознают хуйню и станет только хуже. Это довольно сложная работа — чтобы выполнять её в собственных бизнесах, мне понадобилось 10 лет ежедневного руководства командами и 5 лет психотерапии. До сих пор есть, куда расти.

Мой идеал спокойствия — Людвиг Быстроновский, арт-директор, с которым я когда-то давно работал в студии. Судя по его рассказам (посмотрите его цикл лекций о шторме) — человек довольно взрывной внутри. Несмотря на это, всегда когда у меня случался полный пиздец (а в клиентской работе полные пиздецы случаются раз в неделю), если на проекте был Людвиг — я успокаивался гораздо быстрее. Он не применял никаких специальных инструментов — просто спокойно разговаривал о проблемах. Наверное это работало где-то на уровне химии и языка тела, не знаю. Часто мне даже не надо было с ним разговаривать — я садился писать ему письмо и, даже не дописав, понимал что делать. Сейчас я стараюсь быть таким же для своих коллег — давать уверенность и спокойствие, что бы ни происходило в бизнесе.

Так вот, к чему это я: если начали руководить даже двумя людьми — учитесь приносить им спокойствие. Тревоги им и без вас достаточно.

Опять про DevEx

Кароч, мы тут сделали курс по Developer Experience. В посте рассказываю, зачем мы его сделали, чем он отличается от прошлогоднего (маленького) вебинара, и зову купить билеты. Они недорогие — хотим, чтобы наши письма были как аптечка, доступны каждому.

В ИТ-тусовочке складывается очень узкое понимание понятия Developer Experience. Типа чтобы стать специалистом по DevEx, достаточно написать пару скриптов для команды, поправить конфигу таскраннера и заменить Elastic APM на Datadog. Получается так же, как стало с DevOps — когда целую систему взаимодействия между разработкой и эксплуатацией превратили в новое название для системного администрирования, потеряв по дороге большую часть смысла.

DevEx — это не (только) про инструменты, это — про повышение эффективности разработки. То есть про то, как уменьшенить когнитивную нагрузку, создать комфортную рабочую среду и безопасный контекст. Что-то вроде современной гигиены труда, помноженной на грамотное управление творческими людьми. Опыт в DevEx (может быть даже несформулированный) — это то, чем отличаются управленцы, вышедшие из разработки. Если обычные менеджеры в случае проблем склонны нанимать больше программистов, то управленцы из разработки — наоборот, создавать более удобную среду, в которой меньшее количество программистов делает ту же работу.

Вот об это и наш курс — как работать быстрее, но не растить команду. Курс получился довольно коротким и лёгким — всего 4 письма за 4 недели. Говорим о JTBD, когнитивной нагрузке и онбординге, разбираем, чем удобные инструменты отличаются от неудобных. Последний модуль — о современных Agile-ритуалах: как подчинить разработку требованиям бизнеса, не жертвуя удобством программистов. Писали его для тимлидов, CTO, менеджеров и синьёров. Мидлам и околопрограммистам — если хотите больше понимать, что происходит вокруг или расти в управление. Джунам смысла нет.

Смотреть программу →

Если были на прошлогоднем вебинаре — смысл есть: материал полностью новый, его больше, и подан он более вдумчиво и легко.. Стартуем 15 ноября (это уже через 2 недели). Учимся 4 недели. До 7 ноября действует промокод CRUNCH на 10% скидки.

Firefox!

Я тут внезапно перешёл на сабж и ничего не случилось.

С самого первого дня на маке я юзал Сафари — мне очень нравилась скорость и интерфейс без лишних кнопочек. Ради этих двух вещей я почти 10 лет мирился с некорректным рендерингом некоторых сайтов, невнятными адблокерами (сначала опенсорсный Ka-Block, потом вообще 1Blocker), и корявыми расширениями, вроде Cascadea для юзерстилей или глючного 1password.

Последний и стал причиной перехода — в какой-то момент создатели 1password вынудили меня перейти с 7 на 8 версию (говно на электроне). Поскольку деваться было некуда, и лучше сделать это заранее, чем ловить глюки от разных версий, основное рабочее место я тоже перевёл на 1password 8. После танцев с бубном завелось всё, кроме плагина для Safari — он ужасно глючил. Так я и перешёл на Firefox, который решил последние мои проблемы: у него расширение работает как часы (насколько это применимо к говну на электроне). Выбрал его из-за приватности — в нём гораздо легче отключить гугловую телеметрию и другие плюшки вроде автохода в гугл.

Firefox тут же напомнил про забытые за 10 лет возможности — вроде нормального адблокера вместо 1blocker или работающего Consent-O-Matic вместо корявых решений для Safari. Зарабоали даже штуки, аналогов которых для Сафари я просто не знал — вроде SponsorBlock и DeArrow для ютуба. Работает всё так же быстро, как раньше, и даже интерфейс удалось сделать (почти) таким же чистым.

Теперь у меня два основных браузера — FF для сёрфинга и Brave, когда надо поковыряться в потрохах чьего-нибудь фронтенда или поработать с Metamask.

А давайте встретимся в Алматы?

В понедельник, 21 октября, проводим открытый митап с CDO kolesa.kz Николаем Киндяковым. Повестки нет — хотим просто собраться в офлайне и поразгонять на тему конфликта бизнеса и разработки, поотвечать на вопросы или позадавать их вам.

Встречаемся по адресу ул. Шевченко 155/6, в понедельник, в 18:30 UTC+5. Если хотите прийти — заранее зарегистрируйтесь

Учиться у редакторов и дизайнеров

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

А вот программистов этому не учат. Не в смысле делать хорошие тексты и интерфейсы (хотя и не помешало бы), а в смысле смотреть глазами потребителя их кода — другого программиста в будущем. Открываешь модуль — а в нём 3 класса, 5 функций и ещё сколько-то кода выполняется при импорте. Почему они все вместе? Что делает модуль? Непонятно. Или читаешь функцию — а там 50 строк, 10 if и поди пойми, зачем она вообще существует.

О коде нужно думать как редактор или дизайнер. Цикломатическая сложность, чистота по дяде Бобу или <любая ваша метрика> — это базовая гигиена, как отсутствие грамматических ошибок в тексте у редактора. Гораздо важнее высокий уровень — как будущие программисты будет решать свои задачи в нашей кодовой базе. Если надо будет пилить новую бизнес-логику, поймут ли они, в каком формате у нас это принято делать — сервисыные объекты\контролелры\микросервисы? Сколько времени будущие программисты будут разбираться, как у нас прокидываются настройки из рантайма? Если надо будет что-то делать с БД, поймут ли как у нас работают миграции схемы?

А помогите нам получить премию

Мы подали «Анализ систем» ещё на одну премию — School of Education. Результаты оцениваются по итогам голосования, но там нужно не просто нажать кнопку, а написать содержательный отзыв на 100 слов. Если вам понравился курс — потратьте 3 минут на отзыв (или хотя бы на промт).

Для всех, кто оставит голос, мы сделаем с Антоном Давыдовым факультатив на какую-то тему, которая касается курса — присылайте скрины на [email protected], а мы напишем в ответ, как только определимся с датой и темой.

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

Пришёл я недавно к Антону комментить статью про Obsidian — я потихоньку делаю лонгрид о том, как использовать его в качестве личного дневника, и очень заинтересовался паттернами Антона.

Довольно обидно стало, когда Антон, вместе с благодарностью за коммент, рассказал, что эта статья — самая комментируемая у него него за последнее время. Обидно — потому, что я знаю у себя привычку к такого рода прократстинации — вместо того, чтобы пойти и сделать работу, потратить время на то, чтобы сделать эту работу на 2% *эффективнее* — как тот линуксоид, который за 2 часа напишет скрипт, который за 5 минут сделает то, что юзер руками делал бы час.

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

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

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

OpenWRT и сисадминство

Я давно расстался с сисадминской привычкой сисадминить всё вокруг себя — выбираю iOS вместо Android и мак вместо линукса, езжу на свежей Toyota вместо старой BMW и предпочитаю готовые инструменты собственным огородикам (даже в последние 2 года). Понимаю, что контроль за инструментами — это не только возможность, но и обязанность: когда сломается BMW — её надо починить, а в линуксе нужно будет периодически чинить отвалившийся WiFi или сканер отпечатков пальцев.

После 12 сентября, когда сразу куча зарубежных сервисов перестали работать из России, пришлось перерешивать одну из таких проблем, которую я считал закрытой. Уже лет 7 у меня дома стоит замечательный роутер Amplifi, который за всё это время ни разу не завис и позволял мне не думать о качестве приёма внутри квартиры. Но, увы, промышленность не выпускает роутеров, которые умеют заворачивать в shadowsocks выборочные маршруты, а теперь без этого комфортно работать не получается. Поэтому пришлось переходить на OpenWRT.

Пока ждал роутер (выбрал Mikrotik Hex) — в голову лезли вьетанские флешбеки сисадминские мысли:
— А давай воткнём в роутер SD-карту, чтобы можно было установить питон и обновлять маршруты автоматически?
— Если не SD-карту, то давай хотя бы скрипт перепишем на micropython.
— О, а ещё есть старый LTE-модем. Давай сделаем второй интернет, на случай если откажет первый?
— А в списке пакетов есть ещё cloudflared! Клёво будет ходить на роутер, даже когда он переключится на запасной интернет!
— И ещё надо сделать автовыбор эндпоинтов для VPN — чтобы переключаться с одного на другой, если они начнут отказывать.
— О, может ещё тем для luci поставить?

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

Жалею конечно, что пришлось отказаться от старого проверенного решения, но выбора у меня, кажется, не было. Ну и горжусь, что смог не насисадминить лишнего даже с OpenWRT, которая буквально подталкивает к этому.

#вопрос не расту на работе, уже джва года ничего не происходит — ни обязанностей не прибавляется, ни зарплаты. Подумываю уволиться. Что делать?

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

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

Следующий шаг — принять факт, что никто вас вперёд толкать не будет. Хотите делать больше и интереснее — ищите как. Я тогда занялся ростом самостоятельно — построил план роста на год: выучить питон и джангу, потренироваться в общении с людьми через random coffee и личные встречи с предпринимателями. Всё это прекрасно уложилось в рабочее расписание — я вложился, настроил дела так, чтобы работали с минимальным участием и честно пошёл заниматься своими делами.

Увольнялся я бы только в третью очередь — только после того, как исчерпал все другие возможности. Дело в том, что ваше текущее состояние — отличный способ потренировать проактивность: когда вы не ждёте, что желаемое сваливается на вас с неба (или приходит вместе с новой работой), а добиваетесь этого сами. Это отличный навык, который пригождается в любом деле, и не только на работе.

Это был традиционный вопрос по понедельникам. Задавайте свои на [email protected]

Как хорошо оценивать задачи

Когда речь идёт о хорошей оценке задач, многие представляют себе эксперта-сметчика с годами наработанной интуицией, который обложился доверительными интервалами и матмоделями, оценил в жизни 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. Вернулся домой и сразу же удалил нафиг тот позорный чеклист, и теперь экономлю по полтора часа в месяц.

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

Это был традиционный #вопрос по понедельникам. Задавайте свои на [email protected]