#вопрос Подскажи пожалуйста, всегда ли вам хватало возможностей Django для ваших кейсов? Были ли моменты когда было желание переписать на чём то пошустрее? Есть ли какие-то кейсы когда ты бы не взял Django как основу для веб-проекта (помимо микросервисов и жестких ограничений по latency)?
Нам Django всегда хватало. Правда у нас много аутсорсной специфики: команды с высокими требованиями к времени ответа обычно реализуют проекты in-house с помощью собственных дорогих специалистов. В аутсорсе мы практически не работаем с нагрузкой, которую нельзя закешировать.
Даже там где работаем — предпочитаем делать простой, но медленный код, избегая преждевременной оптимизации. Порядок мыслей здесь простой — нагрузка может и не вырасти, а понятный и покрытый код всегда ценнее для команды, которая заберёт у нас проект, чем непонятный, но быстрый.
Хоть я с этим и не сталкивался на практике, рискну предположить, что современные облака с неограниченным горизонтальным масштабированием позволяют даже забить на GIL. Так что пока мы остаёмся на Django: на ней гораздо проще оказывать стандартную услугу разработки, чем на зоопарке из красивых фреймворков.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Нам Django всегда хватало. Правда у нас много аутсорсной специфики: команды с высокими требованиями к времени ответа обычно реализуют проекты in-house с помощью собственных дорогих специалистов. В аутсорсе мы практически не работаем с нагрузкой, которую нельзя закешировать.
Даже там где работаем — предпочитаем делать простой, но медленный код, избегая преждевременной оптимизации. Порядок мыслей здесь простой — нагрузка может и не вырасти, а понятный и покрытый код всегда ценнее для команды, которая заберёт у нас проект, чем непонятный, но быстрый.
Хоть я с этим и не сталкивался на практике, рискну предположить, что современные облака с неограниченным горизонтальным масштабированием позволяют даже забить на GIL. Так что пока мы остаёмся на Django: на ней гораздо проще оказывать стандартную услугу разработки, чем на зоопарке из красивых фреймворков.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Управляющие воздействия
Когда я оцениваю проекты, команды или даже отдельных людей, я использую понятие «управляющее воздействие». Чем меньше таких воздействий нужно, чтобы нужные вещи случались — тем лучше.
Плохая команда не едет вперёд без дейликов. Несамостоятельный сотрудник не выполняет задачи без десятка комментариев от меня. Плохо настроенный проект буксует без ежедневных встреч всех участников.
Это как с машинами — от Москвы до Воронежа можно доехать на мерседесе или на жигулях примерно за одно и то же время. Только на мерседесе будешь разглядывать дорогу и слушать музыку, а на жигулях придётся подруливать, следить за температурой двигателя и может быть даже остановиться, если что-то сломается.
Правда, в отличие от машин, ответственные сотрудники хотят не на порядок больше денег, чем обычные.
Когда я оцениваю проекты, команды или даже отдельных людей, я использую понятие «управляющее воздействие». Чем меньше таких воздействий нужно, чтобы нужные вещи случались — тем лучше.
Плохая команда не едет вперёд без дейликов. Несамостоятельный сотрудник не выполняет задачи без десятка комментариев от меня. Плохо настроенный проект буксует без ежедневных встреч всех участников.
Это как с машинами — от Москвы до Воронежа можно доехать на мерседесе или на жигулях примерно за одно и то же время. Только на мерседесе будешь разглядывать дорогу и слушать музыку, а на жигулях придётся подруливать, следить за температурой двигателя и может быть даже остановиться, если что-то сломается.
Правда, в отличие от машин, ответственные сотрудники хотят не на порядок больше денег, чем обычные.
Модель юзера — только для authn/authz
В Django есть две окаменелости — это система шаблонов и модель юзера. Про систему шаблонов я уже писал, когда рассказывал что Django — это API, а на второй остановлюсь подробнее: во-первых я не про
Проблема любой модели юзера в любом таком фреймворке — она своим существованием буквально просит неопытного программиста писать в себя код. Пишешь метод получения заказа? Как же клёво будет сделать
В итоге получается божественный объект, который буквально умеет всё, находится в центре любой схемы данных и не помещается в одной голове, чтобы его отрефакторить. Особенно грустно становится, когда в системе есть несколько видов юзеров — скажем потребители и контент-менеджеры. Первый действительно часто нужно делать
Конечно можете разбить код по рельсовым concerns или по питоньим миксинам, но этим вы притащите больше проблем, чем решите. Кроме того, что вы перестанете понимать, откуда приходит какой метод, вы (по крайней мере в django) отделите код консёрна от его полей: django не умеет собирать набор полей в модели из множественного наследования.
Так что настоятельно рекомендую, если работаете с MVC-фреймворкаии — не используйте модель юзера ни для чего кроме аунтификации и авторизации: запутаетесь.
В Django есть две окаменелости — это система шаблонов и модель юзера. Про систему шаблонов я уже писал, когда рассказывал что Django — это API, а на второй остановлюсь подробнее: во-первых я не про
AUTH_USER_MODEL, как вы подумали, а во-вторых, этот антипаттерн встречается не только у нас, но и в рельсе и, препдоложу в других M(VC)-фреймворках.Проблема любой модели юзера в любом таком фреймворке — она своим существованием буквально просит неопытного программиста писать в себя код. Пишешь метод получения заказа? Как же клёво будет сделать
request.user.get\_orders(). Делаешь почтовые уведомления? request.user.send\_email(). Хочешь отдать в API накопительную скидку? request.user\_get\_discount(). В итоге получается божественный объект, который буквально умеет всё, находится в центре любой схемы данных и не помещается в одной голове, чтобы его отрефакторить. Особенно грустно становится, когда в системе есть несколько видов юзеров — скажем потребители и контент-менеджеры. Первый действительно часто нужно делать
.get\_orders(), то у других больше востребованы методы для работы с пермишенами и аудитлогом. И все они лежат в одном месте, путаясь друг с другом!Конечно можете разбить код по рельсовым concerns или по питоньим миксинам, но этим вы притащите больше проблем, чем решите. Кроме того, что вы перестанете понимать, откуда приходит какой метод, вы (по крайней мере в django) отделите код консёрна от его полей: django не умеет собирать набор полей в модели из множественного наследования.
Так что настоятельно рекомендую, если работаете с MVC-фреймворкаии — не используйте модель юзера ни для чего кроме аунтификации и авторизации: запутаетесь.
#вопрос Не возникало ли желания разработать свой инструмент для отрисовки фронта? Я имею ввиду backend driven ui. Возможно что-то используешь из существующего, расскажи пожалуйста об этом. И как в целом рассматриваешь такой подход? И поделись пожалуйста мнением о собственной разработке подобных решений, стоит ли игра свеч?
Начну со второго вопроса. Желание делать собственные инструменты у меня пропало лет 10–12 назад, когда я понял, что попытки конкурировать с сообществом не приносят ни денег, ни счастья. Чтобы делать собственные фреймворки, нужно быть очень хорошим инженером, уметь разговаривать с людьми и разбираться в продуктоводстве. Разговаривая с опенсорсерами уровня Никиты Соболева я понимаю, что мне с моим ремесленническим подходом до этого очень далеко.
Про backend driven ui я уже где-то писал. Даже если отбросить крайности вроде приснопамятного GWT или попыток делать динамические формы на Django, делать фронт силами бекендеров довольно невыгодно с точки зрения бизнеса. Во-первых, на рынке труда гораздо больше неуниверсальных специалистов, то есть проще нанять отдельно бекендера и отдельно фронтендера, чем фуллстека. Во-вторых, все инструменты генерации фронта на бекенде, которые я видел, — довольно маргинальные. Как не конфигури тулзы вроде django-webpack, DX там будет ужасным — ни горячей перезагрузки, ни zero-configuration, даже разворачивать всё это на одной тачке крайне больно. Получается довольно обидно — настраиваешь неделю кучу всякой фигни, с трудом ищешь людей, которые с ней будут работать, а на соседнем проекте набирают npm init vue и получают всё то же самое, но сто раз проще.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Начну со второго вопроса. Желание делать собственные инструменты у меня пропало лет 10–12 назад, когда я понял, что попытки конкурировать с сообществом не приносят ни денег, ни счастья. Чтобы делать собственные фреймворки, нужно быть очень хорошим инженером, уметь разговаривать с людьми и разбираться в продуктоводстве. Разговаривая с опенсорсерами уровня Никиты Соболева я понимаю, что мне с моим ремесленническим подходом до этого очень далеко.
Про backend driven ui я уже где-то писал. Даже если отбросить крайности вроде приснопамятного GWT или попыток делать динамические формы на Django, делать фронт силами бекендеров довольно невыгодно с точки зрения бизнеса. Во-первых, на рынке труда гораздо больше неуниверсальных специалистов, то есть проще нанять отдельно бекендера и отдельно фронтендера, чем фуллстека. Во-вторых, все инструменты генерации фронта на бекенде, которые я видел, — довольно маргинальные. Как не конфигури тулзы вроде django-webpack, DX там будет ужасным — ни горячей перезагрузки, ни zero-configuration, даже разворачивать всё это на одной тачке крайне больно. Получается довольно обидно — настраиваешь неделю кучу всякой фигни, с трудом ищешь людей, которые с ней будут работать, а на соседнем проекте набирают npm init vue и получают всё то же самое, но сто раз проще.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Надёжность
Основа рабочих отношений в нашей компании — надёжность. Когда программист говорит, что сделает задачу в пятницу — менеджер проекта уверен, что в пятницу увидит код на проде, или в среду получит сигнал о том, что программист не успевает.
Когда два сотрудника назначают встречу на 16:00 — я уверен, что в 16:01 встреча уже будет идти. Когда любой сотрудник компании пишет письмо любому другому сотруднику (мне в том числе), он уверен, что письмо не потеряется.
Надёжность нужна, потому что мы — маленькие, а значит должны быть предельно эффективными: не тратить время, чтобы напоминать другу-другу о забытых обещаниях или извиняться перед клиентами за поехавшие сроки.
Внедрять надёжность а компании тяжело — приходится и увольнять людей, и самому «ходить в поля», чтобы понять состояние дел, — в общем целая история, о которой даже писать не хочется. Наверное, единственный понятный шаг, который с гарантией повысиит надёжности — это внедрить асинхронную коммуникацию: чем меньше люди на связи друг с другом, тем более понимают, раз пообещал — нужно сделать.
Основа рабочих отношений в нашей компании — надёжность. Когда программист говорит, что сделает задачу в пятницу — менеджер проекта уверен, что в пятницу увидит код на проде, или в среду получит сигнал о том, что программист не успевает.
Когда два сотрудника назначают встречу на 16:00 — я уверен, что в 16:01 встреча уже будет идти. Когда любой сотрудник компании пишет письмо любому другому сотруднику (мне в том числе), он уверен, что письмо не потеряется.
Надёжность нужна, потому что мы — маленькие, а значит должны быть предельно эффективными: не тратить время, чтобы напоминать другу-другу о забытых обещаниях или извиняться перед клиентами за поехавшие сроки.
Внедрять надёжность а компании тяжело — приходится и увольнять людей, и самому «ходить в поля», чтобы понять состояние дел, — в общем целая история, о которой даже писать не хочется. Наверное, единственный понятный шаг, который с гарантией повысиит надёжности — это внедрить асинхронную коммуникацию: чем меньше люди на связи друг с другом, тем более понимают, раз пообещал — нужно сделать.
Мы в школе стараемся не играть в скидки, потому что считаем, что хорошие знания приобретаются осознанно, а не через импульсные покупки. Промокоды используем как награду — ребятам, которые читают рассылку или ранним пташкам, которые покупают курсы сразу после запуска.
Сейчас проводим эксперимент — объявляем чёрнопятничную распродажу: в течение 24 и 25 ноября даём скидку 25% на самостоятельный тариф любого нашего курса по промокоду BlackFriday. Хотим использовать пятницу, чтобы дать возможность познакомиться со школой тем, кто сомневается и видит недостаточно ценности в курсах. Или подарить друзьям.
Если заработает — будем раз в год придумывать что-нибудь новое.
Выбрать курс →
Если вы юрлицо, и хотите со скидкой купить 5 или больше билетов — напишите нам в чатик на сайте, для вас промокод тоже действует.
Сейчас проводим эксперимент — объявляем чёрнопятничную распродажу: в течение 24 и 25 ноября даём скидку 25% на самостоятельный тариф любого нашего курса по промокоду BlackFriday. Хотим использовать пятницу, чтобы дать возможность познакомиться со школой тем, кто сомневается и видит недостаточно ценности в курсах. Или подарить друзьям.
Если заработает — будем раз в год придумывать что-нибудь новое.
Выбрать курс →
Если вы юрлицо, и хотите со скидкой купить 5 или больше билетов — напишите нам в чатик на сайте, для вас промокод тоже действует.
#вопрос Как нанимать сотрудника на незнакомый стек? К примеру, если мне нужно нанять react-разработчика, то я знаю какие вопросы задать, т.к. я сам пишу на реакте. Но как быть, если в команду нужен специалист по machine learning и ни у кого нет опыта в этом направлении?
Для начала — смириться с тем, что джуна вы не наймёте: не разбираясь в стеке, вы вряд ли отличите нормального джуна с горящими глазами от выпускника вайтишных курсов: вы не поймёте, насколько актуальны его знания, чем он интересуется и, тем более, не увидите его слабых мест.
Скорее всего, вы будете нанимать синьёров, а их собеседовать нужно уже как синьёров — не спрашивать, что нового в последней версии Keras, а пытаться понять, насколько он умеет разбираться в задачах бизнеса, быть самостоятельным, выполнять обещания, организовывать других и ещё кучу всего.
Ещё посоветую, если в компании нет экспертизы в ML, не пытаться её вырастить сразу, а обратиться к аутсорсерам. С теми всё ещё проще — вы просто говорите о деньгах и сроках, и выгоняете тех, кто не укладывается в обещания: не важно, подрядчик это по ML или какой-нибудь аутсорс-девопс.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Для начала — смириться с тем, что джуна вы не наймёте: не разбираясь в стеке, вы вряд ли отличите нормального джуна с горящими глазами от выпускника вайтишных курсов: вы не поймёте, насколько актуальны его знания, чем он интересуется и, тем более, не увидите его слабых мест.
Скорее всего, вы будете нанимать синьёров, а их собеседовать нужно уже как синьёров — не спрашивать, что нового в последней версии Keras, а пытаться понять, насколько он умеет разбираться в задачах бизнеса, быть самостоятельным, выполнять обещания, организовывать других и ещё кучу всего.
Ещё посоветую, если в компании нет экспертизы в ML, не пытаться её вырастить сразу, а обратиться к аутсорсерам. С теми всё ещё проще — вы просто говорите о деньгах и сроках, и выгоняете тех, кто не укладывается в обещания: не важно, подрядчик это по ML или какой-нибудь аутсорс-девопс.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
FEDOR BORSHEV
Надёжность Основа рабочих отношений в нашей компании — надёжность. Когда программист говорит, что сделает задачу в пятницу — менеджер проекта уверен, что в пятницу увидит код на проде, или в среду получит сигнал о том, что программист не успевает. Когда…
Узнал тут из комментов, что для кого-то может быть приемлемо опоздать на встречу, если есть отмазка в виде другой пересекающейся встречи: новая встреча уже началась, а старая ещё не закончилась. Кажется, такие пересекающиеся встречи — это верхушка целого айсберга проблем, которые надо решать тем, кто опаздывает:
— У вас нет перерывов между встречами. Значит после 2–3 таких встреч остальные становятся бесполезны — вы будете банально тупить на них.
— Вы не защищаете свой календарь. Вряд ли вы сами поставили себе встречу, которая пересекается с другой: скорее всего вас позвали, а вы не смогли отказать.
— У вас принято задерживаться на встречах. Это значит, что встречи скорее всего проходят без повестки или в неудачном составе.
Если у вас или у коллег есть привычка задерживаться на пересекающихся встречах — посмотрите внимательно, скорее всего что-то вокруг вас серьёзно не так.
Мы с Марьянойготовим курс о коммуникации в компании, где в том числе будем рассказывать и о том, как бороться с излишним количеством встреч .
— У вас нет перерывов между встречами. Значит после 2–3 таких встреч остальные становятся бесполезны — вы будете банально тупить на них.
— Вы не защищаете свой календарь. Вряд ли вы сами поставили себе встречу, которая пересекается с другой: скорее всего вас позвали, а вы не смогли отказать.
— У вас принято задерживаться на встречах. Это значит, что встречи скорее всего проходят без повестки или в неудачном составе.
Если у вас или у коллег есть привычка задерживаться на пересекающихся встречах — посмотрите внимательно, скорее всего что-то вокруг вас серьёзно не так.
Мы с Марьяной
#вопрос Я всю жизнь промышленно пишу бэкенд, периодически ненадолго заглядывая во фронтенд по мере надобности (есть минимальный опыт с React, Svelte). Сейчас выбираю стек технологий для личного проекта. Нужен будет API для приложений и для фронта; фронт— админка и простой сайт для пользователей.
Первую версию напишу сам, но в будущем хочу иметь возможность нанять кого-то для поддержки. Посоветуй, что выбрать, чтобы было проще «въехать» самому и чтобы было кого нанять на эти технологии позднее.
Сам склоняюсь к Django+React (хотя душа просит Svelte). Если можешь, расскажи, какие технологии сейчас позволяют программисту сделать сайт, как будто он чуть-чуть дизайнер. (Я слышал слово «tailwind».
———
Для начала посоветую крепко подумать, и во все места проекта, которые могут обойтись без фронтенда, бекенда и их интеграции, засунуть тильду, bubble или что-нибудь ещё зерокодное. Если проект начнёт расти — сделаешь нормально. Если не начнёт — не потратишь врея.
Но допустим, этот этап ты прошёл, и код всё-таки писать нужно. Тогда я посоветую выбрать самую популярную технологию из доступных: так проще будет найти документацию, инструменты, а самое главное — специалистов, чтобы задать вопрос, и чтобы передать им проект по мере роста. У Реакта на фронте сейчас, к сожалению, конкурентов нет, так что смело забивай на красоту, новизну и всё другое, что любят инженеры, и делай «в лоб».
У tailwind есть своё место — на нём удобно собирать админки и простые CRUD-интерфейсы. Если интерфейсы становятся сложными и в команде появляется дизайнер — становится тесновато. В контексте роста проекта у инструментов вроде tailwind довольно узкое окно: когда зерокода уже мало, а для полноценной разработки пока рановато. Как пример — мы делаем на нём новую версию школьной LMS: старая упёрлась в техдолг, дизайнера и UI-кита в команде нет, вот мы и взяли готовое.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Первую версию напишу сам, но в будущем хочу иметь возможность нанять кого-то для поддержки. Посоветуй, что выбрать, чтобы было проще «въехать» самому и чтобы было кого нанять на эти технологии позднее.
Сам склоняюсь к Django+React (хотя душа просит Svelte). Если можешь, расскажи, какие технологии сейчас позволяют программисту сделать сайт, как будто он чуть-чуть дизайнер. (Я слышал слово «tailwind».
———
Для начала посоветую крепко подумать, и во все места проекта, которые могут обойтись без фронтенда, бекенда и их интеграции, засунуть тильду, bubble или что-нибудь ещё зерокодное. Если проект начнёт расти — сделаешь нормально. Если не начнёт — не потратишь врея.
Но допустим, этот этап ты прошёл, и код всё-таки писать нужно. Тогда я посоветую выбрать самую популярную технологию из доступных: так проще будет найти документацию, инструменты, а самое главное — специалистов, чтобы задать вопрос, и чтобы передать им проект по мере роста. У Реакта на фронте сейчас, к сожалению, конкурентов нет, так что смело забивай на красоту, новизну и всё другое, что любят инженеры, и делай «в лоб».
У tailwind есть своё место — на нём удобно собирать админки и простые CRUD-интерфейсы. Если интерфейсы становятся сложными и в команде появляется дизайнер — становится тесновато. В контексте роста проекта у инструментов вроде tailwind довольно узкое окно: когда зерокода уже мало, а для полноценной разработки пока рановато. Как пример — мы делаем на нём новую версию школьной LMS: старая упёрлась в техдолг, дизайнера и UI-кита в команде нет, вот мы и взяли готовое.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Умение рассказывать истории
Кажется, самый недооцененный среди программистов софт-скилл — умение выстраивать интересные истории из своих мыслей. Проблема типичная для интровертов — в голове всё такое стройное, а когда пытаешься рассказать окружающим — наталкиваешься на непонимание.
На работе люди рассказывают истории всегда — на собеседованиях, когда объясняют новую концепцию на встрече, когда онбордят новичков и ставят задачи — у всего этого есть нарратив, который один человек рассказывает другому. Нарратив может быть минимальным: с началом, серединой и концом. Бывает посложнее — к примерукруг Хармона (того самого, из Рика и Морти) с неясным зовом, поиском, перепетиями и победой в конце.
Вне работы истории рассказывают на свиданиях и посиделках с друзьями, на публичных выступлениях. Когда вечером рассказываете близким как прошёл ваш день — вы тоже рассказываете историю, которая начинается с утра, длится днём и заканчивается вечером.
Умение рассказывать истории — важнейший софт-скилл: если вы не можете увлечь человека своим предложением, скорее всего его не примут, каким-бы гениальным оно не было. Если мечтаете о предпринимательстве — без историй вообще никуда: существуют предприниматели, которые вообще ничего не умеют делать, кроме как рассказывать истории.
Научиться рассказывать истории будучи интровертом — довольно долго. Мне понадобилось 5 лет практики, чтобы люди хоть как-то начали меня понимать. Когда возьмётесь прокачивать у себя — начните с тренера по публичным выступлениям: профессия этих ребят как раз в том, чтобы научить вас рассказывать истории. Пробуйте писать истории для себя (дневник отлично подойдёт). Я в последнее время практикуюсь, пересказывая голосом сюжеты фильмов — когда строишь такой рассказ, ты должен быть максимально кратким (иначе всем станет скучно), но при этом ёмким, не теряя сути — иначе фильм никто не посмотрит.
Кажется, самый недооцененный среди программистов софт-скилл — умение выстраивать интересные истории из своих мыслей. Проблема типичная для интровертов — в голове всё такое стройное, а когда пытаешься рассказать окружающим — наталкиваешься на непонимание.
На работе люди рассказывают истории всегда — на собеседованиях, когда объясняют новую концепцию на встрече, когда онбордят новичков и ставят задачи — у всего этого есть нарратив, который один человек рассказывает другому. Нарратив может быть минимальным: с началом, серединой и концом. Бывает посложнее — к примерукруг Хармона (того самого, из Рика и Морти) с неясным зовом, поиском, перепетиями и победой в конце.
Вне работы истории рассказывают на свиданиях и посиделках с друзьями, на публичных выступлениях. Когда вечером рассказываете близким как прошёл ваш день — вы тоже рассказываете историю, которая начинается с утра, длится днём и заканчивается вечером.
Умение рассказывать истории — важнейший софт-скилл: если вы не можете увлечь человека своим предложением, скорее всего его не примут, каким-бы гениальным оно не было. Если мечтаете о предпринимательстве — без историй вообще никуда: существуют предприниматели, которые вообще ничего не умеют делать, кроме как рассказывать истории.
Научиться рассказывать истории будучи интровертом — довольно долго. Мне понадобилось 5 лет практики, чтобы люди хоть как-то начали меня понимать. Когда возьмётесь прокачивать у себя — начните с тренера по публичным выступлениям: профессия этих ребят как раз в том, чтобы научить вас рассказывать истории. Пробуйте писать истории для себя (дневник отлично подойдёт). Я в последнее время практикуюсь, пересказывая голосом сюжеты фильмов — когда строишь такой рассказ, ты должен быть максимально кратким (иначе всем станет скучно), но при этом ёмким, не теряя сути — иначе фильм никто не посмотрит.
Писать мало кода — это софтскилл
В перерывах между крупными проектами наши программисты обычно делают мелкие задачки для компании и клиентов: рефакторят старый код или настраивают мелкие интеграции, что сэкономить время на рутине. Обычно в таких проектах мы даём полную свободу — можно выбрать любую технологию и любой подход. Недавно на двух таких проектах одновременно заметил тенденцию к оверижинирингу: типа затащить RabbitMQ в проект, который в ответ на один вебхук дёргает другой вебхук или прикрутить строгую типизацию в кодовую базу на 300 строк.
С одной стороны ребят можно понять — хочется больше практиковаться в новых технологиях: когда пришёл на проект, где всё уже работает, самый хороший способ изучить его технологии— воспроизвести с нуля на соседнем проекте. Да и индустрия давит — парочка хайповых технологий в резюме привлечёт больше сорсеров, чем умение решать задачи за день вместо недели или за 300 строк вместо 30 000.
Если планируете развиваться в кого-то кроме синьёра, годами не вылезающего из своего, постепенно превращающегося в легаси, проекта, такой оверижиниринг для вас — стратегическая ошибка. Смотрите сами, технологии — это хард-скиллы. Сегодня RabbitMQ, завтра BunnyPQ или RussMessageOchered: всё это учится за 1–2 недели при желании. А вот умение писать мало кода — это целый сложный софт-скилл: тут и в бизнес-задаче надо разобраться, и изобретать уметь, и заказчику продать свои изобретения. За пару недель не освоишь.
Софт-скиллы качать всегда выгоднее, чем хардскиллы — технологии меняются, а ваша голова и опыт остаются. Так что если на работе достался небольшой проект без ограничений — постарайтесь на нём написать меньше кода, а не больше\.
В перерывах между крупными проектами наши программисты обычно делают мелкие задачки для компании и клиентов: рефакторят старый код или настраивают мелкие интеграции, что сэкономить время на рутине. Обычно в таких проектах мы даём полную свободу — можно выбрать любую технологию и любой подход. Недавно на двух таких проектах одновременно заметил тенденцию к оверижинирингу: типа затащить RabbitMQ в проект, который в ответ на один вебхук дёргает другой вебхук или прикрутить строгую типизацию в кодовую базу на 300 строк.
С одной стороны ребят можно понять — хочется больше практиковаться в новых технологиях: когда пришёл на проект, где всё уже работает, самый хороший способ изучить его технологии— воспроизвести с нуля на соседнем проекте. Да и индустрия давит — парочка хайповых технологий в резюме привлечёт больше сорсеров, чем умение решать задачи за день вместо недели или за 300 строк вместо 30 000.
Если планируете развиваться в кого-то кроме синьёра, годами не вылезающего из своего, постепенно превращающегося в легаси, проекта, такой оверижиниринг для вас — стратегическая ошибка. Смотрите сами, технологии — это хард-скиллы. Сегодня RabbitMQ, завтра BunnyPQ или RussMessageOchered: всё это учится за 1–2 недели при желании. А вот умение писать мало кода — это целый сложный софт-скилл: тут и в бизнес-задаче надо разобраться, и изобретать уметь, и заказчику продать свои изобретения. За пару недель не освоишь.
Софт-скиллы качать всегда выгоднее, чем хардскиллы — технологии меняются, а ваша голова и опыт остаются. Так что если на работе достался небольшой проект без ограничений — постарайтесь на нём написать меньше кода, а не больше\.
Есть минутка
Когда-то я был знаком с руководителем, который требовал от подчинённых, чтобы ему моментально отвечали в вацапе. В основном он там ставил срочные задачи и уточнял статус по уже поставленным.
С одной стороны такое требование можно понять: человек руководит бизнесом, хочет экономить каждую секунду с помощью подчинённых. А с другой — компания страдала тяжелейшей формой организационной немощи: никакие сложные дела не делались, пока всех не запрёшь в одной комнате, и не сядешь там же следить, чтобы больше ни на что не отвлекались. И дело даже не в микроменеджменте — сотрудники тонут в горе чатов, не выполняют обещания, и нормально не отдыхают, потому что в вацап можно писать даже в выходные.
В то же время я познакомился с обратным примером — Студией Лебедева. Там, хоть и не признавали удалённую работу, но никто никого не просил быть на связи, в основном все общались по почте и в таск-трекере. И каково же было моё удивление, когда я не увидел ни следа той самой немощи — вроде и люди более расслаблены, и общения меньше, а дела делаются гораздо быстрее.
В тот момент я решил, что всё дело в людях: типа в студии просто более жестокий отбор. Но через пару лет, когда построил первую самостоятельную команду, понял, что дело не в людях, в отношениях между ними. В хорошей команде люди с бо́льшим уважением относятся ко времени друг-друга: не дёргают по пустякам, не таскают на ненужные встречи, ставят задачи так, чтобы не приходилось переспрашивать. А когда обновляешь статусы в вацапе в перерыве между 5 и 6 встречей за день — не до вдумчивой постановки задач.
Команды, подобные первой (разве что без вацапа) я встречаю постоянно, а вот подобные второй — редко. Поэтому когда Марьяна предложила сделать в школе курс о коммуникации — я с радостью согласился: буду рад, если получится поменять не одну команду через личные советы, а сразу несколько десятков при помощи курса.
Так что мы сделали 3 письма, которые радикально улучшат коммуникацию — вокруг вас, если вы обычный программист или во всей команде, если вы менеджер\тимлид.
Смотреть программу →
Стартуем 1 февраля, до 26 декабря — скидка 10% по промокоду
Когда-то я был знаком с руководителем, который требовал от подчинённых, чтобы ему моментально отвечали в вацапе. В основном он там ставил срочные задачи и уточнял статус по уже поставленным.
С одной стороны такое требование можно понять: человек руководит бизнесом, хочет экономить каждую секунду с помощью подчинённых. А с другой — компания страдала тяжелейшей формой организационной немощи: никакие сложные дела не делались, пока всех не запрёшь в одной комнате, и не сядешь там же следить, чтобы больше ни на что не отвлекались. И дело даже не в микроменеджменте — сотрудники тонут в горе чатов, не выполняют обещания, и нормально не отдыхают, потому что в вацап можно писать даже в выходные.
В то же время я познакомился с обратным примером — Студией Лебедева. Там, хоть и не признавали удалённую работу, но никто никого не просил быть на связи, в основном все общались по почте и в таск-трекере. И каково же было моё удивление, когда я не увидел ни следа той самой немощи — вроде и люди более расслаблены, и общения меньше, а дела делаются гораздо быстрее.
В тот момент я решил, что всё дело в людях: типа в студии просто более жестокий отбор. Но через пару лет, когда построил первую самостоятельную команду, понял, что дело не в людях, в отношениях между ними. В хорошей команде люди с бо́льшим уважением относятся ко времени друг-друга: не дёргают по пустякам, не таскают на ненужные встречи, ставят задачи так, чтобы не приходилось переспрашивать. А когда обновляешь статусы в вацапе в перерыве между 5 и 6 встречей за день — не до вдумчивой постановки задач.
Команды, подобные первой (разве что без вацапа) я встречаю постоянно, а вот подобные второй — редко. Поэтому когда Марьяна предложила сделать в школе курс о коммуникации — я с радостью согласился: буду рад, если получится поменять не одну команду через личные советы, а сразу несколько десятков при помощи курса.
Так что мы сделали 3 письма, которые радикально улучшат коммуникацию — вокруг вас, если вы обычный программист или во всей команде, если вы менеджер\тимлид.
Смотреть программу →
Стартуем 1 февраля, до 26 декабря — скидка 10% по промокоду
NOSYNCNEEDEDВозник #вопрос по поводу твоего поста Кто отвечает, чтобы ПР оказался на проде.
Вроде смысл понятен: дать понять представление о границах ответственности разработчика и definition of done. Но как это работает на практике не очень ясно: разработчик контролирует процесс QA и деплоя и людей, которые за них отвечают? Сам тестирует или деплоит? Что насчет интеграции фронтенд кода с бэкэндом? Продолжается ли ответственность до того, чтобы код правильно работал на проде? Работает ли это по другому сейчас, когда у вас аутсорс разработка?
———
Начну с конца — ничего не изменилось: в аутсорсе по-прежнему каждый отвечает за свои задачи. Конечно, в местах, где нам нужно встраиваться в клиентские процессы (особенно, с крупными корпоратами) стало немного сложнее — тяжело бегать за аутсорсными сисадминами или проходить по три ступени согласования на один макет, но мы пока справляемся.
Теперь отвечу на остальные вопросы.
> разработчик контролирует процесс QA и деплоя и людей, которые за них отвечают?
Да, разработчик сам контролирует процесс QA и деплоя. Конечно, хорошо бы этих процессов вообще не было — чтобы и деплой был автоматический, и QA происходил в фоне (и желательно без людей). В этом, кстати, ключевое отличие нашего аутсорса — у нас с Саматом хватает воли чинить такие проблемы у клиентов, чтобы программисты не страдали от релизных поездов или ручного тестирования.
> Что насчет интеграции фронтенд кода с бэкэндом?
В принципе, если команда взрослая и самостоятельная, можно вполне назначить двоих ответственных за одну задачу — они скорее всего договорятся. У нас, собственно, так и есть.
Когда в команде появляются менее ответственные ребята или джуны, нужно выбирать старшего: задачу может делать хоть 5 человек, но за результат отвечать будет только один из них. Упомянутый пост в таком случае работает как напоминалка: если в команде есть люди, которые не готовы брать ответственность, команда их отторгает. Руководитель в свою очередь помогает команде детектить безответственных ребят и избавляться от них.
> Продолжается ли ответственность до того, чтобы код правильно работал на проде?
Да. Я вообще не понимаю, почему может быть иначе. Ужасаюсь, когда даже в зрелых командах программисты этим грешат — радостно рапортуют, что задача решена, а на просьбу продемонстрировать результат лепечут что-то о следующем релизе и тестовом стенде.
Решённая задача — это работающий код на проде: мы к этому приучаем джунов с самого начала.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
P.S. Если вы питонист и хотите работать в зрелой команде — мы открыли набор.
Вроде смысл понятен: дать понять представление о границах ответственности разработчика и definition of done. Но как это работает на практике не очень ясно: разработчик контролирует процесс QA и деплоя и людей, которые за них отвечают? Сам тестирует или деплоит? Что насчет интеграции фронтенд кода с бэкэндом? Продолжается ли ответственность до того, чтобы код правильно работал на проде? Работает ли это по другому сейчас, когда у вас аутсорс разработка?
———
Начну с конца — ничего не изменилось: в аутсорсе по-прежнему каждый отвечает за свои задачи. Конечно, в местах, где нам нужно встраиваться в клиентские процессы (особенно, с крупными корпоратами) стало немного сложнее — тяжело бегать за аутсорсными сисадминами или проходить по три ступени согласования на один макет, но мы пока справляемся.
Теперь отвечу на остальные вопросы.
> разработчик контролирует процесс QA и деплоя и людей, которые за них отвечают?
Да, разработчик сам контролирует процесс QA и деплоя. Конечно, хорошо бы этих процессов вообще не было — чтобы и деплой был автоматический, и QA происходил в фоне (и желательно без людей). В этом, кстати, ключевое отличие нашего аутсорса — у нас с Саматом хватает воли чинить такие проблемы у клиентов, чтобы программисты не страдали от релизных поездов или ручного тестирования.
> Что насчет интеграции фронтенд кода с бэкэндом?
В принципе, если команда взрослая и самостоятельная, можно вполне назначить двоих ответственных за одну задачу — они скорее всего договорятся. У нас, собственно, так и есть.
Когда в команде появляются менее ответственные ребята или джуны, нужно выбирать старшего: задачу может делать хоть 5 человек, но за результат отвечать будет только один из них. Упомянутый пост в таком случае работает как напоминалка: если в команде есть люди, которые не готовы брать ответственность, команда их отторгает. Руководитель в свою очередь помогает команде детектить безответственных ребят и избавляться от них.
> Продолжается ли ответственность до того, чтобы код правильно работал на проде?
Да. Я вообще не понимаю, почему может быть иначе. Ужасаюсь, когда даже в зрелых командах программисты этим грешат — радостно рапортуют, что задача решена, а на просьбу продемонстрировать результат лепечут что-то о следующем релизе и тестовом стенде.
Решённая задача — это работающий код на проде: мы к этому приучаем джунов с самого начала.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
P.S. Если вы питонист и хотите работать в зрелой команде — мы открыли набор.
Почему я установил себе вацап
Я тут внезапно, после 9-летнего перерыва, купил себе автомобиль. Ради этого пришлось вернуться в тёмный мир дилеров, менеджеров и автомехаников, в котором за 8 лет ничего не поменялось — большинство встреченных людей по-прежнему не выполняют обещаний, ищут способы не делать свою работу или хотя бы взять за неё больше денег, чем она стоит. После уютной айтишечки с золотыми программистами и любимыми клиентами все встреченные в автомире люди мне кажутся обманщиками, недостойными профессии.
Помогает, как и раньше, лекарство из «Русской модели управления» — людям нужно создавать авралы. Грубо говоря, оставляешь машину в автосервисе на неделю и молча ждёшь — за эту неделю к ней даже не притронутся. А если объясняешь, что завтра тебе нужно на этой машине уезжать в Питер (лучше бы не врать, конечно), — время чудом находится. Пока доходчиво не объяснишь продавцу, что не готов покупать его товар по завышенной цене — тебе не скинут ни копейки. Как только объясняешь — магическим образом скидки согласовываются.
Я встречал руководителей, у которых умение создавать авралы — единственный прокачанный скилл. Буквально, других скиллов просто нет — чувак не умеет делегировать, планировать, писать. Умеет только заставлять всех вокруг напряжённо работать. Вряд ли компании с такими руководителями сделают что-то новое или значимое, но на жизнь, наверное, всем хватает.
Конечно, в идеальном бирюзовом мире начальники обслуживают сотрудников, но в реальном мире всё ещё существует куча красных мест, в которых это не так. Вряд ли это когда-нибудь изменится, поэтому я себе даже вацап установил, и расчехляю его, чтобы «быть на связи» и постоянно напоминать о себе. Помогает.
Я тут внезапно, после 9-летнего перерыва, купил себе автомобиль. Ради этого пришлось вернуться в тёмный мир дилеров, менеджеров и автомехаников, в котором за 8 лет ничего не поменялось — большинство встреченных людей по-прежнему не выполняют обещаний, ищут способы не делать свою работу или хотя бы взять за неё больше денег, чем она стоит. После уютной айтишечки с золотыми программистами и любимыми клиентами все встреченные в автомире люди мне кажутся обманщиками, недостойными профессии.
Помогает, как и раньше, лекарство из «Русской модели управления» — людям нужно создавать авралы. Грубо говоря, оставляешь машину в автосервисе на неделю и молча ждёшь — за эту неделю к ней даже не притронутся. А если объясняешь, что завтра тебе нужно на этой машине уезжать в Питер (лучше бы не врать, конечно), — время чудом находится. Пока доходчиво не объяснишь продавцу, что не готов покупать его товар по завышенной цене — тебе не скинут ни копейки. Как только объясняешь — магическим образом скидки согласовываются.
Я встречал руководителей, у которых умение создавать авралы — единственный прокачанный скилл. Буквально, других скиллов просто нет — чувак не умеет делегировать, планировать, писать. Умеет только заставлять всех вокруг напряжённо работать. Вряд ли компании с такими руководителями сделают что-то новое или значимое, но на жизнь, наверное, всем хватает.
Конечно, в идеальном бирюзовом мире начальники обслуживают сотрудников, но в реальном мире всё ещё существует куча красных мест, в которых это не так. Вряд ли это когда-нибудь изменится, поэтому я себе даже вацап установил, и расчехляю его, чтобы «быть на связи» и постоянно напоминать о себе. Помогает.
Писать роботов
Одно из ценнейших умений, которое я вынес из ГдеМатериала — это привычка писать небольших роботов, которые автоматизируют рутинную работу. В ГМ на этом был построен весь бизнес: собственно вся наша работа и состояла в том, чтобы автоматизировать стихийные процессы, которые сами себе построили чуваки вроде логистов или руководителей склада.
Роботов, в отличие от кожаных мешков, не нужно оформлять, с ними не нужно говорить, их не нужно организовывать. В бизнесе моей мечты люди вообще делают только творческую работу — придумывают продукты, рисуют, пишут код и текст. Вся остальная работа — на роботах.
В школе мы с Марьяной добились наибольшего успеха в написании роботов — нас в штате всего 3 человека на 5000 учеников. При этом наш замечательный администратор Зоя совсем недавно перешла на фултайм, и занимается далеко не рутинной работой.
Недавно сделали довольно очевидное улучшение в процессе работы с юрлицами. Дело в том, что всем клиентам, которые платят по безналу, нужно в конце каждого потока высылать закрывающие документы. Хоть у нас в стране и довольно прогрессивный ЭДО, огрехи ещё есть: к примеру нельзя просто так взять и отправить новому контрагенту документ — сначала его нужно «пригласить к обмену документами», дождаться ответа, и только после этого можно загружать документы — довольно тупо.
Мы сделали простого робота, который делает всего одну вещь — смотрит на все входящие оплаты и если видит, что это оплата от нового клиента — отправляет ему инвайт. Теперь к концу курса все инвайты уже приняты, и можно просто грузить документы. Как и большую часть нашего кода, выложили в паблик — забирайте, если у вас есть счёт в Тинькофф и работаете с Диадоком. API Диадока правда стоит 18к в год, но мы купили — хотим полностью избавиться от людей для большинства юрлиц.
Одно из ценнейших умений, которое я вынес из ГдеМатериала — это привычка писать небольших роботов, которые автоматизируют рутинную работу. В ГМ на этом был построен весь бизнес: собственно вся наша работа и состояла в том, чтобы автоматизировать стихийные процессы, которые сами себе построили чуваки вроде логистов или руководителей склада.
Роботов, в отличие от кожаных мешков, не нужно оформлять, с ними не нужно говорить, их не нужно организовывать. В бизнесе моей мечты люди вообще делают только творческую работу — придумывают продукты, рисуют, пишут код и текст. Вся остальная работа — на роботах.
В школе мы с Марьяной добились наибольшего успеха в написании роботов — нас в штате всего 3 человека на 5000 учеников. При этом наш замечательный администратор Зоя совсем недавно перешла на фултайм, и занимается далеко не рутинной работой.
Недавно сделали довольно очевидное улучшение в процессе работы с юрлицами. Дело в том, что всем клиентам, которые платят по безналу, нужно в конце каждого потока высылать закрывающие документы. Хоть у нас в стране и довольно прогрессивный ЭДО, огрехи ещё есть: к примеру нельзя просто так взять и отправить новому контрагенту документ — сначала его нужно «пригласить к обмену документами», дождаться ответа, и только после этого можно загружать документы — довольно тупо.
Мы сделали простого робота, который делает всего одну вещь — смотрит на все входящие оплаты и если видит, что это оплата от нового клиента — отправляет ему инвайт. Теперь к концу курса все инвайты уже приняты, и можно просто грузить документы. Как и большую часть нашего кода, выложили в паблик — забирайте, если у вас есть счёт в Тинькофф и работаете с Диадоком. API Диадока правда стоит 18к в год, но мы купили — хотим полностью избавиться от людей для большинства юрлиц.
FEDOR BORSHEV
Почему я установил себе вацап Я тут внезапно, после 9-летнего перерыва, купил себе автомобиль. Ради этого пришлось вернуться в тёмный мир дилеров, менеджеров и автомехаников, в котором за 8 лет ничего не поменялось — большинство встреченных людей по-прежнему…
Ещё немножко про авралы
Кстати, подтверждение мыслям из «Русской Модели Управления» о том, что люди не работают без авралов, я встречал в совершенно разных местах.
Вот, к примеру про крестьян до революции, у Акунина:
«Полевые работы в основном приходились на три напряженных, но довольно коротких периода: посев, покос, сбор урожая. В остальное время года, особенно зимой, наступал период затишья. Ключевский пишет: «Так великоросс приучался к чрезмерному кратковременному напряжению сил, привыкал работать скоро, лихорадочно и споро, а потом отдыхать в продолжение вынужденного осеннего и зимнего безделья. Ни один народ в Европе не способен к такому напряжению труда на короткое время, какое может развить великоросс; но и нигде в Европе, кажется, не найдем такой непривычки к ровному, умеренному и размеренному, постоянному труду, как в той же Великороссии»
Такой же крестьянский подход прививают традиционные ВУЗы: большую часть времени студент, особенно на старших курсах, бездельничает, чтобы во время сессии напрячься, прочитать все книги за ночь и кое-как сдать экзамен.
Я против авралов: даже если отбросить чисто человеческие чувства о том, что загонять людей в авралы — это унижение. Авралы плохо влияют на качество кода. Команда с ровной и спокойной нагрузкой без давления практически сразу даёт гораздо более короткий time2market, чем нагруженная и авральная.
Так что давайте не считать программистов крестьянами и студентами — скорее это марафонцы или рабочие на пятилетнем долгострое.
Кстати, подтверждение мыслям из «Русской Модели Управления» о том, что люди не работают без авралов, я встречал в совершенно разных местах.
Вот, к примеру про крестьян до революции, у Акунина:
«Полевые работы в основном приходились на три напряженных, но довольно коротких периода: посев, покос, сбор урожая. В остальное время года, особенно зимой, наступал период затишья. Ключевский пишет: «Так великоросс приучался к чрезмерному кратковременному напряжению сил, привыкал работать скоро, лихорадочно и споро, а потом отдыхать в продолжение вынужденного осеннего и зимнего безделья. Ни один народ в Европе не способен к такому напряжению труда на короткое время, какое может развить великоросс; но и нигде в Европе, кажется, не найдем такой непривычки к ровному, умеренному и размеренному, постоянному труду, как в той же Великороссии»
Такой же крестьянский подход прививают традиционные ВУЗы: большую часть времени студент, особенно на старших курсах, бездельничает, чтобы во время сессии напрячься, прочитать все книги за ночь и кое-как сдать экзамен.
Я против авралов: даже если отбросить чисто человеческие чувства о том, что загонять людей в авралы — это унижение. Авралы плохо влияют на качество кода. Команда с ровной и спокойной нагрузкой без давления практически сразу даёт гораздо более короткий time2market, чем нагруженная и авральная.
Так что давайте не считать программистов крестьянами и студентами — скорее это марафонцы или рабочие на пятилетнем долгострое.
Вечное преимущество того, кто не делает
Бывает такое — получаешь на код-ревью десятое замечание подряд и злишься на себя, типа нифига не шаришь. Вот ревьюер — крутой чел: вон сколько полезных замечаний даёт.
Такое бывает во всех сферах — когда ведёшь машину с инструктором, показываешь свежий текст напарнику, сдаёшь дизайн арт-директору. И всегда легко на себя разозлиться, особенно когда замечания справедливые — ну как же так, почему все понимают лучше меня.
Чтобы с этим справиться, мне помогает осознать, что у человека, который не делает, всегда есть нечестное преимущество — взгляд со стороны. Ревьюер не участвовал в работе: код, над которым ты страдал три дня, он увидел в первый раз — и конечно свежим взглядом ему легко находить проблемы. И конечно он не попадал в ловушку overthinking, когда три дня не думал над задачей.
Ты и сам с такой же лёгкостью будешь искать проблемы, если отложишь код\текст\дизайн на 3 дня и посмотришь заново.
Когда я даю десяток замечаний на один пулл-реквест, это не значит, что я какой-то супер-выдающийся программист: я просто смотрю свежим взглядом. И если нас с автором ПР поменять местами — далеко не факт, что я получу от него меньше замечаний, чем он от меня.
Бывает такое — получаешь на код-ревью десятое замечание подряд и злишься на себя, типа нифига не шаришь. Вот ревьюер — крутой чел: вон сколько полезных замечаний даёт.
Такое бывает во всех сферах — когда ведёшь машину с инструктором, показываешь свежий текст напарнику, сдаёшь дизайн арт-директору. И всегда легко на себя разозлиться, особенно когда замечания справедливые — ну как же так, почему все понимают лучше меня.
Чтобы с этим справиться, мне помогает осознать, что у человека, который не делает, всегда есть нечестное преимущество — взгляд со стороны. Ревьюер не участвовал в работе: код, над которым ты страдал три дня, он увидел в первый раз — и конечно свежим взглядом ему легко находить проблемы. И конечно он не попадал в ловушку overthinking, когда три дня не думал над задачей.
Ты и сам с такой же лёгкостью будешь искать проблемы, если отложишь код\текст\дизайн на 3 дня и посмотришь заново.
Когда я даю десяток замечаний на один пулл-реквест, это не значит, что я какой-то супер-выдающийся программист: я просто смотрю свежим взглядом. И если нас с автором ПР поменять местами — далеко не факт, что я получу от него меньше замечаний, чем он от меня.
Косвенные расходы на встречи
Пустые встречи жрут ресурсы: календарное время и внимание, вырывая программистов из состояния потока. Это все знают и давно научились экономить, кто как может: назначают встречи покороче, ставят их впритык. Но кроме прямых расходов времени есть ещё и косвенные расходы — затраты внимания.
Для себя я называю это «календарь давит». Когда у меня в день назначено две встречи — одна на 14:00, другая, скажем на 18:00 — время между этими встречами я проведу в гораздо более неспокойном состоянии, чем обычно: не начну сложных задач (нафига, потом всё равно из потока вырвут); не уйду гулять (вдруг пробки, опоздаю!). Даже одна встреча в день уже сто́ит мне внимания и ухудшает концентрацию.
Чтобы календарь не давил, я делаю две вещи:
— Уменьшаю количество ad-hoc встреч. Вместо «давай созвонимся и обсудим» я назначаю регулярные встречи с теми, с кем часто созваниваюсь.
— Группирую такие встречи по дням. У меня это вторники и четверги.
Это позволяет мне иметь «дни встреч», в которые я занимаюсь только разговорами и разрешаю себе не делать ничего другого.
В школе у нас с Марьяной почти нет ad-hoc встреч — есть одна регулярка в неделю. В сложные периоды, к примеру когда готовим новые курсы — делаем две. В тихие периоды бывает отменяем регулярку и не разговариваем по две недели. В аутсорсе у меня вообще нет нерегулярных встреч с руководителями проектов: вместо этого я встречаюсь с ними раз в неделю, а с кем-то — и раз в две. Это позволяет мне поддерживать голову в чистоте и иметь дни, в которые я могу спокойно погулять\подумать или весь день потратить на потоковую работу.
О расходах на встречи и чаты, психологических причинах провала сложных встреч и способах максимально простого ведения коммуникации говорим на курсе «Есть минутка». В курсе 3 письма — одно теоретическое (эмоции, особенности восприятия) и два практических — о чатах и про встречах. Приходите до 1 февраля: тариф «закрытый клуб» с чатом и Q&A-сессиями мы продаём только сейчас, потом его не будет.
Смотреть программу →
Пустые встречи жрут ресурсы: календарное время и внимание, вырывая программистов из состояния потока. Это все знают и давно научились экономить, кто как может: назначают встречи покороче, ставят их впритык. Но кроме прямых расходов времени есть ещё и косвенные расходы — затраты внимания.
Для себя я называю это «календарь давит». Когда у меня в день назначено две встречи — одна на 14:00, другая, скажем на 18:00 — время между этими встречами я проведу в гораздо более неспокойном состоянии, чем обычно: не начну сложных задач (нафига, потом всё равно из потока вырвут); не уйду гулять (вдруг пробки, опоздаю!). Даже одна встреча в день уже сто́ит мне внимания и ухудшает концентрацию.
Чтобы календарь не давил, я делаю две вещи:
— Уменьшаю количество ad-hoc встреч. Вместо «давай созвонимся и обсудим» я назначаю регулярные встречи с теми, с кем часто созваниваюсь.
— Группирую такие встречи по дням. У меня это вторники и четверги.
Это позволяет мне иметь «дни встреч», в которые я занимаюсь только разговорами и разрешаю себе не делать ничего другого.
В школе у нас с Марьяной почти нет ad-hoc встреч — есть одна регулярка в неделю. В сложные периоды, к примеру когда готовим новые курсы — делаем две. В тихие периоды бывает отменяем регулярку и не разговариваем по две недели. В аутсорсе у меня вообще нет нерегулярных встреч с руководителями проектов: вместо этого я встречаюсь с ними раз в неделю, а с кем-то — и раз в две. Это позволяет мне поддерживать голову в чистоте и иметь дни, в которые я могу спокойно погулять\подумать или весь день потратить на потоковую работу.
О расходах на встречи и чаты, психологических причинах провала сложных встреч и способах максимально простого ведения коммуникации говорим на курсе «Есть минутка». В курсе 3 письма — одно теоретическое (эмоции, особенности восприятия) и два практических — о чатах и про встречах. Приходите до 1 февраля: тариф «закрытый клуб» с чатом и Q&A-сессиями мы продаём только сейчас, потом его не будет.
Смотреть программу →
Ночные рейсы
Одна из привычек, которая появилась у меня после 30 лет — не покупать ночные рейсы.
Идея ночных рейсов — довольно привлекательная: ты экономишь деньги, вылетая в 03:45, а аэропорт получает чуть более ровную загрузку. Но это же глупость! Во-первых, время — я, как дисциплинированный пассажир, приезжаю в аэропорт за два часа до вылета. Днём я трачу свободное время в аэропорте на работу — просто открываю ноутбук и делаю накопившиеся дела. В час ночи, я так сделать, увы, не могу — голова не работает.
Во-вторых — внимание к цели маршрута. После ночного перелёта всё, что хочет нормальный человек — это отоспаться. Получается, что если я лечу в отпуск, то отпуск должен быть на один день больше. Если лечу по делам — дела занимают на один «отсыпной» день больше. А я мог бы потратить этот день на что-нибудь полезное — хорошо отдохнуть и поработать.
Вряд ли разница в стоимости билетов (пусть она будет хоть 30%) стоит больше, чем деньги, которые я могу заработать за счёт того, что не перехожу в состояние сонной коровы.
Одна из привычек, которая появилась у меня после 30 лет — не покупать ночные рейсы.
Идея ночных рейсов — довольно привлекательная: ты экономишь деньги, вылетая в 03:45, а аэропорт получает чуть более ровную загрузку. Но это же глупость! Во-первых, время — я, как дисциплинированный пассажир, приезжаю в аэропорт за два часа до вылета. Днём я трачу свободное время в аэропорте на работу — просто открываю ноутбук и делаю накопившиеся дела. В час ночи, я так сделать, увы, не могу — голова не работает.
Во-вторых — внимание к цели маршрута. После ночного перелёта всё, что хочет нормальный человек — это отоспаться. Получается, что если я лечу в отпуск, то отпуск должен быть на один день больше. Если лечу по делам — дела занимают на один «отсыпной» день больше. А я мог бы потратить этот день на что-нибудь полезное — хорошо отдохнуть и поработать.
Вряд ли разница в стоимости билетов (пусть она будет хоть 30%) стоит больше, чем деньги, которые я могу заработать за счёт того, что не перехожу в состояние сонной коровы.
Марьяна у себя рассказала о первом письме курса.
Когда я работал над программой, представлял в голове собирательный образ из всех программистов, которых встретил за последние пару лет — и из нашей команды, и встреченных в консалтинге. И задаю себе вопрос — о чём бы мне хотелось им рассказать, чтобы облегчить их жизнь?
В очередной раз поняв, что большинство проблем — в голове, для первого письма мы с Марьяной пригласили Ирину Парфёнову, которая рабоатала с нами на курсе «Самому не проще». И вот что получается:
Когда я работал над программой, представлял в голове собирательный образ из всех программистов, которых встретил за последние пару лет — и из нашей команды, и встреченных в консалтинге. И задаю себе вопрос — о чём бы мне хотелось им рассказать, чтобы облегчить их жизнь?
В очередной раз поняв, что большинство проблем — в голове, для первого письма мы с Марьяной пригласили Ирину Парфёнову, которая рабоатала с нами на курсе «Самому не проще». И вот что получается:
Forwarded from Продукты, книги и любовь
Первый лонгрид «Есть минутка»: что вошло и ласт-колл в «Закрытый клуб»
Мы на финишной прямой с первым лонгридом «Есть минутка». Переписывали его втроем с нуля 4 раза. И еще не знаю сколько раз по кускам. Да и кого я обманываю — будем подкручивать пока не отправим. Собрались одни перфекционисты.
В один момент Ира Парфенова написала мне «Марьяна, надо созвониться, потому что мне кажется, что я книгу пишу, настолько он объемный». Я думала, что она шутит, но потом когда начала читать — подумала, что правда похоже на книгу. Как оказалось, это она только треть написала.
Нам важно, чтобы в лонгриде была концентрация пользы, ни на что не отвлекаться. Только читать и применять. Поэтому пришлось перебрать несколько вариантов подачи. В итоге пришли к простой форме сборника проблем-решений. Мне нравится, что можно прыгать сразу на нужную тему и не читать целиком, если в моменте нет потребности. Полностью отвечает нашему запросу «курс-аптечка». Бери только то, что нужно.
Всего получилось 6 ключевых проблем:
— Мы друг друга не понимаем. Причины: 1/ разные ожидания и вводные, 2/ разговор на разных уровнях коммуникации. Упоминаем модель 5 уровней коммуникации Джона Пауэла и учимся фиксировать и проговаривать ожидания.
— Мне сложно из-за непредсказуемости поступков людей. Причина: не понимаем свои и чужие эмоции и чувства. Учимся распознавать эмоции по модели Плутчика и привываем привычку не задавливать эмоции и выражать их, даже негативные. Как тоже рассказываем.
— Меня часто продавливают. Причина — личные границы: либо не определили, либо не умеете отстаивать. Даем инструкцию и шаблон как выстраивать личные границы и защищать их. Спойлер: сначала нужно разобраться со своими потребностями. Опираемся на книгу «Сила личных границ» Шэрон Мартин.
— Конфликты: часто избегаю и нападаю, когда уже нет сил терпеть. Причина: конфликт — это следствие того, что что-то не так с коммуникациями. Это либо слова тригеры либо вышеперечисленные проблемы. Учимся не бояться конфликтов и не чувствовать вину после. Разбираем круг конфликта Кристофера Мура и матрицу стратегий поведения в конфликте Томаса-Килмена.
— Мне сложно просить и говорить на неудобные темы, например о зарплате. Причина: страх оценки. Разбираем структуру неудобных разговоров и даем алгоритм действий, чтобы было не страшно просить.
— Я делаю работу на отлично, но этого никто не замечает. Причина: не умение рассказывать о своей работе. Разберём причину страха, последствия советского воспитания и расскажем о принципе «Покажи свою работу» Остина Клеона.
Этот лонгрид мы пришлем вам 1 февраля, остальные два с ритмом раз в неделю. А в этот четверг позовем в чатик участников Закрытого клуба (так называется один из тарифов), где будем знакомиться, обсуждать ваши проблемы, чтобы успеть скорректировать контент под вас. В процессе же обучения в чате будем отвечать на вопросы и делиться обратной связью. А в конце — устроим Q&A-сессию, чтобы обсудить то, что сложно было вынести в чат.
Этот тариф мы придумали, чтобы делать курс в диалоге с вами. Он же про коммуникацию, как не крути. Правда продается закрытый клуб только до 1 февраля. После мы закроем его и больше никогда не откроем для покупки. Поэтому если хотели получить обратную связь и повлиять на контент курса — велкам. Осталось меньше недели.
Тариф Аптечка и Юрик будут продаваться и позже, но скорее всего поднимем ценник, потому что пользы получается намного больше, чем мы планировали изначально.
Записаться →
Мы на финишной прямой с первым лонгридом «Есть минутка». Переписывали его втроем с нуля 4 раза. И еще не знаю сколько раз по кускам. Да и кого я обманываю — будем подкручивать пока не отправим. Собрались одни перфекционисты.
В один момент Ира Парфенова написала мне «Марьяна, надо созвониться, потому что мне кажется, что я книгу пишу, настолько он объемный». Я думала, что она шутит, но потом когда начала читать — подумала, что правда похоже на книгу. Как оказалось, это она только треть написала.
Нам важно, чтобы в лонгриде была концентрация пользы, ни на что не отвлекаться. Только читать и применять. Поэтому пришлось перебрать несколько вариантов подачи. В итоге пришли к простой форме сборника проблем-решений. Мне нравится, что можно прыгать сразу на нужную тему и не читать целиком, если в моменте нет потребности. Полностью отвечает нашему запросу «курс-аптечка». Бери только то, что нужно.
Всего получилось 6 ключевых проблем:
— Мы друг друга не понимаем. Причины: 1/ разные ожидания и вводные, 2/ разговор на разных уровнях коммуникации. Упоминаем модель 5 уровней коммуникации Джона Пауэла и учимся фиксировать и проговаривать ожидания.
— Мне сложно из-за непредсказуемости поступков людей. Причина: не понимаем свои и чужие эмоции и чувства. Учимся распознавать эмоции по модели Плутчика и привываем привычку не задавливать эмоции и выражать их, даже негативные. Как тоже рассказываем.
— Меня часто продавливают. Причина — личные границы: либо не определили, либо не умеете отстаивать. Даем инструкцию и шаблон как выстраивать личные границы и защищать их. Спойлер: сначала нужно разобраться со своими потребностями. Опираемся на книгу «Сила личных границ» Шэрон Мартин.
— Конфликты: часто избегаю и нападаю, когда уже нет сил терпеть. Причина: конфликт — это следствие того, что что-то не так с коммуникациями. Это либо слова тригеры либо вышеперечисленные проблемы. Учимся не бояться конфликтов и не чувствовать вину после. Разбираем круг конфликта Кристофера Мура и матрицу стратегий поведения в конфликте Томаса-Килмена.
— Мне сложно просить и говорить на неудобные темы, например о зарплате. Причина: страх оценки. Разбираем структуру неудобных разговоров и даем алгоритм действий, чтобы было не страшно просить.
— Я делаю работу на отлично, но этого никто не замечает. Причина: не умение рассказывать о своей работе. Разберём причину страха, последствия советского воспитания и расскажем о принципе «Покажи свою работу» Остина Клеона.
Этот лонгрид мы пришлем вам 1 февраля, остальные два с ритмом раз в неделю. А в этот четверг позовем в чатик участников Закрытого клуба (так называется один из тарифов), где будем знакомиться, обсуждать ваши проблемы, чтобы успеть скорректировать контент под вас. В процессе же обучения в чате будем отвечать на вопросы и делиться обратной связью. А в конце — устроим Q&A-сессию, чтобы обсудить то, что сложно было вынести в чат.
Этот тариф мы придумали, чтобы делать курс в диалоге с вами. Он же про коммуникацию, как не крути. Правда продается закрытый клуб только до 1 февраля. После мы закроем его и больше никогда не откроем для покупки. Поэтому если хотели получить обратную связь и повлиять на контент курса — велкам. Осталось меньше недели.
Тариф Аптечка и Юрик будут продаваться и позже, но скорее всего поднимем ценник, потому что пользы получается намного больше, чем мы планировали изначально.
Записаться →