FEDOR BORSHEV

2023-03-22 10:45:20 Письмо самому себе

Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.

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

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

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

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

Раньше для для отсылки писем я пользовался программой на айфоне, которая так и называлась — Mail to Self. Однако со временем пришло понимание, что каждый клик понижает вероятность того, что мысль будет записана. Особенно Mail to Self страдала, когда хотелось отправить себе скриншот или фотографию.

Поэтому я пошел дальше и написал себе бота для телеграма — @selfmailbot. Бот делает простую штуку — все что я ему пишу, оказывается у меня на почте. Привычный интерфейс телеграма помогает лениться еще меньше и записывать вообще все, что приходит в голову.

Бот бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь. Если хотите скинуться на хостинг бота и живёте не в России — у меня есть патреон. Открыть/Комментировать

2023-03-20 07:01:15 Точить пилу

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

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

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

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

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

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

Смотреть программу → Открыть/Комментировать

2023-03-15 10:45:21 Не обслуживайте срочность

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

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

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

Не обслуживайте срочность — убивайте её. Открыть/Комментировать

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

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

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

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

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

2023-03-09 10:45:18 Почему автоформаттеры — хорошо

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

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

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

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

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

2023-03-06 10:45:19 Тесты: доверяю себе

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

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

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

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

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

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

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

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

2023-03-01 10:45:19 Перестаньте ставить людей в копию

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

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

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

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

2023-03-01 10:45:19 Открыть/Комментировать

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

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

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

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

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

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

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

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

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

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

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

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

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