Ритуал начала спринта
Для опытных ребят у нас в команде есть всего одна обязательная точка контакта — начало.
Если программист не понимает, для чего он делает конкретную задачу или, еще хуже, вынужден постоянно переспрашивать детали, то удаленная работа больше мешает, чем помогает. Командам, которые испытывают проблемы с постановкой задач, просто необходим офис.
Что мы обсуждаем обязательных встречах:
— Чтобы что. Я рассказываю, зачем задача нужна бизнесу.
— Как. Исполнитель рассказывает о том, что он понял и как будет это делать.
— Для сложных задач — определить чекпоинты и 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
Гигантское коммьюнити, баги чинят быстро. Если выпилить отвлекающие вещи вроде сайдбара или интеграции с гитом, то вполне можно писать код.
Уже почти год на нем, правда теперь всегда таскаю зарядку от ноубтука в рюкзаке.
Вопрос: расскажи, как ты пишешь регламенты
Я регламенты не пишу :-) Мне всегда везло с коллегами — почему-то попадались осознанные люди, которым регламенты не требуются.
Осознанным людям может помочь понятное описание новых для них частей контекста — рассказ о том, что делают коллеги, погружение в новый проект, и т.д. В таких случаях я обычно записываю ролик в Луме — получается лучше, чем текст.
Еще осознанным людям пригодится набор советов, что делать в той или иной ситуации, к примеру как оформить пулл-реквест так, чтобы его хотелось быстрее посмотреть.
А регламенты им скорее всего помешают — придется тратить время, чтобы соответствовать непонятной букве непонятного документа, а не духу здравого смысла.
#вопрос
Я регламенты не пишу :-) Мне всегда везло с коллегами — почему-то попадались осознанные люди, которым регламенты не требуются.
Осознанным людям может помочь понятное описание новых для них частей контекста — рассказ о том, что делают коллеги, погружение в новый проект, и т.д. В таких случаях я обычно записываю ролик в Луме — получается лучше, чем текст.
Еще осознанным людям пригодится набор советов, что делать в той или иной ситуации, к примеру как оформить пулл-реквест так, чтобы его хотелось быстрее посмотреть.
А регламенты им скорее всего помешают — придется тратить время, чтобы соответствовать непонятной букве непонятного документа, а не духу здравого смысла.
#вопрос
Смело тратить время на настройку окружения
Я никогда не стесняюсь тратить время на настройку окружения. Если у меня отвалился плагин для вскода, я могу спокойно потратить пару часов, чтобы разобраться во внутреннем устройстве и все пофиксить. На всех своих проектах я полностью автоматизирую процессы теста и деплоя. Если можно было бы автоматизировать постановку задач, я бы и это автоматизировал.
Профессионал отличается от новичка именно набором инструментов. У профессионального стоматолога никогда не сломается кресло, когда на нем находится клиент с открытым ртом. Как только профессионал заметит намек на проблему — он вызовет мастеров и не будет сильно страдать от того, что примет на пару клиентов меньше, пока кресло будут чинить.
С программированием тоже самое — чтобы писать код, нужно быть предельно сконцентрированным. Я не могу концентрироваться, когда у меня не работает подсветка в IDE. Или когда вместо размышлений о коде я занят тупым перекидыванием файлов на прод, которое все не доходят руки автоматизировать.
А когда я не сконцентрирован — я трачу время впустую, а значит попросту ворую его у себя и у заказчика.
Я никогда не стесняюсь тратить время на настройку окружения. Если у меня отвалился плагин для вскода, я могу спокойно потратить пару часов, чтобы разобраться во внутреннем устройстве и все пофиксить. На всех своих проектах я полностью автоматизирую процессы теста и деплоя. Если можно было бы автоматизировать постановку задач, я бы и это автоматизировал.
Профессионал отличается от новичка именно набором инструментов. У профессионального стоматолога никогда не сломается кресло, когда на нем находится клиент с открытым ртом. Как только профессионал заметит намек на проблему — он вызовет мастеров и не будет сильно страдать от того, что примет на пару клиентов меньше, пока кресло будут чинить.
С программированием тоже самое — чтобы писать код, нужно быть предельно сконцентрированным. Я не могу концентрироваться, когда у меня не работает подсветка в IDE. Или когда вместо размышлений о коде я занят тупым перекидыванием файлов на прод, которое все не доходят руки автоматизировать.
А когда я не сконцентрирован — я трачу время впустую, а значит попросту ворую его у себя и у заказчика.
Сервисы: gemury
Все ребята размером меньше Яндекса давно стремятся как можно меньше инфраструктуры держать у себя, и как можно больше отдавать профессионалам.
Во внешней инфраструктуре можно даже держать такую личную вещь, как репозитории приватных пакетов. Именно этим занимается gemfury — дает удобные приватные хранилища пакетов для всего, что только можно придумать — поддерживаются реестры NPM, индексы питона, репозитории Ruby и PHP. Есть даже совсем странные репозитории, вроде пакетов Дебиана или Bower (помните такой?).
Доступ к реестрам организуется через нативные средства языка — просто для ваших пакетов создается приватный и очень длинный адрес, который вы потом добавляете в свой package.json или requirements.txt.
За совсем небольшие деньги доступны командные аккаунты с разграничением доступа.
Все ребята размером меньше Яндекса давно стремятся как можно меньше инфраструктуры держать у себя, и как можно больше отдавать профессионалам.
Во внешней инфраструктуре можно даже держать такую личную вещь, как репозитории приватных пакетов. Именно этим занимается gemfury — дает удобные приватные хранилища пакетов для всего, что только можно придумать — поддерживаются реестры NPM, индексы питона, репозитории Ruby и PHP. Есть даже совсем странные репозитории, вроде пакетов Дебиана или Bower (помните такой?).
Доступ к реестрам организуется через нативные средства языка — просто для ваших пакетов создается приватный и очень длинный адрес, который вы потом добавляете в свой package.json или requirements.txt.
За совсем небольшие деньги доступны командные аккаунты с разграничением доступа.
Не мешать планам работать
Единственная причина, по которой можно поставить новую задачу посередине спринта — серьезный баг на продакшене, который обходится в понятные деньги.
Если начался спринт, то его скоуп высечен в камне. Это такой договор: я ожидаю результата в срок, а в замен не имею права влезть со своими «срочными» задачами.
Возможность управлять свои временем — одновременно и большая ценность, и большая ответственность. Если люди, которые этого не ценят — для них удаленная работа в маленьких командах противопоказана.
А если люди в вашей команде достаточно взрослы, чтобы самостоятельно планировать свое время, то такой подход экономит время управленца (сразу после запуска можно планировать следующий спринт и больше ни на что не отвлекаться), и улучшает стабильность и эффективность всего производства в целом.
Единственная причина, по которой можно поставить новую задачу посередине спринта — серьезный баг на продакшене, который обходится в понятные деньги.
Если начался спринт, то его скоуп высечен в камне. Это такой договор: я ожидаю результата в срок, а в замен не имею права влезть со своими «срочными» задачами.
Возможность управлять свои временем — одновременно и большая ценность, и большая ответственность. Если люди, которые этого не ценят — для них удаленная работа в маленьких командах противопоказана.
А если люди в вашей команде достаточно взрослы, чтобы самостоятельно планировать свое время, то такой подход экономит время управленца (сразу после запуска можно планировать следующий спринт и больше ни на что не отвлекаться), и улучшает стабильность и эффективность всего производства в целом.
Шаблоны задач
У гитхаба очень клевые шаблоны задач. Люблю их потому, что они текстовые, поэтому никого ни к чему не обязывают. Если вы точно знаете, чего хотите — можно всегда выкинуть штатный шаблон, и написать что-то свое.
У нас всего два шаблона — «Задача» и «Баг». Шаблоны максимально простые, и самое главное, для чего они нужны — отвечать для всех на вопрос «чтобы что». Чего мы ожидаем добиться, сделав задачу? Программист знает, ради чего он пилит таск. Менеджер еще на этапе постановки формирует бизнес-ожидания от задачи.
«Чтобы что» — вообще самый важный вопрос для любой задачи. Если ответ на вопрос не очевиден в момент постановки — это говно, а не задача. Для бага вопрос «чтобы что» тоже актуален — если у вас на сайте на пятом уровне вложенности каталога отваливаются фильтры, то кому станет лучше, если он заработает?
#чтобычто #гитхаб
У гитхаба очень клевые шаблоны задач. Люблю их потому, что они текстовые, поэтому никого ни к чему не обязывают. Если вы точно знаете, чего хотите — можно всегда выкинуть штатный шаблон, и написать что-то свое.
У нас всего два шаблона — «Задача» и «Баг». Шаблоны максимально простые, и самое главное, для чего они нужны — отвечать для всех на вопрос «чтобы что». Чего мы ожидаем добиться, сделав задачу? Программист знает, ради чего он пилит таск. Менеджер еще на этапе постановки формирует бизнес-ожидания от задачи.
«Чтобы что» — вообще самый важный вопрос для любой задачи. Если ответ на вопрос не очевиден в момент постановки — это говно, а не задача. Для бага вопрос «чтобы что» тоже актуален — если у вас на сайте на пятом уровне вложенности каталога отваливаются фильтры, то кому станет лучше, если он заработает?
#чтобычто #гитхаб
Вопрос: мне дают много кода на ревью. Прям так много, что иногда не остается времени на свои задачи. Как соблюдать баланс между своими задачами и чужими?
Можно попробовать мою методику разделения времени. Я делю свое рабочее время на две части — личное и условно-свободное. Личное время я трачу на то, что важно для меня — мои задачи, аналитика, стратегические исследования. На личное время уходят самые продуктивные часы (у меня это утро).
Условно-свободное время я занимаю тем, что важно сейчас — это может быть и ревью кода, и ответы на письма, и помощь кому-то с решением задачи.
Личное время — это святое: оно закрыто в календаре, в это время я не пользуюсь почтой, не захожу в телеграм и даже стараюсь избежать гитхаба, чтобы случайно не увидеть, как кто-нибудь от меня чего-нибудь ждет.
#вопрос
Можно попробовать мою методику разделения времени. Я делю свое рабочее время на две части — личное и условно-свободное. Личное время я трачу на то, что важно для меня — мои задачи, аналитика, стратегические исследования. На личное время уходят самые продуктивные часы (у меня это утро).
Условно-свободное время я занимаю тем, что важно сейчас — это может быть и ревью кода, и ответы на письма, и помощь кому-то с решением задачи.
Личное время — это святое: оно закрыто в календаре, в это время я не пользуюсь почтой, не захожу в телеграм и даже стараюсь избежать гитхаба, чтобы случайно не увидеть, как кто-нибудь от меня чего-нибудь ждет.
#вопрос
Форс-пуши в гитхабе
#гитхаб продолжает радовать полезными фичами — теперь даже при перезаписи истории через force push, он все равно сохраняет промежуточные результаты.
Force push — это такой способ поддерживать красивую историю изменений, когда программист локально переписывает историю коммитов задним числом, а потом отправляет изменения на сервер. Обычно это делают в рамках пулл-реквестов, чтобы легче было понять, что именно задумал автор.
В последнее время в бету прилетело еще много нового — показ похожих тасков при создании новых, возможность удалять их и переносить между проектами.
#гитхаб продолжает радовать полезными фичами — теперь даже при перезаписи истории через force push, он все равно сохраняет промежуточные результаты.
Force push — это такой способ поддерживать красивую историю изменений, когда программист локально переписывает историю коммитов задним числом, а потом отправляет изменения на сервер. Обычно это делают в рамках пулл-реквестов, чтобы легче было понять, что именно задумал автор.
В последнее время в бету прилетело еще много нового — показ похожих тасков при создании новых, возможность удалять их и переносить между проектами.
Параллельность в Circle CI
Это — начало рассказа о том, как у нас устроен Continuous Integration среднеразмерного (> 100K SLOC) приложения на Django. Сейчас мы гоняем в CI около 6000 тестов, а процесс от мерджа в мастер до появления на проде у нас занимает около 4-х минут.
Пока я не совсем понимаю, насколько вообще это вам интересно, поэтому продолжение буду писать только если этот пост наберет 200 лайков.
Начну с самого важного умения Circle CI — параллельности. Сейчас в самом большом нашем проекте около 6000 юнит-тестов, и весь прогон в один поток занимал бы около часа. Для таких ребят как мы серкл дает два инструмента — более быстрые контейнеры и разбиение тестов на несколько машин. Мы используем оба варианта.
Более быстрые контейнеры подразумевают разделение тестов на множество потоков средствами самого тестраннера — мы используем обычный pytest-xdist с двумя потоками на ядро. В данный момент для того, чтобы вам включили возможность самому управлять ресурсами, вам придется связываться с поддержкой (подробнее тут), которая вам предложит специальный вариант оплаты — не за количество контейнеров, как на официальном сайте, а за машинное время, которое вы тратите на сборку. Я советую соглашаться — на наших проектах, перейдя на поминутную оплату, мы стали экономить около 50% денег.
Второй метод, параллельность, доступен всем — при помощи фирменной утилиты, вы разбиваете тесты на несколько пакетов, каждый из которых работает в отдельном контейнере. Когда все контейнеры отрабатывают штатно — запускается следующая задача (к примеру деплой), уже в одном контейнере.
В итоге параллельность позволяет нам минимальными затратами добиться цифр из приложенной картинки.
Интересно продолжение? Лайкайте.
Это — начало рассказа о том, как у нас устроен Continuous Integration среднеразмерного (> 100K SLOC) приложения на Django. Сейчас мы гоняем в CI около 6000 тестов, а процесс от мерджа в мастер до появления на проде у нас занимает около 4-х минут.
Пока я не совсем понимаю, насколько вообще это вам интересно, поэтому продолжение буду писать только если этот пост наберет 200 лайков.
Начну с самого важного умения Circle CI — параллельности. Сейчас в самом большом нашем проекте около 6000 юнит-тестов, и весь прогон в один поток занимал бы около часа. Для таких ребят как мы серкл дает два инструмента — более быстрые контейнеры и разбиение тестов на несколько машин. Мы используем оба варианта.
Более быстрые контейнеры подразумевают разделение тестов на множество потоков средствами самого тестраннера — мы используем обычный pytest-xdist с двумя потоками на ядро. В данный момент для того, чтобы вам включили возможность самому управлять ресурсами, вам придется связываться с поддержкой (подробнее тут), которая вам предложит специальный вариант оплаты — не за количество контейнеров, как на официальном сайте, а за машинное время, которое вы тратите на сборку. Я советую соглашаться — на наших проектах, перейдя на поминутную оплату, мы стали экономить около 50% денег.
Второй метод, параллельность, доступен всем — при помощи фирменной утилиты, вы разбиваете тесты на несколько пакетов, каждый из которых работает в отдельном контейнере. Когда все контейнеры отрабатывают штатно — запускается следующая задача (к примеру деплой), уже в одном контейнере.
В итоге параллельность позволяет нам минимальными затратами добиться цифр из приложенной картинки.
Интересно продолжение? Лайкайте.
Плохое делегирование
Плохое делегирование — это когда ты отдаешь задачу, а потом проверяешь каждый шаг. Типа отдал задачу на неделю, а на следующий день уже пишешь «как дела? что уже сделал?».
Мало того, что на такое делегирование уходит столько же времени и внимания, как на саму работу, так это еще и бесит: не всем приятно, когда с ними обращаются как с ребенком.
Еще один плохой эффект — если людям не давать обосраться, то они привыкают к внешним стимулам. Через месяц работы на стимулах, любой, даже супер-осознанный сотрудник или сбегает, или переключается в режим ежика, который не взлетает, пока его не пнешь.
Плохое делегирование — это когда ты отдаешь задачу, а потом проверяешь каждый шаг. Типа отдал задачу на неделю, а на следующий день уже пишешь «как дела? что уже сделал?».
Мало того, что на такое делегирование уходит столько же времени и внимания, как на саму работу, так это еще и бесит: не всем приятно, когда с ними обращаются как с ребенком.
Еще один плохой эффект — если людям не давать обосраться, то они привыкают к внешним стимулам. Через месяц работы на стимулах, любой, даже супер-осознанный сотрудник или сбегает, или переключается в режим ежика, который не взлетает, пока его не пнешь.
Поговорили с Дмитрием Зыбкиным, ведущим канала @java_developer о том, чем занимается CTO в современном мире
Forwarded from Java Developer
Кто такой CTO
Задал несколько вопросов Фёдору Борщёву, CTO в ГдеМатериал и автору канала @pmdaily.
— Расскажи, как прошел свой путь от простого программиста до технического директора
Я работал в небольшом провинциальном веб-агенстве. Там достаточно быстро начал руководить всей командой разработки. Думаю, это не было моей заслугой — просто в компании было тяжело с людьми, которые одновременно умеют брать на себя ответственность и понимать, как работают технические штуки.
В какой-то момент я осознал, что у меня хорошо получается самостоятельно прокачиваться в хард-скиллах, но вот с софт-скиллами вообще ничего не происходит. Взвесил себя на рынке труда и понял, что со своим балансом знаний я не подхожу ни для чего кроме скучной работы низкопробного веб-программиста, и немного приуныл.
Тогда я и решил на какое-то время завязать с программированием, перебрался в Москву и пошел в студию Лебедева руководить дизайн-проектами. Студия — место с особой атмосферой и особенными людьми. Думаю, именно студия дала мне то, чего не хватало, чтобы стать CTO.
За время редких студийных выходных я выучил Django и сопутствующий стек (до этого писал на PHP). И под конец работы в студии начали сыпаться предложения об интересных технически-сложных проектах.
— Чем занимается CTO?
С точки зрения бизнеса, первая задача CTO — сделать работу с техническими специалистами такой же управляемой как, скажем, с менеджерами по продажам. Бизнес не должен задумываться о том, сколько у него программистов, на каких технологиях они работают, какое у них покрытие кода тестами и объем технического долга. Вместо этого он должен выдавать требования, получать в ответ цифры ФОТ (оплата труда) и результат к заявленному сроку.
Дальше начинается специфика — в маленьких компаниях CTO должен быть мастером на все руки. И в продукт влезть не хуже продакт-менеджера, и код пописать на уровне синьора, и бизнесу рассказать, какие требования лучше отдать в разработку, а какие сделать по старинке на Экселе и AmoCRM.
В больших компаниях, наоборот, CTO становится ближе к администрированию — выбирает правильных подрядчиков, задает им бизнесовые KPI, обращает много внимания на HR — как делить команды (по продуктам? по компетенциям? по фичам?), кого ставить во главу этих команд, как нанимать правильных людей и организовать передачу знаний.
Кроме бизнеса «сверху», есть еще программисты. Программисты обычно ждут от CTO хороших процессов — все хотят получать четко поставленные задачи с четкими критериями приемки, работать на актуальных технологиях, иметь возможность самим принимать решения и расплачиваться с техническом долгом, знать у кого из коллег о чем стоит спросить и т.д. В общем задача CTO для программистов — сделать, чтобы они были счастливыми, а значит — производительными.
— Насколько глубоко CTO должен разбираться в языках программирования? И какие технологии должен знать?
Для маленьких компаний, где CTO «работает руками», чем больше технологий — тем лучше :-) Лично я стараюсь фокусироваться на том, что важно для комфортной и быстрой работы команды, но при этом тяжело дается для изучения на «боевых» задачах — девопс, новые инструменты\механики тестирования, какие-то вещи про будущее.
Кроме самих технологий, CTO должен понимать, куда движется рынок в целом. Скажем года два назад хороший CTO для JS-проектов должен был изучать такие популярные сейчас вещи как Vue.js, typescript, jest, задумываться о serverless, знакомиться с netlify, предсказывать, что хайп вокруг NoSQL сойдет на нет и т.д.
А для больших компаний желание работать руками скорее будет минусом, чем плюсом.
Задал несколько вопросов Фёдору Борщёву, CTO в ГдеМатериал и автору канала @pmdaily.
— Расскажи, как прошел свой путь от простого программиста до технического директора
Я работал в небольшом провинциальном веб-агенстве. Там достаточно быстро начал руководить всей командой разработки. Думаю, это не было моей заслугой — просто в компании было тяжело с людьми, которые одновременно умеют брать на себя ответственность и понимать, как работают технические штуки.
В какой-то момент я осознал, что у меня хорошо получается самостоятельно прокачиваться в хард-скиллах, но вот с софт-скиллами вообще ничего не происходит. Взвесил себя на рынке труда и понял, что со своим балансом знаний я не подхожу ни для чего кроме скучной работы низкопробного веб-программиста, и немного приуныл.
Тогда я и решил на какое-то время завязать с программированием, перебрался в Москву и пошел в студию Лебедева руководить дизайн-проектами. Студия — место с особой атмосферой и особенными людьми. Думаю, именно студия дала мне то, чего не хватало, чтобы стать CTO.
За время редких студийных выходных я выучил Django и сопутствующий стек (до этого писал на PHP). И под конец работы в студии начали сыпаться предложения об интересных технически-сложных проектах.
— Чем занимается CTO?
С точки зрения бизнеса, первая задача CTO — сделать работу с техническими специалистами такой же управляемой как, скажем, с менеджерами по продажам. Бизнес не должен задумываться о том, сколько у него программистов, на каких технологиях они работают, какое у них покрытие кода тестами и объем технического долга. Вместо этого он должен выдавать требования, получать в ответ цифры ФОТ (оплата труда) и результат к заявленному сроку.
Дальше начинается специфика — в маленьких компаниях CTO должен быть мастером на все руки. И в продукт влезть не хуже продакт-менеджера, и код пописать на уровне синьора, и бизнесу рассказать, какие требования лучше отдать в разработку, а какие сделать по старинке на Экселе и AmoCRM.
В больших компаниях, наоборот, CTO становится ближе к администрированию — выбирает правильных подрядчиков, задает им бизнесовые KPI, обращает много внимания на HR — как делить команды (по продуктам? по компетенциям? по фичам?), кого ставить во главу этих команд, как нанимать правильных людей и организовать передачу знаний.
Кроме бизнеса «сверху», есть еще программисты. Программисты обычно ждут от CTO хороших процессов — все хотят получать четко поставленные задачи с четкими критериями приемки, работать на актуальных технологиях, иметь возможность самим принимать решения и расплачиваться с техническом долгом, знать у кого из коллег о чем стоит спросить и т.д. В общем задача CTO для программистов — сделать, чтобы они были счастливыми, а значит — производительными.
— Насколько глубоко CTO должен разбираться в языках программирования? И какие технологии должен знать?
Для маленьких компаний, где CTO «работает руками», чем больше технологий — тем лучше :-) Лично я стараюсь фокусироваться на том, что важно для комфортной и быстрой работы команды, но при этом тяжело дается для изучения на «боевых» задачах — девопс, новые инструменты\механики тестирования, какие-то вещи про будущее.
Кроме самих технологий, CTO должен понимать, куда движется рынок в целом. Скажем года два назад хороший CTO для JS-проектов должен был изучать такие популярные сейчас вещи как Vue.js, typescript, jest, задумываться о serverless, знакомиться с netlify, предсказывать, что хайп вокруг NoSQL сойдет на нет и т.д.
А для больших компаний желание работать руками скорее будет минусом, чем плюсом.
Forwarded from Java Developer
— Какая зарплатная вилка у CTO сейчас?
Зарплата — вопрос сугубо индивидуальный и переговорный. Если посмотреть на рынок труда, то CTO можно называть и единственного веб-программиста, который дорабатывает лендос у сервиса онлайн-курсов, а могут — руководителя производства, критичного для компании уровня ВК или Ламоды. Вот такая же и разница в зарплатах.
— Как программисту стать управленцем?
Вообще любой менеджер будет очень рад, если у него в команде появится программист, с которым можно поделиться ответственностью.
Для начала сделай так, чтобы тебя не нужно было менеджерить — научись выполнять свои собственные обещания и разбираться в задачах. Покачай софтскиллы — пойми зачем в принципе одни люди приходят к другим людям. Вот классические книги, которые в этом помогут:
• Стивен Кови — 7 навыков высокоэффективных людей. Про принятие решений и обещания.
• Джим Кэмп — Сначала скажите «нет». Про то, как разговаривать с другими людьми, чтобы им было полезно.
• Элияху Голдратт — Цель и Критическая цепь. Как лучше разбираться в постановке задач и управлении проектами.
Когда научишься менеджерить себя, останется совсем немного до того, чтобы научиться менеджерить других.
— Как научился брать на себя ответственность? Как понял, что больше хочешь быть управленцем, чем программистом?
Первоначально мне все эти штуки про ответственность были не очень интересны — казалось более прикольным ковыряться в коде и железках :-) Нужно сказать огромное спасибо коллегам, которые начали требовать этого от меня. Ну а дальше — начал читать книги.
Вообще программистам повезло с профессией. Есть, к примеру профессии, в которых можно получать удовольствие только от процесса, но не от результата — рабочий на производстве, дальнобойщик, официант в кафе. Есть наоборот, профессии, в которых важен только результат — это управление большими компаниями или собственным бизнесом, политика.
У программистов есть своеобразный баланс: мы сами выстраиваем себе удобный процесс, и сами выбираем в какой мере отвечать за результат. Не хотим отвечать за результат — пожалуйста, находим команду с хорошим менеджером, и не думаем ни о чем, кроме кода. Даже таким ребятам еще лет 5 будут платить среднерыночную зарплату, пока сохраняется кризис на рынке труда.
А вообще я считаю, что каждый программист должен забирать на себя столько ответственности, сколько только может. Ведь это же твоя жизнь, и именно ответственность определяет ее качество: будешь ли ты сам доволен результатом того, что делаешь?
Зарплата — вопрос сугубо индивидуальный и переговорный. Если посмотреть на рынок труда, то CTO можно называть и единственного веб-программиста, который дорабатывает лендос у сервиса онлайн-курсов, а могут — руководителя производства, критичного для компании уровня ВК или Ламоды. Вот такая же и разница в зарплатах.
— Как программисту стать управленцем?
Вообще любой менеджер будет очень рад, если у него в команде появится программист, с которым можно поделиться ответственностью.
Для начала сделай так, чтобы тебя не нужно было менеджерить — научись выполнять свои собственные обещания и разбираться в задачах. Покачай софтскиллы — пойми зачем в принципе одни люди приходят к другим людям. Вот классические книги, которые в этом помогут:
• Стивен Кови — 7 навыков высокоэффективных людей. Про принятие решений и обещания.
• Джим Кэмп — Сначала скажите «нет». Про то, как разговаривать с другими людьми, чтобы им было полезно.
• Элияху Голдратт — Цель и Критическая цепь. Как лучше разбираться в постановке задач и управлении проектами.
Когда научишься менеджерить себя, останется совсем немного до того, чтобы научиться менеджерить других.
— Как научился брать на себя ответственность? Как понял, что больше хочешь быть управленцем, чем программистом?
Первоначально мне все эти штуки про ответственность были не очень интересны — казалось более прикольным ковыряться в коде и железках :-) Нужно сказать огромное спасибо коллегам, которые начали требовать этого от меня. Ну а дальше — начал читать книги.
Вообще программистам повезло с профессией. Есть, к примеру профессии, в которых можно получать удовольствие только от процесса, но не от результата — рабочий на производстве, дальнобойщик, официант в кафе. Есть наоборот, профессии, в которых важен только результат — это управление большими компаниями или собственным бизнесом, политика.
У программистов есть своеобразный баланс: мы сами выстраиваем себе удобный процесс, и сами выбираем в какой мере отвечать за результат. Не хотим отвечать за результат — пожалуйста, находим команду с хорошим менеджером, и не думаем ни о чем, кроме кода. Даже таким ребятам еще лет 5 будут платить среднерыночную зарплату, пока сохраняется кризис на рынке труда.
А вообще я считаю, что каждый программист должен забирать на себя столько ответственности, сколько только может. Ведь это же твоя жизнь, и именно ответственность определяет ее качество: будешь ли ты сам доволен результатом того, что делаешь?
Вопрос: если посреди задачи программист понимает, что получил недоработанную задачу, что делать — бежать к постановщику или додумывать самому?
Если вы маленькая компания, то скорее всего соотношение мозговремени, потраченного на планирование задачи, с мозговременем, потраченным на ее производство, выглядит так:
Получается, именно программист несколько дней подряд уходит домой и просыпается с задачей в подсознании, в отличие от менеджера и дизайнера, которые давно заняты чем-то другим.
Если в этот момент программист немножко высунется из своей скорлупки и подумает не только про код, но и про бизнес, то он сильно облегчит жизнь всем коллегам, ведь у него же самое системное мышление из всех. Ну а если вылезать лень — можно и постановщику задачу вернуть.
См. также — приходи с решением, а не с проблемой.
Есть #вопрос? Задавай в @fedor_borshev.
Если вы маленькая компания, то скорее всего соотношение мозговремени, потраченного на планирование задачи, с мозговременем, потраченным на ее производство, выглядит так:
|——|———————|. Из всех участников процесса больше всего над задачей думает конечный исполнитель — программист.Получается, именно программист несколько дней подряд уходит домой и просыпается с задачей в подсознании, в отличие от менеджера и дизайнера, которые давно заняты чем-то другим.
Если в этот момент программист немножко высунется из своей скорлупки и подумает не только про код, но и про бизнес, то он сильно облегчит жизнь всем коллегам, ведь у него же самое системное мышление из всех. Ну а если вылезать лень — можно и постановщику задачу вернуть.
См. также — приходи с решением, а не с проблемой.
Есть #вопрос? Задавай в @fedor_borshev.
Positive review против Negative review
Знаю, как многих ребят (я в их числе) бесит, когда написанный код нужно кому-то показывать. Бывают даже крайние случаи, когда код нельзя мерджить, пока не покажем двум-трем ребятам.
Обязательный код-ревью убивает мотивацию и сильно замедляет разработку — ревьюер может быть занят, может не уметь делать ревью (это вообще сплошь и рядом), или вообще начать доебываться до неважных вещей, вроде форматирования кода (это же работа линтера).
Несмотря на это, я все равно ввожу обязательный ревью для всех новичков. Дело в том, что код-ревью — это незаменимый инструмент для передачи знаний. Старшие товарищи всегда ткнут пальцем на ошибки, связанные с незнанием контекста, вроде попыток повторно написать уже написанный код или непонятных юнит-тестов. Они же укажут на критично нагруженные участки кода, в которых нужно быть повнимательнее.
Вообще, в любом приложении есть множество эвристических правил, которые невозможно зафиксировать в регламентах. И код-ревью их отлично передает из одной головы в другую, уменьшая bus factor.
Когда новичок осознает ценность ревью и проходит испытательный срок, он переходит на positive review — его код могут посмотреть товарищи уже после мерджа (а могут и не смотреть). При этом он всегда будет сам звать других ребят, если почувствует, что ему не хватает опыта или знания контекста.
Знаю, как многих ребят (я в их числе) бесит, когда написанный код нужно кому-то показывать. Бывают даже крайние случаи, когда код нельзя мерджить, пока не покажем двум-трем ребятам.
Обязательный код-ревью убивает мотивацию и сильно замедляет разработку — ревьюер может быть занят, может не уметь делать ревью (это вообще сплошь и рядом), или вообще начать доебываться до неважных вещей, вроде форматирования кода (это же работа линтера).
Несмотря на это, я все равно ввожу обязательный ревью для всех новичков. Дело в том, что код-ревью — это незаменимый инструмент для передачи знаний. Старшие товарищи всегда ткнут пальцем на ошибки, связанные с незнанием контекста, вроде попыток повторно написать уже написанный код или непонятных юнит-тестов. Они же укажут на критично нагруженные участки кода, в которых нужно быть повнимательнее.
Вообще, в любом приложении есть множество эвристических правил, которые невозможно зафиксировать в регламентах. И код-ревью их отлично передает из одной головы в другую, уменьшая bus factor.
Когда новичок осознает ценность ревью и проходит испытательный срок, он переходит на positive review — его код могут посмотреть товарищи уже после мерджа (а могут и не смотреть). При этом он всегда будет сам звать других ребят, если почувствует, что ему не хватает опыта или знания контекста.
Circle CI, начало: обзор конфигурации, задачи
Прошлый пост набрал 200 лайков за 3 часа, так что я начну длинную серию с описанием возможностей Circle CI для приложения на Django.
Начнем с базовых вещей — примитивов, используемых в конфигурации.
Для того, чтобы начать собирать ваш проект в Circle CI нужно положить в репозиторий файл
Команда, или шаг (step) — самый маленький шаг, который вы используете в сборке. К примеру «восстановить кеш зависимостей» или «запустить линтер».
Задача (job) — последовательность шагов, которая выполняется в рамках одного контейнера. К примеру «запустить тесты», или «выкатить в прод».
Воркфлоу — последовательность задач, нужная для какого-то осознанного шага в реальном мире, к примеру «после каждого коммита собирать и проверять приложение, а затем выкатывать в прод, если комит был в мастер», или «каждую ночь собирать и выкладывать в докерхаб образы бекенда и базы для фронтендеров»
Разберем подробнее основные характеристики задачи
executor — контекст выполнения: machine (в заранее собранном окружении) или docker — в контейнере на основе любого (хоть вашего внутрикорпоративного) образа. Circle поддерживает целую кучу официальных образов для всех версий популярных языков. Дальше мы, как настоящие хипстеры, рассматриваем только докер.
resource_class — сколько ресурсов будет выделено под вашу задачу. По умолчанию всем дают 2 ядра и 4Гб памяти, но если вы платите серклу за машинное время, то можете выбирать от 1 до 8 CPU, с соответственно меняющимся объемом памяти. Обратите внимание, что эта характеристика привязана к задаче, а не ко всему workflow, то есть вы можете скажем распаковывать и ставить приложение на слабом контейнере, а под тесты, которые хорошо параллелятся — собирать мощные контейнеры хоть с 8 CPU.
parallelism: сколько контейнеров с задачей запускать одновременно. Разбиение нагрузки между контейнерами — на вас.
environment: переменные окружения, скажем доступ к базе или фиче-флаги. Если ваши переменные окружения приватны (к примеру содержат реквизиты для внутреннего реестра контейнеров) то хранить их лучше не здесь, а в настройках проекта, это облегчит распределение доступа внутри компании.
steps: собственно набор шагов, который вы хотите выполнять для сборки.
В следующей заметке будет про workflows и ночные сборки.
Прошлый пост набрал 200 лайков за 3 часа, так что я начну длинную серию с описанием возможностей Circle CI для приложения на Django.
Начнем с базовых вещей — примитивов, используемых в конфигурации.
Для того, чтобы начать собирать ваш проект в Circle CI нужно положить в репозиторий файл
.circleci/config.yml, в котором вы описываете последовательность сборки. Примеры файлов для всех языков можно найти в документации, а в этой заметке мы рассмотрим основные примитивы, которые используются в настройке CI под ваши нужды.Команда, или шаг (step) — самый маленький шаг, который вы используете в сборке. К примеру «восстановить кеш зависимостей» или «запустить линтер».
Задача (job) — последовательность шагов, которая выполняется в рамках одного контейнера. К примеру «запустить тесты», или «выкатить в прод».
Воркфлоу — последовательность задач, нужная для какого-то осознанного шага в реальном мире, к примеру «после каждого коммита собирать и проверять приложение, а затем выкатывать в прод, если комит был в мастер», или «каждую ночь собирать и выкладывать в докерхаб образы бекенда и базы для фронтендеров»
Разберем подробнее основные характеристики задачи
executor — контекст выполнения: machine (в заранее собранном окружении) или docker — в контейнере на основе любого (хоть вашего внутрикорпоративного) образа. Circle поддерживает целую кучу официальных образов для всех версий популярных языков. Дальше мы, как настоящие хипстеры, рассматриваем только докер.
resource_class — сколько ресурсов будет выделено под вашу задачу. По умолчанию всем дают 2 ядра и 4Гб памяти, но если вы платите серклу за машинное время, то можете выбирать от 1 до 8 CPU, с соответственно меняющимся объемом памяти. Обратите внимание, что эта характеристика привязана к задаче, а не ко всему workflow, то есть вы можете скажем распаковывать и ставить приложение на слабом контейнере, а под тесты, которые хорошо параллелятся — собирать мощные контейнеры хоть с 8 CPU.
parallelism: сколько контейнеров с задачей запускать одновременно. Разбиение нагрузки между контейнерами — на вас.
environment: переменные окружения, скажем доступ к базе или фиче-флаги. Если ваши переменные окружения приватны (к примеру содержат реквизиты для внутреннего реестра контейнеров) то хранить их лучше не здесь, а в настройках проекта, это облегчит распределение доступа внутри компании.
steps: собственно набор шагов, который вы хотите выполнять для сборки.
В следующей заметке будет про workflows и ночные сборки.