Ещё немножко про авралы

Кстати, подтверждение мыслям из «Русской Модели Управления» о том, что люди не работают без авралов, я встречал в совершенно разных местах.

Вот, к примеру про крестьян до революции, у Акунина:

«Полевые работы в основном приходились на три напряженных, но довольно коротких периода: посев, покос, сбор урожая. В остальное время года, особенно зимой, наступал период затишья. Ключевский пишет: «Так великоросс приучался к чрезмерному кратковременному напряжению сил, привыкал работать скоро, лихорадочно и споро, а потом отдыхать в продолжение вынужденного осеннего и зимнего безделья. Ни один народ в Европе не способен к такому напряжению труда на короткое время, какое может развить великоросс; но и нигде в Европе, кажется, не найдем такой непривычки к ровному, умеренному и размеренному, постоянному труду, как в той же Великороссии»

Такой же крестьянский подход прививают традиционные ВУЗы: большую часть времени студент, особенно на старших курсах, бездельничает, чтобы во время сессии напрячься, прочитать все книги за ночь и кое-как сдать экзамен.

Я против авралов: даже если отбросить чисто человеческие чувства о том, что загонять людей в авралы — это унижение. Авралы плохо влияют на качество кода. Команда с ровной и спокойной нагрузкой без давления практически сразу даёт гораздо более короткий time2market, чем нагруженная и авральная.

Так что давайте не считать программистов крестьянами и студентами — скорее это марафонцы или рабочие на пятилетнем долгострое.

Вечное преимущество того, кто не делает

Бывает такое — получаешь на код-ревью десятое замечание подряд и злишься на себя, типа нифига не шаришь. Вот ревьюер — крутой чел: вон сколько полезных замечаний даёт.

Такое бывает во всех сферах — когда ведёшь машину с инструктором, показываешь свежий текст напарнику, сдаёшь дизайн арт-директору. И всегда легко на себя разозлиться, особенно когда замечания справедливые — ну как же так, почему все понимают лучше меня.

Чтобы с этим справиться, мне помогает осознать, что у человека, который не делает, всегда есть нечестное преимущество — взгляд со стороны. Ревьюер не участвовал в работе: код, над которым ты страдал три дня, он увидел в первый раз — и конечно свежим взглядом ему легко находить проблемы. И конечно он не попадал в ловушку overthinking, когда три дня не думал над задачей.

Ты и сам с такой же лёгкостью будешь искать проблемы, если отложишь код\текст\дизайн на 3 дня и посмотришь заново.

Когда я даю десяток замечаний на один пулл-реквест, это не значит, что я какой-то супер-выдающийся программист: я просто смотрю свежим взглядом. И если нас с автором ПР поменять местами — далеко не факт, что я получу от него меньше замечаний, чем он от меня.

Косвенные расходы на встречи

Пустые встречи жрут ресурсы: календарное время и внимание, вырывая программистов из состояния потока. Это все знают и давно научились экономить, кто как может: назначают встречи покороче, ставят их впритык. Но кроме прямых расходов времени есть ещё и косвенные расходы — затраты внимания.

Для себя я называю это «календарь давит». Когда у меня в день назначено две встречи — одна на 14:00, другая, скажем на 18:00 — время между этими встречами я проведу в гораздо более неспокойном состоянии, чем обычно: не начну сложных задач (нафига, потом всё равно из потока вырвут); не уйду гулять (вдруг пробки, опоздаю!). Даже одна встреча в день уже сто́ит мне внимания и ухудшает концентрацию.

Чтобы календарь не давил, я делаю две вещи:

— Уменьшаю количество ad-hoc встреч. Вместо «давай созвонимся и обсудим» я назначаю регулярные встречи с теми, с кем часто созваниваюсь.
— Группирую такие встречи по дням. У меня это вторники и четверги.

Это позволяет мне иметь «дни встреч», в которые я занимаюсь только разговорами и разрешаю себе не делать ничего другого.

В школе у нас с Марьяной почти нет ad-hoc встреч — есть одна регулярка в неделю. В сложные периоды, к примеру когда готовим новые курсы — делаем две. В тихие периоды бывает отменяем регулярку и не разговариваем по две недели. В аутсорсе у меня вообще нет нерегулярных встреч с руководителями проектов: вместо этого я встречаюсь с ними раз в неделю, а с кем-то — и раз в две. Это позволяет мне поддерживать голову в чистоте и иметь дни, в которые я могу спокойно погулять\подумать или весь день потратить на потоковую работу.

О расходах на встречи и чаты, психологических причинах провала сложных встреч и способах максимально простого ведения коммуникации говорим на курсе «Есть минутка». В курсе 3 письма — одно теоретическое (эмоции, особенности восприятия) и два практических — о чатах и про встречах. Приходите до 1 февраля: тариф «закрытый клуб» с чатом и Q&A-сессиями мы продаём только сейчас, потом его не будет.

Смотреть программу →

Ночные рейсы

Одна из привычек, которая появилась у меня после 30 лет — не покупать ночные рейсы.

Идея ночных рейсов — довольно привлекательная: ты экономишь деньги, вылетая в 03:45, а аэропорт получает чуть более ровную загрузку. Но это же глупость! Во-первых, время — я, как дисциплинированный пассажир, приезжаю в аэропорт за два часа до вылета. Днём я трачу свободное время в аэропорте на работу — просто открываю ноутбук и делаю накопившиеся дела. В час ночи, я так сделать, увы, не могу — голова не работает.

Во-вторых — внимание к цели маршрута. После ночного перелёта всё, что хочет нормальный человек — это отоспаться. Получается, что если я лечу в отпуск, то отпуск должен быть на один день больше. Если лечу по делам — дела занимают на один «отсыпной» день больше. А я мог бы потратить этот день на что-нибудь полезное — хорошо отдохнуть и поработать.

Вряд ли разница в стоимости билетов (пусть она будет хоть 30%) стоит больше, чем деньги, которые я могу заработать за счёт того, что не перехожу в состояние сонной коровы.

Марьяна у себя рассказала о первом письме курса.

Когда я работал над программой, представлял в голове собирательный образ из всех программистов, которых встретил за последние пару лет — и из нашей команды, и встреченных в консалтинге. И задаю себе вопрос — о чём бы мне хотелось им рассказать, чтобы облегчить их жизнь?

В очередной раз поняв, что большинство проблем — в голове, для первого письма мы с Марьяной пригласили Ирину Парфёнову, которая рабоатала с нами на курсе «Самому не проще». И вот что получается:

Первый лонгрид «Есть минутка»: что вошло и ласт-колл в «Закрытый клуб»

Мы на финишной прямой с первым лонгридом «Есть минутка». Переписывали его втроем с нуля 4 раза. И еще не знаю сколько раз по кускам. Да и кого я обманываю — будем подкручивать пока не отправим. Собрались одни перфекционисты.

В один момент Ира Парфенова написала мне «Марьяна, надо созвониться, потому что мне кажется, что я книгу пишу, настолько он объемный». Я думала, что она шутит, но потом когда начала читать — подумала, что правда похоже на книгу. Как оказалось, это она только треть написала.

Нам важно, чтобы в лонгриде была концентрация пользы, ни на что не отвлекаться. Только читать и применять. Поэтому пришлось перебрать несколько вариантов подачи. В итоге пришли к простой форме сборника проблем-решений. Мне нравится, что можно прыгать сразу на нужную тему и не читать целиком, если в моменте нет потребности. Полностью отвечает нашему запросу «курс-аптечка». Бери только то, что нужно.

Всего получилось 6 ключевых проблем:

— Мы друг друга не понимаем. Причины: 1/ разные ожидания и вводные, 2/ разговор на разных уровнях коммуникации. Упоминаем модель 5 уровней коммуникации Джона Пауэла и учимся фиксировать и проговаривать ожидания.

— Мне сложно из-за непредсказуемости поступков людей. Причина: не понимаем свои и чужие эмоции и чувства. Учимся распознавать эмоции по модели Плутчика и привываем привычку не задавливать эмоции и выражать их, даже негативные. Как тоже рассказываем.

— Меня часто продавливают. Причина — личные границы: либо не определили, либо не умеете отстаивать. Даем инструкцию и шаблон как выстраивать личные границы и защищать их. Спойлер: сначала нужно разобраться со своими потребностями. Опираемся на книгу «Сила личных границ» Шэрон Мартин.

— Конфликты: часто избегаю и нападаю, когда уже нет сил терпеть. Причина: конфликт — это следствие того, что что-то не так с коммуникациями. Это либо слова тригеры либо вышеперечисленные проблемы. Учимся не бояться конфликтов и не чувствовать вину после. Разбираем круг конфликта Кристофера Мура и матрицу стратегий поведения в конфликте Томаса-Килмена.

— Мне сложно просить и говорить на неудобные темы, например о зарплате. Причина: страх оценки. Разбираем структуру неудобных разговоров и даем алгоритм действий, чтобы было не страшно просить.

—  Я делаю работу на отлично, но этого никто не замечает. Причина: не умение рассказывать о своей работе. Разберём причину страха, последствия советского воспитания и расскажем о принципе «Покажи свою работу» Остина Клеона.

Этот лонгрид мы пришлем вам 1 февраля, остальные два с ритмом раз в неделю. А в этот четверг позовем в чатик участников Закрытого клуба (так называется один из тарифов), где будем знакомиться, обсуждать ваши проблемы, чтобы успеть скорректировать контент под вас. В процессе же обучения в чате будем отвечать на вопросы и делиться обратной связью. А в конце — устроим Q&A-сессию, чтобы обсудить то, что сложно было вынести в чат.

Этот тариф мы придумали, чтобы делать курс в диалоге с вами. Он же про коммуникацию, как не крути. Правда продается закрытый клуб только до 1 февраля. После мы закроем его и больше никогда не откроем для покупки. Поэтому если хотели получить обратную связь и повлиять на контент курса — велкам. Осталось меньше недели.

Тариф Аптечка и Юрик будут продаваться и позже, но скорее всего поднимем ценник, потому что пользы получается намного больше, чем мы планировали изначально.

Записаться →

#вопрос Возник вопрос философского характера: надо ли разработчику/тимлиду прям знать досконально язык программирования?

Меня часто мучает синдром самозванца, что я вроде что-то умею, а посади меня без интернета и ощущение, что я ничего не могу написать. Хотя вроде бы продукты делаются, работа ведется, клиенты довольны.

Я в основном работаю на питоне и, например, в pandas я знаю как она работает и что где искать, но на вскидку, с листа группировку с аггрегацией скорее всего не напишу. При этом это не вызывает какого-то рабочего дискомфорта. Скорее психологический.

———————

Ну, даже если вы напишете код без интернета, вряд ли вы сможете без интернета его задеплоить :-)

А если серьёзно — у вас всё отлично. Для тимлидской роли софтскиллы гораздо нужнее — лучше уметь планировать проекты, организовывать работу и договариваться с людьми, чем знать как ковариантность отличается от инвариантности в типизации динамических языков.

Для разработчика — тоже: широкий кругозор гораздо важнее глубоких знаний. Представьте, что вы досконально знаете какие-нибудь asyncio.queues из стандартной библиотеки питона, но не понимаете, чем распределённый лог отличается от распределённой очереди, и вообще ничего знаете про типизацию событий в асинхронных системах. Если действительно, не сажать людей кодить без интернета, то код программиста, знакомого с асинхронными системами в целом, будет гораздо лучше для бизнеса, чем код программиста, идеально знающего одну из реализаций.

В эмоциональном плане я разделяю вашу тревогу. Сам уже пару лет не писал фронтенд, и чувствую себя неуютно, глядя как наши ребята размахивают новыми тулзами вроде vite, pinia (да и composition API, что уж там говорить). Успокаиваю себя тем, что моя роль в компании — совсем другая: найти человека, который знает современный фронт гораздо легче, чем человека, который может отвечать за целый бизнес сразу, включая финпланирование и работу с госорганами.

Если паритесь по поводу своих знаний — попробуйте расписать на бумаге свои обязанности в компании. Вряд ли у вас получится много связанного с доскональным знанием ЯП, но вангую, что найдёте как минимум 2–3 пункта, которые кроме вас не может сделать вообще никто.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Преимущество интровертов в коммуникации

Где-то слышал теорию, что стеснительным замкнутым интровертам в конечном счёте общение с людьми даётся легче, чем общительным экстравертам.

Идея в том, что экстраверты с детства умеют считывать движения тела, мимимку и интонацию — для них это такой же естественный навык, как жевать или ходить пешком. А интровертам приходится постигать всё это вручную: наблюдать, какое поведение за какой мимикой следует, как настроение у людей меняется в зависимости от внешних воздействий. Верю в это потому, что у меня происходит именно так — умение понимать эмоции людей пришло только с возрастом, тренировкой и психтерапией.

Получается, что интроверты умеют прокачивать эмпатию, а экстравертам — столько эмпатии дано, столько и останется: не будете же вы учиться точнее жевать или ходить, если уже делаете это на достаточном уровне.

Среди программистов очень много интровертов, и мне давно хотелось помочь им стать более общительными — чем лучше программист ведёт коммуникацию, тем более полезен он для бизнеса, да и для человечества в целом: быстрее закрывает задачи, пишет более релевантный бизнесу код, проще организует коллег. Самая свежа наша с Марьяной работа на эту тему — курс «Есть минутка», в котором целая неделя посвящена проблемам с коммуникацией (см. выше).

Это я всё к тому, что сегодня — последний день, чтобы запрыгнуть в групповой тариф и попасть в чат людей с такими же проблемами/задачами. С завтрашнего дня можно будет купить только самостоятельный тариф.

Сейф Бекап

Мы с Саматом запустили новый сервис для мониторинга бекапов — safe-backup.ru.

Это такая замена healthchecks.io для тех, у кого серверы стоят в России. Сервис работает по принципу мёртвой руки: скрипт бекапа периодически уведомляет нас, что всё хорошо, а если уведомления перестают приходить — мы присылаем алёрт.

Такая система позволяет с большой вероятностью отловить типичные ошибки: пропало соединение с хранилищем бекапов, закончилось место на диске, сменились креденшелы доступа к базе, — всё это ведёт к тому, что скрипт бекапа не дорабатывает, а значит не присылает нам уведомление.

Пока автор оригинального сервиса не сошёл с ума, я использовал его во всех своих системах, адаптировав несколько опенсорс-решений — для PostgreSQL или для файлов на диске. Сейчас везде, включая borg, я просто поменял адреса вебхуков — сервисы совместимы на уровне API.

Конечно, по дороге мы решили несколько косяков оригинала — к примеру сделали удобные уведомления через телеграм.

Приходите на бета-тестирование — в течение первого месяца можно добавлять неограниченное число сервисов и уведомлений. Скоро добавим уведомления по СМС и оплату картами или по безналичному расчёту.

UPD: Сервис закрыт, пользуйтесь uptimerobot.com (нужна зарубежная карта)

Друзья, я знаю что среди вас здесь много тех, кто руководит программистами. Помогите пожалуйста хорошим людям с исследованием — пройдите небольшой опрос.

Там что-то вроде что-то разыгрывают среди ответивших, но наверное можно сделать и просто так.

Как я могу сделать себе интересно?

Бывает нужно сделать задачу, а она — ну вот совсем скучная: досконально знаешь технологию, представляешь все подводные камни, знаешь даже как лучше поговорить с бизнесом, чтобы задача не раздувалась. Я обычно в таких ситуациях чувствую отвращение — кажется, что трачу свою жизнь на что-то неважное.

Такое бывает не только на работе — дома тоже нужно делать скучные линейные бытовые дела.

Самый хороший способ справиться с этим — сделать себе интересно. Если мне нужно в пятый раз написать похожий плейбук в Ansible — я не стану монотонно повторять работу, а изучу новую тулзу вроде mitogen или придумаю какую-нибудь элегантную автозамену для новых правил ansible-lint. Если надо помыть посуду — можно придумать, какой подкаст послушать. Чтобы не скучать при уборке — посидеть и повыбирать самый подходящий в мире пылесос, чтобы его использование всегда приносило радость.

Буквально — задаём себе вопрос: «а как я могу сделать эту работу для себя интереснее?». Главное — не перестараться: на работе мы всё-таки находимся не чтобы нам было интересно, а чтобы решать задачи работодателя. Но если дать себе правильную дозу интереса — задачи решаются гораздо быстрее и лучше.

Школа: запустили новую LMS

Когда мы только запускались, студенты читали материалы из писем со ссылками на Notion — всем было норм. Потом собрали на коленке LMS — рендерили те же материалы из ноушена, но уже с профилем студента (для диплома), минимальной навигацией и кнопочкой сапорта, чтобы можно было задать нам вопрос.

Та, первая LMS, была одним из самых стыдных моих проектов с точки зрения программирования — хреновый код без тестов, хреновая вёрстка. Серьёзно — отдавая код нашему программисту Тимуру я переживал, что потеряю авторитет как руководитель компании. Теперь про старое позорище можно забыть — материалы красиво рендерятся на всех платформах, со светлой и тёмной темой, код покрыт тестами и сделан на совесть.

Пока проект был в разработке, для меня он был одним из многих в «Феде и Самате» — я просто следил как идут дела и иногда помогал Тимуру договориться с Марьяной. Когда проект закончился, и из техдира я прерватился в счастливого заказчика — я осознал, насколько школе повезло: вряд ли при наших размерах мы могли бы себе позволить полноценный отдел разработки. А аутсорс по себестоимости — вполне смогли.

Если покупали у нас курсы последние полтора года — найдёте всё в lms.tough-dev.school. Код, как и все проекты школы, — в нашем гитхабе.

Технологии: vue3, pinia, vitest, playwright.
Разработчик: Тимур Брачков.

За последние 4 года я глубоко погружался в работу двух десятков команд: говорил с бизнесом, тимлидами и программистами, анализировал проблемы, что-то менял. Где-то получалось успешно, где-то — не очень, но что я точно приобрёл за это время — это насмотренность и умение отличать настроенные команды от разболтанных.

Для бизнеса настроенная команда выглядит почти как конвейер: ставишь задачу, получаешь сроки. В течение этих сроков тебе прозрачно рассказывают, что происходит и заранее предупреждают, если что-то идёт не так. Даже если сроки смещаются — в конце ты получаешь результат с предсказуемым качеством. Разболтанная команда похожа на фрилансера: с лёгкостью принимает задачи, обещает сделать до завтра, а потом у неё заболевает бабушка и команда сдаёт говно или просто пропадает.

О разнице в устройстве настроенных и назболтанных команд можно говорить бесконечно — тут и техдолг, и контроль ритма, и инженерная культура. Но если бы мне нужно было отличить настроенную команду от разболтанный, задав всего один вопрос — я спросил бы как у них дела с тестами.

Тесты говорят одновременно и о качестве кода (без тестов легче писать лапшу), и об уровне планирования (у плохого руководства тесты первом делом летят под нож). Но самое главное, что гарантируют тесты — предсказуемость. Когда один человек пишет код, а работоспособность его решения проверяет другой — у команды нет однозначного индикатора, что задача решена: он повисает где-то а коммуникации между этими двумя людьми. Другое дело — зелёная галочка в гитхабе: запушил код и сразу видишь, насколько он работает. Больше не возьмёшься за новые задачи, не закончив старые — а значит не будешь переключать контексты и (в очередной раз) обманывать бизнес.

3 года назад я сделал вебинар о тестах, который просмотрело несколько сотен человек, делал много стримов, где в живую показывал TDD, а сейчас мы с Никитой Соболевым запускаем большой курс о тестировании в Python.

Первый урок курса — бесплатный, проводим его в эту среду. Сделали его бесплатным, потому что вебинар содержит базовые знания, которые должны быть вообще у всех питонистов. Никита расскажет о моках и стабах, фикстурах и параметризации. Я расскажу о менее измеримых штуках: для чего мы пишем тесты, почему люди думают, что без тестов быстрее, и что вообще такое хороший тест.

Запись будет доступна только тем, кто придёт на курс. Если хотите просто посмотреть — приходите вживую в эту среду в 18:00 MSK, только сначала запишитесь у @tough_dev_bot — он пришлёт вам ссылку на вебинар.

#вопрос Ты как-то упоминал о том, что если вкуришь TDD, то происходит сдвиг мышления. Поделись опытом, какого рода сдвиг произошел у тебя? Я пытаюсь разрабатывать c TDD, но во-первых сложно думать о тестах изначально, а во-вторых — качественных изменений в реализации я пока что не вижу.

Забавное совпадение — вопрос задали в декабре, когда мы начали обсуждать курс с Никитой, и только сейчас до него дошли руки.

Возможно это прозвучит странно, но если у вас получается писать хорошие тесты без TDD, то TDD вам и не нужен. Я сам довольно редко пишу все тесты до кода — обычно сразу пишу 2–3 теста, покрывающих happy path, а остальное дописываю уже вместе с кодом, когда понимаю узкие места, в которых код скорее всего может развалится.

Конечно, есть код, который по TDD писать получается гораздо быстрее — к примеру всякие форматтеры для чисел или текста типа таких: там проще сразу описать все возможные варианты поведения, а затем уже писать код, который удовлетворяет тестам. Получится «разработка методом перебора»: сначала написал тесты, а потом нажимаешь кнопки до тех пор, пока красная лампочка не позеленеет. Я почти не шучу — в таких случаях тесты снимают когнитивную нагрузку настолько, что чувствуешь себя обезьянкой с лампочкой.

Самое главное для чего я использую TDD — это дать новичкам почувствовать эту разницу на себе: один раз пописав код перебором, как обезьянка, начинаешь чувствовать себя неуверенно везде, где нет тестов. И довольно быстро понимаешь, что проверка работоспособности ПО — это задача для роботов, а человеку лучше думать про бизнес-логику и читаемость кода.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Перестаньте ставить людей в копию

Часто руководители проектов жалуются, что их игнорируют: типа пишут клиенту в бейскемпе/на почту, а он не отвечает. При личной встрече вообще выясняется, что клиент и не открывал эти письма.

Скорее всего дело в том, что клиент не ожидает увидеть в письме ничего важного. Вот представьте, что коллега назначил вам встречу. Даже если нет повестки — вы всё равно понимаете, что человек не стал бы просто так тратить своё время. Наверняка у него и без вас куча дел, так что если он нашёл на вас 30 минут в календаре — скорее всего хочет чего-то важного. А теперь представьте, что этот же человек назначает вам не одну встречу, а сразу 40. Скорее всего вы решите, что он сошёл с ума и не придёте ни на одну из них.

То же самое работает с письмами. Если клиенту прилетает по 30 писем в день, в которых вы ставите его в копию, просто «чтобы был» — на третий день он начнёт эти письма игнорировать. Добавите его в чат со 100 сообщениями в день — он перестанет его читать. Начнёте звонить по 10 раз в день — перестанет брать трубку.

Приучайте людей, что ваши сообщения стоят дорого — если уж вы что-то написали, то пусть это будет важным. Если ставите людей в копию — проследите, чтобы они понимали, что вы от них хотите: «Иван, пожалуйста посмотрите юзер-стори — это то, что вы ожидали?»; «Ольга, скажите пожалуйста, это не противоречит требованиям юристов?». Если не можете объяснить, но твёрдо уверены, что человек должен увидеть ваше письмо, попробуйте формулу «вы в копии потому что ...»: «Сергей, вы в копии потому, что это касается информационной безопасности». «Ксения, вы в копии потому, что это касается новостного раздела сайта».

Тесты: доверяю себе

Я впервые познакомился с тестами чуть больше 12 лет назад — я тогда писал на Perl и задался вопросом нафига в opensource-модулях нужны все эти странные файлы с расширением .t. Мне повезло — я имел достаточно свободы, чтобы поработать с тестами на живых проектах (даже код остался, кек). С тех пор я вообще не пишу кода без тестов: стараюсь даже для ad-hoc скриптов собирать минимальные тестовые фреймворки.

В большинстве команд, которые я встретил с тех пор — сначала как сотрудник, потом как консультант — тестов не было. Стараясь ко всему подходить без ожиданий, я всякий раз думал, что им виднее: всё-таки люди годами так работают, и не мне, пришедшему со стороны, их судить. Каждый раз ошибался: во всех этих командах программисты были перегруженными и затюканными срочной работой, а бизнес злился на просранные сроки и постоянно падающий прод.

К слову, за всё время консалтинга я встретил только одну (!) команду, которая писала тесты — и мы прекратили работать с ними через месяц, убедившись, что проблема разработки лишь в том, что не хватает ещё 1–2 таких же хороших разработчиков, и познакомив их с хорошими HR. У остальных тестов либо не было вообще, либо было несколько десятков громоздких, давно отвалившихся тестов, которые даже в CI никто не гонял.

Очень надеюсь, что по крайней мере в моём нетворке ситуация изменится после того, как мы с Никитой Соболевым проведём курс по тестированию на Python: после вебинара в среду курс купило уже 80 человек, так что интерес, видимо, есть.

Никита Соболев — лучший русскоязычный эксперт, которого только можно найти: член команды pytest, core-разработчик CPython, GitHub Star и вообще известный опенсорсер. Никита расскажет всё о тестировании, начиная с базовых инструментов pytest, поговорит о правильной подготовке данных, читаемости, надёжности и скорости тестов. Я тоже участвую — рассказываю, как внедрять тесты в командах, где их ни разу не было.

Если вас ещё не заразили автоматическим тестированием ПО — обязательно приходите, поможем. После курса у вас останется весь набор инструментов, чтобы внедрить тесты где угодно.

Смотреть программу →

До 12 марта действует промокод PYTEST на 10% скидки. Будем ли повторять — пока не знаем, так что если актуально — лучше покупайте сейчас. Можно оплатить из-за рубежа, а рублями — ещё и в рассрочку. От юрлиц оплату тоже принимаем, предоставляя полный комплект документов.

Почему автоформаттеры — хорошо

Недавно обсуждал с одной командой внедрение prettier в один большой старый проект и услышал такое мнение — «автоформаттеры — плохо: когда никто за тебя не форматирует код, привыкаешь писать код сразу красиво, и они становятся не нужны». Я долгое время был приверженцем такого же мнения, поэтому не могу не написать об этом здесь.

Я передумал после того, как вспомнил, что бизнес платит программистам не за их умение писать код красиво (а ещё понятно, без ошибок компиляции и с правилами git-гигиены), а за решённые задачи. В идеальном мире — чем больше бизнес-задач решает разработка в момент времени — тем дороже она сто́ит. Как конвейер на заводе — чем больше он выпускает автомобилей в день, тем больше прибыли.

Как и на конвейере, в разработке работает бездушная автоматизация: пусть в кодовой базе будут некрасивые тернарные операторы и местами нелогичные переносы строк, зато любой новый джун может не тратить неделю на привыкание к кодовому стилю, и может сразу же писать код, который так же легко читается как код старичков.

К счастью, в отличие от конвейера, выгоду от автоматизации забирает себе не только бездушный капиталист. Всё-таки работа у нас творческая, и когда программист освобождает голову от форматирования, в ней появляется больше места на профессиональный рост или просто хороший отдых с близкими.

Так что внедряйте авторформаттеры — чем жёстче и бескомпромиснее, тем лучше.

#вопрос Взял задачу, назначил срок 4–5 дней. Сделал за 4, отправил на ревью, и выяснилось, что неверно понял задачу. Теперь задача требует ещё 4 дня, то есть в два раза больше.

Всегда ли возможно сразу сказать, сколько времени займет задача, учитывая такие моменты? Какие другие ошибки я сделал?
——————

Я вижу тут две ошибки. Во-первых, вы даже будучи уверенными в задаче, когда оценивали её в первый раз, вы ошиблись как минимум в два раза. Вы оценили задачу в 5 дней, а отправили на ревью только через 4, то есть практически в конце срока. А после ревью ещё наверняка будет QA, релизный поезд, служба безопасности или ещё чего пострашнее. И даже если все эти препятствия работают чётко, дня 4 они добавят, это уж точно. Получится уже 8, и это в лучшем случае.

Во-вторых, вы нарушили принцип «исполнитель понимает задачу». Этот принцип хорошо сформулировали в Бюро Горбунова, гляньте. Идея простая — убеждаться в том, что ваш код решает именно ту проблему, которая стоит у бизнеса — это ваша задача. Не менеджера, который формулировал таску, не ревьюера\QA, который её проверяет — ваша. В соответствии с этим принципом нужно было запланировать MVP — может быть прототип решения, или хотя бы документ, где вы своими словами описываете задачу в том виде, как вы её поняли (гляньте «понимание задачи» по ссылке выше). MVP — это такая же часть работы, как и ревью, на неё нужно точно так же закладывать время при планировании. Забирая задачу на 4–5 дней, я бы как минимум взял один день на MVP, согласовал бы его с бизнесом, и только потом называл срок на оставшуюся часть задачи. Так вы никого не подведёте — все понимают, что предсказуемые сроки по задаче вполне стоят небольшого ожидания прототипа.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Не обслуживайте срочность

Недавно на Q&A «Есть минутки» мне задали вопрос — как вести асинхронную коммуникацию, когда кто-то нужен срочно — типа стенд упал, ветка не мёрджится или просто нужно срочно сделать задачу.

Конечно, когда что-то действительно нужно срочно — никакая асинхронная коммуникация не работает: надо писать, звонить и вообще разыскивать всяческими доступными способами. Однако меня смущает, что большинство людей воспринимают срочность как некую аксиому, типа «нам нужен чатик с девопсами, потому что они бывают нам срочно необходимы». Конечно, если системно не работать над происходящим в компании, все будут друг-другу срочно нужны.

Работа менеджера\тимлида состоит не в том, чтобы обслуживать срочность, создавая больше чатиков, а в том, чтобы её убивать: выделять время, чтобы сделать неломаемые стенды; внедрять gitflow, чтобы не было немёрджащихся веток; бить по рукам тем менеджерам, которые выдумывают срочность, потому что не доверяют людям. Такие причины устранить реально — у нас с Саматом в команде на 20 человек и несколько крупных проектов срочность бывает два раза в год при крупных релизах.

Не обслуживайте срочность — убивайте её.

Точить пилу

Когда на собеседованиях говорят, что не писали тестов на предыдущей работе — я всегда спрашиваю, что помешало это сделать. Если отбросить радикальные варианты, когда программисты сами считают, что без тестов — быстрее, самый частый ответ — «нам не дают времени».

Я всегда в такие моменты представляю себе застройщика, который жалеет денег рабочим на каски и с умным лицом рассуждает, что это экономит ресурсы. Правда иногда строителям на голову падают кирпичи — но ничего страшного: теперь на территории есть специальная больница, где таких людей откачивают. Экономия же! К тому же пока никто не умер — есть пара инвалидов, но их пенсия ничтожна по сравнению с экономией на касках.

Таких застройщиков, к счастью не бывает. Так же, как не бывает глупых руководителей бизнеса. Если хорошо объяснить — согласится даже мерзкий капиталист-владелец аутсорса. В основном инженеры не могут объяснить потому, что до конца и сами не верят в эффективность автотестов — попробовали пару раз и не получилось: тесты падали, тормозили, или бесконечно жрали время на поддержку.

Именно таким людям я помогаю уже несколько лет — провожу стримы, где пишу по TDD, постоянно пишу о тестах в канале. К сожалению, это всё не работает, пока инженеры не разрешают себе «заточить пилу». Кажется, научить этому извне невозможно — можно дойти только самому.

Если вы пишете на питоне и уже научились — приходите на наш курс по тестированию с Никитой Соболевым: расскажем и покажем все актуальные способы наточить свою пилу и показать коллегам, как это делать. Кроме вебинара про базовые инструменты (который вы получите в записи) будет ещё три — о читаемости, о скорости/надёжности и о том, как всё это живёт в реальной жизни.

Стартуем сегодня в 18:00 MSK, ещё можно успеть. Есть рассрочка, а если хорошо побегать — можно даже успеть от юрлица.

Смотреть программу →