Хвастаюсь
Мы с Марьяной собрали чатик из выпускников наших курсов — ребята там делятся опытом, дают советы о переезде и управлении командой, нетворкают и всё такое. Так вот, отзывы в чатике — огонь, я прямо загордился.
P.S. Если хотите в чатик — закончите хотя бы один наш курс, к примеру «Асинхронную Архитектуру»: VIP-тарифа уже не осталось, но можно успеть «в тусовке» или пройти самостоятельно. Стартуем послезавтра!
Мы с Марьяной собрали чатик из выпускников наших курсов — ребята там делятся опытом, дают советы о переезде и управлении командой, нетворкают и всё такое. Так вот, отзывы в чатике — огонь, я прямо загордился.
P.S. Если хотите в чатик — закончите хотя бы один наш курс, к примеру «Асинхронную Архитектуру»: VIP-тарифа уже не осталось, но можно успеть «в тусовке» или пройти самостоятельно. Стартуем послезавтра!
Как поменялось моё отношение к огородикам
С 2018 года я публично ругаю привычку многих админов тащить с собой ИТ-инфраструктуру: поднимать локальные GitLab и Sentry, использовать собственные сервисы вместо PaaS, DBaaS и прочих -aaS. После 24 февраля меня стали спрашивать, насколько поменялось моё отношение к внешним сервисам, многие из которых в один момент взяли и перестали обслуживать (российскую) часть своих пользователей.
Ответил в блоге
С 2018 года я публично ругаю привычку многих админов тащить с собой ИТ-инфраструктуру: поднимать локальные GitLab и Sentry, использовать собственные сервисы вместо PaaS, DBaaS и прочих -aaS. После 24 февраля меня стали спрашивать, насколько поменялось моё отношение к внешним сервисам, многие из которых в один момент взяли и перестали обслуживать (российскую) часть своих пользователей.
Ответил в блоге
Блог Фёдора Борщёва
Как поменялось моё отношение к огородикам
С 2018 года я публично ругаю привычку многих админов тащить с собой ИТ-инфраструктуру: поднимать локальные GitLab и Sentry, использовать собственные сервисы вместо PaaS, DBaaS и прочих -aaS. После 24 февраля меня стали спрашивать, насколько поменялось моё…
YubiKey не нужен
Я обожаю инфобезапосность — работаю под ВПН, у меня везде настроена двухфакторная аунтификация, зашифрованы жёсткие диски, я подписываю GPG свои коммиты, и пароль на телефоне у меня из 10 символов разного регистра. Работа у меня довольно мирная — скорее я это делаю просто потому, что могу.
Недавно решил ещё улучшить безопасность и купил себе YubiKey. Кто не знает — это такой железный второй фактор аунтификации — вместо ввода пароля из SMS или Google Authenticator просто вставляем ключ и нажимаем кнопочку — и всё, мы залогинились. Ожидал от него дополнительного уровня безопасности — типа если нет доступа к ключику, то нельзя войти в мой аккаунт даже если знаешь пароль и TOTP.
Оказалось, что в реальном мире это не работает. Во-первых, ни один сервис (кроме разве что Binance) не позволяет использовать хардверный ключ как единственный способ подтвердить действие — GitHub, Heroku, FastMail и Cloudflare во всех местах, где просят нажать кнопку на ключе, делают скромную приписку «или введите одноразовый пароль».
Во-вторых, оказывается в Mac уже давно встроена поддержка WebAuthn (это стандарт, по которому работают такие токены через браузер), и называется она Touch ID: зайдите на webauthn.io с компьютера или телефона и удивитесь. Получается, с такими же трудозатратами можно настроить всё, чтобы логиниться не через ключик, а через отпечаток пальца! Безопасность такая же, а удобство выше — не надо ничего таскать с собой.
Не будьте как я — не выкидывайте деньги на YubiKey.
Я обожаю инфобезапосность — работаю под ВПН, у меня везде настроена двухфакторная аунтификация, зашифрованы жёсткие диски, я подписываю GPG свои коммиты, и пароль на телефоне у меня из 10 символов разного регистра. Работа у меня довольно мирная — скорее я это делаю просто потому, что могу.
Недавно решил ещё улучшить безопасность и купил себе YubiKey. Кто не знает — это такой железный второй фактор аунтификации — вместо ввода пароля из SMS или Google Authenticator просто вставляем ключ и нажимаем кнопочку — и всё, мы залогинились. Ожидал от него дополнительного уровня безопасности — типа если нет доступа к ключику, то нельзя войти в мой аккаунт даже если знаешь пароль и TOTP.
Оказалось, что в реальном мире это не работает. Во-первых, ни один сервис (кроме разве что Binance) не позволяет использовать хардверный ключ как единственный способ подтвердить действие — GitHub, Heroku, FastMail и Cloudflare во всех местах, где просят нажать кнопку на ключе, делают скромную приписку «или введите одноразовый пароль».
Во-вторых, оказывается в Mac уже давно встроена поддержка WebAuthn (это стандарт, по которому работают такие токены через браузер), и называется она Touch ID: зайдите на webauthn.io с компьютера или телефона и удивитесь. Получается, с такими же трудозатратами можно настроить всё, чтобы логиниться не через ключик, а через отпечаток пальца! Безопасность такая же, а удобство выше — не надо ничего таскать с собой.
Не будьте как я — не выкидывайте деньги на YubiKey.
Не планировать на последний момент
Типичная ошибка планирования начинающих программистов (и вообще любых исполнителей) — планировать работу на последний момент. Типа обещал ты в четверг на следующей неделе показать работу, и почему-то в голове думаешь, что в сделаешь её в среду.
Этого не будет. В лучшем случае в среду ночью ты будешь дочинивать десятый неожиданно всплывший баг. В худшем — делать другую срочную задачу, которая всплывёт за неделю.
Чтобы сделать что-то хорошее, последний момент всегда должен оставаться пустым. Если обещаешь закончить в четверг — целься, чтобы закончить во вторник, а среду оставлять на запас.
В умных книгах по управлению проектами пустой последний момент называется «проектным буфером», в бюро — «планированием не впритык». Это правило работает не только на проектах, но и в любой, даже личной задаче. В последний час перед подачей на визу ты не сделаешь красивую фотографию, а если будешь собирать чемодан за 4 часа до вылета — наверняка что-то забудешь.
См. так же:
— Прошло 50% времени, проверь, выполнено ли 50% работы
— Буфер в спринтах
Типичная ошибка планирования начинающих программистов (и вообще любых исполнителей) — планировать работу на последний момент. Типа обещал ты в четверг на следующей неделе показать работу, и почему-то в голове думаешь, что в сделаешь её в среду.
Этого не будет. В лучшем случае в среду ночью ты будешь дочинивать десятый неожиданно всплывший баг. В худшем — делать другую срочную задачу, которая всплывёт за неделю.
Чтобы сделать что-то хорошее, последний момент всегда должен оставаться пустым. Если обещаешь закончить в четверг — целься, чтобы закончить во вторник, а среду оставлять на запас.
В умных книгах по управлению проектами пустой последний момент называется «проектным буфером», в бюро — «планированием не впритык». Это правило работает не только на проектах, но и в любой, даже личной задаче. В последний час перед подачей на визу ты не сделаешь красивую фотографию, а если будешь собирать чемодан за 4 часа до вылета — наверняка что-то забудешь.
См. так же:
— Прошло 50% времени, проверь, выполнено ли 50% работы
— Буфер в спринтах
#вопрос Читал у тебя в блоге и на канале, что нужно всегда выполнять обещание и попадать в эстимейты. В жизни я так и делаю — строго слежу за тем, что говорю. На работе всё диаметрально противоположно — я часто нарушая свои обещания и проёбываю сроки. На словах всё просто: пообещал — сделай. В реальности переодически может вылезти что-то непредвиденное. Как перестать факапить и начать расти как профессионал?
Даже самые крутые профессионалы ошибаются в сроках — такова уж наша специфика: в айтишечке принято бежать довольно быстро. Сравните с каким-нибудь самолётостроением, где выкатывают один самолёт раз в 20 лет, и то, бывает, ошибаются в сроках.
Профессионал отличается от новичка тем, как он реагирует на факапы. Чтобы обнаружить потенциальный факап, не нужно быть супер-опытным чуваком — достаточно пользоваться тупым правилом про 50%. Сложности начинаются, когда за потенциальные факапы нужно взять ответственность.
Новички ведут себя, как будто проблемы не существует — даже когда далёкому от разработки заказчику уже понятно, что сроки проёбываются, новички надеятся на чудо и просто отмалчиваются, будто бы ничего не происходит. Поведение довольно понятное, в такую ловушку может попасть целый город — почитайте, как берлинцы на 9 лет просрочили открытие аэропорта.
Профессионалы принимают проблему и действуют проактивно: предупреждают бизнес-заказчика, приходят с идеями как порезать скоуп или уменьшить степень проработки. Могут даже принять решение пожертвовать качеством — и это будет явное и осознанное решение, а не результат в последнюю ночь что-нибудь слабать на коленке.
Попробуйте и вы так — планируйте экваторы по длинным задачам, честно отвечайте себе на вопрос «сделал ли я половину работы?», и если нет — бейте тревогу.
Это был традиционный вопрос по понедельникам. Вопросы задают на fborshev@pm.me
Даже самые крутые профессионалы ошибаются в сроках — такова уж наша специфика: в айтишечке принято бежать довольно быстро. Сравните с каким-нибудь самолётостроением, где выкатывают один самолёт раз в 20 лет, и то, бывает, ошибаются в сроках.
Профессионал отличается от новичка тем, как он реагирует на факапы. Чтобы обнаружить потенциальный факап, не нужно быть супер-опытным чуваком — достаточно пользоваться тупым правилом про 50%. Сложности начинаются, когда за потенциальные факапы нужно взять ответственность.
Новички ведут себя, как будто проблемы не существует — даже когда далёкому от разработки заказчику уже понятно, что сроки проёбываются, новички надеятся на чудо и просто отмалчиваются, будто бы ничего не происходит. Поведение довольно понятное, в такую ловушку может попасть целый город — почитайте, как берлинцы на 9 лет просрочили открытие аэропорта.
Профессионалы принимают проблему и действуют проактивно: предупреждают бизнес-заказчика, приходят с идеями как порезать скоуп или уменьшить степень проработки. Могут даже принять решение пожертвовать качеством — и это будет явное и осознанное решение, а не результат в последнюю ночь что-нибудь слабать на коленке.
Попробуйте и вы так — планируйте экваторы по длинным задачам, честно отвечайте себе на вопрос «сделал ли я половину работы?», и если нет — бейте тревогу.
Это был традиционный вопрос по понедельникам. Вопросы задают на fborshev@pm.me
Не стесняйся показывать сырую работу
Новые, которые приходят в мою команду, имеют вредную привычку — показывают работу только тогда, когда считают её готовой. К примеру, договорились мы сделать интеграцию с новым сервисом подписок (мы, кстати, перешли на dashamail с mailchimp).
Неопытный програмист, покажет код только после того, как сделает автоматическое прокидывание новых подписчиков, систему тегов, отписок, да ещё и ретраи в celery настроит. А опытный — покажет код ещё на этапе клиента. И выяснит, что на проекте мы давно перешли с requests на httpx, отписки нам не нужны, потому что мы перевели цепочки на собственную реализацию, а теги можно сделать и после запуска, потому что сейчас важно как можно скорее настроить интеграцию, чтобы не терять подписчиков.
Несмотря на то, что мы работаем удалённо, все требования и весь контекст мы всё равно можем описать в задаче. И вместо того, чтобы ждать длинного ТЗ или додумывать самому — гораздо проще показать полуготовое решение и быстро получить обратную связь. Мне ничего не стоит посмотреть прототипный код, а компании это сэкономит кучу времени.
Не стесняйтесь показывать полуготовую работу, особенно если вы не глубоко погружены в контекст проекта — адекватные коллеги вас только поблагодарят за это. Только не забывайте предупреждать, что ваша работа — сырая, и показываете вы её только, чтобы синхронизироваться.
Новые, которые приходят в мою команду, имеют вредную привычку — показывают работу только тогда, когда считают её готовой. К примеру, договорились мы сделать интеграцию с новым сервисом подписок (мы, кстати, перешли на dashamail с mailchimp).
Неопытный програмист, покажет код только после того, как сделает автоматическое прокидывание новых подписчиков, систему тегов, отписок, да ещё и ретраи в celery настроит. А опытный — покажет код ещё на этапе клиента. И выяснит, что на проекте мы давно перешли с requests на httpx, отписки нам не нужны, потому что мы перевели цепочки на собственную реализацию, а теги можно сделать и после запуска, потому что сейчас важно как можно скорее настроить интеграцию, чтобы не терять подписчиков.
Несмотря на то, что мы работаем удалённо, все требования и весь контекст мы всё равно можем описать в задаче. И вместо того, чтобы ждать длинного ТЗ или додумывать самому — гораздо проще показать полуготовое решение и быстро получить обратную связь. Мне ничего не стоит посмотреть прототипный код, а компании это сэкономит кучу времени.
Не стесняйтесь показывать полуготовую работу, особенно если вы не глубоко погружены в контекст проекта — адекватные коллеги вас только поблагодарят за это. Только не забывайте предупреждать, что ваша работа — сырая, и показываете вы её только, чтобы синхронизироваться.
Как найти работу за рубежом
Месяц назад мы провели стрим о поиске работы за рубежом с Димой Рожковым. Тема многим показалась интересной, поэтому теперь Дима — новый эксперт нашей школы: он отлично разбирается в зарубежном трудоустройстве, уже 8 лет живёт в Германии и 4 из них нанимает инженеров со всего мира.
Дима с ходу присоединяется к нам с актуальным курсом — «Вы приняты». Это трёхнедельный практический курс о сабже — как выбрать компанию, сделать профиль в линкедине, пройти собеседование. Никакой теории — только мясо и конкретика.
Стартуем 26 мая, учимся три недели. Как обычно на наших курсах — живое общение с авторами и доброжелательное комьюнити прилагается.
Смотреть программу и первый урок →
До 14 мая скидка 10% по промо-коду
Месяц назад мы провели стрим о поиске работы за рубежом с Димой Рожковым. Тема многим показалась интересной, поэтому теперь Дима — новый эксперт нашей школы: он отлично разбирается в зарубежном трудоустройстве, уже 8 лет живёт в Германии и 4 из них нанимает инженеров со всего мира.
Дима с ходу присоединяется к нам с актуальным курсом — «Вы приняты». Это трёхнедельный практический курс о сабже — как выбрать компанию, сделать профиль в линкедине, пройти собеседование. Никакой теории — только мясо и конкретика.
Стартуем 26 мая, учимся три недели. Как обычно на наших курсах — живое общение с авторами и доброжелательное комьюнити прилагается.
Смотреть программу и первый урок →
До 14 мая скидка 10% по промо-коду
W1ND.#вопрос Работаю в около-гос. компании. Вроде всё как в стартапе и по SCRUM, но есть проблема — тестировщики\аналитики. От заказчика часто возвращаются репорты об ошибках в релизах, которые (по причинам халатности) не были идентифицированы при прохождении предрелизных тестов. Коуч-сессии о командном духе, о командной работе над продуктом не приносят плодов, даже разрабы жалуются на этих аналитиков/тестировщиков о их частой непродуктивности (слишком долгая тестировка, невнятная аналитика).
Последний релиз не был исключением — тестеры все проверили, релиз отдали, заказчик вернулся с репортом, что «все х-ня, давай по новой». Разбор этих репортов показал, что аналитики/тестировщики очень много нюансов просто «недоглядели» (стояли, кивали головами и «мычали»).
Все выходные ломал голову над тем, что может это моя вина? Что я недокоучил их как работать? Или не донес им суть ценности командной работы? Или еще что-то, где я «недосмотрел»… В общем доверия, которое должно быть, просто нет — сейчас я ожидаю от них очередного подвоха по старому сценарию «недосмотрели, проглядели». Как быть в такой ситуации? Стоит ли мне акцентировать все репорты как «моя вина» или же стоит что-то делать с аналитикой/тестировкой (возможно уволить их и взять других)?
——————
Думаю, у плохой работы мануальных тестировщиков могут быть другие причины, кроме недостаточной их приверженности коммандным ценностям :-)
Позволю себе уцепиться за противоречие в вопросе — с одной стороны вы говорите об SCRUM «как в стартапе», а с другой — упоминаете о зафейленном релизе. Предположу, что вы делаете не мобильное приложение и не либу для программистов, а значит механизм релизов (как и ручное тестирование) вам пришлось внедрять не от хорошей жизни.
Возможно отсутствие энтузиазма у аналитиков и тестировщиков вызвано тем, что им на вход поставляют некачественные материалы? Может у вас разработчики накопили такой техдолг, что все силы уходят на удержание в голове структуры вашего пастообразного кода, и места, чтобы проверить свою работу, а уж тем более, подумать о бизнесе, уже не остаётся? Или может быть заказчик настолько часто меняет требования, что переводить их на язык программистов не имеет смысла, потому что этот перевод станет неправдой через неделю?
Попробуйте поговорить со всеми по-отдельности и докопаться до истиной причины проблем. Не обязательно эта причина окажется не в тестировщиках, но проверить точно стоит. Почитайте «Процесс непрерывного улучшения» Голрадта, он настраивает на образ мыслей, который, кажется, вам поможет.
Это был традиционный вопрос по понедельникам. Вопросы задают на fborshev@pm.me
Последний релиз не был исключением — тестеры все проверили, релиз отдали, заказчик вернулся с репортом, что «все х-ня, давай по новой». Разбор этих репортов показал, что аналитики/тестировщики очень много нюансов просто «недоглядели» (стояли, кивали головами и «мычали»).
Все выходные ломал голову над тем, что может это моя вина? Что я недокоучил их как работать? Или не донес им суть ценности командной работы? Или еще что-то, где я «недосмотрел»… В общем доверия, которое должно быть, просто нет — сейчас я ожидаю от них очередного подвоха по старому сценарию «недосмотрели, проглядели». Как быть в такой ситуации? Стоит ли мне акцентировать все репорты как «моя вина» или же стоит что-то делать с аналитикой/тестировкой (возможно уволить их и взять других)?
——————
Думаю, у плохой работы мануальных тестировщиков могут быть другие причины, кроме недостаточной их приверженности коммандным ценностям :-)
Позволю себе уцепиться за противоречие в вопросе — с одной стороны вы говорите об SCRUM «как в стартапе», а с другой — упоминаете о зафейленном релизе. Предположу, что вы делаете не мобильное приложение и не либу для программистов, а значит механизм релизов (как и ручное тестирование) вам пришлось внедрять не от хорошей жизни.
Возможно отсутствие энтузиазма у аналитиков и тестировщиков вызвано тем, что им на вход поставляют некачественные материалы? Может у вас разработчики накопили такой техдолг, что все силы уходят на удержание в голове структуры вашего пастообразного кода, и места, чтобы проверить свою работу, а уж тем более, подумать о бизнесе, уже не остаётся? Или может быть заказчик настолько часто меняет требования, что переводить их на язык программистов не имеет смысла, потому что этот перевод станет неправдой через неделю?
Попробуйте поговорить со всеми по-отдельности и докопаться до истиной причины проблем. Не обязательно эта причина окажется не в тестировщиках, но проверить точно стоит. Почитайте «Процесс непрерывного улучшения» Голрадта, он настраивает на образ мыслей, который, кажется, вам поможет.
Это был традиционный вопрос по понедельникам. Вопросы задают на fborshev@pm.me
Чем вы делаете бекапы?
В последнее время у меня появилось много инфраструктуры. С удивлением обнаружил, что за прошедшие 5 лет с момента, когда я серьёзно занимался инфраструктурой, ничего не поменялось в мире бекапов — кажется все так же пишут скрипты, которые ежедневно/-недельно запускают rsync или складывают бекапы куда-нибудь на s3. Разве что продвинуты ребята используют write-only доступы и healthchecks.io, чтобы получить уведомление о сфейленном бекапе.
Я понимаю, что проблема бекапов — довольно сложная: инфраструктуры и требования у всех разные. Но ведь для десктопа же есть решения всё-в-одном, вроде Backblaze или хотя бы TimeMachine на маке. Почему я не смог найти ничего похожего для серверов? Есть только жуткий на вид veeam.
Расскажите пожалуйста в комментах, может знаете какой-нибудь простой инструмент для бекапов?
В последнее время у меня появилось много инфраструктуры. С удивлением обнаружил, что за прошедшие 5 лет с момента, когда я серьёзно занимался инфраструктурой, ничего не поменялось в мире бекапов — кажется все так же пишут скрипты, которые ежедневно/-недельно запускают rsync или складывают бекапы куда-нибудь на s3. Разве что продвинуты ребята используют write-only доступы и healthchecks.io, чтобы получить уведомление о сфейленном бекапе.
Я понимаю, что проблема бекапов — довольно сложная: инфраструктуры и требования у всех разные. Но ведь для десктопа же есть решения всё-в-одном, вроде Backblaze или хотя бы TimeMachine на маке. Почему я не смог найти ничего похожего для серверов? Есть только жуткий на вид veeam.
Расскажите пожалуйста в комментах, может знаете какой-нибудь простой инструмент для бекапов?
Ипотека
Тут недавно в комментах у Тонского объясняли, как работает и зачем нужна ипотека. Я много об этом думаю в последнее время — из-за войны я потерял сбережения, которых как раз хватало на небольшую квартиру в провинции, так что имею право вставить свои 5 копеек.
Если отбросить сакральную часть про «жить в своей квартире», то ипотека, как и сама недвижимость — это финансовый инструмент, ультраконсервативный защитный актив с низким риском и низким (или даже отрицательным) доходом. Инструмент может подходить владельцу или не подходить.
Возьмём ситуацию: есть свободные 10 миллионов рублей, хотим обезопасить сбережения. Можно сохранить небольшую финансовую подушку, а на оставшиеся деньги — купить двухкомнатную квартиру в условной Туле за кеш. А можно купить там же, но в ипотеку с большим первоначальным взносом под условные 7%. Переплата по ипотеке будут ниже уровня инфляции, а свободные деньги можно вложить в бизнес\акции\облигации, которые уж точно обеспечат больше 7% годовых. Кажется норм, рабочий инструмент.
Или так: живём в Москве\Берлине, сбережений нет, а бабушкиной квартиры хватает на 1,5 квадратных метра. Берём ипотеку на 40 лет, с платежом в половину зарплаты. Лишаемся возможности сменить работу, переехать в другую страну или взять саббатикал. Через 40 лет остаёмся без сбережений, но зато со своей квартирой. Ну или передаём долг по наследству, если что-то пошло не так. Такое себе.
Я конечно описал крайние ситуации, между которыми есть целый спектр, ориентироваться в котором помогает эксель. Но в любом случае, подчинять жизнь покупке защитных активов с высоким порогом вхождения мне кажется довольно странным занятием: лучше уж золото потихоньку покупать.
Я сам нахожусь примерно в такой же ситуации, как Тонский в Берлине — чтобы купить квартиру в месте, где я живу, мне нужно продаться в рабство лет на 20. При этом первые 5 лет я буду ещё и выкраивать деньги на ремонт в ванной, чтобы строительная пыль не сыпалась на голову, пока я принимаю душ. Так что мой выбор — достроить бизнес до состояния, когда я смогу себе позволить жильё, которое хочу. И по дороге поддерживать разумную долю защитных активов в портфеле.
Тут недавно в комментах у Тонского объясняли, как работает и зачем нужна ипотека. Я много об этом думаю в последнее время — из-за войны я потерял сбережения, которых как раз хватало на небольшую квартиру в провинции, так что имею право вставить свои 5 копеек.
Если отбросить сакральную часть про «жить в своей квартире», то ипотека, как и сама недвижимость — это финансовый инструмент, ультраконсервативный защитный актив с низким риском и низким (или даже отрицательным) доходом. Инструмент может подходить владельцу или не подходить.
Возьмём ситуацию: есть свободные 10 миллионов рублей, хотим обезопасить сбережения. Можно сохранить небольшую финансовую подушку, а на оставшиеся деньги — купить двухкомнатную квартиру в условной Туле за кеш. А можно купить там же, но в ипотеку с большим первоначальным взносом под условные 7%. Переплата по ипотеке будут ниже уровня инфляции, а свободные деньги можно вложить в бизнес\акции\облигации, которые уж точно обеспечат больше 7% годовых. Кажется норм, рабочий инструмент.
Или так: живём в Москве\Берлине, сбережений нет, а бабушкиной квартиры хватает на 1,5 квадратных метра. Берём ипотеку на 40 лет, с платежом в половину зарплаты. Лишаемся возможности сменить работу, переехать в другую страну или взять саббатикал. Через 40 лет остаёмся без сбережений, но зато со своей квартирой. Ну или передаём долг по наследству, если что-то пошло не так. Такое себе.
Я конечно описал крайние ситуации, между которыми есть целый спектр, ориентироваться в котором помогает эксель. Но в любом случае, подчинять жизнь покупке защитных активов с высоким порогом вхождения мне кажется довольно странным занятием: лучше уж золото потихоньку покупать.
Я сам нахожусь примерно в такой же ситуации, как Тонский в Берлине — чтобы купить квартиру в месте, где я живу, мне нужно продаться в рабство лет на 20. При этом первые 5 лет я буду ещё и выкраивать деньги на ремонт в ванной, чтобы строительная пыль не сыпалась на голову, пока я принимаю душ. Так что мой выбор — достроить бизнес до состояния, когда я смогу себе позволить жильё, которое хочу. И по дороге поддерживать разумную долю защитных активов в портфеле.
Первый год Школа Сильных Программистов существовала без названия — мы думали над концепцией, потому что не хотели делать ещё одну школу на рынке. Хотели сделать пространство с поддерживающей средой и возможностью развития. Чтобы отвечать на вопросы которые страшно, стыдно, неуместно задавать.
И все курсы, которые мы делаем, следуют этим принципам. «Вы приняты» — не исключение. Во втором уроке Дима довольного глубоко уходит в нюансы фаагнов, компаний второго и третьего эшелона — честно рассказывает про технологии, релокацию, местный колорит, центры принятия решений. В других уроках мы подробно разбираем резюме и собеседования и даже делаем собесбота, чтобы можно было потренироваться на кошках.
Для некоторых в этом курсе дилбрейкер — это собеседования на английском. Многие собираются за рубеж, но пока стесняются или плохо владеют языком. Вы конечно же можете делать домашку на русском, а потом перестроиться. Но лучше тренироваться на кошках в безопасной среде сейчас, чем потом идти сразу в бой. Лучшего времени никогда не будет, а над вашим английским никто тут смеяться не будет.
Если собираетесь за рубеж — промокод
Смотреть программу и первый урок →
И все курсы, которые мы делаем, следуют этим принципам. «Вы приняты» — не исключение. Во втором уроке Дима довольного глубоко уходит в нюансы фаагнов, компаний второго и третьего эшелона — честно рассказывает про технологии, релокацию, местный колорит, центры принятия решений. В других уроках мы подробно разбираем резюме и собеседования и даже делаем собесбота, чтобы можно было потренироваться на кошках.
Для некоторых в этом курсе дилбрейкер — это собеседования на английском. Многие собираются за рубеж, но пока стесняются или плохо владеют языком. Вы конечно же можете делать домашку на русском, а потом перестроиться. Но лучше тренироваться на кошках в безопасной среде сейчас, чем потом идти сразу в бой. Лучшего времени никогда не будет, а над вашим английским никто тут смеяться не будет.
Если собираетесь за рубеж — промокод
W1ND действует до вечера понедельника. Честную рассрочку, которая пропала после начала войны, мы восстановили. Будет ли повтор курса мы не знаем, так что если хотели — присоединяйтесь.Смотреть программу и первый урок →
Forwarded from Продукты, книги и любовь
Второй раз на те же грабли
У меня дежавю. Два года назад мы с Федей запустили курс про делегирование «Самому не проще». Тогда на открытие продаж, я говорила что это для программистов, потому что все примеры для них. Но бесстрашные люди других профессий покупали и писали мне, что я не права — им тоже полезно. Через полтора года я поменяла упаковку и сама начала советовать его, если видела, что человеку нужно. В итоге курс прошли почти 200 человек.
В начале мая мы открыли продажу на новый курс про поиск работы за рубежом под названием «Вы приняты». Снова упаковка для программистов. После открытия продаж, если мне писали «а можно мне, если я продакт», я отвечала, что нет.
Сейчас мы подготовили 3 урока из 7 и я для себя поймала на том, что уже выписала целую простыню пользы. Например, как оценивать оффер и торговаться за условия по формуле Бэна Оренстина. Или что может входить в релокейт пакет, а что нет, стоит ли озвучивать свои зарплатных ожидания до собеседования и ок ли потом поменять свое мнение, узнав подробнее о своей роли или задачах.
Блин, это же совершенно универсальные штуки, которые подойдут и помогут повысить шансы найма любому человеку, который сейчас в поиске работы за рубежом. А я говорю «не покупайте» 🤦♀️
Короче, меняю формулировку. Если вы программист — покупайте вип-тариф или тусовку, чтобы получить по максимуму обратной связи и поддержки комьюнити. Если вы непрограммист — берите самостоятельный тариф, будет полезно и стоит всего 6500 руб. В тусовке вы можете себя чувствовать чужим, там будут в основном инженеры.
Стартуем 26 мая. Всего три недели. По два урока в неделю. Много практики, бери и делай. От меня промокод love на 10% скидки до 25 мая.
Посмотреть программу и первый урок →
P.S. По традиции выделили 20 мест для тех, кто недавно потерял работу или выбрался из небезопасного места и уже имеет силы учиться. Напишите нам, если вас это касается. Почта на странице курса.
У меня дежавю. Два года назад мы с Федей запустили курс про делегирование «Самому не проще». Тогда на открытие продаж, я говорила что это для программистов, потому что все примеры для них. Но бесстрашные люди других профессий покупали и писали мне, что я не права — им тоже полезно. Через полтора года я поменяла упаковку и сама начала советовать его, если видела, что человеку нужно. В итоге курс прошли почти 200 человек.
В начале мая мы открыли продажу на новый курс про поиск работы за рубежом под названием «Вы приняты». Снова упаковка для программистов. После открытия продаж, если мне писали «а можно мне, если я продакт», я отвечала, что нет.
Сейчас мы подготовили 3 урока из 7 и я для себя поймала на том, что уже выписала целую простыню пользы. Например, как оценивать оффер и торговаться за условия по формуле Бэна Оренстина. Или что может входить в релокейт пакет, а что нет, стоит ли озвучивать свои зарплатных ожидания до собеседования и ок ли потом поменять свое мнение, узнав подробнее о своей роли или задачах.
Блин, это же совершенно универсальные штуки, которые подойдут и помогут повысить шансы найма любому человеку, который сейчас в поиске работы за рубежом. А я говорю «не покупайте» 🤦♀️
Короче, меняю формулировку. Если вы программист — покупайте вип-тариф или тусовку, чтобы получить по максимуму обратной связи и поддержки комьюнити. Если вы непрограммист — берите самостоятельный тариф, будет полезно и стоит всего 6500 руб. В тусовке вы можете себя чувствовать чужим, там будут в основном инженеры.
Стартуем 26 мая. Всего три недели. По два урока в неделю. Много практики, бери и делай. От меня промокод love на 10% скидки до 25 мая.
Посмотреть программу и первый урок →
P.S. По традиции выделили 20 мест для тех, кто недавно потерял работу или выбрался из небезопасного места и уже имеет силы учиться. Напишите нам, если вас это касается. Почта на странице курса.
Forwarded from запуск завтра
Наш ведущий фронтендер Миша Бурмистров сделал чеклист по веб-безопасности для фронтенд-разработчиков компании.
Хвастаюсь!
Опубликую ещё первый комментарий Миши к этому посту (не видны публично):
Было бы удобно, если бы ко всем пунктам списка были приложены материалы, но поиск/фильтрация материалов это работа, которую я не готов сейчас делать. Кроме того, у всех разные предпочтения в плане формата контента — кто-то любит статьи на русском, кто-то видео на английском и т. п. Все темы из списка довольно известные — уверен, вам не составит труда найти по ним информацию. Можете делиться понравившимися материалами в комментах.
А чтобы почитать остальные комментарии — придется устроиться к нам на работу :)
Признаюсь, я и сам не знаю некоторых аббревиатур 🙈
Разработчики, которые думают о безопасности — единственный способ делать безопасные приложения. Никакие отделы безопасности не спасут, если разработчикам пофиг. Так же, как и с тестированием — о качестве должны думать все разработчики, а не только «специалисты»!
В общем, горжусь и хвастаюсь!
Хвастаюсь!
Опубликую ещё первый комментарий Миши к этому посту (не видны публично):
Было бы удобно, если бы ко всем пунктам списка были приложены материалы, но поиск/фильтрация материалов это работа, которую я не готов сейчас делать. Кроме того, у всех разные предпочтения в плане формата контента — кто-то любит статьи на русском, кто-то видео на английском и т. п. Все темы из списка довольно известные — уверен, вам не составит труда найти по ним информацию. Можете делиться понравившимися материалами в комментах.
А чтобы почитать остальные комментарии — придется устроиться к нам на работу :)
Признаюсь, я и сам не знаю некоторых аббревиатур 🙈
Разработчики, которые думают о безопасности — единственный способ делать безопасные приложения. Никакие отделы безопасности не спасут, если разработчикам пофиг. Так же, как и с тестированием — о качестве должны думать все разработчики, а не только «специалисты»!
В общем, горжусь и хвастаюсь!
Как за один вопрос разрушить отношения с покупателем?
Довольно легко — нужно предложить ему ему написать заявление на возврат.
Недавно я попытался воспользоваться сервисом одной известной бухглатерской компании, которую пару лет назад купил Сбер — мне нужно было оформить заявление на налоговый вычет. Довольно быстро я передумал — оказывается, чтобы воспользоваться их услугами, нужно несколько дней сидеть возле телефона в ожидании звонка от очередного некомпетентного специалиста. На третий день сидения у телефона, очередной некомпетентный специалист в ответ на просьбу просто вернуть деньги, прислал мне заявление на возврат. Это такой документ, который нужно заполнить от руки (!), отсканировать (!) и отправить им на почту.
Такой вот клиентский сервис — человек уже недоволен вашими услугами, а вы просите его пройти унизительную процедуру возврата. Мне вдвойне обидно, потому что я знаю, что такая процедура не обоснована совершенно ничем: любой банк-эквайер возвращает деньги в один запрос API (или два клика), параллельно выбивая чек возврата. Есть всего две причины, по которой люди так делают — они либо не могут договориться с собственной бухгалтерией, либо искусственно снижают процент возвратов. Обе эти причины, конечно же, не заслуживают никакого уважения.
В Школе мы возвращаем деньги по первому требованию. Возможно именно поэтому процент возвратов у нас намного меньше единицы. Хочу, чтобы так было везде.
Довольно легко — нужно предложить ему ему написать заявление на возврат.
Недавно я попытался воспользоваться сервисом одной известной бухглатерской компании, которую пару лет назад купил Сбер — мне нужно было оформить заявление на налоговый вычет. Довольно быстро я передумал — оказывается, чтобы воспользоваться их услугами, нужно несколько дней сидеть возле телефона в ожидании звонка от очередного некомпетентного специалиста. На третий день сидения у телефона, очередной некомпетентный специалист в ответ на просьбу просто вернуть деньги, прислал мне заявление на возврат. Это такой документ, который нужно заполнить от руки (!), отсканировать (!) и отправить им на почту.
Такой вот клиентский сервис — человек уже недоволен вашими услугами, а вы просите его пройти унизительную процедуру возврата. Мне вдвойне обидно, потому что я знаю, что такая процедура не обоснована совершенно ничем: любой банк-эквайер возвращает деньги в один запрос API (или два клика), параллельно выбивая чек возврата. Есть всего две причины, по которой люди так делают — они либо не могут договориться с собственной бухгалтерией, либо искусственно снижают процент возвратов. Обе эти причины, конечно же, не заслуживают никакого уважения.
В Школе мы возвращаем деньги по первому требованию. Возможно именно поэтому процент возвратов у нас намного меньше единицы. Хочу, чтобы так было везде.
Только 80 порт
Большая боль для современной эксплуатации — это бекенд, который лезет на уровень протокола: терминирует SSL, отдаёт заголовки HSTS или CSP или даже делает Basic-авторизацию. С одной стороны звучит довольно просто — поставил пару пакетов для любимого фреймворка, и добавил безопасности и удобства.
К сожалению, это не правда. Возьмём, к примеру, HSTS — заголовок, с помощью которого приложение может сказать «дальше соединяйся со мной только по HTTPS, пожалуйста». Браузер кеширует этот заголовок, и больше никогда не пойдёт по HTTP-ссылке на приложение. Вроде бы отличное поведение, но ровно до того момента, пока вы не запустите приложение с таким заголовком на локалхосте, после чего у вас перестают работать все не-SSL приложения, которые висят на этом же порту.
Или CSP — список доменов, с которых браузеру разрешено грузить внешние ассеты. Вроде бы клёво, когда программисты сами прописывают, что им нужно, но представьте, как грустно становится админу, когда он разворачивает какой-нибудь новый вид тестовой среды — скажем песочницу для потенциальных партнёров. Ему нужно идти к программистам, чтобы те добавили новые хосты в свои списки, иначе песочница будет падать с кучей ошибок.
Я не говорю о попытках терминировать SSL или реализовать HTTP/2 в том же контейнере, где крутится код. В специально приспособленных местах такие вещи делаются за 1 строку кода, или вообще без неё. А в контейнер приходится заводить nginx, letsnencrypt и ещё кучу скучных вещей.
Всё, что должен знать современный бекенд про HTTP — это то, что его будут спрашивать по 80 порту (и то не обязательно). Всё остальное — забота балансировщика, nginx, cloudflare или что там у вас.
Большая боль для современной эксплуатации — это бекенд, который лезет на уровень протокола: терминирует SSL, отдаёт заголовки HSTS или CSP или даже делает Basic-авторизацию. С одной стороны звучит довольно просто — поставил пару пакетов для любимого фреймворка, и добавил безопасности и удобства.
К сожалению, это не правда. Возьмём, к примеру, HSTS — заголовок, с помощью которого приложение может сказать «дальше соединяйся со мной только по HTTPS, пожалуйста». Браузер кеширует этот заголовок, и больше никогда не пойдёт по HTTP-ссылке на приложение. Вроде бы отличное поведение, но ровно до того момента, пока вы не запустите приложение с таким заголовком на локалхосте, после чего у вас перестают работать все не-SSL приложения, которые висят на этом же порту.
Или CSP — список доменов, с которых браузеру разрешено грузить внешние ассеты. Вроде бы клёво, когда программисты сами прописывают, что им нужно, но представьте, как грустно становится админу, когда он разворачивает какой-нибудь новый вид тестовой среды — скажем песочницу для потенциальных партнёров. Ему нужно идти к программистам, чтобы те добавили новые хосты в свои списки, иначе песочница будет падать с кучей ошибок.
Я не говорю о попытках терминировать SSL или реализовать HTTP/2 в том же контейнере, где крутится код. В специально приспособленных местах такие вещи делаются за 1 строку кода, или вообще без неё. А в контейнер приходится заводить nginx, letsnencrypt и ещё кучу скучных вещей.
Всё, что должен знать современный бекенд про HTTP — это то, что его будут спрашивать по 80 порту (и то не обязательно). Всё остальное — забота балансировщика, nginx, cloudflare или что там у вас.
Загружаться творческой работой на ночь
Мой любимый метод преодолевать творческий кризис — загружать голову работой на ночь. Идея простая — если мы упёрлись а задачу, где не видим красивого решения, надо сформулировать для себя вопрос и лечь с ним спать.
Важно, чтобы этот вопрос был максимально конкретным:
— Как заложить одновременную поддержку SNOMED и МКБ11 в модель данных МИС?
— Как сохранить привязку к метафоре в конце доклада?
— Чем заменить маркетинговую функциональность mailchimp?\
— Какой мой жизненный опыт подходит для примера в факультативе про собеседования?
Не знаю, как это работает, но если найти в себе силы задать такой вопрос на ночь, с утра гарантированно просыпаешься с решением. Конечно при этом важно после пробуждения не хвататься первым делом за телефон, а 5–10 минут полежать в одиночестве и спокойствии. Лучше вообще чтобы телефона рядом не было.
#новая_продуктивность
Мой любимый метод преодолевать творческий кризис — загружать голову работой на ночь. Идея простая — если мы упёрлись а задачу, где не видим красивого решения, надо сформулировать для себя вопрос и лечь с ним спать.
Важно, чтобы этот вопрос был максимально конкретным:
— Как заложить одновременную поддержку SNOMED и МКБ11 в модель данных МИС?
— Как сохранить привязку к метафоре в конце доклада?
— Чем заменить маркетинговую функциональность mailchimp?\
— Какой мой жизненный опыт подходит для примера в факультативе про собеседования?
Не знаю, как это работает, но если найти в себе силы задать такой вопрос на ночь, с утра гарантированно просыпаешься с решением. Конечно при этом важно после пробуждения не хвататься первым делом за телефон, а 5–10 минут полежать в одиночестве и спокойствии. Лучше вообще чтобы телефона рядом не было.
#новая_продуктивность
«Вы приняты» — стартуем послезавтра
Забавный факт — когда я проверял за Димой четвёртый урок курса, то понял, что совсем не умею писать резюме — так уж вышло, что на все рабочие места в жизни я устраивался через cover letter и личные встречи. В больших компаниях, тем более зарубежных, так не сработает — вам придётся проходить все формальности: сорсера, HR-менеджера и только потом уже встречаться с командой.
Каждый из них ищет в резюме ответы на свои вопросы: сорсер ищет знакомые технологии, менеджер смотрит на самопрезентацию, инженер — на опыт. Вашу историю нужно адаптировать для каждого из них, как именно — говорим в четвёртом уроке.
Кроме написания резюме и выбора компании, мы говорим о том, как торговаться за офер, тренируем самопрезентацию, факультативно изучаем ведение профессионального блога и пет-проектов. Курс ориентирован на разработчиков, но подойдёт всем, кто связан с айтишечкой. Если вы разработчик — берите «VIP» или «в тусовке», если просто интересуетесь поиском работы за рубежом — «самостоятельный».
Стартуем послезавтра (26 мая) со встречи-знакомства в 19:00 — смотрите программу и приходите. По промокоду LC10 скидка 12% до 23:59.
Записаться →
Забавный факт — когда я проверял за Димой четвёртый урок курса, то понял, что совсем не умею писать резюме — так уж вышло, что на все рабочие места в жизни я устраивался через cover letter и личные встречи. В больших компаниях, тем более зарубежных, так не сработает — вам придётся проходить все формальности: сорсера, HR-менеджера и только потом уже встречаться с командой.
Каждый из них ищет в резюме ответы на свои вопросы: сорсер ищет знакомые технологии, менеджер смотрит на самопрезентацию, инженер — на опыт. Вашу историю нужно адаптировать для каждого из них, как именно — говорим в четвёртом уроке.
Кроме написания резюме и выбора компании, мы говорим о том, как торговаться за офер, тренируем самопрезентацию, факультативно изучаем ведение профессионального блога и пет-проектов. Курс ориентирован на разработчиков, но подойдёт всем, кто связан с айтишечкой. Если вы разработчик — берите «VIP» или «в тусовке», если просто интересуетесь поиском работы за рубежом — «самостоятельный».
Стартуем послезавтра (26 мая) со встречи-знакомства в 19:00 — смотрите программу и приходите. По промокоду LC10 скидка 12% до 23:59.
Записаться →
Менеджер слышит то, что хочет услышать
Если составить топ проблем разработки, с которыми ко мне когда-либо приходили проектные менежеры, то в самом верху будет «срываются сроки». Банальное — договорились сдать в четверг, настал уже вечер пятницы, а от программиста всё ещё ни слуху, ни духу. Часто в этом виноват накопленный техдолг, плохая коммуникация или безответственные программисты. Но причина может быть и в самом менеджере, вернее в его неумении слушать.
Когда программисты называют сроки в виде вилки, типа «2–4 дня», многие менеджеры слышат только первую часть вилки — «2 дня». Если сказать «во второй половине мая», менеджер услышит «15 мая» вместо «между 15 и 30 мая». Если сказать «не меньше трёх дней», менеджер услышит «три дня».
Что с этим делать? Если вы программист — называйте абсолютные, а не относительные сроки. Не «2–4 дня», а «будет в следующий понедельник». Не «во второй половине мая», а «1 июня». Не «не меньше трёх дней», а «через три дня назову срок».
Если вы менеджер — закладывайте запасы и слушайте то, что люди говорят на самом деле, а не то, что вы хотите от них услышать.
Если составить топ проблем разработки, с которыми ко мне когда-либо приходили проектные менежеры, то в самом верху будет «срываются сроки». Банальное — договорились сдать в четверг, настал уже вечер пятницы, а от программиста всё ещё ни слуху, ни духу. Часто в этом виноват накопленный техдолг, плохая коммуникация или безответственные программисты. Но причина может быть и в самом менеджере, вернее в его неумении слушать.
Когда программисты называют сроки в виде вилки, типа «2–4 дня», многие менеджеры слышат только первую часть вилки — «2 дня». Если сказать «во второй половине мая», менеджер услышит «15 мая» вместо «между 15 и 30 мая». Если сказать «не меньше трёх дней», менеджер услышит «три дня».
Что с этим делать? Если вы программист — называйте абсолютные, а не относительные сроки. Не «2–4 дня», а «будет в следующий понедельник». Не «во второй половине мая», а «1 июня». Не «не меньше трёх дней», а «через три дня назову срок».
Если вы менеджер — закладывайте запасы и слушайте то, что люди говорят на самом деле, а не то, что вы хотите от них услышать.
Четырёхдневная рабочая неделя
Мы в «Феде и Самате» запустили эксперимент — перешли на 4-х дневную рабочую неделю. Считаем, что так команда будет лучше себя чувствовать, а производительность не изменится.
Во-первых, если из среднерыночной команды выкинуть все встречи, которых у нас нет — дейли-митинги, покер-планинги и «давайте синхронизируемся», останется как раз четыре рабочих дня.
Во-вторых, я не знаю ни одного программиста, который в состоянии целую неделю без перерыва писать код. Не хочу обманывать ни себя, ни команду — из 5 дней как минимум один окажется пустым и неэффективным, просто потому что мозгу тяжело делать одно и то же столько времени. А вот 4 дня мне кажутся вполне возможной целью.
В-третьих, мы, как и многие, игнорируем государственные праздники. Когда вся страна отдыхает в очередной день единения — мы работаем: спринты не смещаются под праздники и карантины. Думаю, 52 дополнительных выходных в год должны это морально компенсировать.
Пока запускаем эксперимент на два месяца — до августа. Производительность будем замерять по ощущениям: просто сравним списки закрытых задач по периодам. Параллельно делаем анонимный опрос (спасибо, Ксюша) «Работал ли ты в эту пятницу».
О ходе эксперимента буду рассказывать здесь и дальше. Буду рад вопросам и советам :-)
Мы в «Феде и Самате» запустили эксперимент — перешли на 4-х дневную рабочую неделю. Считаем, что так команда будет лучше себя чувствовать, а производительность не изменится.
Во-первых, если из среднерыночной команды выкинуть все встречи, которых у нас нет — дейли-митинги, покер-планинги и «давайте синхронизируемся», останется как раз четыре рабочих дня.
Во-вторых, я не знаю ни одного программиста, который в состоянии целую неделю без перерыва писать код. Не хочу обманывать ни себя, ни команду — из 5 дней как минимум один окажется пустым и неэффективным, просто потому что мозгу тяжело делать одно и то же столько времени. А вот 4 дня мне кажутся вполне возможной целью.
В-третьих, мы, как и многие, игнорируем государственные праздники. Когда вся страна отдыхает в очередной день единения — мы работаем: спринты не смещаются под праздники и карантины. Думаю, 52 дополнительных выходных в год должны это морально компенсировать.
Пока запускаем эксперимент на два месяца — до августа. Производительность будем замерять по ощущениям: просто сравним списки закрытых задач по периодам. Параллельно делаем анонимный опрос (спасибо, Ксюша) «Работал ли ты в эту пятницу».
О ходе эксперимента буду рассказывать здесь и дальше. Буду рад вопросам и советам :-)
Измеримые критерии усталости
У меня тут в начале мая случилась авария — я переработал до отказа: буквально руки не поднимались делать дела, сил хватало закрыть 1–2 задачи в день, а всё остальное время сливал в пустоту. После почти двухнедельного отдыха (это для меня много), я сел и начал анализировать — из-за чего это случилось, и что сделать, чтобы больше так не выдыхаться.
Из-за чего случилось — довольно понятно: мой предыдущий отпуск был запланирован на 26 февраля, и конечно же я его отменил — и курс доллара непонятный (я летел в ОАЭ), и от команды далеко уходить не хотелось. Потом я как-то пытался компенсировать отдых — брать дейоффы, побольше спать и поменьше работать, но не получилось — видимо сказался общий нервяк от войны.
Где-то к апрелю я пришёл в состояние «некогда отдыхать» — когда даже боишься себе представить, что перестанешь работать на пару часов пораньше или проведёшь лишний выходной с семьёй. Получилась положительная обратная связь — стал работать так много, что перестал адекватно воспринимать работу, от чего начинал работать ещё больше. К чему это привело — написал выше.
Ну ок, почему выдохся — понятно. Осталось придумать, как избежать этого в будущем. Клёво было бы найти какой-нибудь универсальный маркер накопленной усталости — ведь когда ты разогнан до предела, вряд ли ты сам замечаешь свою неадекватность: её можно заметить только снаружи.
В поисках KPI я посравнивал своё отдохнувшее состояние с тем, что было в начале мая и нашёл вот такие отличия усталого Феди от нормального. Усталый Федя:
— Избегает общения с новыми людьми (да и со старыми тоже).
— Не хочет слушать новую музыку (даже daily mix в Spotify), смотреть новые фильмы.
— Не хочет медитировать и писать в дневник.
— Много ест (странно, но потребление алкоголя при этом в норме).
— Не хочет в новый город\новую кофейню\новый ресторан.
Кажется самый показательный и измеримый пункт из этого — дневник. Day One, который я использую, показывает календарь с днями, в которые я пишу заметки. В апреле дней с заметками было всего 6, причём в середине месяца было целых три недели подряд, в которые я вообще не притрагивался к дневнику.
Это и будет KPI — теперь если я обнаружу, что за две недели ни разу не притрагивался к дневнику, то я сразу же брошу все дела и устрою себе минимум 5-дневный отпуск.
А какие у вас есть измеримые критерии усталости?
У меня тут в начале мая случилась авария — я переработал до отказа: буквально руки не поднимались делать дела, сил хватало закрыть 1–2 задачи в день, а всё остальное время сливал в пустоту. После почти двухнедельного отдыха (это для меня много), я сел и начал анализировать — из-за чего это случилось, и что сделать, чтобы больше так не выдыхаться.
Из-за чего случилось — довольно понятно: мой предыдущий отпуск был запланирован на 26 февраля, и конечно же я его отменил — и курс доллара непонятный (я летел в ОАЭ), и от команды далеко уходить не хотелось. Потом я как-то пытался компенсировать отдых — брать дейоффы, побольше спать и поменьше работать, но не получилось — видимо сказался общий нервяк от войны.
Где-то к апрелю я пришёл в состояние «некогда отдыхать» — когда даже боишься себе представить, что перестанешь работать на пару часов пораньше или проведёшь лишний выходной с семьёй. Получилась положительная обратная связь — стал работать так много, что перестал адекватно воспринимать работу, от чего начинал работать ещё больше. К чему это привело — написал выше.
Ну ок, почему выдохся — понятно. Осталось придумать, как избежать этого в будущем. Клёво было бы найти какой-нибудь универсальный маркер накопленной усталости — ведь когда ты разогнан до предела, вряд ли ты сам замечаешь свою неадекватность: её можно заметить только снаружи.
В поисках KPI я посравнивал своё отдохнувшее состояние с тем, что было в начале мая и нашёл вот такие отличия усталого Феди от нормального. Усталый Федя:
— Избегает общения с новыми людьми (да и со старыми тоже).
— Не хочет слушать новую музыку (даже daily mix в Spotify), смотреть новые фильмы.
— Не хочет медитировать и писать в дневник.
— Много ест (странно, но потребление алкоголя при этом в норме).
— Не хочет в новый город\новую кофейню\новый ресторан.
Кажется самый показательный и измеримый пункт из этого — дневник. Day One, который я использую, показывает календарь с днями, в которые я пишу заметки. В апреле дней с заметками было всего 6, причём в середине месяца было целых три недели подряд, в которые я вообще не притрагивался к дневнику.
Это и будет KPI — теперь если я обнаружу, что за две недели ни разу не притрагивался к дневнику, то я сразу же брошу все дела и устрою себе минимум 5-дневный отпуск.
А какие у вас есть измеримые критерии усталости?