Делал у себя в сторис опрос при каком заряде батареи люди начинают тревожиться.
Сделал небольшой статистический анализ.
Я ожидал нормальное распределение в форме колокола вокруг 15% или типа того, но получился очень сильный перекос влево. Если убрать статистические выбросы (outliers), то распределение выглядит более-менее равномерным (нижний график).
Практическая ценность этого анализа ограничена. Разве что если вы продаёте пауэр-бэнки, то можно смело использовать 20% для нагнетания тревожности у своей целевой аудитории.
Кстати, интересно — при 20% индикатор зарядки в iOS становится красным, потому что в Apple знают, что люди естественным путем тревожатся при 20% или люди как раз-таки тревожатся, потому что Apple нас приучили, что 20% - это мало и можно начинать беспокоиться?
Материалы:
- Файл Google Sheets, если кто-то хочет взглянуть на формулы.
- Мой пост про статистику для продактов
Сделал небольшой статистический анализ.
Я ожидал нормальное распределение в форме колокола вокруг 15% или типа того, но получился очень сильный перекос влево. Если убрать статистические выбросы (outliers), то распределение выглядит более-менее равномерным (нижний график).
Практическая ценность этого анализа ограничена. Разве что если вы продаёте пауэр-бэнки, то можно смело использовать 20% для нагнетания тревожности у своей целевой аудитории.
Кстати, интересно — при 20% индикатор зарядки в iOS становится красным, потому что в Apple знают, что люди естественным путем тревожатся при 20% или люди как раз-таки тревожатся, потому что Apple нас приучили, что 20% - это мало и можно начинать беспокоиться?
Материалы:
- Файл Google Sheets, если кто-то хочет взглянуть на формулы.
- Мой пост про статистику для продактов
🔥10❤3
Кейс о том, как на первый взгляд простое изменение в UX оказывается весьма непростым из-за технических ограничений.
В нынешней версии Metacast, пользователь почти сразу видит экран, где можно или залогиниться, или войти как "гость". При этом, если юзер выбирает режим гостя, мы как можем запугиваем его тем, что можно потерять данные.
Когда только запускались, мы сильно хотели, чтобы люди создавали аккаунты. Изначально мы не хотели иметь даже гостевые аккаунты и добавили их уже в открытой бете по итогам фидбека от пользователей.
Мы получили прямую обратную связь, что некоторые люди попросту не хотят создавать аккаунт. После запуска мы также увидели в метриках, что 60% пользователей на этом этапе отваливаются. Это очень много.
И вот мы решили сделать так, чтобы, открывая приложение, у пользователя автоматически создавался гостевой аккаунт (прозрачно для него, это выглядит как будто аккаунта нет и приложение сразу готово к использованию), а потом уже, если они захотят, они могут создать полноценный аккаунт.
Техническое ограничение состоит в том, что мы используем Firebase и у любого пользователя обязательно на бэкенде создается аккаунт. К нему привязаны плейлисты, история прослушиваний и т.п. Гостевой аккаунт отличается от "нормального" тем, что, выйдя из него или удалив приложение, в него невозможно попасть обратно.
Может возникнуть вопрос — "а почему бы не хранить данные на устройстве пользователя?" Вопрос резонный, но для этого нужно создавать параллельную систему хранения данных или мигрировать с Firebase на другое решение.
Этот поезд ушёл. Поэтому работаем с ограничением, которое существует.
С точки зрения UX возникают осложнение, которого не было заметно на поверхности.
Если у пользователя раньше уже был аккаунт (например, он пользовался приложением давно, но забыл), а теперь хочет сконвертировать свой гостевой аккаунт в полноценный, что делать с данными, если оба аккаунта не пустые?
Если он выйдет из гостевого и залогинится в старый, он уже никогда не сможет получить доступ к гостевому аккаунту. Плюс нет технической возможности сделать превью, а что же там в другом аккаунте, чтобы решить, какой сохранить.
Один из вариантов решения этой задачи — сделать экспорт всех данных в текущем гостевом аккаунте и замёрджить (merge) их в старый. Другой — хотя бы проверить, потеряет ли пользователь данные в принципе, может аккаунт пустой и тогда снижается риск потери данных.
Вариантов несколько, один дороже другого.
В итоге мы решили, что на нашем масштабе это edge case и можно пока отложить оптимизацию (есть такой термин "преждевременная оптимизация" (premature optimization) — запомните его, разработчиков бесит, когда продакты его используют).
В данном случае я сам закодил это изменение, поэтому хорошо разобрался в том, как всё работало под капотом. Если бы я был просто продактом, то мне было бы очень полезно понять как работает система аутентификации и её ограничения, чтобы стоимость идеальной имплементации фичи не была шокирующей.
Как любит говорить мой папа, "учите матчасть". Понимание стэка в хозяйстве всегда пригодится.
@ilyabezdelev_blog #техническийпродактменеджмент
В нынешней версии Metacast, пользователь почти сразу видит экран, где можно или залогиниться, или войти как "гость". При этом, если юзер выбирает режим гостя, мы как можем запугиваем его тем, что можно потерять данные.
Когда только запускались, мы сильно хотели, чтобы люди создавали аккаунты. Изначально мы не хотели иметь даже гостевые аккаунты и добавили их уже в открытой бете по итогам фидбека от пользователей.
Мы получили прямую обратную связь, что некоторые люди попросту не хотят создавать аккаунт. После запуска мы также увидели в метриках, что 60% пользователей на этом этапе отваливаются. Это очень много.
И вот мы решили сделать так, чтобы, открывая приложение, у пользователя автоматически создавался гостевой аккаунт (прозрачно для него, это выглядит как будто аккаунта нет и приложение сразу готово к использованию), а потом уже, если они захотят, они могут создать полноценный аккаунт.
Техническое ограничение состоит в том, что мы используем Firebase и у любого пользователя обязательно на бэкенде создается аккаунт. К нему привязаны плейлисты, история прослушиваний и т.п. Гостевой аккаунт отличается от "нормального" тем, что, выйдя из него или удалив приложение, в него невозможно попасть обратно.
Может возникнуть вопрос — "а почему бы не хранить данные на устройстве пользователя?" Вопрос резонный, но для этого нужно создавать параллельную систему хранения данных или мигрировать с Firebase на другое решение.
Этот поезд ушёл. Поэтому работаем с ограничением, которое существует.
С точки зрения UX возникают осложнение, которого не было заметно на поверхности.
Если у пользователя раньше уже был аккаунт (например, он пользовался приложением давно, но забыл), а теперь хочет сконвертировать свой гостевой аккаунт в полноценный, что делать с данными, если оба аккаунта не пустые?
Если он выйдет из гостевого и залогинится в старый, он уже никогда не сможет получить доступ к гостевому аккаунту. Плюс нет технической возможности сделать превью, а что же там в другом аккаунте, чтобы решить, какой сохранить.
Один из вариантов решения этой задачи — сделать экспорт всех данных в текущем гостевом аккаунте и замёрджить (merge) их в старый. Другой — хотя бы проверить, потеряет ли пользователь данные в принципе, может аккаунт пустой и тогда снижается риск потери данных.
Вариантов несколько, один дороже другого.
В итоге мы решили, что на нашем масштабе это edge case и можно пока отложить оптимизацию (есть такой термин "преждевременная оптимизация" (premature optimization) — запомните его, разработчиков бесит, когда продакты его используют).
В данном случае я сам закодил это изменение, поэтому хорошо разобрался в том, как всё работало под капотом. Если бы я был просто продактом, то мне было бы очень полезно понять как работает система аутентификации и её ограничения, чтобы стоимость идеальной имплементации фичи не была шокирующей.
Как любит говорить мой папа, "учите матчасть". Понимание стэка в хозяйстве всегда пригодится.
@ilyabezdelev_blog #техническийпродактменеджмент
👍25❤8😁2
Илья Безделев: лытдыбр о работе
Я почти созрел на платную подписку на ChatGPT. Пользуюсь им каждый день для написания кода. Он всё ещё делает много ошибок и галлюцинирует, но он часто дает мне подсказки, благодаря которым я быстрее нахожу решения + учит меня + помогает искать ошибки в коде.…
Вчера оформил платную подписку на ChatGPT Plus за $20. Цена, конечно, кусачая, но ощущение, что я отбил эти деньги за один вечер.
Закинул в чат транскрипт нашего последнего эпизода подкаста и попросил LLM извлечь из него предложения для постов, которые могут быть интересны аудитории из стартаперов и разработчиков.
Потом попросил его написать эти посты, используя мою лексику из транскрипции, не добавляя лишнего.
Получилось на 70% окей. Пришлось поиграться с запросами, чтобы он не добавлял свою типичную кринжатину.
Он написал мне 4 поста и я потратил около часа на правки. Раньше каждый пост занял бы час. Плюс не все из этих идей я бы вспомнил и не все из них я бы смог подать в таком же ключе. Он подсказал мне идеи для фрейминга. Научил меня новому.
Запостил их на LinkedIn. Посмотрим как пойдут.
Также использовал чат для формирования summary эпизода и списка топиков с таймкодами. Я раньше тратил на это не то чтобы слишком много времени, но меня раздражала эта работа, я отвлекался и выходил из состояния потока.
Ещё использовал чат, чтобы разобраться с математическими концепциями из олимпиадных задач. Разница между бесплатной и платной версией - как между BMW и трехколёсным велосипедом. Причем, на русском языке!
Покодить с платной подпиской еще не успел. Жду не дождусь завтрашнего рабочего дня.
Закинул в чат транскрипт нашего последнего эпизода подкаста и попросил LLM извлечь из него предложения для постов, которые могут быть интересны аудитории из стартаперов и разработчиков.
Потом попросил его написать эти посты, используя мою лексику из транскрипции, не добавляя лишнего.
Получилось на 70% окей. Пришлось поиграться с запросами, чтобы он не добавлял свою типичную кринжатину.
Он написал мне 4 поста и я потратил около часа на правки. Раньше каждый пост занял бы час. Плюс не все из этих идей я бы вспомнил и не все из них я бы смог подать в таком же ключе. Он подсказал мне идеи для фрейминга. Научил меня новому.
Запостил их на LinkedIn. Посмотрим как пойдут.
Также использовал чат для формирования summary эпизода и списка топиков с таймкодами. Я раньше тратил на это не то чтобы слишком много времени, но меня раздражала эта работа, я отвлекался и выходил из состояния потока.
Ещё использовал чат, чтобы разобраться с математическими концепциями из олимпиадных задач. Разница между бесплатной и платной версией - как между BMW и трехколёсным велосипедом. Причем, на русском языке!
Покодить с платной подпиской еще не успел. Жду не дождусь завтрашнего рабочего дня.
🔥42👍10❤8
Сегодня целый день потратил на прохождения курса Learn Next.js от создателей фреймворка (компания Vercel).
Курс покрывает создание веб-приложения с данными в Postgres и аутентификацией. Также немного затрагивается TailwindCSS. Для прохождения требуются основы TypeScript и React.
Мне зашло, рекомендую. Голова гудит, но закончил курс за день, почти не отвлекаясь и это меня радует.
Следующим шагом переведу свой личный сайт на Next.js, мигрирую туда веб-блог и подкаст, добавлю механизмы оплаты за свои услуги (чтобы не принимать деньги переводами) и создам портал для пользователей, где можно будет запланировать консультации и пройти курсы.
Курс покрывает создание веб-приложения с данными в Postgres и аутентификацией. Также немного затрагивается TailwindCSS. Для прохождения требуются основы TypeScript и React.
Мне зашло, рекомендую. Голова гудит, но закончил курс за день, почти не отвлекаясь и это меня радует.
Следующим шагом переведу свой личный сайт на Next.js, мигрирую туда веб-блог и подкаст, добавлю механизмы оплаты за свои услуги (чтобы не принимать деньги переводами) и создам портал для пользователей, где можно будет запланировать консультации и пройти курсы.
🔥22👍8
Меня задолбали подписки.
Есть сервисы, на которые не жалко тратиться ежемесячно. YouTube Premium, ChatGPT, Google One, Spotify, Metacast, Bear, 1Password, iCloud, GitHub— я использую эти сервисы почти каждый день и платить за них мне не западло.
Но есть сервисы, которыми пользуюсь редко или мало и платить за них хочется как-то соотвествующе — пропорционально степени использования.
Сегодня смотрел API для отправки емейлов пользователям SendGrid, Resend, Postmark. У них всех ограниченный бесплатный тариф, а потом сразу скачок на $20 в месяц за базовый план, в который включены десятки тысяч емейлов, которые мне не нужны.
Адекватная стоимость для меня была бы в районе 2-3 долларов в месяц или даже меньше.
Но ценообразование облачных сервисов - хитрая штука.
Слишком много тарифов - пользователь запутается и вообще ничего не купит. Купит у тех, у кого проще.
Сделаешь тарификацию pay as you go - часть пользователей запутается (тру стори, это было в моей практике при работе в GCP), другая будет переплачивать, третья будет хотеть предсказуемости, а при небольшом масштабе это ещё может быть и неприбыльно.
Фиксированные тарифы - как подписки на спортзал.
Будет несколько человек, которые будут использовать все тренажеры в хвост и гриву. Если бы все пользователи были такими, инфраструктура сервиса попросту бы не справлялась и они бы работали в ноль или даже в минус.
К счастью для вендоров большинство платных пользователей пользуются от силы 20% лимита. Их платежи почти полностью - валовая прибыль (gross margin, выручка за вычетом стоимости инфраструктуры). Так и живут на «сдачу».
В поисках необходимого мне сервиса для отправки емейлов (для подтверждения адресов электронной почты, напоминаний об ивентах и т.п.), я вспомнил про старый добрый Amazon Simple Email Service (SES), который берет по 10 центов за 1000 отправленных емейлов. SES, наверняка, сильно уступает по фичам и удобству SendGrid, но для моего use case они не нужны. А ради более низкой стоимости можно немного потерпеть неудобства на этапе конфигурации.
У меня нет цифр, но я больше чем уверен, что сервис сам по себе убыточный (с учетом стоимости сотрудников для его поддержки), но он является ценным компонентом экосистемы AWS.
Им-то и воспользуюсь, а заодно посмотрю что там ещё у AWS хорошего есть. Я хотел для своего проекта использовать гугловский Firestore (база данных NoSQL), но раз уж все равно создавать аккаунт в AWS, есть смысл рассмотреть DynamoDB. По деньгам будет плюс-минус то же самое, но два облачных гиперскейлера в стеке - это операционный гемор.
Потыкаюсь в SES и отпишусь. 5 лет не пользовался AWS. Уверен, что интерфейс за это время стал только хуже 😬
Есть сервисы, на которые не жалко тратиться ежемесячно. YouTube Premium, ChatGPT, Google One, Spotify, Metacast, Bear, 1Password, iCloud, GitHub— я использую эти сервисы почти каждый день и платить за них мне не западло.
Но есть сервисы, которыми пользуюсь редко или мало и платить за них хочется как-то соотвествующе — пропорционально степени использования.
Сегодня смотрел API для отправки емейлов пользователям SendGrid, Resend, Postmark. У них всех ограниченный бесплатный тариф, а потом сразу скачок на $20 в месяц за базовый план, в который включены десятки тысяч емейлов, которые мне не нужны.
Адекватная стоимость для меня была бы в районе 2-3 долларов в месяц или даже меньше.
Но ценообразование облачных сервисов - хитрая штука.
Слишком много тарифов - пользователь запутается и вообще ничего не купит. Купит у тех, у кого проще.
Сделаешь тарификацию pay as you go - часть пользователей запутается (тру стори, это было в моей практике при работе в GCP), другая будет переплачивать, третья будет хотеть предсказуемости, а при небольшом масштабе это ещё может быть и неприбыльно.
Фиксированные тарифы - как подписки на спортзал.
Будет несколько человек, которые будут использовать все тренажеры в хвост и гриву. Если бы все пользователи были такими, инфраструктура сервиса попросту бы не справлялась и они бы работали в ноль или даже в минус.
К счастью для вендоров большинство платных пользователей пользуются от силы 20% лимита. Их платежи почти полностью - валовая прибыль (gross margin, выручка за вычетом стоимости инфраструктуры). Так и живут на «сдачу».
В поисках необходимого мне сервиса для отправки емейлов (для подтверждения адресов электронной почты, напоминаний об ивентах и т.п.), я вспомнил про старый добрый Amazon Simple Email Service (SES), который берет по 10 центов за 1000 отправленных емейлов. SES, наверняка, сильно уступает по фичам и удобству SendGrid, но для моего use case они не нужны. А ради более низкой стоимости можно немного потерпеть неудобства на этапе конфигурации.
У меня нет цифр, но я больше чем уверен, что сервис сам по себе убыточный (с учетом стоимости сотрудников для его поддержки), но он является ценным компонентом экосистемы AWS.
Им-то и воспользуюсь, а заодно посмотрю что там ещё у AWS хорошего есть. Я хотел для своего проекта использовать гугловский Firestore (база данных NoSQL), но раз уж все равно создавать аккаунт в AWS, есть смысл рассмотреть DynamoDB. По деньгам будет плюс-минус то же самое, но два облачных гиперскейлера в стеке - это операционный гемор.
Потыкаюсь в SES и отпишусь. 5 лет не пользовался AWS. Уверен, что интерфейс за это время стал только хуже 😬
😁15👍7❤4
Мне пришло понимание, почему я не воспринимаю российский big tech как tech. Для меня весь российский tech кроме Яндекса — это "бизнес с айти", а не "technology".
Я как-то слышал фразу от сотрудника раннего Амазона, что до появления AWS, Амазон по большому счёту был интернет-магазином с отделом разработки.
Только когда Амазон начал создавать новые технологии и платформы — свои ЦОД, электронные читалки Kindle, облачные сервисы, Alexa — он стал по-настоящему технологической компанией. Только тогда непосредственно технологические разработки стали либо продуктом, либо платформой для продукта, которые очень сложно скопировать, не имея технологий.
Банк, интернет-магазин или сайт объявлений с ИТ-отделом используют созданный другими технологический фундамент для достижения своих бизнес-целей. То есть это в первую очередь бизнес, а какой уж там стек под капотом — вторично.
Это крутые бизнесы, но их конкурентное преимущество — в процессах, маркетинге и партнёрствах. Приложения и сайты попросту отражают эти процессы.
Команда сильных программистов сможет скопировать стек Авито, Т-Банк и Озон (смогут ли они достигнуть масштаба — это другой вопрос, скорее всего, нет). Однако, команда сильных программистов не сможет скопировать и создать с нуля поиск Яндекса, операционную систему Windows (Microsoft), LLM (OpenAI), Kubernetes (Google), Lambda (AWS) или фреймворк React (запрещённая соц сеть), когда в мире ещё нет аналогов, которые можно скопировать.
Помимо умения писать код и комбинировать современные технологии в продукт, такие платформы требуют глубокой технической экспертизы в узком домене. И дело даже не в том джун программист или синиор. Требуется другой подход — программисты в компаниях с ИТ-отделами решают прикладные задачи, а в настоящем tech есть группы людей (далеко не все!), которые занимаются computer science и создают то, чем потом пользуются все.
Я был в нескольких митингах с Марком Брукером, создателем AWS Lambda, у которого больше патентов, чем у кого-либо в Амазоне. Сейчас он Distinguished Engineer (его коллеги по цеху в Амазоне, это такие люди как Джеймс Гослинг, создатель Java). Это человек с другой планеты. Он по-другому мыслит.
Я не утверждаю, что одни компании лучше других. Они просто разные. И те, и другие в первую очередь зарабатывают деньги. Но разница в подходе позволяет по-настоящему технологическим компаниям становиться мировыми лидерами, потому что их технологии становятся платформами для всех остальных, в то время как бизнес, который "просто" бизнес — привязан к одной компании или даже к одной географии.
Я как-то слышал фразу от сотрудника раннего Амазона, что до появления AWS, Амазон по большому счёту был интернет-магазином с отделом разработки.
Только когда Амазон начал создавать новые технологии и платформы — свои ЦОД, электронные читалки Kindle, облачные сервисы, Alexa — он стал по-настоящему технологической компанией. Только тогда непосредственно технологические разработки стали либо продуктом, либо платформой для продукта, которые очень сложно скопировать, не имея технологий.
Банк, интернет-магазин или сайт объявлений с ИТ-отделом используют созданный другими технологический фундамент для достижения своих бизнес-целей. То есть это в первую очередь бизнес, а какой уж там стек под капотом — вторично.
Это крутые бизнесы, но их конкурентное преимущество — в процессах, маркетинге и партнёрствах. Приложения и сайты попросту отражают эти процессы.
Команда сильных программистов сможет скопировать стек Авито, Т-Банк и Озон (смогут ли они достигнуть масштаба — это другой вопрос, скорее всего, нет). Однако, команда сильных программистов не сможет скопировать и создать с нуля поиск Яндекса, операционную систему Windows (Microsoft), LLM (OpenAI), Kubernetes (Google), Lambda (AWS) или фреймворк React (запрещённая соц сеть), когда в мире ещё нет аналогов, которые можно скопировать.
Помимо умения писать код и комбинировать современные технологии в продукт, такие платформы требуют глубокой технической экспертизы в узком домене. И дело даже не в том джун программист или синиор. Требуется другой подход — программисты в компаниях с ИТ-отделами решают прикладные задачи, а в настоящем tech есть группы людей (далеко не все!), которые занимаются computer science и создают то, чем потом пользуются все.
Я был в нескольких митингах с Марком Брукером, создателем AWS Lambda, у которого больше патентов, чем у кого-либо в Амазоне. Сейчас он Distinguished Engineer (его коллеги по цеху в Амазоне, это такие люди как Джеймс Гослинг, создатель Java). Это человек с другой планеты. Он по-другому мыслит.
Я не утверждаю, что одни компании лучше других. Они просто разные. И те, и другие в первую очередь зарабатывают деньги. Но разница в подходе позволяет по-настоящему технологическим компаниям становиться мировыми лидерами, потому что их технологии становятся платформами для всех остальных, в то время как бизнес, который "просто" бизнес — привязан к одной компании или даже к одной географии.
🔥46💯16👍9❤5
Меня спросили в комменте типа «не пойдешь в русский тех?»
Я подумал, подумал и наверное пошел бы куда-то пилить API-first продукт для разработчиков как CPO.
Я подумал, подумал и наверное пошел бы куда-то пилить API-first продукт для разработчиков как CPO.
🔥8
В бизнес-жаргоне много военных терминов. Есть они и в айти.
Я большой фанат т.н. "трассирующих пуль" (tracer bullets). В автоматическом оружии в ленте с боеприпасами с определенной периодичностью размещены пули, которые оставляют за собой след. Стрелок видит глазами траекторию очереди и это помогает ему калиброваться в реальном времени.
В книге The Pragmatic Programmer, Дейв Томас и Эндрю Хант говорят о применении этого подхода к разработке. Вместо того, чтобы пилить софт пошагово и сразу правильно, сначала нужно создать его каркас, работающий от и до (end-to-end).
Не просто прототип на выброс, а именно каркас. Условно фронтенд на реакте с одним полем в форме и кнопкой, при нажатии на которую триггерится API на бэкенде, который переправляет данные в какой-нибудь легаси сервис, который пишет в базу данных. Всё очень примитивно, но функционально помогает проверить, что данные "текут", политики безопасности работают, технические возможности валидированы. Мы видим, что "пули" летят в верном направлении.
По мере разработки мы наполняем каркас, постоянно проверяя, что всё работает.
Противоположный подход — запилить компоненты по отдельности, а потом пытаться их интегрировать, выявляя несовместимости на стадии, когда переделывать их дорого и больно.
Я большой фанат т.н. "трассирующих пуль" (tracer bullets). В автоматическом оружии в ленте с боеприпасами с определенной периодичностью размещены пули, которые оставляют за собой след. Стрелок видит глазами траекторию очереди и это помогает ему калиброваться в реальном времени.
В книге The Pragmatic Programmer, Дейв Томас и Эндрю Хант говорят о применении этого подхода к разработке. Вместо того, чтобы пилить софт пошагово и сразу правильно, сначала нужно создать его каркас, работающий от и до (end-to-end).
Не просто прототип на выброс, а именно каркас. Условно фронтенд на реакте с одним полем в форме и кнопкой, при нажатии на которую триггерится API на бэкенде, который переправляет данные в какой-нибудь легаси сервис, который пишет в базу данных. Всё очень примитивно, но функционально помогает проверить, что данные "текут", политики безопасности работают, технические возможности валидированы. Мы видим, что "пули" летят в верном направлении.
По мере разработки мы наполняем каркас, постоянно проверяя, что всё работает.
Противоположный подход — запилить компоненты по отдельности, а потом пытаться их интегрировать, выявляя несовместимости на стадии, когда переделывать их дорого и больно.
🔥19❤11
Всегда был оверачивером. Знаете какая самая большая проблема у оверачиверов?
Мы считаем себя недоачиверами.
Всегда ощущение, что можно больше. Что что-то упущено. Мало.
Можно сказать «не парься». Но это как сказать человеку с РПП «ну ты просто перестань есть». Как сказать алкашу «ты просто перестань пить».
Это не плохо. Это наша природа. Бросаться в среднем возрасте во все тяжкие и уходить в дзен может быть деструктивно.
Нужно просто учиться использовать эту энергию умеренно и лишний раз себя не гнобить. Радоваться тому, что уже получилось. Просто знать, что в будущем тоже получится, не загоняя себя в яму тревожностью.
Жить в настоящем.
Мы считаем себя недоачиверами.
Всегда ощущение, что можно больше. Что что-то упущено. Мало.
Можно сказать «не парься». Но это как сказать человеку с РПП «ну ты просто перестань есть». Как сказать алкашу «ты просто перестань пить».
Это не плохо. Это наша природа. Бросаться в среднем возрасте во все тяжкие и уходить в дзен может быть деструктивно.
Нужно просто учиться использовать эту энергию умеренно и лишний раз себя не гнобить. Радоваться тому, что уже получилось. Просто знать, что в будущем тоже получится, не загоняя себя в яму тревожностью.
Жить в настоящем.
❤43🔥11👍7
Есть выражение “the grass is always greener on the other side”, символизирующее побег от текущей реальности в реальность воображаемую, где непременно ждёт разочарование.
На другой работе будет лучше. В другой стране будет лучше. С другим человеком в отношениях будет лучше.
Те из нас, кто уже пожил достаточно на этом свете, знают, что иногда это действительно так, но чаще — совсем не так.
Другая работа — такое же болото. В другой стране всё так же через ж.пу, только по-другому. Другой человек такой же абьюзер.
Скролля ленту, я наткнулся на фразу, которая имхо всегда должна следовать за той, с которой я начал пост.
Это так просто и так гениально. Трава зеленее там, где мы её поливаем.
Искать хорошее в том, что есть. Менять то, что не нравится. Постригать и поливать свой газон вместо того, чтобы искать новый, как только на твоём завяли цветы.
Цветы завяли не потому что они плохие. А потому что ты не ухаживал за ними.
Да, на твоем газоне могут быть сорняки, тля и клопы. Так они есть и на другом газоне. Просто хорошо прячутся, когда смотришь на них через розовые очки.
Искусство жизни — в том, чтобы регулярно отлавливать клопов-вонючек и удалять их со своего газона, поливать траву и полоть её от сорняков.
Ключевое слово — регулярно.
Я очень люблю фразу “do what you love, love what you do”. Её суть в том, чтобы относиться к тому, что есть, с заботой и любовью. Когда любишь то, что делаешь, ты начинаешь делать то, что любишь.
Всем пис и хорошего начала рабочей недели ❤️
На другой работе будет лучше. В другой стране будет лучше. С другим человеком в отношениях будет лучше.
Те из нас, кто уже пожил достаточно на этом свете, знают, что иногда это действительно так, но чаще — совсем не так.
Другая работа — такое же болото. В другой стране всё так же через ж.пу, только по-другому. Другой человек такой же абьюзер.
Скролля ленту, я наткнулся на фразу, которая имхо всегда должна следовать за той, с которой я начал пост.
The grass is greener where you water it.
Это так просто и так гениально. Трава зеленее там, где мы её поливаем.
Искать хорошее в том, что есть. Менять то, что не нравится. Постригать и поливать свой газон вместо того, чтобы искать новый, как только на твоём завяли цветы.
Цветы завяли не потому что они плохие. А потому что ты не ухаживал за ними.
Да, на твоем газоне могут быть сорняки, тля и клопы. Так они есть и на другом газоне. Просто хорошо прячутся, когда смотришь на них через розовые очки.
Искусство жизни — в том, чтобы регулярно отлавливать клопов-вонючек и удалять их со своего газона, поливать траву и полоть её от сорняков.
Ключевое слово — регулярно.
Я очень люблю фразу “do what you love, love what you do”. Её суть в том, чтобы относиться к тому, что есть, с заботой и любовью. Когда любишь то, что делаешь, ты начинаешь делать то, что любишь.
Всем пис и хорошего начала рабочей недели ❤️
❤84🔥15💯7👍4😁1
Илья Безделев: лытдыбр о работе
Есть выражение “the grass is always greener on the other side”, символизирующее побег от текущей реальности в реальность воображаемую, где непременно ждёт разочарование. На другой работе будет лучше. В другой стране будет лучше. С другим человеком в отношениях…
В комментах был хороший поинт про то, что важны и климатические условия для травы. То есть иногда всё же нужно пойти на другое поле.
С этим согласен 100%.
Присказка про траву актуальна в ситуациях, когда вы перемещаетесь внутри одного климата. Условно, перепрыгнули из одно технобанка в другой в Москве. Или перешли из Амазона в Микрософт. Если переходите на одну и ту же должность, убегая от того, что не нравилось в первом месте, во втором вероятно будет почти то же самое.
Если вы уезжаете из провинции покорять Москву или западное побережье США, то это качественный скачок (step function change), которого невозможно достигнуть в вашей локации/индустрии. Если уходите из QA в разработку, потому что хотите создавать, а не проверять чужой код, это тоже качественный скачок.
Трава на новом месте не обязательно будет зеленее во всех её проявлениях. Но вы попадаете на качественно иной луг. Отказываетесь от одуванчиков ради пышной тропической растительности.
Пальмы вам тоже могут остоп.здеть и захочется обратно в берёзки, но если ваша цель — побыть Индианой Джонсом, то такие скачки того стоят. К берёзкам можно всегда вернуться, а сожаления о неувиденных пальмах будут терзать до самой смерти.
С этим согласен 100%.
Присказка про траву актуальна в ситуациях, когда вы перемещаетесь внутри одного климата. Условно, перепрыгнули из одно технобанка в другой в Москве. Или перешли из Амазона в Микрософт. Если переходите на одну и ту же должность, убегая от того, что не нравилось в первом месте, во втором вероятно будет почти то же самое.
Если вы уезжаете из провинции покорять Москву или западное побережье США, то это качественный скачок (step function change), которого невозможно достигнуть в вашей локации/индустрии. Если уходите из QA в разработку, потому что хотите создавать, а не проверять чужой код, это тоже качественный скачок.
Трава на новом месте не обязательно будет зеленее во всех её проявлениях. Но вы попадаете на качественно иной луг. Отказываетесь от одуванчиков ради пышной тропической растительности.
Где пальме хорошо, там берёзе смерть :)
- (из комментов)
Пальмы вам тоже могут остоп.здеть и захочется обратно в берёзки, но если ваша цель — побыть Индианой Джонсом, то такие скачки того стоят. К берёзкам можно всегда вернуться, а сожаления о неувиденных пальмах будут терзать до самой смерти.
🔥28👍7💯4❤3
Год назад нам бесплатно сделали сайт. На тот момент у нас не доходили руки и кстати попался молодой парень, который предложил поработать забесплатно, за опыт.
Мы согласились. Сайт вышел норм. Мы даже по ходу дела добавляли туда страницы и потихоньку его развивали. Благодаря SEO, он начинает привлекать пользователей в приложение.
В процессе мы видели, что в какой-то момент потребуется рефакторинг всего сайта. У него нет постоянства в разметке, цвета захардкожены прямо в разметке, много повторяющегося кода, используются растровые изображения вместо SVG в оформлении…
Но оно кагбэ работало да и ладно.
Сейчас, когда мне нужно было внести очередные изменения, я понял, что больше так жить невозможно. И затеял массовый рефакторинг, на который ушло уже 3 дня и уйдет ещё пара дней.
Пока Арнаб колесит по западному побережью в роадтрипе, подготовлю ему PR на 2000 строк, который можно не ревьювить.
Потестим в проде.
Мы согласились. Сайт вышел норм. Мы даже по ходу дела добавляли туда страницы и потихоньку его развивали. Благодаря SEO, он начинает привлекать пользователей в приложение.
В процессе мы видели, что в какой-то момент потребуется рефакторинг всего сайта. У него нет постоянства в разметке, цвета захардкожены прямо в разметке, много повторяющегося кода, используются растровые изображения вместо SVG в оформлении…
Но оно кагбэ работало да и ладно.
Сейчас, когда мне нужно было внести очередные изменения, я понял, что больше так жить невозможно. И затеял массовый рефакторинг, на который ушло уже 3 дня и уйдет ещё пара дней.
Пока Арнаб колесит по западному побережью в роадтрипе, подготовлю ему PR на 2000 строк, который можно не ревьювить.
Потестим в проде.
😁23❤14😱3
В тему предыдущего поста.
ChatGPT умеет генерировать новые и видоизменять существующие SVG!
Если не знакомы с форматом - это формат изображения, в котором прописываются «пути движения» геометрических фигур в формате, для понимания которого нужна твердая шестерка по геометрии.
Это улёт, ребята. Я в восторге.
ChatGPT умеет генерировать новые и видоизменять существующие SVG!
Если не знакомы с форматом - это формат изображения, в котором прописываются «пути движения» геометрических фигур в формате, для понимания которого нужна твердая шестерка по геометрии.
<svg width="100" height="80" viewBox="0 0 100 80" xmlns="http://www.w3.org/2000/svg">
<path d="M10 20 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
<path d="M10 40 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
<path d="M10 60 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
</svg>
Я просил его сгенерировать мне иконку для гамбургерного меню для мобильного сайта. Я просил его растянуть существующее изображение, чтобы оно стало шире.Это улёт, ребята. Я в восторге.
👍12🔥5❤1
Анекдот от чат жпт.
И ещё один
Приходит как-то продакт-менеджер к разработчику и говорит:
— Ну-ка, отгадай загадку: «Без кода, без тестов, на проде фичи работают».
Разработчик думал-думал и говорит:
— Баги!
— Нет, это костыль! Ладно, вот тебе ещё одна загадка: «Два коммита, один пуш, а посередине деплой».
Разработчик долго думал и говорит:
— Баги!
— Нет, это CI/CD!
Продакт-менеджер ушёл, а разработчик решил проверить джуна. Пока шёл, всё в голове перепутал. Приходит к джуну и говорит:
— А ну, отгадай загадку: «Без кода, без пуша, полна жопа багов».
Джун в замешательстве:
— Что-то не то, кажется…
Разработчик:
— Вот и я думаю, что не то, а продакт-менеджер говорит, CI/CD!
И ещё один
Приходит как-то продакт-менеджер к разработчику и говорит:
— Ну-ка, отгадай загадку: «Без ТЗ, без сроков, но задача на вчера».
Разработчик думал-думал и говорит:
— Это твоё устное требование!
— Нет, это agile! Ладно, вот ещё одна загадка: «Два экрана, три кнопки, а багов миллион».
Разработчик долго думал и говорит:
— Это твоё требование!
— Нет, это MVP!
Продакт-менеджер ушёл, а разработчик пошёл к джуну проверить, как тот соображает. Пока шёл, в голове всё перепутал. Приходит к джуну и говорит:
— А ну, отгадай загадку: «Без сроков, без экранов, полна жопа багов».
Джун растерялся:
— Что-то чушь какая-то…
Разработчик:
— Вот и я думаю, что чушь, а продакт-менеджер говорит, agile!
😁39🔥10
Илья Безделев: лытдыбр о работе
Год назад нам бесплатно сделали сайт. На тот момент у нас не доходили руки и кстати попался молодой парень, который предложил поработать забесплатно, за опыт. Мы согласились. Сайт вышел норм. Мы даже по ходу дела добавляли туда страницы и потихоньку его…
А как прошла ваша неделя?
P.S. Я чёт надеялся, что удалённого кода будет больше, чем нового. Но я добавил пару фич по ходу дела, поэтому не вышел из меня мега-сеньор, который удаляет кода больше, чем пишет.
P.S. Я чёт надеялся, что удалённого кода будет больше, чем нового. Но я добавил пару фич по ходу дела, поэтому не вышел из меня мега-сеньор, который удаляет кода больше, чем пишет.
😱5👍3
Кто-нибудь знает какие фреймворки для мобильных приложений используют Т-Банк, Сбер, Озон и Авито?
Приложения выглядят одинаково как под копирку. Стало интересно.
Приложения выглядят одинаково как под копирку. Стало интересно.