Хвастаться на ретроспективе

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

Радоваться и рассказывать об успехах — хорошо. Это заряжает рассказчика, добавляет прозрачности («Вот, Вася не зря у нас работает, вон какой деплой настроил») и в целом поднимает всем настроение.

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

​Начинаем через 5 минут!

Буду писать код и отвечать на вопросы про питон, джанго и всё такое https://youtu.be/smuIDCVeJvo

#вопрос Как замотивировать себя на работу? Не выполнение задач на рабочем месте (с этим не так много проблем), а самостоятельно делать своё дело. Есть проект, он потенциально принесёт мне большую прибыль. Но нет особого энтузиазма в желании его осуществить.

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

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

Каждый понедельник я отвечаю на один вопрос с конкретно описанной проблемой. Задавайте любые вопросы на fedor@borshev.comfedor@borshev.com

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

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

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

В соавторстве с Марьяной Онысько, руководителем новых проектов в МИФе, я собрал целый курс о навыках тимлида который так и называется «Стать тимлидом». Марьяна классно разбирается в продуктах и имеет огромный опыт в МИФе, и вместе мы покажем ситуацию с обоих сторон баррикад — я буду говорить со стороны разработки, а Марьяна — со стороны бизнеса.

Наш курс будет полезен тем, кто только собирается стать тимлидом, и тем, кто уже работает тимлидом и хочет прокачать навыки. Занятия стартуют 26 октября и продлятся 5 недель. На каждой неделе вы будете получать лонгрид, домашнее задание, публичную q&a сессию, и одного (а иногда и двух) признанных в индустрии спикеров, помимо нас с Марьяной.

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

В честь первого дня продаж ловите промокод на скидку 15 процентов — fedor. Если вы — мой патрон на патреоне, не торопитесь, вам придут личные промо-коды.

Почему я не использую два монитора

После статьи про мой сетап разработчика несколько ребят спросили в личке, почему я не пользуюсь двумя мониторами. Внезапно обнаружил, что так и не опубликовал ответ, поэтому отвечу сейчас.

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

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

Как только я это осознал, я принял решение — с этого момента я буду просто делать работу максимально простым путём, не пытаясь изобрести чего-то уникального. Купил себе мак, поставил редактор кода (сначала sublime, потом Atom и VSСode) и стал просто писать код. Из линуксового прошлого я притащил только любовь к vim (в виде плагина для редактора) и привычку сидеть в консоли. Внезапно появилось время и на рефакторинг, и на блог, и на чтение книг.

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

Как искать баланс между пользой для команды и пользой для себя?

В «советах» мне задали вопрос, над которым я очень крепко задумался — какое время важнее: время для себя или время для команды?

Точного ответа я так и не нашёл, но зато поделился личным опытом, как сам решал эту дилемму.

Чеклист хорошей задачи

Для меня курс «Стать тимлидом» — это новый уровень в систематизации знаний. Процесс очень сильно отличается от постинга в канал — сюда я пишу короткие заметки: одна мысль — один пост. С курсом всё по-другому — там я сажусь и формирую целые системы из знаний:

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

Всё это хочется выкладывать прямо сюда — польза же! Но я пока держусь. Одной штукой Марьяна меня всё-таки уговорила поделиться — это чеклист из 7 пунктов о том, как должна выглядеть хорошая задача. Чеклист важен для всех, кто имеет отношение к постановке задач — к менеджерам, тимлидам, QA и просто программистам, которые любят сами себе ставить задачи. Выложил его на страницу курса, заходите и скачивайте.

Не жди, а предлагай

Хорошая черта программиста (да и вообще любого творческого сотрудника) — иметь собственное мнение.

Не ждать, пока синьор предложит структуру БД на новом проекте, а написать самому и отдать на критику. Не надеяться, что кто-то перепишет говнокод в проекте, а самому исправлять по кусочкам. Не ждать неделями ответа от бизнес-заказчика, а самому формировать требования и согласовывать с командой.

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

Будущее инструментов data science

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

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

Напишите на fedor@borshev.com пожалуйста, если попробуете.

Заключать контракты

Любой консультант знает, что работу с клиентом стоит начинать с чётко прописанных ожиданий. Это же правило прекрасно работает и во внутренних командах, но им почему-то все пренебрегают.

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

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

Особенно важно заключать контракты с лидерами. Представьте, что вы отвечаете в компании за базу знаний, а к вам приходит какой-нибудь CTO и говорит что-то вроде «у тебя ноушен хуёвый, с жирой не интегрирован: давайте-ка перейдём на конфлюенс». Я, конечно, утрирую (да и конфлюенс всё-таки говно), но вы точно не будете чувствовать себя в порядке.

Всегда заключайте контракты в новых командах, хотя бы устно.

Простой принцип разрывания монолита

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

Обычное решение — просто начать писать код рядом, «сбоку». Классный подход для этого — Self Contained Services. Принцип простой: делаем шину данных, в которые монолит складывает события обо всех своих внутренних изменениях. Скажем, пришёл к нам заказ — положили его в RabbitMQ. Изменился статус у заказа — положили новый статус.

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

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

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

Но принцип именно такой — превращаем монолит в «генератор событий», а дальше пилим весь код в обработчиках этих событий.

P.S. Более подробно тему разрыва монолитов мы разбираем на курсе «Стать Тимлидом», который стартует 26 октября. Чтобы быть более полезным, я пригласил классного эксперта в этой области — Антона Давыдова.

QA не должны искать ошибки

Многие программисты почему-то рассчитывают на QA как на «тестировщиков» — чуваков, которым можно отдать задачу, а они проверят, сделал ты её или нет. Делать так нельзя.

Во-первых, это адская коммуникационная дыра. Передал задачу → через два часа QA принял → ещё через два прислал баг-лист — вот уже 4 часа и потерялись. Ты уже занят чем-то другим, а тут тебе баги прилетели, и хорошо, если в этот же день.

Во-вторых, это трата времени людей. Я говорю не об автоматических e2e-тестах на регресс, а о банальных интеграционных тестах. Какой смысл ждать по 4 часа ответа от кожаного мешка, когда можно за час написать робота, который проверит этот кусок работы? Причём робот сделает это не только сейчас, но и потом — в CI, при регрессионном тестировании, всегда.

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

Еженедельная рефлексия

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

Просто открываете редактор и пишете в свободной форме, что случилось за неделю. Один проект — один файл. Если рассказать вдруг нечего — это причина подумать: нужен ли вам такой проект, по которому за неделю ничего не случилось? Или, может, это самый важный проект и надо выкинуть все другие, чтобы его делать?

Если, наоборот, текст получается длинным — тоже повод задуматься: а не многовато ли времени вы уделяете конкретно этому проекту? Не надо ли отдать побольше времени другим?

Если нет времени рефлексировать — тоже повод задуматься: а всё ли у вас в порядке с тайм-менеджментом, если вы не можете найти сраных 10 минут, которые радикально улучшат вашу работу на следующей неделе?

Курс «стать тимлидом» идёт уже 13 часов и 40 минут, но пока ещё можно успеть.

Первая неделя посвящена переговорам. Завтра участники получат учебные материалы, а в среду придут на выступление Юли Максиной — директора по б2б-продажам в МИФе, в копилке которой такие клиенты как Мейл.ру, Сбер и Ростелеком.

На каждой из 5 недель мы рассмотрим один из основных навыков тимлида — переговоры, найм\увольнение, настройку процессов, управление продуктом и работу с техдолгом. Места с поддержкой уже закончились, но пока ещё можно купить самостоятельное участие. Там всё то же самое, доступны даже домашки — только вот проверить их мы не сможем. Зато, вместо этого сможете обсудить любой вопрос в чатике с другими участниками.

Если вам очень нужно оплатить по безналу от имени компании — тоже можно успеть: напишите нам в чат на сайте и мы добавим вас авансом.

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

Главный принцип найма самостоятельных людей

Когда мы нанимаем человека на должность, которая подразумевает много самостоятельности (а я на другие стараюсь не нанимать), на собеседовании нужно определить, собственно, его уровень самостоятельности. Сделать это точно без испытательного срока мне кажется невозможным, но зато я знаю классный способ как минимум отсеять тех, кто к самостоятельной работе не готов совсем.

Самостоятельного человека всегда что-нибудь парит. Самостоятельного программиста может парить говнокод, самостоятельного менеджера — бардак в продуктовых процессах или неспособность бизнес-заказчика договариваться. Когда человека что-то парит, он с этим что-то делает. Если парит говнокод — программист сам потихоньку рефакторит код и помогает коллегам. Парит то, что бизнес-заказчик не смотрит в цифры, — менеджер сам их собирает и носит одновременно заказчику и его начальнику или начальнику его начальника.

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

Сдавать с первого раза

И ещё один банальный софтскилл, которого не хватает 80% программистов, которых я встречал — сдавать работу с первого раза.

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

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

Я говорю о простых случаях, которые может заметить кто угодно, банальном «нажимаю на кнопку — получаю ошибку». Непосредственных причин такой хуйни может быть много — CI упал, код не прошёл валидацию\тесты, программист забыл сделать git push.

А вот фундаментальная причина одна, и ее легко исправить — это непонимание definition of done. В случае бага все просто — баг не воспроизводится на продакшене. В сложных фичах приходится задавать вопросы — что постановщик ожидает получить от фичи? Какие самые частые сценарии использования? В каком виде лучше показывать результат?

Самое лучшее средство от непонимания definition of done — всегда подкреплять свои слова доказательством. Пофиксил баг — приложи скриншот. Выкатил фичу — запиши видосик.

Если не понимаешь, что скриншотить/записывать — иди за пониманием задачи к тимлиду или менеджеру.

​Вышел новый совет: как и о чём поговорить с руководителем, который ведёт себя некомпетентно

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

Дарю отличную возможность раньше других обругать мои madskillz в области звукозаписи всего за $5 в месяц.

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

Вход рубль, выход — два

В любом, даже самом молодом продукте, новую фичу запилить легче, чем её выпилить. Вот представьте, что вы сделали у себя в магазине, скажем, поддержку промокодов. Это затрагивает код для создания заказа, веб, два мобильных приложения, а ещё на бекенде появляется какое-нибудь поле «скидка по промокоду», которое заполняется автоматически для выгрузки заказа в бухгалтерию.

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

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

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

​Сетап, действие и асёрт

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

Завязка: в лесу живут поросята. Чтобы волк их не съел, поросята строят домики, кто-то из бетона, кто-то — из грязи и палок.
Действие: в лес приходит волк и пытается достать поросят из домиков.
Развязка: часть поросят выжила.

Расскажем такую же историю про условный метод send_email() у класса User, который отсылает почту. Давайте расскажем его happy path как историю

Завязка (сетап): Существует юзер с имейлом us3r@domain.com.
Действие: мы вызываем у юзера метод send_email()
Развязка (асёрт): в очереди исходящей почты появляется письмо на адрес us3r@domain.com

Расскажем так же unhappy path

Сетап: Существует юзер с пустой строкой вместо имейла
Действие: мы вызываем у юзера метод send_email()
Асёрт: в очереди исходящей почти ничего нет, а приложение не упало.

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

Идеально, если тест вообще состоит всего из трёх строк: одна строка на сетап, одна на действие и одна на асёрт.

Посмотрите, как я пишу такие тесты на стримах. Если пишете на питоне, посмотрите на flake8-aaa, который заставляет писать хорошо структурированные тесты на уровне линтера. Если хотите копнуть глубже — посмотрите мой мастер-класс Как написать первый тест на любом проекте.