FEDOR BORSHEV
21.5K subscribers
13 photos
1 video
4 files
474 links
Пишу о производстве сложных проектов, управлении продуктами, профессиональном росте программистов.

borshev.com / patreon.com/f213

Связаться со мной — fborshev@pm.me

Реклама не продаётся.
Download Telegram
#вопрос Читал у тебя в блоге и на канале, что нужно всегда выполнять обещание и попадать в эстимейты. В жизни я так и делаю — строго слежу за тем, что говорю. На работе всё диаметрально противоположно — я часто нарушая свои обещания и проёбываю сроки. На словах всё просто: пообещал — сделай. В реальности переодически может вылезти что-то непредвиденное. Как перестать факапить и начать расти как профессионал?

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

Профессионал отличается от новичка тем, как он реагирует на факапы. Чтобы обнаружить потенциальный факап, не нужно быть супер-опытным чуваком — достаточно пользоваться тупым правилом про 50%. Сложности начинаются, когда за потенциальные факапы нужно взять ответственность.

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

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

Попробуйте и вы так — планируйте экваторы по длинным задачам, честно отвечайте себе на вопрос «сделал ли я половину работы?», и если нет — бейте тревогу.

Это был традиционный вопрос по понедельникам. Вопросы задают на fborshev@pm.me
Не стесняйся показывать сырую работу

Новые, которые приходят в мою команду, имеют вредную привычку — показывают работу только тогда, когда считают её готовой. К примеру, договорились мы сделать интеграцию с новым сервисом подписок (мы, кстати, перешли на dashamail с mailchimp).

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

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

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

Месяц назад мы провели стрим о поиске работы за рубежом с Димой Рожковым. Тема многим показалась интересной, поэтому теперь Дима — новый эксперт нашей школы: он отлично разбирается в зарубежном трудоустройстве, уже 8 лет живёт в Германии и 4 из них нанимает инженеров со всего мира.

Дима с ходу присоединяется к нам с актуальным курсом — «Вы приняты». Это трёхнедельный практический курс о сабже — как выбрать компанию, сделать профиль в линкедине, пройти собеседование. Никакой теории — только мясо и конкретика.

Стартуем 26 мая, учимся три недели. Как обычно на наших курсах — живое общение с авторами и доброжелательное комьюнити прилагается.

Смотреть программу и первый урок →

До 14 мая скидка 10% по промо-коду W1ND.
#вопрос Работаю в около-гос. компании. Вроде всё как в стартапе и по SCRUM, но есть проблема — тестировщики\аналитики. От заказчика часто возвращаются репорты об ошибках в релизах, которые (по причинам халатности) не были идентифицированы при прохождении предрелизных тестов. Коуч-сессии о командном духе, о командной работе над продуктом не приносят плодов, даже разрабы жалуются на этих аналитиков/тестировщиков о их частой непродуктивности (слишком долгая тестировка, невнятная аналитика).

Последний релиз не был исключением — тестеры все проверили, релиз отдали, заказчик вернулся с репортом, что «все х-ня, давай по новой». Разбор этих репортов показал, что аналитики/тестировщики очень много нюансов просто «недоглядели» (стояли, кивали головами и «мычали»).

Все выходные ломал голову над тем, что может это моя вина? Что я недокоучил их как работать? Или не донес им суть ценности командной работы? Или еще что-то, где я «недосмотрел»… В общем доверия, которое должно быть, просто нет — сейчас я ожидаю от них очередного подвоха по старому сценарию «недосмотрели, проглядели». Как быть в такой ситуации? Стоит ли мне акцентировать все репорты как «моя вина» или же стоит что-то делать с аналитикой/тестировкой (возможно уволить их и взять других)?

——————

Думаю, у плохой работы мануальных тестировщиков могут быть другие причины, кроме недостаточной их приверженности коммандным ценностям :-)

Позволю себе уцепиться за противоречие в вопросе — с одной стороны вы говорите об SCRUM «как в стартапе», а с другой — упоминаете о зафейленном релизе. Предположу, что вы делаете не мобильное приложение и не либу для программистов, а значит механизм релизов (как и ручное тестирование) вам пришлось внедрять не от хорошей жизни.

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

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

Это был традиционный вопрос по понедельникам. Вопросы задают на fborshev@pm.me
Чем вы делаете бекапы?

В последнее время у меня появилось много инфраструктуры. С удивлением обнаружил, что за прошедшие 5 лет с момента, когда я серьёзно занимался инфраструктурой, ничего не поменялось в мире бекапов — кажется все так же пишут скрипты, которые ежедневно/-недельно запускают rsync или складывают бекапы куда-нибудь на s3. Разве что продвинуты ребята используют write-only доступы и healthchecks.io, чтобы получить уведомление о сфейленном бекапе.

Я понимаю, что проблема бекапов — довольно сложная: инфраструктуры и требования у всех разные. Но ведь для десктопа же есть решения всё-в-одном, вроде Backblaze или хотя бы TimeMachine на маке. Почему я не смог найти ничего похожего для серверов? Есть только жуткий на вид veeam.

Расскажите пожалуйста в комментах, может знаете какой-нибудь простой инструмент для бекапов?
Ипотека

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

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

Возьмём ситуацию: есть свободные 10 миллионов рублей, хотим обезопасить сбережения. Можно сохранить небольшую финансовую подушку, а на оставшиеся деньги — купить двухкомнатную квартиру в условной Туле за кеш. А можно купить там же, но в ипотеку с большим первоначальным взносом под условные 7%. Переплата по ипотеке будут ниже уровня инфляции, а свободные деньги можно вложить в бизнес\акции\облигации, которые уж точно обеспечат больше 7% годовых. Кажется норм, рабочий инструмент.

Или так: живём в Москве\Берлине, сбережений нет, а бабушкиной квартиры хватает на 1,5 квадратных метра. Берём ипотеку на 40 лет, с платежом в половину зарплаты. Лишаемся возможности сменить работу, переехать в другую страну или взять саббатикал. Через 40 лет остаёмся без сбережений, но зато со своей квартирой. Ну или передаём долг по наследству, если что-то пошло не так. Такое себе.

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

Я сам нахожусь примерно в такой же ситуации, как Тонский в Берлине — чтобы купить квартиру в месте, где я живу, мне нужно продаться в рабство лет на 20. При этом первые 5 лет я буду ещё и выкраивать деньги на ремонт в ванной, чтобы строительная пыль не сыпалась на голову, пока я принимаю душ. Так что мой выбор — достроить бизнес до состояния, когда я смогу себе позволить жильё, которое хочу. И по дороге поддерживать разумную долю защитных активов в портфеле.
Первый год Школа Сильных Программистов существовала без названия — мы думали над концепцией, потому что не хотели делать ещё одну школу на рынке. Хотели сделать пространство с поддерживающей средой и возможностью развития. Чтобы отвечать на вопросы которые страшно, стыдно, неуместно задавать.

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

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

Если собираетесь за рубеж — промокод W1ND действует до вечера понедельника. Честную рассрочку, которая пропала после начала войны, мы восстановили. Будет ли повтор курса мы не знаем, так что если хотели — присоединяйтесь.

Смотреть программу и первый урок
Второй раз на те же грабли

У меня дежавю. Два года назад мы с Федей запустили курс про делегирование «Самому не проще». Тогда на открытие продаж, я говорила что это для программистов, потому что все примеры для них. Но бесстрашные люди других профессий покупали и писали мне, что я не права — им тоже полезно. Через полтора года я поменяла упаковку и сама начала советовать его, если видела, что человеку нужно. В итоге курс прошли почти 200 человек.

В начале мая мы открыли продажу на новый курс про поиск работы за рубежом под названием «Вы приняты». Снова упаковка для программистов. После открытия продаж, если мне писали «а можно мне, если я продакт», я отвечала, что нет.

Сейчас мы подготовили 3 урока из 7 и я для себя поймала на том, что уже выписала целую простыню пользы. Например, как оценивать оффер и торговаться за условия по формуле Бэна Оренстина. Или что может входить в релокейт пакет, а что нет, стоит ли озвучивать свои зарплатных ожидания до собеседования и ок ли потом поменять свое мнение, узнав подробнее о своей роли или задачах.

Блин, это же совершенно универсальные штуки, которые подойдут и помогут повысить шансы найма любому человеку, который сейчас в поиске работы за рубежом. А я говорю «не покупайте» 🤦‍♀️

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

Стартуем 26 мая. Всего три недели. По два урока в неделю. Много практики, бери и делай. От меня промокод love на 10% скидки до 25 мая.

Посмотреть программу и первый урок

P.S. По традиции выделили 20 мест для тех, кто недавно потерял работу или выбрался из небезопасного места и уже имеет силы учиться. Напишите нам, если вас это касается. Почта на странице курса.
​​Наш ведущий фронтендер Миша Бурмистров сделал чеклист по веб-безопасности для фронтенд-разработчиков компании.

Хвастаюсь!

Опубликую ещё первый комментарий Миши к этому посту (не видны публично):

Было бы удобно, если бы ко всем пунктам списка были приложены материалы, но поиск/фильтрация материалов это работа, которую я не готов сейчас делать. Кроме того, у всех разные предпочтения в плане формата контента — кто-то любит статьи на русском, кто-то видео на английском и т. п. Все темы из списка довольно известные — уверен, вам не составит труда найти по ним информацию. Можете делиться понравившимися материалами в комментах.

А чтобы почитать остальные комментарии — придется устроиться к нам на работу :)

Признаюсь, я и сам не знаю некоторых аббревиатур 🙈

Разработчики, которые думают о безопасности — единственный способ делать безопасные приложения. Никакие отделы безопасности не спасут, если разработчикам пофиг. Так же, как и с тестированием — о качестве должны думать все разработчики, а не только «специалисты»!

В общем, горжусь и хвастаюсь!
Как за один вопрос разрушить отношения с покупателем?

Довольно легко — нужно предложить ему ему написать заявление на возврат.

Недавно я попытался воспользоваться сервисом одной известной бухглатерской компании, которую пару лет назад купил Сбер — мне нужно было оформить заявление на налоговый вычет. Довольно быстро я передумал — оказывается, чтобы воспользоваться их услугами, нужно несколько дней сидеть возле телефона в ожидании звонка от очередного некомпетентного специалиста. На третий день сидения у телефона, очередной некомпетентный специалист в ответ на просьбу просто вернуть деньги, прислал мне заявление на возврат. Это такой документ, который нужно заполнить от руки (!), отсканировать (!) и отправить им на почту.

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

В Школе мы возвращаем деньги по первому требованию. Возможно именно поэтому процент возвратов у нас намного меньше единицы. Хочу, чтобы так было везде.
Только 80 порт

Большая боль для современной эксплуатации — это бекенд, который лезет на уровень протокола: терминирует SSL, отдаёт заголовки HSTS или CSP или даже делает Basic-авторизацию. С одной стороны звучит довольно просто — поставил пару пакетов для любимого фреймворка, и добавил безопасности и удобства.

К сожалению, это не правда. Возьмём, к примеру, HSTS — заголовок, с помощью которого приложение может сказать «дальше соединяйся со мной только по HTTPS, пожалуйста». Браузер кеширует этот заголовок, и больше никогда не пойдёт по HTTP-ссылке на приложение. Вроде бы отличное поведение, но ровно до того момента, пока вы не запустите приложение с таким заголовком на локалхосте, после чего у вас перестают работать все не-SSL приложения, которые висят на этом же порту.

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

Я не говорю о попытках терминировать SSL или реализовать HTTP/2 в том же контейнере, где крутится код. В специально приспособленных местах такие вещи делаются за 1 строку кода, или вообще без неё. А в контейнер приходится заводить nginx, letsnencrypt и ещё кучу скучных вещей.

Всё, что должен знать современный бекенд про HTTP — это то, что его будут спрашивать по 80 порту (и то не обязательно). Всё остальное — забота балансировщика, nginx, cloudflare или что там у вас.
Загружаться творческой работой на ночь

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

Важно, чтобы этот вопрос был максимально конкретным:
— Как заложить одновременную поддержку SNOMED и МКБ11 в модель данных МИС?
— Как сохранить привязку к метафоре в конце доклада?
— Чем заменить маркетинговую функциональность mailchimp?\
— Какой мой жизненный опыт подходит для примера в факультативе про собеседования?

Не знаю, как это работает, но если найти в себе силы задать такой вопрос на ночь, с утра гарантированно просыпаешься с решением. Конечно при этом важно после пробуждения не хвататься первым делом за телефон, а 5–10 минут полежать в одиночестве и спокойствии. Лучше вообще чтобы телефона рядом не было.
«Вы приняты» — стартуем послезавтра

Забавный факт — когда я проверял за Димой четвёртый урок курса, то понял, что совсем не умею писать резюме — так уж вышло, что на все рабочие места в жизни я устраивался через cover letter и личные встречи. В больших компаниях, тем более зарубежных, так не сработает — вам придётся проходить все формальности: сорсера, HR-менеджера и только потом уже встречаться с командой.

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

Кроме написания резюме и выбора компании, мы говорим о том, как торговаться за офер, тренируем самопрезентацию, факультативно изучаем ведение профессионального блога и пет-проектов. Курс ориентирован на разработчиков, но подойдёт всем, кто связан с айтишечкой. Если вы разработчик — берите «VIP» или «в тусовке», если просто интересуетесь поиском работы за рубежом — «самостоятельный».

Стартуем послезавтра (26 мая) со встречи-знакомства в 19:00 — смотрите программу и приходите. По промокоду LC10 скидка 12% до 23:59.

Записаться →
Менеджер слышит то, что хочет услышать

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

Когда программисты называют сроки в виде вилки, типа «2–4 дня», многие менеджеры слышат только первую часть вилки — «2 дня». Если сказать «во второй половине мая», менеджер услышит «15 мая» вместо «между 15 и 30 мая». Если сказать «не меньше трёх дней», менеджер услышит «три дня».

Что с этим делать? Если вы программист — называйте абсолютные, а не относительные сроки. Не «2–4 дня», а «будет в следующий понедельник». Не «во второй половине мая», а «1 июня». Не «не меньше трёх дней», а «через три дня назову срок».

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

Мы в «Феде и Самате» запустили эксперимент — перешли на 4-х дневную рабочую неделю. Считаем, что так команда будет лучше себя чувствовать, а производительность не изменится.

Во-первых, если из среднерыночной команды выкинуть все встречи, которых у нас нет — дейли-митинги, покер-планинги и «давайте синхронизируемся», останется как раз четыре рабочих дня.

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

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

Пока запускаем эксперимент на два месяца — до августа. Производительность будем замерять по ощущениям: просто сравним списки закрытых задач по периодам. Параллельно делаем анонимный опрос (спасибо, Ксюша) «Работал ли ты в эту пятницу».

О ходе эксперимента буду рассказывать здесь и дальше. Буду рад вопросам и советам :-)
Измеримые критерии усталости

У меня тут в начале мая случилась авария — я переработал до отказа: буквально руки не поднимались делать дела, сил хватало закрыть 1–2 задачи в день, а всё остальное время сливал в пустоту. После почти двухнедельного отдыха (это для меня много), я сел и начал анализировать — из-за чего это случилось, и что сделать, чтобы больше так не выдыхаться.

Из-за чего случилось — довольно понятно: мой предыдущий отпуск был запланирован на 26 февраля, и конечно же я его отменил — и курс доллара непонятный (я летел в ОАЭ), и от команды далеко уходить не хотелось. Потом я как-то пытался компенсировать отдых — брать дейоффы, побольше спать и поменьше работать, но не получилось — видимо сказался общий нервяк от войны.

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

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

В поисках KPI я посравнивал своё отдохнувшее состояние с тем, что было в начале мая и нашёл вот такие отличия усталого Феди от нормального. Усталый Федя:
— Избегает общения с новыми людьми (да и со старыми тоже).
— Не хочет слушать новую музыку (даже daily mix в Spotify), смотреть новые фильмы.
— Не хочет медитировать и писать в дневник.
— Много ест (странно, но потребление алкоголя при этом в норме).
— Не хочет в новый город\новую кофейню\новый ресторан.

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

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

А какие у вас есть измеримые критерии усталости?
Меняю банки

В связи со всеми этими изменениями в банках, я сделал для себя довольно смешной вывод: есть области, где интерфейс — совершенно не главное.

Даже смешно, что раньше банк я выбирал по красоте приложения. Что толку от приложения Тинькофф, если оно не умеет отсылать переводы за границу в евро? Зачем нужен ещё более классный Револют, если он эти платежи не умеет принимать?

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

Но сейчас я понимаю, что за дизайнерами стоят менеджеры, а за менеджерами — политики. И банк теперь выбираю по возможностям, а не по интерфейсу — поэтому привет Райффайзен и Bunq (претендент на звание самого запутанного банковского приложения): спасибо, что к вам не надо ходить ногами, вы пока умеете переводить деньги в евро, не берёте конскую комиссию за хранение трёх тысяч долларов.

Самое смешное, что на этом фоне я стал серьёзно задумываться о переходе обратно на линукс после ~10 лет на маке, но про это расскажу как-нибудь отдельно.
Ценность vs бойлерплейт

Когда я был разработчиком (и даже CTO в стартапе), я всегда чётко отделял вспомогательную работу от работы, приносящей пользу бизнесу. Вспомогательная деятельность — это организовать выплату зарплаты, сделать новую инфраструктуру, написать новый регламент, встретиться с бухгалтерией: делать не хочется, но надо, иначе основная деятельность загнётся. Основная деятельность — это сделать код-ревью, помочь с планированием роадмапа, накидать архитектуру, настроить линтер, поговорить 1:1 с разработчиком: это такая работа, от которой бизнес ощущает пользу, и которую хочется делать 100% времени.

Я всегда старался поддерживать соотношение 80% работы к 20% вспомогательной деятельности, и жил хорошо. Но потом я ушёл в собственный бизнес. Первое время я страдал от огромного количества совершенно пустых и скучных дел — разобраться с налоговой и юрлицом, оплатить сервисы, сходить на встречи с 10 потенциальными клиентами, подключить диадок, настроить бейксемп и почту: несмотря на умение делегировать, мне было скучно — хотелось просто писать код для клиентов, в крайнем случае — нанимать программистов, чтобы они писали код за меня.

Недавно понял, что моё отношение поменялось — _я больше не хочу участвовать в написании кода_. Теперь свою ценность я вижу как раз в том, что раньше мне казалось бойлерплейтом — в умении организовать работу команды: сделать, чтобы деньги от зарубежных клиентов попадали в страну, изолировать программистов от слишком торопливых заказчиков, обеспечить бесперебойную работу бухгалтерской инфраструктуры, сформировать принципы взаимодействия в команде. Код и архитектуру конечно бросать нельзя, но теперь целевое соотношение будет обратным — 20% кода и 80% организации.

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

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

Конечно, выполнить это решение оказалось не так легко, как принять. Кажется, что арендовать и настроить сервак легко — ведь я это делал уже сотню раз, не меньше. Но на самом деле, даже если забыть про десяток часов на первоначальную настройку (hetzner server auction, накатить операционку, поднять nextcloud/cloudflared/gitea, настроить бекапы), мы всё равно получаем получаем противно зудящий потребитель времени. То бекапы отвалились, то nextcloud записал десяток гигабайт в свой логфайл, то сокет mariadb отвалился из контейнера, то nextcloud перешёл в maintanence mode по одному ему видимым причинам, то штатный образ ubuntu из hetzner не перенёс перезагрузку и завис.

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

— Настроить gmvault, чтобы бекапить почту из gmail (адекватной замены я так и не нашёл)
— Перейти на borgbackup
— Нормально настроить системные логи и их мониторинг
— Настроить автоматические зерклаирование копроративных и собственных репозиториев во внутренний gitea
— Сделать ещё пару секретных вещей

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

Есть идеи, чего ещё добавить в план?
8 июля (это через две недели) выступаю на Ural Digital Weekend в Перми. Буду говорить о терминале для программистов — как с помощью современных консольных утилит экономить время и почему пользоваться ими быстрее, чем IDE.

Кроме обзора инструментов, расскажу что ещё можно делать в терминале — почему через vim получается быстрее редактировать текст и как автоматизировать скучные дела при помощи ansible.

Организаторы дали мне промокод со скидкой на участие — BORSHCHEV145, приходите.