Писать мало кода — это софтскилл
В перерывах между крупными проектами наши программисты обычно делают мелкие задачки для компании и клиентов: рефакторят старый код или настраивают мелкие интеграции, что сэкономить время на рутине. Обычно в таких проектах мы даём полную свободу — можно выбрать любую технологию и любой подход. Недавно на двух таких проектах одновременно заметил тенденцию к оверижинирингу: типа затащить 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 февраля. После мы закроем его и больше никогда не откроем для покупки. Поэтому если хотели получить обратную связь и повлиять на контент курса — велкам. Осталось меньше недели.
Тариф Аптечка и Юрик будут продаваться и позже, но скорее всего поднимем ценник, потому что пользы получается намного больше, чем мы планировали изначально.
Записаться →
#вопрос Возник вопрос философского характера: надо ли разработчику/тимлиду прям знать досконально язык программирования?
Меня часто мучает синдром самозванца, что я вроде что-то умею, а посади меня без интернета и ощущение, что я ничего не могу написать. Хотя вроде бы продукты делаются, работа ведется, клиенты довольны.
Я в основном работаю на питоне и, например, в pandas я знаю как она работает и что где искать, но на вскидку, с листа группировку с аггрегацией скорее всего не напишу. При этом это не вызывает какого-то рабочего дискомфорта. Скорее психологический.
———————
Ну, даже если вы напишете код без интернета, вряд ли вы сможете без интернета его задеплоить :-)
А если серьёзно — у вас всё отлично. Для тимлидской роли софтскиллы гораздо нужнее — лучше уметь планировать проекты, организовывать работу и договариваться с людьми, чем знать как ковариантность отличается от инвариантности в типизации динамических языков.
Для разработчика — тоже: широкий кругозор гораздо важнее глубоких знаний. Представьте, что вы досконально знаете какие-нибудь asyncio.queues из стандартной библиотеки питона, но не понимаете, чем распределённый лог отличается от распределённой очереди, и вообще ничего знаете про типизацию событий в асинхронных системах. Если действительно, не сажать людей кодить без интернета, то код программиста, знакомого с асинхронными системами в целом, будет гораздо лучше для бизнеса, чем код программиста, идеально знающего одну из реализаций.
В эмоциональном плане я разделяю вашу тревогу. Сам уже пару лет не писал фронтенд, и чувствую себя неуютно, глядя как наши ребята размахивают новыми тулзами вроде vite, pinia (да и composition API, что уж там говорить). Успокаиваю себя тем, что моя роль в компании — совсем другая: найти человека, который знает современный фронт гораздо легче, чем человека, который может отвечать за целый бизнес сразу, включая финпланирование и работу с госорганами.
Если паритесь по поводу своих знаний — попробуйте расписать на бумаге свои обязанности в компании. Вряд ли у вас получится много связанного с доскональным знанием ЯП, но вангую, что найдёте как минимум 2–3 пункта, которые кроме вас не может сделать вообще никто.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Меня часто мучает синдром самозванца, что я вроде что-то умею, а посади меня без интернета и ощущение, что я ничего не могу написать. Хотя вроде бы продукты делаются, работа ведется, клиенты довольны.
Я в основном работаю на питоне и, например, в pandas я знаю как она работает и что где искать, но на вскидку, с листа группировку с аггрегацией скорее всего не напишу. При этом это не вызывает какого-то рабочего дискомфорта. Скорее психологический.
———————
Ну, даже если вы напишете код без интернета, вряд ли вы сможете без интернета его задеплоить :-)
А если серьёзно — у вас всё отлично. Для тимлидской роли софтскиллы гораздо нужнее — лучше уметь планировать проекты, организовывать работу и договариваться с людьми, чем знать как ковариантность отличается от инвариантности в типизации динамических языков.
Для разработчика — тоже: широкий кругозор гораздо важнее глубоких знаний. Представьте, что вы досконально знаете какие-нибудь asyncio.queues из стандартной библиотеки питона, но не понимаете, чем распределённый лог отличается от распределённой очереди, и вообще ничего знаете про типизацию событий в асинхронных системах. Если действительно, не сажать людей кодить без интернета, то код программиста, знакомого с асинхронными системами в целом, будет гораздо лучше для бизнеса, чем код программиста, идеально знающего одну из реализаций.
В эмоциональном плане я разделяю вашу тревогу. Сам уже пару лет не писал фронтенд, и чувствую себя неуютно, глядя как наши ребята размахивают новыми тулзами вроде vite, pinia (да и composition API, что уж там говорить). Успокаиваю себя тем, что моя роль в компании — совсем другая: найти человека, который знает современный фронт гораздо легче, чем человека, который может отвечать за целый бизнес сразу, включая финпланирование и работу с госорганами.
Если паритесь по поводу своих знаний — попробуйте расписать на бумаге свои обязанности в компании. Вряд ли у вас получится много связанного с доскональным знанием ЯП, но вангую, что найдёте как минимум 2–3 пункта, которые кроме вас не может сделать вообще никто.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Преимущество интровертов в коммуникации
Где-то слышал теорию, что стеснительным замкнутым интровертам в конечном счёте общение с людьми даётся легче, чем общительным экстравертам.
Идея в том, что экстраверты с детства умеют считывать движения тела, мимимку и интонацию — для них это такой же естественный навык, как жевать или ходить пешком. А интровертам приходится постигать всё это вручную: наблюдать, какое поведение за какой мимикой следует, как настроение у людей меняется в зависимости от внешних воздействий. Верю в это потому, что у меня происходит именно так — умение понимать эмоции людей пришло только с возрастом, тренировкой и психтерапией.
Получается, что интроверты умеют прокачивать эмпатию, а экстравертам — столько эмпатии дано, столько и останется: не будете же вы учиться точнее жевать или ходить, если уже делаете это на достаточном уровне.
Среди программистов очень много интровертов, и мне давно хотелось помочь им стать более общительными — чем лучше программист ведёт коммуникацию, тем более полезен он для бизнеса, да и для человечества в целом: быстрее закрывает задачи, пишет более релевантный бизнесу код, проще организует коллег. Самая свежа наша с Марьяной работа на эту тему — курс «Есть минутка», в котором целая неделя посвящена проблемам с коммуникацией (см. выше).
Это я всё к тому, что сегодня — последний день, чтобы запрыгнуть в групповой тариф и попасть в чат людей с такими же проблемами/задачами. С завтрашнего дня можно будет купить только самостоятельный тариф.
Где-то слышал теорию, что стеснительным замкнутым интровертам в конечном счёте общение с людьми даётся легче, чем общительным экстравертам.
Идея в том, что экстраверты с детства умеют считывать движения тела, мимимку и интонацию — для них это такой же естественный навык, как жевать или ходить пешком. А интровертам приходится постигать всё это вручную: наблюдать, какое поведение за какой мимикой следует, как настроение у людей меняется в зависимости от внешних воздействий. Верю в это потому, что у меня происходит именно так — умение понимать эмоции людей пришло только с возрастом, тренировкой и психтерапией.
Получается, что интроверты умеют прокачивать эмпатию, а экстравертам — столько эмпатии дано, столько и останется: не будете же вы учиться точнее жевать или ходить, если уже делаете это на достаточном уровне.
Среди программистов очень много интровертов, и мне давно хотелось помочь им стать более общительными — чем лучше программист ведёт коммуникацию, тем более полезен он для бизнеса, да и для человечества в целом: быстрее закрывает задачи, пишет более релевантный бизнесу код, проще организует коллег. Самая свежа наша с Марьяной работа на эту тему — курс «Есть минутка», в котором целая неделя посвящена проблемам с коммуникацией (см. выше).
Это я всё к тому, что сегодня — последний день, чтобы запрыгнуть в групповой тариф и попасть в чат людей с такими же проблемами/задачами. С завтрашнего дня можно будет купить только самостоятельный тариф.
Сейф Бекап
Мы с Саматом запустили новый сервис для мониторинга бекапов — safe-backup.ru.
Это такая замена healthchecks.io для тех, у кого серверы стоят в России. Сервис работает по принципу мёртвой руки: скрипт бекапа периодически уведомляет нас, что всё хорошо, а если уведомления перестают приходить — мы присылаем алёрт.
Такая система позволяет с большой вероятностью отловить типичные ошибки: пропало соединение с хранилищем бекапов, закончилось место на диске, сменились креденшелы доступа к базе, — всё это ведёт к тому, что скрипт бекапа не дорабатывает, а значит не присылает нам уведомление.
Пока автор оригинального сервиса не сошёл с ума, я использовал его во всех своих системах, адаптировав несколько опенсорс-решений — для PostgreSQL или для файлов на диске. Сейчас везде, включая borg, я просто поменял адреса вебхуков — сервисы совместимы на уровне API.
Конечно, по дороге мы решили несколько косяков оригинала — к примеру сделали удобные уведомления через телеграм.
Приходите на бета-тестирование — в течение первого месяца можно добавлять неограниченное число сервисов и уведомлений. Скоро добавим уведомления по СМС и оплату картами или по безналичному расчёту.
UPD: Сервис закрыт, пользуйтесь uptimerobot.com (нужна зарубежная карта)
Мы с Саматом запустили новый сервис для мониторинга бекапов — safe-backup.ru.
Это такая замена healthchecks.io для тех, у кого серверы стоят в России. Сервис работает по принципу мёртвой руки: скрипт бекапа периодически уведомляет нас, что всё хорошо, а если уведомления перестают приходить — мы присылаем алёрт.
Такая система позволяет с большой вероятностью отловить типичные ошибки: пропало соединение с хранилищем бекапов, закончилось место на диске, сменились креденшелы доступа к базе, — всё это ведёт к тому, что скрипт бекапа не дорабатывает, а значит не присылает нам уведомление.
Пока автор оригинального сервиса не сошёл с ума, я использовал его во всех своих системах, адаптировав несколько опенсорс-решений — для PostgreSQL или для файлов на диске. Сейчас везде, включая borg, я просто поменял адреса вебхуков — сервисы совместимы на уровне API.
Конечно, по дороге мы решили несколько косяков оригинала — к примеру сделали удобные уведомления через телеграм.
Приходите на бета-тестирование — в течение первого месяца можно добавлять неограниченное число сервисов и уведомлений. Скоро добавим уведомления по СМС и оплату картами или по безналичному расчёту.
UPD: Сервис закрыт, пользуйтесь uptimerobot.com (нужна зарубежная карта)
Друзья, я знаю что среди вас здесь много тех, кто руководит программистами. Помогите пожалуйста хорошим людям с исследованием — пройдите небольшой опрос.
Там что-то вроде что-то разыгрывают среди ответивших, но наверное можно сделать и просто так.
Там что-то вроде что-то разыгрывают среди ответивших, но наверное можно сделать и просто так.
Как я могу сделать себе интересно?
Бывает нужно сделать задачу, а она — ну вот совсем скучная: досконально знаешь технологию, представляешь все подводные камни, знаешь даже как лучше поговорить с бизнесом, чтобы задача не раздувалась. Я обычно в таких ситуациях чувствую отвращение — кажется, что трачу свою жизнь на что-то неважное.
Такое бывает не только на работе — дома тоже нужно делать скучные линейные бытовые дела.
Самый хороший способ справиться с этим — сделать себе интересно. Если мне нужно в пятый раз написать похожий плейбук в Ansible — я не стану монотонно повторять работу, а изучу новую тулзу вроде mitogen или придумаю какую-нибудь элегантную автозамену для новых правил ansible-lint. Если надо помыть посуду — можно придумать, какой подкаст послушать. Чтобы не скучать при уборке — посидеть и повыбирать самый подходящий в мире пылесос, чтобы его использование всегда приносило радость.
Буквально — задаём себе вопрос: «а как я могу сделать эту работу для себя интереснее?». Главное — не перестараться: на работе мы всё-таки находимся не чтобы нам было интересно, а чтобы решать задачи работодателя. Но если дать себе правильную дозу интереса — задачи решаются гораздо быстрее и лучше.
Бывает нужно сделать задачу, а она — ну вот совсем скучная: досконально знаешь технологию, представляешь все подводные камни, знаешь даже как лучше поговорить с бизнесом, чтобы задача не раздувалась. Я обычно в таких ситуациях чувствую отвращение — кажется, что трачу свою жизнь на что-то неважное.
Такое бывает не только на работе — дома тоже нужно делать скучные линейные бытовые дела.
Самый хороший способ справиться с этим — сделать себе интересно. Если мне нужно в пятый раз написать похожий плейбук в Ansible — я не стану монотонно повторять работу, а изучу новую тулзу вроде mitogen или придумаю какую-нибудь элегантную автозамену для новых правил ansible-lint. Если надо помыть посуду — можно придумать, какой подкаст послушать. Чтобы не скучать при уборке — посидеть и повыбирать самый подходящий в мире пылесос, чтобы его использование всегда приносило радость.
Буквально — задаём себе вопрос: «а как я могу сделать эту работу для себя интереснее?». Главное — не перестараться: на работе мы всё-таки находимся не чтобы нам было интересно, а чтобы решать задачи работодателя. Но если дать себе правильную дозу интереса — задачи решаются гораздо быстрее и лучше.
Школа: запустили новую LMS
Когда мы только запускались, студенты читали материалы из писем со ссылками на Notion — всем было норм. Потом собрали на коленке LMS — рендерили те же материалы из ноушена, но уже с профилем студента (для диплома), минимальной навигацией и кнопочкой сапорта, чтобы можно было задать нам вопрос.
Та, первая LMS, была одним из самых стыдных моих проектов с точки зрения программирования — хреновый код без тестов, хреновая вёрстка. Серьёзно — отдавая код нашему программисту Тимуру я переживал, что потеряю авторитет как руководитель компании. Теперь про старое позорище можно забыть — материалы красиво рендерятся на всех платформах, со светлой и тёмной темой, код покрыт тестами и сделан на совесть.
Пока проект был в разработке, для меня он был одним из многих в «Феде и Самате» — я просто следил как идут дела и иногда помогал Тимуру договориться с Марьяной. Когда проект закончился, и из техдира я прерватился в счастливого заказчика — я осознал, насколько школе повезло: вряд ли при наших размерах мы могли бы себе позволить полноценный отдел разработки. А аутсорс по себестоимости — вполне смогли.
Если покупали у нас курсы последние полтора года — найдёте всё в lms.tough-dev.school. Код, как и все проекты школы, — в нашем гитхабе.
Технологии: vue3, pinia, vitest, playwright.
Разработчик: Тимур Брачков.
Когда мы только запускались, студенты читали материалы из писем со ссылками на Notion — всем было норм. Потом собрали на коленке LMS — рендерили те же материалы из ноушена, но уже с профилем студента (для диплома), минимальной навигацией и кнопочкой сапорта, чтобы можно было задать нам вопрос.
Та, первая LMS, была одним из самых стыдных моих проектов с точки зрения программирования — хреновый код без тестов, хреновая вёрстка. Серьёзно — отдавая код нашему программисту Тимуру я переживал, что потеряю авторитет как руководитель компании. Теперь про старое позорище можно забыть — материалы красиво рендерятся на всех платформах, со светлой и тёмной темой, код покрыт тестами и сделан на совесть.
Пока проект был в разработке, для меня он был одним из многих в «Феде и Самате» — я просто следил как идут дела и иногда помогал Тимуру договориться с Марьяной. Когда проект закончился, и из техдира я прерватился в счастливого заказчика — я осознал, насколько школе повезло: вряд ли при наших размерах мы могли бы себе позволить полноценный отдел разработки. А аутсорс по себестоимости — вполне смогли.
Если покупали у нас курсы последние полтора года — найдёте всё в lms.tough-dev.school. Код, как и все проекты школы, — в нашем гитхабе.
Технологии: vue3, pinia, vitest, playwright.
Разработчик: Тимур Брачков.
За последние 4 года я глубоко погружался в работу двух десятков команд: говорил с бизнесом, тимлидами и программистами, анализировал проблемы, что-то менял. Где-то получалось успешно, где-то — не очень, но что я точно приобрёл за это время — это насмотренность и умение отличать настроенные команды от разболтанных.
Для бизнеса настроенная команда выглядит почти как конвейер: ставишь задачу, получаешь сроки. В течение этих сроков тебе прозрачно рассказывают, что происходит и заранее предупреждают, если что-то идёт не так. Даже если сроки смещаются — в конце ты получаешь результат с предсказуемым качеством. Разболтанная команда похожа на фрилансера: с лёгкостью принимает задачи, обещает сделать до завтра, а потом у неё заболевает бабушка и команда сдаёт говно или просто пропадает.
О разнице в устройстве настроенных и назболтанных команд можно говорить бесконечно — тут и техдолг, и контроль ритма, и инженерная культура. Но если бы мне нужно было отличить настроенную команду от разболтанный, задав всего один вопрос — я спросил бы как у них дела с тестами.
Тесты говорят одновременно и о качестве кода (без тестов легче писать лапшу), и об уровне планирования (у плохого руководства тесты первом делом летят под нож). Но самое главное, что гарантируют тесты — предсказуемость. Когда один человек пишет код, а работоспособность его решения проверяет другой — у команды нет однозначного индикатора, что задача решена: он повисает где-то а коммуникации между этими двумя людьми. Другое дело — зелёная галочка в гитхабе: запушил код и сразу видишь, насколько он работает. Больше не возьмёшься за новые задачи, не закончив старые — а значит не будешь переключать контексты и (в очередной раз) обманывать бизнес.
3 года назад я сделал вебинар о тестах, который просмотрело несколько сотен человек, делал много стримов, где в живую показывал TDD, а сейчас мы с Никитой Соболевым запускаем большой курс о тестировании в Python.
Первый урок курса — бесплатный, проводим его в эту среду. Сделали его бесплатным, потому что вебинар содержит базовые знания, которые должны быть вообще у всех питонистов. Никита расскажет о моках и стабах, фикстурах и параметризации. Я расскажу о менее измеримых штуках: для чего мы пишем тесты, почему люди думают, что без тестов быстрее, и что вообще такое хороший тест.
Запись будет доступна только тем, кто придёт на курс. Если хотите просто посмотреть — приходите вживую в эту среду в 18:00 MSK, только сначала запишитесь у @tough_dev_bot — он пришлёт вам ссылку на вебинар.
Для бизнеса настроенная команда выглядит почти как конвейер: ставишь задачу, получаешь сроки. В течение этих сроков тебе прозрачно рассказывают, что происходит и заранее предупреждают, если что-то идёт не так. Даже если сроки смещаются — в конце ты получаешь результат с предсказуемым качеством. Разболтанная команда похожа на фрилансера: с лёгкостью принимает задачи, обещает сделать до завтра, а потом у неё заболевает бабушка и команда сдаёт говно или просто пропадает.
О разнице в устройстве настроенных и назболтанных команд можно говорить бесконечно — тут и техдолг, и контроль ритма, и инженерная культура. Но если бы мне нужно было отличить настроенную команду от разболтанный, задав всего один вопрос — я спросил бы как у них дела с тестами.
Тесты говорят одновременно и о качестве кода (без тестов легче писать лапшу), и об уровне планирования (у плохого руководства тесты первом делом летят под нож). Но самое главное, что гарантируют тесты — предсказуемость. Когда один человек пишет код, а работоспособность его решения проверяет другой — у команды нет однозначного индикатора, что задача решена: он повисает где-то а коммуникации между этими двумя людьми. Другое дело — зелёная галочка в гитхабе: запушил код и сразу видишь, насколько он работает. Больше не возьмёшься за новые задачи, не закончив старые — а значит не будешь переключать контексты и (в очередной раз) обманывать бизнес.
3 года назад я сделал вебинар о тестах, который просмотрело несколько сотен человек, делал много стримов, где в живую показывал TDD, а сейчас мы с Никитой Соболевым запускаем большой курс о тестировании в Python.
Первый урок курса — бесплатный, проводим его в эту среду. Сделали его бесплатным, потому что вебинар содержит базовые знания, которые должны быть вообще у всех питонистов. Никита расскажет о моках и стабах, фикстурах и параметризации. Я расскажу о менее измеримых штуках: для чего мы пишем тесты, почему люди думают, что без тестов быстрее, и что вообще такое хороший тест.
Запись будет доступна только тем, кто придёт на курс. Если хотите просто посмотреть — приходите вживую в эту среду в 18:00 MSK, только сначала запишитесь у @tough_dev_bot — он пришлёт вам ссылку на вебинар.
#вопрос Ты как-то упоминал о том, что если вкуришь TDD, то происходит сдвиг мышления. Поделись опытом, какого рода сдвиг произошел у тебя? Я пытаюсь разрабатывать c TDD, но во-первых сложно думать о тестах изначально, а во-вторых — качественных изменений в реализации я пока что не вижу.
Забавное совпадение — вопрос задали в декабре, когда мы начали обсуждать курс с Никитой, и только сейчас до него дошли руки.
Возможно это прозвучит странно, но если у вас получается писать хорошие тесты без TDD, то TDD вам и не нужен. Я сам довольно редко пишу все тесты до кода — обычно сразу пишу 2–3 теста, покрывающих happy path, а остальное дописываю уже вместе с кодом, когда понимаю узкие места, в которых код скорее всего может развалится.
Конечно, есть код, который по TDD писать получается гораздо быстрее — к примеру всякие форматтеры для чисел или текста типа таких: там проще сразу описать все возможные варианты поведения, а затем уже писать код, который удовлетворяет тестам. Получится «разработка методом перебора»: сначала написал тесты, а потом нажимаешь кнопки до тех пор, пока красная лампочка не позеленеет. Я почти не шучу — в таких случаях тесты снимают когнитивную нагрузку настолько, что чувствуешь себя обезьянкой с лампочкой.
Самое главное для чего я использую TDD — это дать новичкам почувствовать эту разницу на себе: один раз пописав код перебором, как обезьянка, начинаешь чувствовать себя неуверенно везде, где нет тестов. И довольно быстро понимаешь, что проверка работоспособности ПО — это задача для роботов, а человеку лучше думать про бизнес-логику и читаемость кода.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Забавное совпадение — вопрос задали в декабре, когда мы начали обсуждать курс с Никитой, и только сейчас до него дошли руки.
Возможно это прозвучит странно, но если у вас получается писать хорошие тесты без TDD, то TDD вам и не нужен. Я сам довольно редко пишу все тесты до кода — обычно сразу пишу 2–3 теста, покрывающих happy path, а остальное дописываю уже вместе с кодом, когда понимаю узкие места, в которых код скорее всего может развалится.
Конечно, есть код, который по TDD писать получается гораздо быстрее — к примеру всякие форматтеры для чисел или текста типа таких: там проще сразу описать все возможные варианты поведения, а затем уже писать код, который удовлетворяет тестам. Получится «разработка методом перебора»: сначала написал тесты, а потом нажимаешь кнопки до тех пор, пока красная лампочка не позеленеет. Я почти не шучу — в таких случаях тесты снимают когнитивную нагрузку настолько, что чувствуешь себя обезьянкой с лампочкой.
Самое главное для чего я использую TDD — это дать новичкам почувствовать эту разницу на себе: один раз пописав код перебором, как обезьянка, начинаешь чувствовать себя неуверенно везде, где нет тестов. И довольно быстро понимаешь, что проверка работоспособности ПО — это задача для роботов, а человеку лучше думать про бизнес-логику и читаемость кода.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Перестаньте ставить людей в копию
Часто руководители проектов жалуются, что их игнорируют: типа пишут клиенту в бейскемпе/на почту, а он не отвечает. При личной встрече вообще выясняется, что клиент и не открывал эти письма.
Скорее всего дело в том, что клиент не ожидает увидеть в письме ничего важного. Вот представьте, что коллега назначил вам встречу. Даже если нет повестки — вы всё равно понимаете, что человек не стал бы просто так тратить своё время. Наверняка у него и без вас куча дел, так что если он нашёл на вас 30 минут в календаре — скорее всего хочет чего-то важного. А теперь представьте, что этот же человек назначает вам не одну встречу, а сразу 40. Скорее всего вы решите, что он сошёл с ума и не придёте ни на одну из них.
То же самое работает с письмами. Если клиенту прилетает по 30 писем в день, в которых вы ставите его в копию, просто «чтобы был» — на третий день он начнёт эти письма игнорировать. Добавите его в чат со 100 сообщениями в день — он перестанет его читать. Начнёте звонить по 10 раз в день — перестанет брать трубку.
Приучайте людей, что ваши сообщения стоят дорого — если уж вы что-то написали, то пусть это будет важным. Если ставите людей в копию — проследите, чтобы они понимали, что вы от них хотите: «Иван, пожалуйста посмотрите юзер-стори — это то, что вы ожидали?»; «Ольга, скажите пожалуйста, это не противоречит требованиям юристов?». Если не можете объяснить, но твёрдо уверены, что человек должен увидеть ваше письмо, попробуйте формулу «вы в копии потому что ...»: «Сергей, вы в копии потому, что это касается информационной безопасности». «Ксения, вы в копии потому, что это касается новостного раздела сайта».
Часто руководители проектов жалуются, что их игнорируют: типа пишут клиенту в бейскемпе/на почту, а он не отвечает. При личной встрече вообще выясняется, что клиент и не открывал эти письма.
Скорее всего дело в том, что клиент не ожидает увидеть в письме ничего важного. Вот представьте, что коллега назначил вам встречу. Даже если нет повестки — вы всё равно понимаете, что человек не стал бы просто так тратить своё время. Наверняка у него и без вас куча дел, так что если он нашёл на вас 30 минут в календаре — скорее всего хочет чего-то важного. А теперь представьте, что этот же человек назначает вам не одну встречу, а сразу 40. Скорее всего вы решите, что он сошёл с ума и не придёте ни на одну из них.
То же самое работает с письмами. Если клиенту прилетает по 30 писем в день, в которых вы ставите его в копию, просто «чтобы был» — на третий день он начнёт эти письма игнорировать. Добавите его в чат со 100 сообщениями в день — он перестанет его читать. Начнёте звонить по 10 раз в день — перестанет брать трубку.
Приучайте людей, что ваши сообщения стоят дорого — если уж вы что-то написали, то пусть это будет важным. Если ставите людей в копию — проследите, чтобы они понимали, что вы от них хотите: «Иван, пожалуйста посмотрите юзер-стори — это то, что вы ожидали?»; «Ольга, скажите пожалуйста, это не противоречит требованиям юристов?». Если не можете объяснить, но твёрдо уверены, что человек должен увидеть ваше письмо, попробуйте формулу «вы в копии потому что ...»: «Сергей, вы в копии потому, что это касается информационной безопасности». «Ксения, вы в копии потому, что это касается новостного раздела сайта».