Как спрашивать «зачем»?
Как вы помните из заметки про фичреквесты, которые не стоит выполнять, вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.
Однако задавать постоянно этот вопрос не так уж и просто: если в лоб спрашивать у каждого постановщика, зачем ему эта задача, он может и обидеться — к вам же пришли, оторвались от важных дел, подумали головой, а вы тут сидите с умным видом и объясняете, что делать ничего не нужно.
Вот пара трюков, чтобы процесс задавания вопросов пошел легче:
• Объясните, чем вы можете помочь, имея это знание. К примеру, только вы знаете все уголки системы настолько, чтобы не пилить новую фичу, а предложить уже существующую похожую.
• Поговорите про цифры: «Подскажи, какие показатели мы прогнозируем в результате?». Когда вы говорите про цифры и гипотезы, то вы находитесь максимально далеко от личности постановщика задачи, а значит ему будет спокойнее отвечать на ваши вопросы.
• Расскажите, что понимая конечный результат, вы забираете на себя больше ответственности — если в конце спринта будет говно, то виноваты будете вы сами, а не тот, кто плохо поставил вам задачу. Для постановщика это выглядит как делегирование, а делегирование любят все менеджеры.
#чтобычто
Как вы помните из заметки про фичреквесты, которые не стоит выполнять, вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.
Однако задавать постоянно этот вопрос не так уж и просто: если в лоб спрашивать у каждого постановщика, зачем ему эта задача, он может и обидеться — к вам же пришли, оторвались от важных дел, подумали головой, а вы тут сидите с умным видом и объясняете, что делать ничего не нужно.
Вот пара трюков, чтобы процесс задавания вопросов пошел легче:
• Объясните, чем вы можете помочь, имея это знание. К примеру, только вы знаете все уголки системы настолько, чтобы не пилить новую фичу, а предложить уже существующую похожую.
• Поговорите про цифры: «Подскажи, какие показатели мы прогнозируем в результате?». Когда вы говорите про цифры и гипотезы, то вы находитесь максимально далеко от личности постановщика задачи, а значит ему будет спокойнее отвечать на ваши вопросы.
• Расскажите, что понимая конечный результат, вы забираете на себя больше ответственности — если в конце спринта будет говно, то виноваты будете вы сами, а не тот, кто плохо поставил вам задачу. Для постановщика это выглядит как делегирование, а делегирование любят все менеджеры.
#чтобычто
Гитхаб позавчера выкатил пост мортем об инциденте прошлой недели.
Вкратце — из-за короткого (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 и ночные сборки.
Вопрос: считаете ли вы трудозатраты, сколько обошлась выкатка фичи в прод?
Нет, не считаем. Во-первых мы вообще не учитываем ничье время, потому что договариваемся друг с другом о результатах (работающих фичах), а не о процессе (затраченном времени).
Во-вторых, непонятно куда можно было бы использовать такую статистику. Скажем, у нас есть программист, который запилил фичу A за X времени. Допустим, у нас есть фича B, которая коллективным решением (ха-ха), признана в 2 раза сложнее, чем фича A. Значит ли это, что время, которое уйдет на фичу B, равняется 2X? Нет, и математика тут не поможет — во время разработки фичи B программист может заболеть, наткнуться на непреодолимые преграды в коде, может упасть прод, прийти менеджер с более срочной задачей (у нас не может), в конце концов оценка может оказаться неправильной.
#вопрос Задать свой — @fedor_borshev
Нет, не считаем. Во-первых мы вообще не учитываем ничье время, потому что договариваемся друг с другом о результатах (работающих фичах), а не о процессе (затраченном времени).
Во-вторых, непонятно куда можно было бы использовать такую статистику. Скажем, у нас есть программист, который запилил фичу A за X времени. Допустим, у нас есть фича B, которая коллективным решением (ха-ха), признана в 2 раза сложнее, чем фича A. Значит ли это, что время, которое уйдет на фичу B, равняется 2X? Нет, и математика тут не поможет — во время разработки фичи B программист может заболеть, наткнуться на непреодолимые преграды в коде, может упасть прод, прийти менеджер с более срочной задачей (у нас не может), в конце концов оценка может оказаться неправильной.
#вопрос Задать свой — @fedor_borshev
Управляй своим временем
— Договорились. Когда сделаешь?
— Эм, дай подумать... В следующую среду.
— Ой, а давай в понедельник? А то у нас презентация важная.
— Ну давай.
Все, пиздец, управление потеряно.
Вокруг очень много людей, которые стремятся отнять у тебя право управлять твоим собственным временем. Их можно понять: любому человеку комфортнее, когда ситуацией управляет он сам, а не кто-то другой (ты).
К тому же менеджер, который только что украл у тебя время, наверняка уже много раз сталкивался с плохими исполнителями, нарушающими любой срок, который только ни назовут. Чтобы добиться результата от таких ребят, приходится прожимать их по срокам, чтобы пораньше можно было спросить «ну как?», и запустить инструменты повышения продуктивности, вроде телефонных звонков и начальства в копии.
Не будь тем, кому нужно звонить. Никогда не торгуйся по срокам. Просто не давай лишних обещаний, а дал обещание — выполняй вовремя.
— Договорились. Когда сделаешь?
— Эм, дай подумать... В следующую среду.
— Ой, а давай в понедельник? А то у нас презентация важная.
— Ну давай.
Все, пиздец, управление потеряно.
Вокруг очень много людей, которые стремятся отнять у тебя право управлять твоим собственным временем. Их можно понять: любому человеку комфортнее, когда ситуацией управляет он сам, а не кто-то другой (ты).
К тому же менеджер, который только что украл у тебя время, наверняка уже много раз сталкивался с плохими исполнителями, нарушающими любой срок, который только ни назовут. Чтобы добиться результата от таких ребят, приходится прожимать их по срокам, чтобы пораньше можно было спросить «ну как?», и запустить инструменты повышения продуктивности, вроде телефонных звонков и начальства в копии.
Не будь тем, кому нужно звонить. Никогда не торгуйся по срокам. Просто не давай лишних обещаний, а дал обещание — выполняй вовремя.