Страх ошибиться — самый большой враг хорошего кода
Есть много людей, которым лучше не ошибаться — к примеру пилоты самолета или сердечные хирурги. Программистам повезло — им ошибаться можно.
Ошибки программистов проходят через очень хороший контроль: автотесты, отделы QA, фиче-флаги.
Даже когда ошибка добирается до продакшена, у нас есть множество инструментов быстрого отката: k8s не заведет больной контейнер, дежурный инженер откатит непрошедшую миграцию. Если ни один инструмент не подошел, всегда можно просто накатить хотфинкс поверх выложенной кодовой базы.
Но, несмотря на внушительный набор инструментов, мы все еще боимся рефакторинга, «потому что может сломаться». На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.
Давайте не бояться ошибок — мы не пилоты самолета, в конце концов. Хотя и пилоты занимаются на тренажере именно для того, чтобы ошибаться и отрабатывать исправление этих ошибок.
Есть много людей, которым лучше не ошибаться — к примеру пилоты самолета или сердечные хирурги. Программистам повезло — им ошибаться можно.
Ошибки программистов проходят через очень хороший контроль: автотесты, отделы QA, фиче-флаги.
Даже когда ошибка добирается до продакшена, у нас есть множество инструментов быстрого отката: k8s не заведет больной контейнер, дежурный инженер откатит непрошедшую миграцию. Если ни один инструмент не подошел, всегда можно просто накатить хотфинкс поверх выложенной кодовой базы.
Но, несмотря на внушительный набор инструментов, мы все еще боимся рефакторинга, «потому что может сломаться». На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.
Давайте не бояться ошибок — мы не пилоты самолета, в конце концов. Хотя и пилоты занимаются на тренажере именно для того, чтобы ошибаться и отрабатывать исправление этих ошибок.
Выбрать фреймворк для нового проекта
Многие ребята, выбирая инструменты для нового проекта, начинают строить таблицы, сравнивая фичи. Серьезно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.
Если вы выбираете инструменты для «домашнего» проекта — это вполне ок: подобрать приятный тулинг в этом случае настолько же важно, как и запустить проект.
А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта _сейчас_. Подумайте лучше о том, каким будет ваш фреймворк _тогда_. Удержит ли он комьюнити? Успеет ли за быстроизменяющейся средой? Будет ли адекватное предложение на рынке труда?
Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends.
И да, если вы выбираете фреймворк для фронтенда, то берите любой — все равно он протухнет через год.
Многие ребята, выбирая инструменты для нового проекта, начинают строить таблицы, сравнивая фичи. Серьезно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.
Если вы выбираете инструменты для «домашнего» проекта — это вполне ок: подобрать приятный тулинг в этом случае настолько же важно, как и запустить проект.
А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта _сейчас_. Подумайте лучше о том, каким будет ваш фреймворк _тогда_. Удержит ли он комьюнити? Успеет ли за быстроизменяющейся средой? Будет ли адекватное предложение на рынке труда?
Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends.
И да, если вы выбираете фреймворк для фронтенда, то берите любой — все равно он протухнет через год.
Юнит-тесты и фронтенд
Самое сложное место для автоматизированного тестирования — интерфейсы. Сложность тестирования проистекает от их асинхронной природы — ты никогда не поймешь, почему в тесте не нажимается кнопка: потому что она еще не загрузилась из-за задержки в браузере, или потому, что ее действительно сломали в последнем коммите.
С юнит-тестами тоже все плохо — фронтовый код сложно разбивать на вменяемые куски, которые приятно тестировать. Спасает только TDD и хорошие библиотеки типа vue.js, которые сводят количество процедурного кода к минимуму.
Сложность тестирования обостряет извечную проблему для проектов с плохим покрытием — регрессии.
Мой любимый способ борьбы с плохим покрытием на фронте — писать поменьше кода. Серьезно — максимум логики из фронтенда нужно уносить на бекенд: там живут достаточно взрослые и удобные технологии, на которых тесты писать легко и приятно.
Мы в mtrl.ai прямо запрещаем писать бизнес-логику на фронте. Если код в интерфейсе ходит в один эндпоинт, а в зависимости от результатов ходит в другой эндпоинт — это уже не очень хороший код. Если эндпоинта три — мы этот код не пропускаем.
Самое сложное место для автоматизированного тестирования — интерфейсы. Сложность тестирования проистекает от их асинхронной природы — ты никогда не поймешь, почему в тесте не нажимается кнопка: потому что она еще не загрузилась из-за задержки в браузере, или потому, что ее действительно сломали в последнем коммите.
С юнит-тестами тоже все плохо — фронтовый код сложно разбивать на вменяемые куски, которые приятно тестировать. Спасает только TDD и хорошие библиотеки типа vue.js, которые сводят количество процедурного кода к минимуму.
Сложность тестирования обостряет извечную проблему для проектов с плохим покрытием — регрессии.
Мой любимый способ борьбы с плохим покрытием на фронте — писать поменьше кода. Серьезно — максимум логики из фронтенда нужно уносить на бекенд: там живут достаточно взрослые и удобные технологии, на которых тесты писать легко и приятно.
Мы в mtrl.ai прямо запрещаем писать бизнес-логику на фронте. Если код в интерфейсе ходит в один эндпоинт, а в зависимости от результатов ходит в другой эндпоинт — это уже не очень хороший код. Если эндпоинта три — мы этот код не пропускаем.
Сделай это завтра
Тайм-менеджмент в технологической компании — сложная задача: работы всегда больше, чем можно успеть. На проблемы планирования часто накладывается наша эмоциональность — сложно отказать руководителю, который громко требует «пойти и работать». И почти невозможно отказать самому себе, когда хочется поделать фичу, которая только что пришла в голову, и «точно всем нужна».
Моя библиотека книг по тайм-менеджменту ограничена единственной Getting Things Done, поэтому я обрадовался, когда ребята из издательской студии Поле предложили написать рецензию на книгу Марка Форстера «Сделай это завтра», которая выходит у них в ноябре.
Книга приносит идеи, которые будут полезны не только менеджерам, но инженерам. К примеру, закрытые списки дел на день. Список закрыт, если под ним подведена черта, и в него нельзя ничего добавить. Все новые дела, которые появляются за день, нельзя вносить в сегодняшний список — только на завтра.
Моя любимая часть — про «видение». Марк Форстер рассказывает, как клево живется, когда у тебя есть четкая система, которая отделяет вещи, которые нужно делать от вещей, которые делать не нужно.
К примеру, лучше не брать задачу, которую ты считаешь недостаточно важной, или не уверен что сделаешь хорошо. Лучше честно отказать коллегам, чем обмануть ожидания и потратить время на половину результата, которая никому не пригодится.
Конечно, книга не заменяет ГТД с его пустыми инбоксами, но хорошо дополняет. По предзаказу стоит 600 рублей.
Тайм-менеджмент в технологической компании — сложная задача: работы всегда больше, чем можно успеть. На проблемы планирования часто накладывается наша эмоциональность — сложно отказать руководителю, который громко требует «пойти и работать». И почти невозможно отказать самому себе, когда хочется поделать фичу, которая только что пришла в голову, и «точно всем нужна».
Моя библиотека книг по тайм-менеджменту ограничена единственной Getting Things Done, поэтому я обрадовался, когда ребята из издательской студии Поле предложили написать рецензию на книгу Марка Форстера «Сделай это завтра», которая выходит у них в ноябре.
Книга приносит идеи, которые будут полезны не только менеджерам, но инженерам. К примеру, закрытые списки дел на день. Список закрыт, если под ним подведена черта, и в него нельзя ничего добавить. Все новые дела, которые появляются за день, нельзя вносить в сегодняшний список — только на завтра.
Моя любимая часть — про «видение». Марк Форстер рассказывает, как клево живется, когда у тебя есть четкая система, которая отделяет вещи, которые нужно делать от вещей, которые делать не нужно.
К примеру, лучше не брать задачу, которую ты считаешь недостаточно важной, или не уверен что сделаешь хорошо. Лучше честно отказать коллегам, чем обмануть ожидания и потратить время на половину результата, которая никому не пригодится.
Конечно, книга не заменяет ГТД с его пустыми инбоксами, но хорошо дополняет. По предзаказу стоит 600 рублей.
Не тороплюсь смотреть код в конце спринта
Несмотря на принятую у нас систему positive review, бывает так, что мы все равно показываем друг другу код по публикации, а не после.
Если просьба приходит в конце спринта, то я обычно сразу отказываюсь.
Во-первых, это невежливо: я точно так же пишу код, и так же могу что-нибудь проебывать и делать в последний момент.
Во-вторых, две головы лучше одной только тогда, когда близко нет дедлайна. Зачем мне влезать, если ответственность за сдачу лежит не на мне, а написать «все говно» не позволяют сроки?
В-третьих, в пулл-реквесте, который отложили на последний момент, вряд ли все хорошо и понятно: коллега скорее всего торопился, и принимать адекватные решения уже было тяжело. А я обычно отказываюсь смотреть непонятный код.
Так что если у вас осталась незавершенная работа на понедельник — уж выпихивайте как есть: завтра перепишете.
Несмотря на принятую у нас систему positive review, бывает так, что мы все равно показываем друг другу код по публикации, а не после.
Если просьба приходит в конце спринта, то я обычно сразу отказываюсь.
Во-первых, это невежливо: я точно так же пишу код, и так же могу что-нибудь проебывать и делать в последний момент.
Во-вторых, две головы лучше одной только тогда, когда близко нет дедлайна. Зачем мне влезать, если ответственность за сдачу лежит не на мне, а написать «все говно» не позволяют сроки?
В-третьих, в пулл-реквесте, который отложили на последний момент, вряд ли все хорошо и понятно: коллега скорее всего торопился, и принимать адекватные решения уже было тяжело. А я обычно отказываюсь смотреть непонятный код.
Так что если у вас осталась незавершенная работа на понедельник — уж выпихивайте как есть: завтра перепишете.
Два свободных дня
После пятничного поста сразу несколько ребят написали в личку, что если откладывать говнокод на следующие спринты, он повисает мёртвый грузом.
У нас это не так. Во-первых мы весьма адекватно управляем техдолгом (расскажу как-нибудь), во-вторых у нас есть система самолечения.
Самолечение происходит в свободное время — между спринтами каждый программист получает два свободных дня. Свобода — полная, делать можно что угодно. Два условия — это должно быть полезно для проекта, а по итогам нужно будет рассказать коллегам о том, что ты сделал.
Обычно в это время мы занимаемся рефакторингом — делаем вещи, которые позволят нам более приятно и быстро работать в следующем спринте. Иногда берем срочные бизнес-требования, или начинаем большие проекты.
Такое свободное время позволяет не только бороться с легаси, но и делает нас более реактивными, давая возможность поддерживать целую категорию фич, которые появляются на продакшене в течение пары дней после обсуждения, без ожидания следующего спринта.
#техдолг
После пятничного поста сразу несколько ребят написали в личку, что если откладывать говнокод на следующие спринты, он повисает мёртвый грузом.
У нас это не так. Во-первых мы весьма адекватно управляем техдолгом (расскажу как-нибудь), во-вторых у нас есть система самолечения.
Самолечение происходит в свободное время — между спринтами каждый программист получает два свободных дня. Свобода — полная, делать можно что угодно. Два условия — это должно быть полезно для проекта, а по итогам нужно будет рассказать коллегам о том, что ты сделал.
Обычно в это время мы занимаемся рефакторингом — делаем вещи, которые позволят нам более приятно и быстро работать в следующем спринте. Иногда берем срочные бизнес-требования, или начинаем большие проекты.
Такое свободное время позволяет не только бороться с легаси, но и делает нас более реактивными, давая возможность поддерживать целую категорию фич, которые появляются на продакшене в течение пары дней после обсуждения, без ожидания следующего спринта.
#техдолг
Быстрая коммуникация
Важный этап при внедрении новых коллег в нашу команду — отучить их от привычки к быстрой коммуникации.
В безумном мире люди привыкли звонить друг-другу или писать в чат «привет». У нас не так: мы все в разных часовых зонах, а в чатик кидаем только мемасики.
Помимо того, что асинхронная коммуникация позволяет нормально взаимодействовать в разных часовых поясах (у нас всего двое ребят в GMT+3), это еще и приводит голову в порядок: заставляет не задавать глупых вопросов и лучше планировать время.
Как я это объясняю новым ребятам? Просто игнорирую телеграм, а на почту отвечаю тогда, когда это удобно мне, а не им.
Важный этап при внедрении новых коллег в нашу команду — отучить их от привычки к быстрой коммуникации.
В безумном мире люди привыкли звонить друг-другу или писать в чат «привет». У нас не так: мы все в разных часовых зонах, а в чатик кидаем только мемасики.
Помимо того, что асинхронная коммуникация позволяет нормально взаимодействовать в разных часовых поясах (у нас всего двое ребят в GMT+3), это еще и приводит голову в порядок: заставляет не задавать глупых вопросов и лучше планировать время.
Как я это объясняю новым ребятам? Просто игнорирую телеграм, а на почту отвечаю тогда, когда это удобно мне, а не им.
Кому проект для портфолио?
Ребята, я знаю, что среди вас есть много питонистов. У меня к вам предложение, которое прокачает ваше порфтолио.
У меня есть опенсорсный проект — @selfmailbot. Это бот для ГТД-гиков, который шлет заметки из телеграма в почту. Подробное описание — тут, исходники — на гитхабе, там python-telegram-bot и pytest.
Я собрал бота за несколько вечеров в качестве развлечения, но он оказался полезным — в день через него уходит до 100 сообщений. Думаю, что бота стоит еще немножечко развить, к примеру научить его дешифровать голосовые заметки и высылать текст на почту.
К сожалению, я не найду на это времени, поэтому ищу питониста, который любит телеграм и опенсорс. В замен на контрибьюты вы получите жесткий код-ревью (по желанию) и проект со звездочками в профиле.
Если вам интересно — напишите на fedor@borshev.com, начните с примеров своих работ.
Ребята, я знаю, что среди вас есть много питонистов. У меня к вам предложение, которое прокачает ваше порфтолио.
У меня есть опенсорсный проект — @selfmailbot. Это бот для ГТД-гиков, который шлет заметки из телеграма в почту. Подробное описание — тут, исходники — на гитхабе, там python-telegram-bot и pytest.
Я собрал бота за несколько вечеров в качестве развлечения, но он оказался полезным — в день через него уходит до 100 сообщений. Думаю, что бота стоит еще немножечко развить, к примеру научить его дешифровать голосовые заметки и высылать текст на почту.
К сожалению, я не найду на это времени, поэтому ищу питониста, который любит телеграм и опенсорс. В замен на контрибьюты вы получите жесткий код-ревью (по желанию) и проект со звездочками в профиле.
Если вам интересно — напишите на fedor@borshev.com, начните с примеров своих работ.
Вопрос: есть проект средних размеров с плохой кодовой базой. Как понять — рефакторить текущий или переписывать заново?
Начну с того, что пропадать на долгий срок — плохо: лучше потихоньку, но стабильно исправлять проблемы.
Ну ок, рассмотрим крайний случай, когда весь бизнес ушел на каникулы, а вы остались один на один с кодовой базой. Раз вы выбираете чинить или выбрасывать, значит технологии у вас еще не совсем протухли — если бы у вас была ERP-система на CGI и prototype.js, наверное вы вообще ничего бы не спрашивали.
А раз технологии современны, то вопрос сводится к оценке времени. Начните с того, что определите свою скорость — потратьте день на рефакторинг.
Сколько с такой скоростью потребуется времени на весь проект, чтобы успеть с запасом? Умножьте ответ на два, и решите, что получится быстрее — закончить начатую работу или начать с нуля. Оценку для проекта с нуля тоже не забудьте умножить.
Другие ответы — #вопрос. Задать свой — @fedor_borshev.
Начну с того, что пропадать на долгий срок — плохо: лучше потихоньку, но стабильно исправлять проблемы.
Ну ок, рассмотрим крайний случай, когда весь бизнес ушел на каникулы, а вы остались один на один с кодовой базой. Раз вы выбираете чинить или выбрасывать, значит технологии у вас еще не совсем протухли — если бы у вас была ERP-система на CGI и prototype.js, наверное вы вообще ничего бы не спрашивали.
А раз технологии современны, то вопрос сводится к оценке времени. Начните с того, что определите свою скорость — потратьте день на рефакторинг.
Сколько с такой скоростью потребуется времени на весь проект, чтобы успеть с запасом? Умножьте ответ на два, и решите, что получится быстрее — закончить начатую работу или начать с нуля. Оценку для проекта с нуля тоже не забудьте умножить.
Другие ответы — #вопрос. Задать свой — @fedor_borshev.
Правила пулл-реквестов
Я очень не люблю бюрократию в разработке — это медленно, угнетает и размывает ответственность. В любых правилах внутри команды я всегда стараюсь ограничиться здравым смыслом.
Сегодня я выкладываю наши правила составления пулл-реквестов — в противовес гигантским талмудам, их всего 5:
— Специализированный: решает одну задачу
— Краткость: больше 500 строк — плохо
— Унитарные коммиты — показывают последовательное решение задачи
— Привязан к задаче в трекере
— Называется понятно.
Во вложении ПДФ с примерами, можно внедрять у себя, если еще нет.
Я очень не люблю бюрократию в разработке — это медленно, угнетает и размывает ответственность. В любых правилах внутри команды я всегда стараюсь ограничиться здравым смыслом.
Сегодня я выкладываю наши правила составления пулл-реквестов — в противовес гигантским талмудам, их всего 5:
— Специализированный: решает одну задачу
— Краткость: больше 500 строк — плохо
— Унитарные коммиты — показывают последовательное решение задачи
— Привязан к задаче в трекере
— Называется понятно.
Во вложении ПДФ с примерами, можно внедрять у себя, если еще нет.
Github и MS
Недавно уже десятый человек рассказал мне, как его парит, что злой MS купил добрый #гитхаб.
Не понимаю, как такая движуха может не радовать. Лучшее, что может случиться с продуктом — хорошие люди: `Head of Product` и `Head of Marketing`. Они и в рынок правильный попадут, и фичи новые запилят такие, которые будут не просто развивать существующие привычки, а сделают что-то новое.
Превратить контроль версий в социальную сеть, сделать платформу для совместной работы программистов и роботов, обернуть набор unix-way скриптов понятным для гуманитария интерфейсом — это все задачи для людей с вѝдением. Это вам не мердж-реквесты пилить, вместе неработающим CI.
А видение (как и умение нанимать\мотивировать крутых людей) у MS есть, посмотрите:
Недавно уже десятый человек рассказал мне, как его парит, что злой MS купил добрый #гитхаб.
Не понимаю, как такая движуха может не радовать. Лучшее, что может случиться с продуктом — хорошие люди: `Head of Product` и `Head of Marketing`. Они и в рынок правильный попадут, и фичи новые запилят такие, которые будут не просто развивать существующие привычки, а сделают что-то новое.
Превратить контроль версий в социальную сеть, сделать платформу для совместной работы программистов и роботов, обернуть набор unix-way скриптов понятным для гуманитария интерфейсом — это все задачи для людей с вѝдением. Это вам не мердж-реквесты пилить, вместе неработающим CI.
А видение (как и умение нанимать\мотивировать крутых людей) у MS есть, посмотрите:
Важное и срочное
Недавно в любимом Blinkist наткнулся на саммари «7 навыков» Стивена Кови вспомнил, что с помощью именно этой книги в первый раз осознал разницу между срочным и важным.
Есть много срочных и неважных дел — телефонный звонок, встреча, новое письмо от коллеги. Есть даже срочные но неважные клиенты, которые топают ногами, требуют немедленной реакции, но не приносят денег.
Есть много важных и несрочных дел — написать пост в блог, привести в порядок резюме, проверить статусы задач в месячном плане.
Важных и срочных задач обычно мало — к примеру горит здание или заболел ребенок.
Неважные и несрочные дела не стоят упоминания.
Фокус в том, что делать нужно только важные дела (ну и от пожара убегать конечно). Срочные, но неважные дела никому не нужны: никто не умрет, если вы проигнорируете телефонный звонок, не придете на пустую встречу или не ответите на новое письмо в ту же секунду.
Недавно в любимом Blinkist наткнулся на саммари «7 навыков» Стивена Кови вспомнил, что с помощью именно этой книги в первый раз осознал разницу между срочным и важным.
Есть много срочных и неважных дел — телефонный звонок, встреча, новое письмо от коллеги. Есть даже срочные но неважные клиенты, которые топают ногами, требуют немедленной реакции, но не приносят денег.
Есть много важных и несрочных дел — написать пост в блог, привести в порядок резюме, проверить статусы задач в месячном плане.
Важных и срочных задач обычно мало — к примеру горит здание или заболел ребенок.
Неважные и несрочные дела не стоят упоминания.
Фокус в том, что делать нужно только важные дела (ну и от пожара убегать конечно). Срочные, но неважные дела никому не нужны: никто не умрет, если вы проигнорируете телефонный звонок, не придете на пустую встречу или не ответите на новое письмо в ту же секунду.
Ритуал начала спринта
Для опытных ребят у нас в команде есть всего одна обязательная точка контакта — начало.
Если программист не понимает, для чего он делает конкретную задачу или, еще хуже, вынужден постоянно переспрашивать детали, то удаленная работа больше мешает, чем помогает. Командам, которые испытывают проблемы с постановкой задач, просто необходим офис.
Что мы обсуждаем обязательных встречах:
— Чтобы что. Я рассказываю, зачем задача нужна бизнесу.
— Как. Исполнитель рассказывает о том, что он понял и как будет это делать.
— Для сложных задач — определить чекпоинты и definition of done.
Форматы передачи результата, пожелания к коду, тексты транзакционных писем — все не так важно по сравнению с частями «чтобы что» и «как».
#чтобычто
Для опытных ребят у нас в команде есть всего одна обязательная точка контакта — начало.
Если программист не понимает, для чего он делает конкретную задачу или, еще хуже, вынужден постоянно переспрашивать детали, то удаленная работа больше мешает, чем помогает. Командам, которые испытывают проблемы с постановкой задач, просто необходим офис.
Что мы обсуждаем обязательных встречах:
— Чтобы что. Я рассказываю, зачем задача нужна бизнесу.
— Как. Исполнитель рассказывает о том, что он понял и как будет это делать.
— Для сложных задач — определить чекпоинты и definition of done.
Форматы передачи результата, пожелания к коду, тексты транзакционных писем — все не так важно по сравнению с частями «чтобы что» и «как».
#чтобычто
Вопрос: расскажи, как удается сохранять концентрацию целый день, работая дома?
Наверное вы хотите услышать не про банальности вроде техники помодоро, поэтому расскажу про способы улучшения концентрации, которые кажутся специфичными именно для моего стиля работы.
Я редко работаю из дома прям целый день — стараюсь менять рабочее место хотя бы один раз за сутки. В качестве альтернативы дому у меня есть несколько любимых кофеен, библиотека и, внезапно, метро — там можно писать тексты на телефоне.
Важный момент для концентрации дома — рабочая зона. Кроме того, что рабочая зона должна быть удобной (я предпочитаю работать стоя), она должна быть только рабочей — всем вокруг должно быть понятно, что вы работаете, а не присели сериальчик посмотреть.
Ну и конечно же — это обязательное личное время. Критично важно выбирать время, в которое вы НЕ работаете. Желательно, чтобы таких периодов было несколько в течение дня. Этот принцип называется «плати себе первому» — дело в том, что при удаленной работе легко упороться и провести за компьютером целый день. Насколько вы будете полезны после дня непрерывной работы? А после недели? А через месяц?
#вопрос
Наверное вы хотите услышать не про банальности вроде техники помодоро, поэтому расскажу про способы улучшения концентрации, которые кажутся специфичными именно для моего стиля работы.
Я редко работаю из дома прям целый день — стараюсь менять рабочее место хотя бы один раз за сутки. В качестве альтернативы дому у меня есть несколько любимых кофеен, библиотека и, внезапно, метро — там можно писать тексты на телефоне.
Важный момент для концентрации дома — рабочая зона. Кроме того, что рабочая зона должна быть удобной (я предпочитаю работать стоя), она должна быть только рабочей — всем вокруг должно быть понятно, что вы работаете, а не присели сериальчик посмотреть.
Ну и конечно же — это обязательное личное время. Критично важно выбирать время, в которое вы НЕ работаете. Желательно, чтобы таких периодов было несколько в течение дня. Этот принцип называется «плати себе первому» — дело в том, что при удаленной работе легко упороться и провести за компьютером целый день. Насколько вы будете полезны после дня непрерывной работы? А после недели? А через месяц?
#вопрос
Как спрашивать «зачем»?
Как вы помните из заметки про фичреквесты, которые не стоит выполнять, вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.
Однако задавать постоянно этот вопрос не так уж и просто: если в лоб спрашивать у каждого постановщика, зачем ему эта задача, он может и обидеться — к вам же пришли, оторвались от важных дел, подумали головой, а вы тут сидите с умным видом и объясняете, что делать ничего не нужно.
Вот пара трюков, чтобы процесс задавания вопросов пошел легче:
• Объясните, чем вы можете помочь, имея это знание. К примеру, только вы знаете все уголки системы настолько, чтобы не пилить новую фичу, а предложить уже существующую похожую.
• Поговорите про цифры: «Подскажи, какие показатели мы прогнозируем в результате?». Когда вы говорите про цифры и гипотезы, то вы находитесь максимально далеко от личности постановщика задачи, а значит ему будет спокойнее отвечать на ваши вопросы.
• Расскажите, что понимая конечный результат, вы забираете на себя больше ответственности — если в конце спринта будет говно, то виноваты будете вы сами, а не тот, кто плохо поставил вам задачу. Для постановщика это выглядит как делегирование, а делегирование любят все менеджеры.
#чтобычто
Как вы помните из заметки про фичреквесты, которые не стоит выполнять, вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.
Однако задавать постоянно этот вопрос не так уж и просто: если в лоб спрашивать у каждого постановщика, зачем ему эта задача, он может и обидеться — к вам же пришли, оторвались от важных дел, подумали головой, а вы тут сидите с умным видом и объясняете, что делать ничего не нужно.
Вот пара трюков, чтобы процесс задавания вопросов пошел легче:
• Объясните, чем вы можете помочь, имея это знание. К примеру, только вы знаете все уголки системы настолько, чтобы не пилить новую фичу, а предложить уже существующую похожую.
• Поговорите про цифры: «Подскажи, какие показатели мы прогнозируем в результате?». Когда вы говорите про цифры и гипотезы, то вы находитесь максимально далеко от личности постановщика задачи, а значит ему будет спокойнее отвечать на ваши вопросы.
• Расскажите, что понимая конечный результат, вы забираете на себя больше ответственности — если в конце спринта будет говно, то виноваты будете вы сами, а не тот, кто плохо поставил вам задачу. Для постановщика это выглядит как делегирование, а делегирование любят все менеджеры.
#чтобычто
Гитхаб позавчера выкатил пост мортем об инциденте прошлой недели.
Вкратце — из-за короткого (43 секунды) раъединения связи между датацентрами в разных концах США, механизм выбора мастера сломался, и сделал так, что приложения стали жить в одном ДЦ, а данные — в другом.
Из-за пинга в 60ms между серверами и БД собственно и начались проблемы, которые они восстанавливали больше суток.
Интересное:
— Количество данных они измеряют во времени, которое ушло на их генерацию (a few seconds of data, 30 minutes of data).
— Можно было потерять 30 минут данных, но не вырубать систему на сутки. Понимая сроки в самом начале, они все равно решили вырубаться. Сильное решение.
— Полный бекап БД гитхаба занимает несколько терабайт, снимается раз в 4 часа и восстанавливается для проверки раз в день.
— Они очень быстро реагируют — через 11 минут после начала проблем гитхаб перевел индикатор работоспособности в желтый режим, а еще через 2 минуты пришел некий Incident Coordinator (интересно, сколько человек у них on-call?) и перевел индикатор в красный.
#гитхаб
Вкратце — из-за короткого (43 секунды) раъединения связи между датацентрами в разных концах США, механизм выбора мастера сломался, и сделал так, что приложения стали жить в одном ДЦ, а данные — в другом.
Из-за пинга в 60ms между серверами и БД собственно и начались проблемы, которые они восстанавливали больше суток.
Интересное:
— Количество данных они измеряют во времени, которое ушло на их генерацию (a few seconds of data, 30 minutes of data).
— Можно было потерять 30 минут данных, но не вырубать систему на сутки. Понимая сроки в самом начале, они все равно решили вырубаться. Сильное решение.
— Полный бекап БД гитхаба занимает несколько терабайт, снимается раз в 4 часа и восстанавливается для проверки раз в день.
— Они очень быстро реагируют — через 11 минут после начала проблем гитхаб перевел индикатор работоспособности в желтый режим, а еще через 2 минуты пришел некий Incident Coordinator (интересно, сколько человек у них on-call?) и перевел индикатор в красный.
#гитхаб
The GitHub Blog
October 21 post-incident analysis
In-depth analysis of the incident that impacted GitHub services on October 21 and 22.
Производство и потребление
Есть два режима жизнедеятельности — производство и потребление.
Производство — это когда после вас остаются артефакты: код, письма, идеи, макеты. Потребление — все остальное. Написать программу — производство, посмотреть фейсбук — потребление.
В увеличении потребления заинтересованы те, кто вас окружает: ютубчик, макдональдс, друзья, которым нужна компания для похода в бар, да и вся мировая экономика в целом.
В увеличении производства в первую очередь заинтересованы вы сами. Чем больше вы делаете (или другие, с вашей помощью) — тем быстрее достигаете целей.
Человечество изобрело кучу инструментов для потребления —телефоны, торговые центры, push-уведомления, шаурма у метро.
Инструментов для производства, вроде скетча, макбука и молескина — наоборот, мало. На самом деле, можно производить больше, чем 95% людей, имея только сильное желание и блокнот, но это тема для отдельного разговора.
Разделяйте потребление и производство. Не получится продуктивно работать, если отвлекаться на фейсбучный тупняк. Не получится насладиться ужином, пытаясь написать код.
Есть два режима жизнедеятельности — производство и потребление.
Производство — это когда после вас остаются артефакты: код, письма, идеи, макеты. Потребление — все остальное. Написать программу — производство, посмотреть фейсбук — потребление.
В увеличении потребления заинтересованы те, кто вас окружает: ютубчик, макдональдс, друзья, которым нужна компания для похода в бар, да и вся мировая экономика в целом.
В увеличении производства в первую очередь заинтересованы вы сами. Чем больше вы делаете (или другие, с вашей помощью) — тем быстрее достигаете целей.
Человечество изобрело кучу инструментов для потребления —телефоны, торговые центры, push-уведомления, шаурма у метро.
Инструментов для производства, вроде скетча, макбука и молескина — наоборот, мало. На самом деле, можно производить больше, чем 95% людей, имея только сильное желание и блокнот, но это тема для отдельного разговора.
Разделяйте потребление и производство. Не получится продуктивно работать, если отвлекаться на фейсбучный тупняк. Не получится насладиться ужином, пытаясь написать код.
Три текстовых редактора
Кроме писем и телеграма, я еще пишу код. В этой заметке кратко расскажу про историю текстовых редакторов, которые я сменил.
Vim
Vim — клевый: быстро работает, позволяет редактировать текст со скоростью мысли. Но попытки приблизить его к IDE съедают столько времени, что нормально пригоден он только для написания текста. Попробуйте к примеру пописать что-нибудь на vue.js или настроить нормальный автокомплит для питона.
Sublime
Быстрый как vim, с теми же хоткеями (vintageous/six), куча фич через плагины. Почти год на нем сидел, но уперся в нестабильность плагинов: то хоткеи отвалятся, то подсветка postcss во vue. Починить что-то самому — нереально, в исходниках большинства плагинов — лапша.
Vscode
Гигантское коммьюнити, баги чинят быстро. Если выпилить отвлекающие вещи вроде сайдбара или интеграции с гитом, то вполне можно писать код.
Уже почти год на нем, правда теперь всегда таскаю зарядку от ноубтука в рюкзаке.
Кроме писем и телеграма, я еще пишу код. В этой заметке кратко расскажу про историю текстовых редакторов, которые я сменил.
Vim
Vim — клевый: быстро работает, позволяет редактировать текст со скоростью мысли. Но попытки приблизить его к IDE съедают столько времени, что нормально пригоден он только для написания текста. Попробуйте к примеру пописать что-нибудь на vue.js или настроить нормальный автокомплит для питона.
Sublime
Быстрый как vim, с теми же хоткеями (vintageous/six), куча фич через плагины. Почти год на нем сидел, но уперся в нестабильность плагинов: то хоткеи отвалятся, то подсветка postcss во vue. Починить что-то самому — нереально, в исходниках большинства плагинов — лапша.
Vscode
Гигантское коммьюнити, баги чинят быстро. Если выпилить отвлекающие вещи вроде сайдбара или интеграции с гитом, то вполне можно писать код.
Уже почти год на нем, правда теперь всегда таскаю зарядку от ноубтука в рюкзаке.
Вопрос: расскажи, как ты пишешь регламенты
Я регламенты не пишу :-) Мне всегда везло с коллегами — почему-то попадались осознанные люди, которым регламенты не требуются.
Осознанным людям может помочь понятное описание новых для них частей контекста — рассказ о том, что делают коллеги, погружение в новый проект, и т.д. В таких случаях я обычно записываю ролик в Луме — получается лучше, чем текст.
Еще осознанным людям пригодится набор советов, что делать в той или иной ситуации, к примеру как оформить пулл-реквест так, чтобы его хотелось быстрее посмотреть.
А регламенты им скорее всего помешают — придется тратить время, чтобы соответствовать непонятной букве непонятного документа, а не духу здравого смысла.
#вопрос
Я регламенты не пишу :-) Мне всегда везло с коллегами — почему-то попадались осознанные люди, которым регламенты не требуются.
Осознанным людям может помочь понятное описание новых для них частей контекста — рассказ о том, что делают коллеги, погружение в новый проект, и т.д. В таких случаях я обычно записываю ролик в Луме — получается лучше, чем текст.
Еще осознанным людям пригодится набор советов, что делать в той или иной ситуации, к примеру как оформить пулл-реквест так, чтобы его хотелось быстрее посмотреть.
А регламенты им скорее всего помешают — придется тратить время, чтобы соответствовать непонятной букве непонятного документа, а не духу здравого смысла.
#вопрос