Письмо самому себе
Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.
Первые две вещи настолько банальны, что на них не стоит останавливаться. А вот про письма в будущее расскажу подробнее.
Вы когда-нибудь задумывались, почему маленькое сообщение в телеграме заставляет людей отвлечься от интересной беседы или важной работы? Все дело в распространенной логической ошибке, которая называется привлекательность новизны. Грубо говоря, каждая последующая мысль пришедшая в голову, кажется более важной, чем предыдущая.
Если не сохранять внезапные мысли, то они будут улетать в бездонную пропасть. А если постоянно на них переключаться, то вы просто ничего не будете успевать — ведь рано или поздно вместо важной мысли вам придет голову идея проверить личные сообщения в фейсбуке, и вы проснетесь вечером в обнимку с котиками или очередной петицией против кровавого режима.
Чтобы не терять важное, я пишу письма самому себе. Как только в голову приходит любая мысль, которая не имеет отношения к тому, чем я занят сейчас, я ее записываю и отсылаю себе на почту. Мысль из головы сразу же уходит, и я возвращаюсь обратно к тому, что делал. Мысль не проебется — почту я проверяю периодически и полностью вычищаю ящик.
Раньше для для отсылки писем я пользовался программой на айфоне, которая так и называлась — Mail to Self. Однако со временем пришло понимание, что каждый клик понижает вероятность того, что мысль будет записана. Особенно Mail to Self страдала, когда хотелось отправить себе скриншот или фотографию.
Поэтому я пошел дальше и написал себе бота для телеграма — @selfmailbot. Бот делает простую штуку — все что я ему пишу, оказывается у меня на почте. Привычный интерфейс телеграма помогает лениться еще меньше и записывать вообще все, что приходит в голову.
Бот, кстати, бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь — @selfmailbot.
Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.
Первые две вещи настолько банальны, что на них не стоит останавливаться. А вот про письма в будущее расскажу подробнее.
Вы когда-нибудь задумывались, почему маленькое сообщение в телеграме заставляет людей отвлечься от интересной беседы или важной работы? Все дело в распространенной логической ошибке, которая называется привлекательность новизны. Грубо говоря, каждая последующая мысль пришедшая в голову, кажется более важной, чем предыдущая.
Если не сохранять внезапные мысли, то они будут улетать в бездонную пропасть. А если постоянно на них переключаться, то вы просто ничего не будете успевать — ведь рано или поздно вместо важной мысли вам придет голову идея проверить личные сообщения в фейсбуке, и вы проснетесь вечером в обнимку с котиками или очередной петицией против кровавого режима.
Чтобы не терять важное, я пишу письма самому себе. Как только в голову приходит любая мысль, которая не имеет отношения к тому, чем я занят сейчас, я ее записываю и отсылаю себе на почту. Мысль из головы сразу же уходит, и я возвращаюсь обратно к тому, что делал. Мысль не проебется — почту я проверяю периодически и полностью вычищаю ящик.
Раньше для для отсылки писем я пользовался программой на айфоне, которая так и называлась — Mail to Self. Однако со временем пришло понимание, что каждый клик понижает вероятность того, что мысль будет записана. Особенно Mail to Self страдала, когда хотелось отправить себе скриншот или фотографию.
Поэтому я пошел дальше и написал себе бота для телеграма — @selfmailbot. Бот делает простую штуку — все что я ему пишу, оказывается у меня на почте. Привычный интерфейс телеграма помогает лениться еще меньше и записывать вообще все, что приходит в голову.
Бот, кстати, бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь — @selfmailbot.
Важная мысль про сложные переговоры, которой почему-то нет в книгах
Когда мне предстоят важные и сложные переговоры, значит я скорее всего уже делаю что-то не так. Если результат мне так важен, то почему я поставил его в зависимость всего лишь от одной встречи?
Скажем, я нервничаю перед встречей, которая должна спасти отношения с важным клиентом. Почему я не следил за этими отношениями раньше? Почему испортил их до такого состояния, что надо идти и уговаривать кого-то остаться? Что мешало мне поставить на проект более сильного менеджера или построить систему сигналов, которая уведомляет меня в случае проблем?
Или нервяк перед собеседованием на работу. Какие причины нервничать, если я отлично разбираюсь в том, чем занимаюсь, у меня крутое резюме и рекомендации от известных людей?
Если за спиной все в порядке, то любые переговоры будут простыми. А если вы не уверены в себе, то никакие манипуляционные техники из книжек не помогут.
Единственный автор, который хоть немного подводит к этой мысли — Джим Кэмп со своей системой про «Нет». А остальные, кажется, просто пишут селф-хелп про то, как побороть неуверенность.
Когда мне предстоят важные и сложные переговоры, значит я скорее всего уже делаю что-то не так. Если результат мне так важен, то почему я поставил его в зависимость всего лишь от одной встречи?
Скажем, я нервничаю перед встречей, которая должна спасти отношения с важным клиентом. Почему я не следил за этими отношениями раньше? Почему испортил их до такого состояния, что надо идти и уговаривать кого-то остаться? Что мешало мне поставить на проект более сильного менеджера или построить систему сигналов, которая уведомляет меня в случае проблем?
Или нервяк перед собеседованием на работу. Какие причины нервничать, если я отлично разбираюсь в том, чем занимаюсь, у меня крутое резюме и рекомендации от известных людей?
Если за спиной все в порядке, то любые переговоры будут простыми. А если вы не уверены в себе, то никакие манипуляционные техники из книжек не помогут.
Единственный автор, который хоть немного подводит к этой мысли — Джим Кэмп со своей системой про «Нет». А остальные, кажется, просто пишут селф-хелп про то, как побороть неуверенность.
Вопрос: у нас небольшая команда без менеджера, и мне кажется, что один из участников недорабатывает. Спринты закрываем вовремя, но этот участник мало коммитит в приоритетные задачи. Что делать? Надо ли вообще?
Для начала, надо разобраться, почему это вас беспокоит.
Если сосед ставит под угрозу каждый спринт, и вам с коллегами приходится из-за него работать ночами — попробуйте сами увеличить его нагрузку. Эмоциональный разговор с выяснением отношений тут не поможет — просто системно, каждый спринт, просите делать его больше работы, присылая конкретные запросы, уровня «напиши такой-то код по такой-то задаче».
Если не хотите прокачиваться в дипломатии — сходите к тому, кто может решить вашу проблему — CTO, тимлиду, скрам-мастеру.
Но если сосед не создаёт явных проблем для планов, то может быть и ничего страшного в этом нет — просто производительность у всех людей разная.
Так что начните с честного ответа на вопрос, почему вас это беспокоит. Если ответ окажется неизмеримым — сфокусируйтесь лучше на своей производительности, чем на чужой: так будет гораздо больше выхлопа лично для вас.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Для начала, надо разобраться, почему это вас беспокоит.
Если сосед ставит под угрозу каждый спринт, и вам с коллегами приходится из-за него работать ночами — попробуйте сами увеличить его нагрузку. Эмоциональный разговор с выяснением отношений тут не поможет — просто системно, каждый спринт, просите делать его больше работы, присылая конкретные запросы, уровня «напиши такой-то код по такой-то задаче».
Если не хотите прокачиваться в дипломатии — сходите к тому, кто может решить вашу проблему — CTO, тимлиду, скрам-мастеру.
Но если сосед не создаёт явных проблем для планов, то может быть и ничего страшного в этом нет — просто производительность у всех людей разная.
Так что начните с честного ответа на вопрос, почему вас это беспокоит. Если ответ окажется неизмеримым — сфокусируйтесь лучше на своей производительности, чем на чужой: так будет гораздо больше выхлопа лично для вас.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
MVP и юнит-тесты
В руководствах для стартаперов часто пишут — забейте на идеальный код, не пишите юнит-тестов во время разработки MVP.
По-моему, не писать тесты — это то же самое, что отказаться от фигурной скобки или от отступов в коде. Конечно идеальный код писать действительно глупо — кому он нужен, если проект не запустился?. Но вот тесты — важная вещь даже для founders code.
Дело в том, что на этапе MVP критично важна скорость изменений — вы должны очень быстро выкатывать кучу сырых фич. А выкаченная фича — это когда код написан, выложен на прод и выполняет свою работу.
И если первые два пункта без тестов получаются немного быстрее (в первую неделю), то последний начинает тянуть вас вниз: программист без внешней помощи не может уследить за работоспособностью созданной им системы. И закрытые задачи начинают открываться обратно.
В компании из трех человек начинаются избыточные процессы вроде «приемки задачи», когда CEO будущего единорога садится и проверяет код за программистов. Ну а что, не станете же вы нанимать QA, чтобы тестировать MVP?
Самый хороший вариант — вообще не писать сложного кода на начальных этапах. Разместите свою бизнес-логику на каких-нибудь готовых движках, на худой конец напишите serverless. А если уж взялись пилить функциональность — покройте тестами хотя бы API. И пишите тесты не когда-нибудь потом, а до первой строчки кода.
В руководствах для стартаперов часто пишут — забейте на идеальный код, не пишите юнит-тестов во время разработки MVP.
По-моему, не писать тесты — это то же самое, что отказаться от фигурной скобки или от отступов в коде. Конечно идеальный код писать действительно глупо — кому он нужен, если проект не запустился?. Но вот тесты — важная вещь даже для founders code.
Дело в том, что на этапе MVP критично важна скорость изменений — вы должны очень быстро выкатывать кучу сырых фич. А выкаченная фича — это когда код написан, выложен на прод и выполняет свою работу.
И если первые два пункта без тестов получаются немного быстрее (в первую неделю), то последний начинает тянуть вас вниз: программист без внешней помощи не может уследить за работоспособностью созданной им системы. И закрытые задачи начинают открываться обратно.
В компании из трех человек начинаются избыточные процессы вроде «приемки задачи», когда CEO будущего единорога садится и проверяет код за программистов. Ну а что, не станете же вы нанимать QA, чтобы тестировать MVP?
Самый хороший вариант — вообще не писать сложного кода на начальных этапах. Разместите свою бизнес-логику на каких-нибудь готовых движках, на худой конец напишите serverless. А если уж взялись пилить функциональность — покройте тестами хотя бы API. И пишите тесты не когда-нибудь потом, а до первой строчки кода.
Размер бандла как сервис
У фронтендеров весьма сложная жизнь — в работе приходится использовать огромные объемы кода, которые не в состоянии охватить не только человек, но иногда и компьютер.
Пара мегабайт кода на фронтенде сейчас считается нормой — туда входят и пакеты совместимости со старыми браузерами, и удобные библиотеки из трех строк вроде left-pad.
Чтобы не раздувать бандл с кодом до предела, нужно постоянно замерять его размер. Для разового замера подойдет webpack-bundle-analyzer, но если вы не хотите сами колдовать с конфигой вебпака и настройкой CI, то есть прикольный сервис — packtracker.io.
Работает при помощи простого плагина к вебпаку, который отправляет результаты каждой сборки на сервер. Packtracker можно интегрировать с гитхабом, что позволяет буквально мышкой настраивать попроектные лимиты на размер бандла.
За 3 приватных проекта сервис просит $9 в месяц. Ребята кажется достаточно плотно завязаны на вебпак, поэтому интересно, что они будут делать, когда мир перейдет на zero-config сборщики вроде parcel. Но пока — норм.
У фронтендеров весьма сложная жизнь — в работе приходится использовать огромные объемы кода, которые не в состоянии охватить не только человек, но иногда и компьютер.
Пара мегабайт кода на фронтенде сейчас считается нормой — туда входят и пакеты совместимости со старыми браузерами, и удобные библиотеки из трех строк вроде left-pad.
Чтобы не раздувать бандл с кодом до предела, нужно постоянно замерять его размер. Для разового замера подойдет webpack-bundle-analyzer, но если вы не хотите сами колдовать с конфигой вебпака и настройкой CI, то есть прикольный сервис — packtracker.io.
Работает при помощи простого плагина к вебпаку, который отправляет результаты каждой сборки на сервер. Packtracker можно интегрировать с гитхабом, что позволяет буквально мышкой настраивать попроектные лимиты на размер бандла.
За 3 приватных проекта сервис просит $9 в месяц. Ребята кажется достаточно плотно завязаны на вебпак, поэтому интересно, что они будут делать, когда мир перейдет на zero-config сборщики вроде parcel. Но пока — норм.
Вопрос: Что думаешь о Node.js на вебе? Как по сравнению с Python & Django? Почему вы выбрали именно Django?
Примерно то же, что и про монорепозитории — если вам ок, и вы решаете свои задачи — отлично!
Когда мы выбирали технологии в mtrl.ai, мы осознавали, что начинаем большой проект — гипотеза уже доказана, MVP уже работает. Монолит выбрали потому, что микросервисы требуют слишком много инфраструктуры, а это неприемлемо для команды из двух человек, с которой мы начинали.
JS не взяли потому, что в экосистеме ноды технологии умирают слишком быстро. Если бы в 2017 году мы начали кодить наш проект на ноде, то к концу 2018 мы бы получили неуправляемый монолит на неподдерживаемом фреймворке вроде какого-нибудь meteor.js.
Отвечая на вторую часть вопроса про то, что лучше — python или JS, дам ссылку на пост в моем блоге про выбор языка программирования для менеджеров.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Примерно то же, что и про монорепозитории — если вам ок, и вы решаете свои задачи — отлично!
Когда мы выбирали технологии в mtrl.ai, мы осознавали, что начинаем большой проект — гипотеза уже доказана, MVP уже работает. Монолит выбрали потому, что микросервисы требуют слишком много инфраструктуры, а это неприемлемо для команды из двух человек, с которой мы начинали.
JS не взяли потому, что в экосистеме ноды технологии умирают слишком быстро. Если бы в 2017 году мы начали кодить наш проект на ноде, то к концу 2018 мы бы получили неуправляемый монолит на неподдерживаемом фреймворке вроде какого-нибудь meteor.js.
Отвечая на вторую часть вопроса про то, что лучше — python или JS, дам ссылку на пост в моем блоге про выбор языка программирования для менеджеров.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Менеджер реагирующий vs менеджер инициирующий
Всю активность менеджера можно условно разделить на два вида: реагирование и инициирование. Реагирование — это работа с внешними раздражителями: телефонными звонками, письмами, коллегами, которые подошли с вопросом.
Инициирование — это действия, направленные на то, чтобы результаты достигались, а раздражителей было поменьше: планирование встреч, отчеты, постановка задач.
Плохой менеджер всегда больше реагирует, чем инициирует. Вместо того, чтобы тратить по 10 минут в неделю на регулярное отчетное письмо команде, он предпочитает лично в слаке рассказывать каждому новости, и потом ещё решать проблемы вызванные дискоммуникацией, когда левая рука не знает, что делает правая.
У программистов все так же: плохой программист реагирует на инциденты вроде упавшего прода, а хороший — делает так, чтобы прод не падал: пишет тесты, внимательно проверяет работу перед публикацией, настраивает автооткат проблемных изменений, строит процессы и коммуникацию вокруг себя.
Чем больше вы инициируете, тем меньше становится раздражителей, на которые приходится реагировать, а значит тем спокойнее вы спите и тем лучше управляете своим расписанием.
Всю активность менеджера можно условно разделить на два вида: реагирование и инициирование. Реагирование — это работа с внешними раздражителями: телефонными звонками, письмами, коллегами, которые подошли с вопросом.
Инициирование — это действия, направленные на то, чтобы результаты достигались, а раздражителей было поменьше: планирование встреч, отчеты, постановка задач.
Плохой менеджер всегда больше реагирует, чем инициирует. Вместо того, чтобы тратить по 10 минут в неделю на регулярное отчетное письмо команде, он предпочитает лично в слаке рассказывать каждому новости, и потом ещё решать проблемы вызванные дискоммуникацией, когда левая рука не знает, что делает правая.
У программистов все так же: плохой программист реагирует на инциденты вроде упавшего прода, а хороший — делает так, чтобы прод не падал: пишет тесты, внимательно проверяет работу перед публикацией, настраивает автооткат проблемных изменений, строит процессы и коммуникацию вокруг себя.
Чем больше вы инициируете, тем меньше становится раздражителей, на которые приходится реагировать, а значит тем спокойнее вы спите и тем лучше управляете своим расписанием.
Почему я не люблю дейли-митинги
Практика ежедневных встреч в скраме поначалу обещает многое — вроде бы сотрудники будут сами обсуждать между собой планы и проблемы. Кажется это клево — задачи не подвисают между участниками, причастные люди узнают о проблемах в течение суток после того, как они появляются.
Но с другой стороны, руководитель, который назначает обязательную ежедневную встречу, как бы говорит своей команде: «ребята, вы плохо справляетесь с коммуникацией и тайм-менеджментом, поэтому вот вам теперь фреймворк — дейли-митинги. Теперь вам не нужно ничего думать, просто каждое утро собирайтесь и проходитесь по пунктам». Это не страшно — многим людям этого правда не хватает. Но лично для меня выглядит как наказание.
Взрослые люди сами в состоянии управлять своим временем и обозначать проблемы. Им не нужно сжигать человекочасы на пустые встречи по формальной повестке — гораздо проще написать письмо или поставить задачу в трекере, чем ждать следующей встречи.
Мы в mtrl.ai практикуем в команде дейли-митинги только в двух случаях — когда несколько человек делают один проект (и сами об этом договорились), или когда участник не справляется с задачами и ему нужна помощь извне.
Практика ежедневных встреч в скраме поначалу обещает многое — вроде бы сотрудники будут сами обсуждать между собой планы и проблемы. Кажется это клево — задачи не подвисают между участниками, причастные люди узнают о проблемах в течение суток после того, как они появляются.
Но с другой стороны, руководитель, который назначает обязательную ежедневную встречу, как бы говорит своей команде: «ребята, вы плохо справляетесь с коммуникацией и тайм-менеджментом, поэтому вот вам теперь фреймворк — дейли-митинги. Теперь вам не нужно ничего думать, просто каждое утро собирайтесь и проходитесь по пунктам». Это не страшно — многим людям этого правда не хватает. Но лично для меня выглядит как наказание.
Взрослые люди сами в состоянии управлять своим временем и обозначать проблемы. Им не нужно сжигать человекочасы на пустые встречи по формальной повестке — гораздо проще написать письмо или поставить задачу в трекере, чем ждать следующей встречи.
Мы в mtrl.ai практикуем в команде дейли-митинги только в двух случаях — когда несколько человек делают один проект (и сами об этом договорились), или когда участник не справляется с задачами и ему нужна помощь извне.
Вопрос: вот у вас большое приложение на Django. Как вы разбиваете код по отдельным приложениям внутри?
Сейчас самый большой наш проект разбит на ~50 приложений Django, и намертво мы завязаны не больше, чем на 10 из них.
Правило простое — при проектировании нового приложения внутри Django нужно делать его таким, чтобы в любой момент его было можно удалить. Отцепляемые приложения сами по себе требуют красивых конструкций — маленьких моделей, продуманных интерфейсов взаимодействия.
Если я отцеплляю новое приложение и падает всего пара десятков тестов — это ок. Если падает 100 и больше — значит я написал что-то слишком толстое.
Ну а в остальном — нужно ориентироваться на здравый смысл и размер
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Кстати, ответьте пожалуйста, насколько вам здесь интересно читать про Python/Django и вообще про разработку больших приложений с точки зрения кода?
😞 — пофиг, 😍 — интересно, 🚴 — еще расскажи про девопс и микросервисы на ноде
Сейчас самый большой наш проект разбит на ~50 приложений Django, и намертво мы завязаны не больше, чем на 10 из них.
Правило простое — при проектировании нового приложения внутри Django нужно делать его таким, чтобы в любой момент его было можно удалить. Отцепляемые приложения сами по себе требуют красивых конструкций — маленьких моделей, продуманных интерфейсов взаимодействия.
Если я отцеплляю новое приложение и падает всего пара десятков тестов — это ок. Если падает 100 и больше — значит я написал что-то слишком толстое.
Ну а в остальном — нужно ориентироваться на здравый смысл и размер
models.py.Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Кстати, ответьте пожалуйста, насколько вам здесь интересно читать про Python/Django и вообще про разработку больших приложений с точки зрения кода?
😞 — пофиг, 😍 — интересно, 🚴 — еще расскажи про девопс и микросервисы на ноде
FOMO
FOMO это когнитивное искажение, которое заставляет нас делать странные вещи, к примеру покупать акции «на новостях» — когда упал второй боинг подряд, и мы сломя голову бежим покупать вдолгую.
Тот же самый FOMO настигает нас в торговом центре, когда мы заходим в магазин с распродажей и покупаем себе третий подряд ненужный джемпер, «потому что потом подорожает».
FOMO — это сокращение от Fear Of Missing Out, страх упустить возможность. Он сидит настолько глубоко в каждом из нас, что часто не мы находим возможности, а возможности находят нас и подчиняют себе. Увидел красивый банер с детьми и улыбающейся женщиной в домашней одежде, по телефону тебе объясняют, что цена действует «всего три недели» — и бац, ты уже подписываешь кабальный контракт, по которому 15 лет (треть активной жизни!) будешь платить за однушку посреди поля в 40 километрах от МКАД.
Да, возможности нужно ценить. Акции действительно выгоднее покупать, когда они дешевеют. Одежду действительно лучше покупать на распродажах. Но это нужно делать по плану: купленные акции должны соответствовать стратегии портфеля.
Идеально, когда стратегия с самого начала основана на том, чтобы не упускать возможности, но и не зависеть от них. Я, к примеру, обновляю обувь раз в год — в феврале. Я очень люблю кроссовки Salomon, а февраль — традиционно мёртвый сезон для продавцов спорттоваров, поэтому я экономлю не меньше половины от стоимости тех же самых кроссовок осенью или весной.
Однако Salomon — кроссовки надежные. Если вдруг скидок в феврале не случится (или я не смогу ими воспользоваться, как в этом году), то я не останусь без обуви — просто прохожу ещё год в тех же самых кроссовках.
Так что читайте Нассима Николасовича и не упускайте возможности.
FOMO это когнитивное искажение, которое заставляет нас делать странные вещи, к примеру покупать акции «на новостях» — когда упал второй боинг подряд, и мы сломя голову бежим покупать вдолгую.
Тот же самый FOMO настигает нас в торговом центре, когда мы заходим в магазин с распродажей и покупаем себе третий подряд ненужный джемпер, «потому что потом подорожает».
FOMO — это сокращение от Fear Of Missing Out, страх упустить возможность. Он сидит настолько глубоко в каждом из нас, что часто не мы находим возможности, а возможности находят нас и подчиняют себе. Увидел красивый банер с детьми и улыбающейся женщиной в домашней одежде, по телефону тебе объясняют, что цена действует «всего три недели» — и бац, ты уже подписываешь кабальный контракт, по которому 15 лет (треть активной жизни!) будешь платить за однушку посреди поля в 40 километрах от МКАД.
Да, возможности нужно ценить. Акции действительно выгоднее покупать, когда они дешевеют. Одежду действительно лучше покупать на распродажах. Но это нужно делать по плану: купленные акции должны соответствовать стратегии портфеля.
Идеально, когда стратегия с самого начала основана на том, чтобы не упускать возможности, но и не зависеть от них. Я, к примеру, обновляю обувь раз в год — в феврале. Я очень люблю кроссовки Salomon, а февраль — традиционно мёртвый сезон для продавцов спорттоваров, поэтому я экономлю не меньше половины от стоимости тех же самых кроссовок осенью или весной.
Однако Salomon — кроссовки надежные. Если вдруг скидок в феврале не случится (или я не смогу ими воспользоваться, как в этом году), то я не останусь без обуви — просто прохожу ещё год в тех же самых кроссовках.
Так что читайте Нассима Николасовича и не упускайте возможности.
1:1 вместо дейли-митингов
Сразу несколько ребят спросили в личку, а как мы вообще общаемся в команде. Отвечу — коммуникация между разработчиками никак не регламентирована (все взрослые, а команда пока маленькая). А общение разработчиков со мной имеет один обязательный элемент — периодические встречи 1:1.
Я обязательно провожу такие встречи с каждым без исключения участником команды. Цель 1:1 — получить обратную связь: хорошо ли прошли последние спринты, получает ли программист удовольствие от задач, какие проблемы в команде и процессах он видит, что его беспокоит.
Хотя 1:1 может проходить в свободном режиме, совсем без повестки, я готовлюсь к ним все время — в Notes есть заметочка для каждого сотрудника, в которую я записываю идея для обсуждения на следующей 1:1.
Сразу несколько ребят спросили в личку, а как мы вообще общаемся в команде. Отвечу — коммуникация между разработчиками никак не регламентирована (все взрослые, а команда пока маленькая). А общение разработчиков со мной имеет один обязательный элемент — периодические встречи 1:1.
Я обязательно провожу такие встречи с каждым без исключения участником команды. Цель 1:1 — получить обратную связь: хорошо ли прошли последние спринты, получает ли программист удовольствие от задач, какие проблемы в команде и процессах он видит, что его беспокоит.
Хотя 1:1 может проходить в свободном режиме, совсем без повестки, я готовлюсь к ним все время — в Notes есть заметочка для каждого сотрудника, в которую я записываю идея для обсуждения на следующей 1:1.
Django — это API
Периодически встречаю ребят, которые учат Django от корки до корки, включая такие странные вещи как Django Templates или Django Forms.
Ребята, не тратьте на это время! Если на вашем проекте в 2019 году генерируют HTML на бекенде, он скорее всего серьезно болеет. Гораздо быстрее, понятнее и проще взять любой современный JS-фреймворк. Или вообще без него обойтись, но ни в коем случае не генерить HTML в Django.
В Django есть несколько удобных и красивых (если не читать исходники) вещей — Django ORM, Django admin, вещи связанные с обработкой HTTP-запросов и переводами. Во всем остальном Django — это монстр из начала двухтысячных, затаскивая которого в проект вы с первой строчки начинаете писать legacy.
Так что ставьте DRF, Graphene или что вам ближе, но даже не пытайтесь генерить HTML на джанге.
Периодически встречаю ребят, которые учат Django от корки до корки, включая такие странные вещи как Django Templates или Django Forms.
Ребята, не тратьте на это время! Если на вашем проекте в 2019 году генерируют HTML на бекенде, он скорее всего серьезно болеет. Гораздо быстрее, понятнее и проще взять любой современный JS-фреймворк. Или вообще без него обойтись, но ни в коем случае не генерить HTML в Django.
В Django есть несколько удобных и красивых (если не читать исходники) вещей — Django ORM, Django admin, вещи связанные с обработкой HTTP-запросов и переводами. Во всем остальном Django — это монстр из начала двухтысячных, затаскивая которого в проект вы с первой строчки начинаете писать legacy.
Так что ставьте DRF, Graphene или что вам ближе, но даже не пытайтесь генерить HTML на джанге.
Уменьшить количество обещаний
Обещания надо соблюдать. Пацан сказал — пацан сделал.
Самый хороший способ соблюдать обещания — давать их поменьше. К примеру я очень не приветствую обещания, которые оканчиваются посреди спринта: если задача ушла в спринт, то у неё должен быть такой же дедлайн, как и у всех остальных.
Это уменьшает количество точек контроля: мне не нужно каждый день проверять, выполняю ли я обещания, которые когда-то дал на сегодня — достаточно в середине и конце спринта проверить, что я выполняю все обещания, данные на спринт.
К тому же, когда у команды каждый день — дедлайн, это давит. Когда дедлайн раз в две недели — давит только раз в две недели. А при своевременном контроле и здоровой атмосфере в команде — не давит вообще.
Обещания надо соблюдать. Пацан сказал — пацан сделал.
Самый хороший способ соблюдать обещания — давать их поменьше. К примеру я очень не приветствую обещания, которые оканчиваются посреди спринта: если задача ушла в спринт, то у неё должен быть такой же дедлайн, как и у всех остальных.
Это уменьшает количество точек контроля: мне не нужно каждый день проверять, выполняю ли я обещания, которые когда-то дал на сегодня — достаточно в середине и конце спринта проверить, что я выполняю все обещания, данные на спринт.
К тому же, когда у команды каждый день — дедлайн, это давит. Когда дедлайн раз в две недели — давит только раз в две недели. А при своевременном контроле и здоровой атмосфере в команде — не давит вообще.
Не надо учить технологии — учитесь решать задачи
В личке много ребят задают вопрос — как правильно выбрать технологии? Что учить, чтобы не отстать от прогресса?
Технологии (фреймворки, паттерны, методики разработки, языки программирования) — это хард-скиллы, то есть навыки, которым можно научиться, просто прочитав пару толстых книг и немного попрактиковавшись. Имея базовые знания о том, как устроены инструменты программиста, ничего не стоит выучить нужный, в любом возрасте.
Но умные компании покупают на рынке труда не знание конкретных инструментов — они покупают умение решать задачи. А это уже — софт-скилл, навык, который приходит только с опытом.
Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.
Чем вы построите этот дом: шуруповертом, подъёмным краном или нанятой командой монтажников — не так уж важно. Важно ваше умение решать задачи, при необходимости включая в свой арсенал неизвестные ранее инструменты.
В личке много ребят задают вопрос — как правильно выбрать технологии? Что учить, чтобы не отстать от прогресса?
Технологии (фреймворки, паттерны, методики разработки, языки программирования) — это хард-скиллы, то есть навыки, которым можно научиться, просто прочитав пару толстых книг и немного попрактиковавшись. Имея базовые знания о том, как устроены инструменты программиста, ничего не стоит выучить нужный, в любом возрасте.
Но умные компании покупают на рынке труда не знание конкретных инструментов — они покупают умение решать задачи. А это уже — софт-скилл, навык, который приходит только с опытом.
Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.
Чем вы построите этот дом: шуруповертом, подъёмным краном или нанятой командой монтажников — не так уж важно. Важно ваше умение решать задачи, при необходимости включая в свой арсенал неизвестные ранее инструменты.
Вопрос: вот уже третий раз пытаюсь внедрить пустой инбокс, но к концу недели все равно копится гора писем, которую не хочется разбирать. В итоге я в унынии забиваю. Что делать?
Самый важный показатель при работе с почтой — это уровень спокойствия, ведь почта это раздражитель. В общем-то основная цель пустого инбокса — снять возможные переживания, когда вы ложитесь спать, а у вас висят какие-то невыполненные дела или неотвеченные письма.
Если количество писем в инбоксе причиняет сильное беспокойство (ааа, 200 писем, куда бежать??77) то вряд ли вы их когда-нибудь разберете. У меня вообще в такие моменты включается чувство вины (условное «я дно, даже почту разобрать не могу»). Хочется всячески прокрастинировать: писать всем в телеграм, звонить по телефону, или тупануть в фейсбучек.
Это — нормальные реакции мозга. И способа побороться с ними всего два — либо постигнуть дзен и перестать беспокоиться обо всем сразу, либо убрать раздражитель, то есть все-таки очистить ящик. Вот мои способы очистить ящик, которыми я пользуюсь, когда загоняю себя в ловушку с бездонным инбоксом.
1) «Отвечу через неделю». Можно просто пообещать ответить через неделю, запланировать задачу, и заархивировать письмо. Есть много задач, для которых это нормально: к примеру вы обсуждаете постановку задачи на следующий спринт, до которого ещё пара недель. Избавляешься таким образом от первого десятка писем — и отвращение выключается, дальше начинается нормальный разбор.
2) Попрятать все письма куда подальше. Смысл в том, чтобы убрать вообще все напоминания о неразобранной горе, включая саму папку входящих. Помогает от отвращения, которое возникает в момент открытия почтового клиента, чтобы, скажем, написать письмо. Я для этих целей держу специальную папочку «_empty», куда прячу все письма из инбокса, пока он не дорастет до нормальных размеров. Содержимое этой папочки разбираю потихоньку, по 30 минут в день.
3) Почтовое банкротство. Внезапно, можно просто удалить все письма. Кому надо — еще раз напишут. Я так делаю два-три раза в год, и пока никто не умер :-)
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Самый важный показатель при работе с почтой — это уровень спокойствия, ведь почта это раздражитель. В общем-то основная цель пустого инбокса — снять возможные переживания, когда вы ложитесь спать, а у вас висят какие-то невыполненные дела или неотвеченные письма.
Если количество писем в инбоксе причиняет сильное беспокойство (ааа, 200 писем, куда бежать??77) то вряд ли вы их когда-нибудь разберете. У меня вообще в такие моменты включается чувство вины (условное «я дно, даже почту разобрать не могу»). Хочется всячески прокрастинировать: писать всем в телеграм, звонить по телефону, или тупануть в фейсбучек.
Это — нормальные реакции мозга. И способа побороться с ними всего два — либо постигнуть дзен и перестать беспокоиться обо всем сразу, либо убрать раздражитель, то есть все-таки очистить ящик. Вот мои способы очистить ящик, которыми я пользуюсь, когда загоняю себя в ловушку с бездонным инбоксом.
1) «Отвечу через неделю». Можно просто пообещать ответить через неделю, запланировать задачу, и заархивировать письмо. Есть много задач, для которых это нормально: к примеру вы обсуждаете постановку задачи на следующий спринт, до которого ещё пара недель. Избавляешься таким образом от первого десятка писем — и отвращение выключается, дальше начинается нормальный разбор.
2) Попрятать все письма куда подальше. Смысл в том, чтобы убрать вообще все напоминания о неразобранной горе, включая саму папку входящих. Помогает от отвращения, которое возникает в момент открытия почтового клиента, чтобы, скажем, написать письмо. Я для этих целей держу специальную папочку «_empty», куда прячу все письма из инбокса, пока он не дорастет до нормальных размеров. Содержимое этой папочки разбираю потихоньку, по 30 минут в день.
3) Почтовое банкротство. Внезапно, можно просто удалить все письма. Кому надо — еще раз напишут. Я так делаю два-три раза в год, и пока никто не умер :-)
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Автоматизация рутины при помощи клавиатурных шаблонов в маке
Я, как любой разработчик, люблю автоматизировать рутину. В этой заметке расскажу про не очень очевидный способ автоматизации — при помощи клавиатурных шаблонов.
К примеру я часто отправляю тестовое задание потенциальным коллегам. Это целый процесс, который состоит из нескольких сообщений — поставить задачу в репозитории, отправить приглашение и инструкцию и т.д. Если бы я каждый раз вручную писал эти письма — я бы целыми днями только и делал бы то, что отсылал тестовые задания. Если бы искал их в каком-нибудь списке почтовых шаблонов — было бы быстрее, но не намного.
Поэтому я выбрал путь настоящего джедая — клавиатурные сокращения в настройках мака: Keyboard → Text.
К примеру я набираю «гм-тз-гитхаб» и получаю текст сообщения, которым я приглашаю соискателя выполнить тестовое задание.
Набираю «календарик» и получаю ссылку на свой appoint.ly, которую высылаю для назначения встречи со мной, чтобы не обмениваться письмами.
Я, как любой разработчик, люблю автоматизировать рутину. В этой заметке расскажу про не очень очевидный способ автоматизации — при помощи клавиатурных шаблонов.
К примеру я часто отправляю тестовое задание потенциальным коллегам. Это целый процесс, который состоит из нескольких сообщений — поставить задачу в репозитории, отправить приглашение и инструкцию и т.д. Если бы я каждый раз вручную писал эти письма — я бы целыми днями только и делал бы то, что отсылал тестовые задания. Если бы искал их в каком-нибудь списке почтовых шаблонов — было бы быстрее, но не намного.
Поэтому я выбрал путь настоящего джедая — клавиатурные сокращения в настройках мака: Keyboard → Text.
К примеру я набираю «гм-тз-гитхаб» и получаю текст сообщения, которым я приглашаю соискателя выполнить тестовое задание.
Набираю «календарик» и получаю ссылку на свой appoint.ly, которую высылаю для назначения встречи со мной, чтобы не обмениваться письмами.
Ответы на вопросы переезжают
Ответы на вопросы про ИТ, которые я давал по понедельникам, плавно переезжают на сайт Бюро Горбунова. Там они будут выходить в формате советов, по четвергам, раз в три недели.
Аудитория бюро по большей части состоит из дизайнеров и руководителей, а вопросы ко мне прилетают гораздо чаще, чем раз в три недели, поэтому я продолжу отвечать и здесь. На сайт бюро пойдут более развернутые и фундаментальные ответы, а здесь останутся короткие и практические советы. Например, вопрос «Федя, расскажи вы у себя оформляете пулл-реквесты» получит ответ в канале, а «Федя, какие технические знания нужны менеджеру, чтобы управлять командой программистов?» — пойдет на сайт Бюро.
Вышел уже первый совет-представление, где я рассказываю о себе и привожу примеры, о чем меня стоит спрашивать.
Совет на сайте бюро можно спросить не только у меня, но и у других экспертов в дизайне продуктов и услуг, верстке, переговорах, программировании, управлении проектами и редактуре:
Ответы на вопросы про ИТ, которые я давал по понедельникам, плавно переезжают на сайт Бюро Горбунова. Там они будут выходить в формате советов, по четвергам, раз в три недели.
Аудитория бюро по большей части состоит из дизайнеров и руководителей, а вопросы ко мне прилетают гораздо чаще, чем раз в три недели, поэтому я продолжу отвечать и здесь. На сайт бюро пойдут более развернутые и фундаментальные ответы, а здесь останутся короткие и практические советы. Например, вопрос «Федя, расскажи вы у себя оформляете пулл-реквесты» получит ответ в канале, а «Федя, какие технические знания нужны менеджеру, чтобы управлять командой программистов?» — пойдет на сайт Бюро.
Вышел уже первый совет-представление, где я рассказываю о себе и привожу примеры, о чем меня стоит спрашивать.
Совет на сайте бюро можно спросить не только у меня, но и у других экспертов в дизайне продуктов и услуг, верстке, переговорах, программировании, управлении проектами и редактуре:
А еще на VC вышла моя статья о том, как правильно готовить гитхаб, чтобы людям не приходилось переключаться между 5 разными средствами коллаборации — https://vc.ru/services/60710-github-kak-edinstvennoe-sredstvo-obshcheniya
Если на работе вас сейчас достает Асана\Битрикс\Жира и слек с телеграмом, почитайте по ссылке как надо было.
Если на работе вас сейчас достает Асана\Битрикс\Жира и слек с телеграмом, почитайте по ссылке как надо было.
vc.ru
GitHub как единственное средство общения
GitHub в нашем стартапе — единственный инструмент общения для команды из десяти разработчиков. У нас нет Jira, Slack или Asana, Telegram-чат мы завели для мемов, а Trello используем только для общения с бизнесом.
Python: никогда не использовать unittest
В стандартной библиотеке питона лежит модуль unittest — набор инструментов для написания тестов. В комлпекте Django лежит даже надстройка над unittest, которая умеет ходить в API и заворачивать тесты в транзакции.
Так вот — никогда не пытайтесь использовать эту библиотеку, даже на маленьких проектах и даже чтобы попробовать. Unittest — ОЧЕНЬ плохая библиотека.
Начнем с того, что unittest — это порт древнего Junit, кажется вообще первого инструмента для тестирования, которое придумало человечество еще в 90-х годах. От Java в нем осталось совершенно ненужное ООП и наркоманские ассерты, вроде
А еще:
— unittest не умеет нормально распараллеливать тесты (вроде бы есть
— unittest не позволяет переиспользовать фикстуры. Только через наследование, из-за которого вы очень быстро перестаете понимать, что у вас вообще происходит.
— В unittest очень неудобно отключать тест большими кусками — у вас нет возможности пометить набор тестов, скажем как требующий elasticsearch, и прогонять их только в средах, где elasticsearch доступен — только по именам тестовых классов
— У unittest очень плохой генератор тестов.
Возьмите лучше pytest. Да порог входа чуть выше — функциональное программирование понятно не с первого раза. Но если вы собираетесь построить проект с управляемыми тестами, то замену вы вряд ли найдете.
Кстати, каждый тесткейс на unittest — это тесткейс и на pytest, так что можете взять его прямо сейчас.
В стандартной библиотеке питона лежит модуль unittest — набор инструментов для написания тестов. В комлпекте Django лежит даже надстройка над unittest, которая умеет ходить в API и заворачивать тесты в транзакции.
Так вот — никогда не пытайтесь использовать эту библиотеку, даже на маленьких проектах и даже чтобы попробовать. Unittest — ОЧЕНЬ плохая библиотека.
Начнем с того, что unittest — это порт древнего Junit, кажется вообще первого инструмента для тестирования, которое придумало человечество еще в 90-х годах. От Java в нем осталось совершенно ненужное ООП и наркоманские ассерты, вроде
self.assertEqual(a, 'b') вместо assert a == 'b'.А еще:
— unittest не умеет нормально распараллеливать тесты (вроде бы есть
nose, но он умер). Когда на проекте появляется больше 500 тестов, это становится большой проблемой.— unittest не позволяет переиспользовать фикстуры. Только через наследование, из-за которого вы очень быстро перестаете понимать, что у вас вообще происходит.
— В unittest очень неудобно отключать тест большими кусками — у вас нет возможности пометить набор тестов, скажем как требующий elasticsearch, и прогонять их только в средах, где elasticsearch доступен — только по именам тестовых классов
— У unittest очень плохой генератор тестов.
Возьмите лучше pytest. Да порог входа чуть выше — функциональное программирование понятно не с первого раза. Но если вы собираетесь построить проект с управляемыми тестами, то замену вы вряд ли найдете.
Кстати, каждый тесткейс на unittest — это тесткейс и на pytest, так что можете взять его прямо сейчас.
Чем опытнее программист, тем проще код он пишет
Как отличить код новичка от кода опытного синьора? Код у синьора обычно проще и понятнее, чем код новичка, который решает ту же задачу. Код у крутого синьора понятен настолько, что гляда на код бизнес-логику может осознать человек, который знает английский язык, но ничего не понимает в программировании.
Я говорю не о цикломатической сложности — дело скорее в читаемости. У новичка код как будто из фильма про хакеров: неинтутивные названия переменных (
Хотите стать синьором — пишите проще. Представьте, что ваш код будет читать QA, который не сильно глубоко знает ваш язык, и сделайте так, чтобы он вас понял.
Как отличить код новичка от кода опытного синьора? Код у синьора обычно проще и понятнее, чем код новичка, который решает ту же задачу. Код у крутого синьора понятен настолько, что гляда на код бизнес-логику может осознать человек, который знает английский язык, но ничего не понимает в программировании.
Я говорю не о цикломатической сложности — дело скорее в читаемости. У новичка код как будто из фильма про хакеров: неинтутивные названия переменных (
o вместо order), сложные методы, излишние абстрактные классы и генераторы, «лазанья» и т.д.Хотите стать синьором — пишите проще. Представьте, что ваш код будет читать QA, который не сильно глубоко знает ваш язык, и сделайте так, чтобы он вас понял.
Вопрос: были ли у вас проблемы с внимательностью у разработчиков? Как отлавливаете это на собеседовании?
Я знаю, что существуют тесты на внимательность для бухгалтеров — им дают бумажку с двумя колонками длинных цифр и просят найти отличия. Разработчиков тестировать таким образом кажется странным: сверять цифры — это задача машины.
Я проверяю внимательность новых ребят точно таким же способом, как проверяю проактивность, усидчивость, умение управлять своим временем, понимать коллег, разбираться в бизнес-контексте и читать документацию — я просто предлагаю им пару недель поработать в моей команде. Работает лучше любых тестов и вопросов про крышки люков или форму пожарного ведра.
А вообще хочется разобраться поглубже — какие проблемы невнимательность вызывает в бизнесе? Возможно проблема не в разработчиках? К примеру, если вам кажется, что из-за невнимательности говно часто попадает в релиз, то наверное у вас плохие тесты или проблемы с QA. Если невнимательность приводит к тому, что программисты не соблюдают требования, прописанные в задачах, то может быть вы просто мало говорите со своей командой?
Другие вопросы — #вопрос. Задать свой — @fedor_borshev
Я знаю, что существуют тесты на внимательность для бухгалтеров — им дают бумажку с двумя колонками длинных цифр и просят найти отличия. Разработчиков тестировать таким образом кажется странным: сверять цифры — это задача машины.
Я проверяю внимательность новых ребят точно таким же способом, как проверяю проактивность, усидчивость, умение управлять своим временем, понимать коллег, разбираться в бизнес-контексте и читать документацию — я просто предлагаю им пару недель поработать в моей команде. Работает лучше любых тестов и вопросов про крышки люков или форму пожарного ведра.
А вообще хочется разобраться поглубже — какие проблемы невнимательность вызывает в бизнесе? Возможно проблема не в разработчиках? К примеру, если вам кажется, что из-за невнимательности говно часто попадает в релиз, то наверное у вас плохие тесты или проблемы с QA. Если невнимательность приводит к тому, что программисты не соблюдают требования, прописанные в задачах, то может быть вы просто мало говорите со своей командой?
Другие вопросы — #вопрос. Задать свой — @fedor_borshev