У нас в стартапе выработался анти-паттерн, который пока работает и мы его не трогаем.

Когда мы работаем над фичей, я создаю таску в GitHub Issues. В ней содержится только контекст проблемы, краткое описание решения и acceptance criteria. По мере того как мы обсуждаем фичу, таска дополняется деталями. В таске практически никогда нет UX, мы очень редко дизайним что-то отдельно в Фигме.

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

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

Наша продуктовая документация — пулл-ревкесты, прилинкованные к таске. Это не очень удобно пост-фактум, когда хочешь посмотреть как было принято то или иное решение. Это возникает нечасто, зато коллаборация в PR делает обсуждения ближе к коду, то есть прямо в том контексте, где происходит работа.

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

- Сколько программистов нужно, чтобы подоить корову?
- Пять, один держит корову за вымя, остальные 4 поднимают за ногу.

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

Аспект "соответствия духу" вместо "следования процессу" — то, что часто не понимают апологеты скрама. Если интересно копнуть глубже, можете послушать/посмотреть наше интервью с одним из авторов Agile Manifesto Дэйвом Томасом.

@ilyabezdelev_blog #agile

Инсайт дня — для фаундера с СДВГ ранние стадии стартапа это 🔥, потому что все и сразу, видение, идеи и т.п. Средняя стадия стартапа, когда везде пожары — это бесконечный стресс.

Природа СДВГ такая, что, чем больше хаоса, тем он более парализующий и, как следствие, тем больше хаоса и так далее. Бонусом тревожность, что приводит к ещё большему бездействию в хаосе.

Это спираль вниз.

Я решил попробовать эксперимент на ноябрь.

Я буду только писать код, не занимаясь маркетингом (есть причины, по которым маркетинг можно отложить).

Посмотрю как это будет отражаться на самочувствии.

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

Инструкции для отзывов в Авито, наверное, написаны по тому же принципу 🙈

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

Я 15 лет не жил в России и пропустил всё развитие интернет-сервисов. Некоторые вещи меня до сих пор шокируют.

Фокус, фидбек и раздражение

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

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

Меня всегда бесило, когда, выкроив пару часов на покодить, мой СТО Арнаб присылал code review со 100500 комментариев, на которые у меня уходило ещё полдня, а то и больше.

Проблема, конечно же, была в том, что я говнокодил. Но меня жутко раздражало то, что мне нужно вкладывать больше времени.

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

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

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

Я даже получаю удовольствие от хирургически точечного рефакторинга!

То же самое происходило когда я писал продуктовые документы, работая в Гугле и Амазоне.

Я никогда не писал их между делом. Я освобождал день от митингов, ставил статус «недоступен» и уходил в свою пещеру писать доки. За день мог сделать то, что с трудом можно успеть за неделю, если отвлекаться.

Потом так же выделял полдня-день на работу с фидбеком. Накапливал обратную связь и садился писать следующую итерацию.

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

Now playing: Skid Row - Slave to the Grind

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

1) С утра не за что было схватиться едва продрав глаза.

2) Пришлось его поставить на зарядку минимум минут на 30, что даст время спокойно приготовить завтрак и даже поесть в кругу семьи.

Не благодарите.

P.S. Это, конечно же, непрактично… Хотя кто знает. На эти мысли меня натолкнуло отсутствие розетки рядом с кроватью и встал выбор: поставить телефон заряжаться далеко от ложа или же дать ему разрядиться и зарядить утром?

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

Чем больше изменений, тем...

— Больше потенциальных проблем. Часть изменений будет недотестирована. 100% будут баги.

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

— Больнее диагностировать неочевидные проблемы (например, crashes — когда приложение "вылетает"). Хз какое из 10 обновлений это вызвало...

Мы стараемся релизить раз в неделю-две, как только в приложении добавляется какая-то ценность, о которой можно написать release notes.

Поэтому важно иметь CI/CD, чтобы всё сияло и не сидело бестолку, а сразу шло в продакшен.

Мы используем Tramline для оркестрации автоматических деплоев в App Store и Google Play. Использование трамлайна было одним из лучших ранних решений.

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

Но самая крутая польза от CI/CD в том, что мы можем за день сделать несколько непубличных бета релизов всего лишь тремя командами в командной строке. Выполняем команду и через 20 минут у нас на телефонах обновленный билд.

git checkout RELEASE_BRANCH
git merge main
git push

Без CI/CD возникает проблема "бэби-ситтинга", когда каждый релиз нужно готовить, загружать файлы, а затем следить, чтобы всё прошло гладко.

Это жутко неэффективный расход времени разработчиков. Няньчанье с релизами не только отвлекает от разработки фич и ставит людей в режим ожидания, но ещё и бесит. Бесит == выдирает из потока и делает менее эффективным.

Никто не хочет делать тупую работу руками. Поэтому её начинают избегать, релизы становятся больше, требуют больше тестирования, а также времени "замачивания" (soak time) или "выпекания" (bake time).

Автоматизация релизов ускоряет разработку. Отсутствие автоматизации — замедляет, когда растёт команда и кодовая база. Другими словами, если вы не автоматизируете свои процессы, вы активно их замедляете.

У вас есть CI/CD? Какие инструменты используете?

Ребенок попросил показать как я выглядел в 18 лет. Смотрели старые фотки и свело олдскулы. На этой фотке меня нет, это мои друзья. Я фотографировал их мультиплеер. Не могу вспомнить, что это за игра.

С 2009 года я практически не читал книги и статьи на русском языке, переключился полностью на английский.

Я всегда думал, что быстро читаю на инглише, но как-то раз мы вместе с сыном читали книгу и он читал раза в полтора быстрее меня. Я офигел. Жена даже думала, что он придуривается…

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

Потом настал момент истины.

На днях начал читать Neverwhere Нила Геймана (на русском Никогде) и прочувствовал разницу.

На русском я как рыба в воде. Только успеваю перелистывать страницы.

На английском я как пловец-спортсмен. Быстро, но требуются усилия.

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

Потом включил ту же книгу в аудио (в исполнении самого Геймана) и понял, что аудио идет вообще без усилий. Я всё так же не понимаю некоторые слова, но они просто проходят мимо ушей. Мозг сам додумывает всё, что нужно, в потоке речи.

Короче, нашел лайфхак. На английском буду читать только нехудожку, для которой как раз-таки полезно замедление. А художку, где хочется легкости, буду слушать.

На русском всё буду только читать.

P.S. Переводы читать не хочу, особенно, художку. Во-первых, теряются нюансы, особенно, юмор. А во-вторых, это упущенная возможность изучения идиоматического использования языка.

В корпорации есть два типа людей:

1) Те, что оптимизируют рост. Херачат, играют в политику, подстраиваются под культуру, становятся частью культа.

2) Те, что оптимизируют, чтобы их не уволили. Делают минимум, играют в политику, подстраиваются под культуру, становятся частью культа, херачат только при возникновении опасности.

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

В корпорации не нужно 100% инициативного персонала. Кто-то должен сидеть на веслах.

Не тянет писать и читать о работе сейчас.

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

Вот парочка из сегодняшнего в моем вольном переводе:

Blaze Bayley, Iron Maiden:

Нам нужно заботиться о себе так, как мы заботимся о своих домашних животных.

Ну ведь так и есть. Своим собакам и детям мы плохого никогда не сделаем. Главные абьюзеры самих себя - это мы сами.

Дафф МакКеган, Guns N’Roses:

Если ты веришь в себя, ничто не может тебя остановить.

Мой слоган по жизни, который я тоже подсмотрел где-то в мемасике лет 10 назад: “I want it. Excuses are irrelevant.”

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

Нил Гейман, Neverwhere (Никогде):

У него было смутное ощущение, что он — нечто большее, чем просто тело и разум, нечто большее, с огромным потенциалом. Он мог быть кем угодно; он мог делать все, что захочет. А потом он проснулся и понял, что он — всего лишь Ричард Мэйхью.

Блин, ну как Гейман умеет описать ощущения людей. Прям английский Гришковец.

Просыпаешься утром и тебе море по колено первые несколько секунд. А потом кортизол начинает «возвращать тебя обратно в тело» со всеми страхами, стрессом и бытовыми проблемами.

Всех обнял ❤️

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

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

Когда увидел «мы всё переделали», мне захотелось ответить «уже боюсь!»

«Все переделали» обычно кайф только для разработчиков самого приложения. Какой разработчик не любит рефактор?

Пользователям же нужно переучиваться на новый интерфейс. Это оправдано, когда приложение до этого было безнадёжно кривое и терять нечего.

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

Интересно в целом вы как пользователь как бы отреагировали на «мы всё переделали» в приложении, к которому вы привыкли?

У меня кровь в жилах стынет.

P.S. Я об этом уже писал. Создатель Overcast до сих пор разгребает последствия редизайна.

Я почти созрел на платную подписку на ChatGPT. Пользуюсь им каждый день для написания кода.

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

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

Нужен совет от гиков по рабочим местам.

В Штатах у меня был монитор Dell 27" (не изогнутый). Меня в принципе всё устраивало. В офисе был Dell 32" изогнутый, мне не зашёл его размер. Не люблю крутить головой. По той же причине мне не зашла работа на 2 мониторах.

Хочу купить монитор. Выбор между двумя 27-дюймовыми самсунгами — G5 (изогнутый) и G3 (обычный плоский).

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

Мой основной юзкейс для монитора — экран поделённый пополам.

1) Слева IDE, справа терминал и симулятор/браузер с приложением.

2) Слева браузер с таблицами, справа среда для SQL.

3) Слева среда обработки аудио, справа браузер с гугл доком для заметок.

4) Слева Google Meet, справа гугл док с заметками.

Я не совсем представляю как это будет выглядеть на изогнутом 27" мониторе.

P.S. Не хотелось бы тратить слишком много.

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

У меня есть подруга, которую чуть не выслали обратно в Россию, после того, как её команда пожаловалась на неё в HR в Великобритании. Ей повезло, что это закончилось тем, что компания наняла ей коуча, благодаря которому она смогла увидеть свои неадекватности и вырасти.

У меня была обратная проблема. Я избегаю конфликтов. Мне всегда было некомфортно в нашей среде, когда я был молодой и принимал всё близко к сердцу.

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

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

За последний год я вынес для себя, что для стартапов не подходит ни тот, ни другой подход.

Токсичная "справедливость" разрушит отношения с кофаундером и первыми сотрудниками. Все и так в постоянном стрессе. Надо друг друга поддерживать.

"Нежный" подход слишком долгий. Люди не всегда с первого раза понимают суть такого фидбека, а на повторение нет времени.

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

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

"Мне не нравится, потому что..."

"Я прямо скажу, что я категорически не согласен, потому что..."

"Давай не будем тратить на это время, надо по-другому, потому что..."

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

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

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

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

Большинство проблем решаются сами по себе, если их активно не решать.

@ilyabezdelev_blog #софтскиллы

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

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

Ответ пришёл в выходные, когда слушал интервью с Ronnie Radke, вокалистом группы Falling in Reverse (послушайте Voices in My Head, если не знаете их). Он отсидел 2.5 года в тюрьме и в интервью честно поделился своим опытом привыкания к новой реальности и пост-травматического стресса после выхода на свободу.

Он сказал такую вещь (мой вольный перевод):

Когда в тюрьме становится тихо, назревает какая-то жопа.

У меня такое же отношение к работе. Если становится комфортно, значит, что-то идёт не так. Нужно срочно что-то менять, пока меня не накрыло. Бить на упреждение. Уходить из-под стрелы.

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

Таким образом, тревога — двигатель роста. Звучит как патология.

Я пока что на стадии неполного признания патологичности своего поведения. Не могу решить проблема это всё-таки или нет — постоянно что-то строить, потом ломать и снова перестраивать.

Мой контр-аргумент в том, что, если бы я постоянно всё не менял, то я бы жалел о том, что не попробовал (regret minimization framework от Джеффа Безоса). Но может это тоже лечится.

@ilyabezdelev_blog #карьера

Сложные разговоры с разработчиками

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

Фича была в OKR на ноябрь как "stretch" — это означает, что мы делаем её только если мы закончили всё, на что мы закоммитились. Но я решил всё равно её запилить заодно с другой фичей в том же файле...

Это всего лишь несколько строчек кода, у меня пара часов до конца рабочего дня... What could go wrong??

Мы оба согласились, что фичу лучше было запилить в другом месте (на бэкэнде вместо фронтенда), но упёрлись в камень преткновения.

Суть разногласия можно свести к фундаментальному принципу "что мы приоритизируем — скорость релиза или правильность кода?"

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

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

СТО: На бэкенде это почти так же легко, как на фронте. Почему сразу не сделать правильно?

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

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

СТО: Но это усложняет фронтенд... (мы начали ходить кругами)

Я: Этот код будет легко вырезать и заменить новым на бэкенде.

СТО: Зачем это нужно, если можно сразу сделать правильно?

Я: Но я уже сделал как сделал. Код на 90% готов. Давай шипнем уже.

СТО: Ок, но сделай X, Y & Z.

Я: Ок.

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

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

Работая со мной, мой СТО испытывает давление по скорости имплементации. Мы — не Амазон, где можно годами обтачивать код напильником. Нам нужны пользователи, готовые платить за ценность. Если бы мы оба были перфекционистами, мы бы до сих пор ничего не запустили в проде.

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

@ilyabezdelev_blog #разработка

Есть поговорка — “when in Rome, do as Romans do” — в Риме делай как Римляне.

Наверное, из-за того, что мне в жизни приходилось очень много переезжать (10 квартир и 3 школы к 16 годам), я научился очень хорошо подстраиваться под среду.

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

До сих пор себя за это прощаю 🙈

Итог «простого изменения» ради быстрой фичи:
- 500 измененных строк кода в 8 файлах
- 36 коммитов
- 173 комментария (самое большое из всех наших PR за полтора года)
- 2 часа на телефоне
- Неучтенное количество сообщений в чате
- Неделя календарного времени

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

И всё ради вот этого - в Metacast теперь можно кликать таймкоды в описании эпизода и прыгать на интересный кусок подкаста.

Фича пока в бете. Выкатим через неделю.