🎢Неустойчивое равновесие

Предыдущий год для меня был годом борьбы за энергию.

Начинал я его депрессивным и выгоревшим из за проблем на работе. Мы тогда сократили почти всю команду.

К середине года вышел в ноль.

К началу декабря чувствовал себя если не сверхчеловеком, то близко.

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

Слетел режим сна, еды, 4х месячный страйк без алкоголя. Я перестал трекать ежедневные задачи, 2 недели не занимаюсь спортом, не было сил общаться с людьми. Нет ничего, что не было бы задето.

Мне это напоминает график из школьной физики с потенциальной ямой и барьером. Телу так легко находиться в яме с минимумом потенциальной энергии, и так сложно держать равновесие в локальном максимуме.

Начало года, начало месяца и недели - идеальное время чтоб начать все сначала и замерить свой failure recovery time.

Как у вас? Кто со мной?

🏋Как Github измеряет продуктивность команд?

Недавно читал про Copilot и наткнулся на статью Github о том, как они измеряют продуктивность команд разработки и импакт их AI-вундерфафли.

Если коротко - нет какой-то одной универсальной метрики. Это скорее совокупность всех метрик из предыдущего опроса.

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

Employee satisfaction and well-being.

Это же подтверждается тем, что я недавно узнал из разговоров с психологом и магистром менеджмента Виктором Мизилиным

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

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

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

А еще наша контрольная система не дает нам покоя и постоянно просит отвлечься, показать ей еще тиктоков и рилсов, почитать новостей.

👉 Резюмирую. Берегите себя самого и свою команду. Не пытайтесь достичь продуктивности работая больше, лучше позаботьтесь о своей менталочке, это даст больше плодов на дистанции.

📣 Пошарье этот пост со своими коллегами, руководителем или просто близкими, которые работают на износ.

@ctobuddy

Упоролся немного по теме well-beingа на рабочем месте. Читаю исследования на тему факторов стресса, влияния многозадачности на продуктивность, выгорания среди айтишников.

Может получится что то интересное.

Написал большую статью для вастрика.
Будет много научных данных и цифр.
Жду вас в комментариях.

https://vas3k.club/post/22464/

Сегодня воскресный мем,
а завтра начнем неделю с чего-то серьезного.

Кстати, сегодня у меня третье интервью по использованию GenAI программистами, на этой неделе отвлекался на well-being тему. Со следующей недели хочу поплотнее заняться AI.

Если вы используете GenAI в работе каждый день или знаете такого человека, пожалуйста, напишите мне.

@ctobuddy

🛠 Arc42 - фреймворк описания архитектуры

Arc42 мне нравится за его логичность. Идешь спокойно сверху вниз и описываешь систему.

У него есть младший брат - С4 model, но мне как то не заходит из-за излишней простоты.

Arc42 местами может наоборот показаться громоздким, но никто не мешает просто выкинуть ненужные части.

Начинаем описывать систему с бизнесовой части, типа целей проекта, юзкейсов, ограничений, бизнес контекста(с какими другими системами наша система будет взаимодействовать)

Дальше спускаемся на уровень ниже и описываем нашу систему в компонентах, еще уровнем ниже описываем каждый компонент отдельно.

После того как описали компоненты, описываем как они взаимодействуют между собой по всем важным сценариям. Тут будет много sequence диаграмм.

В Crosscutting Concepts указываются другие полезности типа мер безопасности, логгирования и мониторинга, процесса разработки и тд

И самое главное в конце не забыть про Риски!

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

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

@ctobuddy

Вчера посмотрел отличную комедию про выгорание, токсичное начальство и сокращения. Прям в тему моей последней статьи.

Офисное пространство(Office Space) снят в 1999 году, во время пузыря доткомов и не утратил актуальности сегодня.

За хороший вечер спасибо @imctobitch

@ctobuddy

🥵За что я не люблю программирование

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

Я дико кайфовал с написания кода - наваливаешь минимал техно в наушниках и попер писать.

Но есть две херни, которые тебя регулярно выбивают и колеи:

- Борьба с самим собой
- Танцы с бубнами

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

С другой стороны, нет более капризной стихии, чем программирование. Мне кажется даже астрология более точная “наука”. Хороший программист должен уметь говорить с богами, читать невидимые знаки в логах, гадать по стектрейсу.

Если уж разгневал богов, то нужно уметь задобрить, тут надо танцевать с бубном. Бывает такое, что достаточно просто перезапустить код и проблема уходит аки не было, барабашка пошалил.

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

Такие вот планы на вечер.

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

Ставьте 🔥 who can relate

@ctobuddy

🏦 Как мы оптимизировали процесс на $0.5m. Часть 1 Точка А

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

Под каждого клиента нужно было:

- Запустить пару десятков микросервисов с огромным количеством конфигураций - от домена, с которого приходят письма, до лимитов финансовых операций, помноженных на минимум 2 окружения.
- Создать, раздать доступы и сконфигурировать аккаунты в десятке сторонних сервисов типа Apple/Google Developer Console, Mailchimp, Twillio, Intercom, Firebase и тд. Все правильно проинициализировать в конфигах.
- Кастомизировать и собрать 4 приложения(админка, веб, ios, android) каждое состоящее из нескольких модулей со своими конфигами, тысячами строк локализации и сотнями кастомных изображений.
- Протестировать и отдать клиенту.

Первых двух клиентов мы запускали очень болезненно. В процессе участвовала практически вся команда. Бизнес, техническая команда, саппорт - в сумме человек 20-30.

Хоть какое то абстрактное понимание процесса было только у меня в голове, из-за этого было множество затыков: то с клиента не все собрали, кому то не дали доступ, кто-то что-то сконфигурировал только частично, забыл передать какую нибудь строку и тд.

Это выливалось в огромное количество стресса для всех.

В итоге процесс занимал 2 месяца, и как позже выяснилось - минимум на 75% состоял из мусора.

На очереди стояло еще несколько клиентов. Было принято решение, что так продолжаться не может, нужно оптимизировать!

О том, как мы это делали расскажу в следующей части.

@ctobuddy

🏦 Как мы оптимизировали процесс на $0.5m. Часть 2 Процесс

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

Целью оптимизации была простая идея - “Мы должны делать сборку приложений один раз”

Из-за чего были постоянные пересборки и бесконечное тестирование?

- От клиента не было получено сразу всей информации. Например, кастомизировали все строки, собрали приложения, а потом выясняется, что адрес клиента на выписке транзакций не поменяли. Нужно идти дозапрашивать данные, ждать ответа, менять, пересобирать, перепроверять. Из за одного параметра.
- Внутренние затыки связанные с все той же передачей информации. Собрали приложение, не работают пуш нотификейшены на IOS - забыли токен указать. В итоге в какой нибудь Apple Developer Account нужно было заходить с десяток раз, чтоб каждый раз поменять какую то фигню.

Теперь мы понимаем проблему, что будем делать?

1. Вытащить знания из голов и положить на бумагу

Провели многочисленные интервью с людьми и вытащили неструктурированные данные.

В итоге нам как то, в первом приближении, получилось составить представление о процессе, но он был такой большой, что одним мозгом его было не охватить, тогда еще не было LLM, но мы как то выделили фазы и первые задачи.

2. Определить границы процесса.

Мы не трогали часть ведения клиента до сделки, комплаенса и сбора данных с клиента. Мы дали перечень данных, который было необходимо собрать с клиента, без которых мы не начнем ничего делать.

Тут нужно быть принципиальным, например, у клиентов были трудности с открытием Apple аккаунта(требует верификации бизнеса), и они то и дело хотели чтоб мы запустили сначала андройд и веб, а потом IOS.

Но это бы жестко ломало процесс, тк все взаимосвязано. На вебе, например, конфигурировались deep links для мобильных приложений.

Очень сложно было это объяснять, даже внутри компании.

3. Прогнать процесс еще раз

Теперь прогоняем процесс еще раз с новым знанием и просим каждого досконально записывать каждый клик и движение мышкой.

Особое внимание уделяем входным и исходящим параметрам. Как я писал выше, все затыки из за потоков данных.

На этом этапе мы создали отдельный проект в Jira куда заводили каждую задачку и от каких других задачек она зависит.

Благодаря Jira и сторонним плагинам мы построили дерево зависимостей задач, только это не было деревом, а было скорее запутанным клубком, который предстояло распутать.

Кстати, огромная благодарность Jira-кудескику Владимиру Луневу. Обращайтесь к нему за помощью с Atlassian продуктами.

4. Наконец-то оптимизировать

Берем клубок задач и распутываем, меняем очередность задач, какие-то задачи объединяем, чтоб по возможности заходить в Apple Developer Account только один раз для настройки всего сразу.

Для каждой задачи описываем четкий список действий и input/output. Создаем центролизованное место для обмена конфигурациями, странички в Confluence для каждого клиента.

5. Автоматизируем

Какие то части можно было легко/выгодно автоматизировать. Например, для каждого клиента наши дизайнеры создавали файл кастомизации в Figma, откуда мы автоматически скачивали все ассеты и запекали в сборки.

6. Повторяем еще несколько раз

PROFIT!🫰

Большой выдался пост, поставьте 🔥, в следующей части распишу о результатах.

🎒Tallinn→Serbia→Porto→Azores→???

Завтра отправляюсь в Гранд путешестие с друзьями.

🏂 Сначала будем катать на досках в Сербии, в месте, где 200 солнечных дней в году.

🐙Дальше летим в Порто наслаждаться свежими морепродуктами, вкуснейшими фруктами и культурой.

🍍Потом летим на Азорские острова, хайкаем по вечнозеленым вулканам, отмокаем в горячих источниках и всячески преисполняемся.

🗽Дальше планы туманны, скорее всего полечу в США уже по работе.

Пропадать не буду, все время планирую работать, писать посты, финально провалидироать AI идею.

Кстати, для фотокарточек у меня есть инстаграм, подписывайтесь!