Lead’s Notes

Кто я и зачем Спустя пару лет существования канала я всё же сделаю интро:) Мой бэкграунд без неожиданностей: — stem, graduated with honors — несколько лет разработки: движок репликации данных в большом и хайповом онлайн-банке (если кто-то из подписчиков встречал в своей жизни ods2, простите, ради бога, я был молод); софт для миграции тачек между облаками (из aws в azure, например, для желающих легко переместиться), другие околостартапные и неожиданно низкоуровневые начинания — несколько лет tech startups в яндексе: mvp, пилоты, неожиданные взлеты и болезненные неудачи. Кикшеринг (надеюсь, вас не сбивали школьники на наших самокатах), умные камеры, финтех для водителей такси (если водитель жаловался тебе, что недополучает денег, можешь свалить на меня), whatever можно было придумать в городе на колёсах — несколько лет трансформаций больших и тяжелых инженерных команд: логистика и стартапы фудтеха (где-то на ютубе есть перезалив старого выступления о том, как мы пытались переделать логистику всего, что связано с курьерами, из эпохи, когда я еще брился. В целом, на том же ютубе можно найти обо мне ещё). Затем Лавка (вы могли заметить, что в какой-то момент в ней появилось много разного, включая фарму, ритейл, маркет и what-not, а также она появилась за пределами РФ) — потом я устал от построения карьеры и курса акций компаний, с которыми работаю ——— И начал заниматься только двумя вещами, которые я люблю: 1. Как получить от своего подразделения tech больше, не увеличивая бюджет? Я видел много плохого и хорошего кода, плохих и хороших инженеров, правильно и неправильно выбранных метрик эффективности. Если N твоих разработчиков два года назад делали больше, чем делают 3*N сегодня — это сюда. Если одни и те же N стабильно меньше и хуже, чем ты ожидаешь — тоже сюда. 2. Как сделать "вот эту непонятную хреновину, которую негде скопировать"? Я могу быстро сгенерировать несколько более-менее жизнеспособных идей реализации и рассказать, какими людьми и как это сделать. Я, разумеется, не могу быть экспертом в любых технологиях, но длинный инженерный нетворк, накопленный в бигтехах, и бессонница очень помогают. Обычно приходят с вещами на стыке сложной функции и непонятной технологии. Например (с поправкой на NDA): "а можно ли сделать умный девайс, ценой до X тысяч долларов за штуку, на котором будут крутиться такие-то модельки без бэкенда?" или "как бы нам сделать self-hosted агента, который красиво говорит на арабском?" или даже "как бы нам выжать еще несколько тысяч rps из монолита на php, который мы уже 5 лет боимся разбирать?" Вот, собственно, и всё. ——— Если ты: — Из любой позиции сталкиваешься с управлением разработкой (в том числе лично и напрямую в ней находишься) и хочешь получать больше результатов или — Хочешь сделать что-то сложное и никак не получается, либо ошибка стоит дорого и страшно даже пробовать Приходи. Вот сюда можно написать о своей проблеме.

Работа с людьми — это отдельный набор навыков, которому можно обучить ТОЛЬКО человека, который этого хочет Научить писать код на новом стэке / оформлять тикеты / жить в рамках определенных ритуалов людей можно и без их большого желания. И будет приемлемо. Я встречал большое количество инженеров, не испытывающих большого рвения использовать технологию, но при этом выдающих адекватное качество решений. Терпишь и делаешь, и нормально, если ревьюер есть. Научить человека управлять другими людьми, если он этого не хочет, нельзя. Подход "придумаю как решить задачу, используя свои харды, а потом просто скажу подчиненным, что делать", не работает. В каждого, кому регулярно напрямую говоришь, что делать, нужно вкладывать время и строить отношения, вести переговоры и тд, это никогда не работает как "довесок" к работе, это основная работа и есть. Люди, которые не хотят вести переговоры и строить отношения с другими людьми, делают это плохо. И продолжают встречаться на очень разных уровнях, производя на свет очень странные компании со странными результатами (если cto генерирует классные идеи, но при этом его подчиненные текут по 30-40% в год и НЕ понимают, что он говорит, реализовать эти идеи не получится). "Продавать" менеджерскую работу человеку, который к ней предрасположен, не нужно. Люди, которые реально хотят не код писать, а управлять другими людьми, в этом не сомневаются. И это слабо коррелирует с опытом: бывают стажеры, которые уже знают, что хотят стать менеджерами. Бывают люди, которые провели в разработке 15 лет, были запромоучены в CTO и производят, в лучшем случае, плохой эффект на организацию (с одной стороны — спасибо, конечно, такие CTO создают для меня платящих клиентов-CEO. С другой — людей мне жалко). Бывают и переходы, конечно — когда человек 10 лет писал код, а потом устал как от написания кода, так и от плохого менеджмента, и решил заняться этим сам. И тем не менее, сомнений у хороших будущих менеджеров к этому моменту уже нет. Если сомневаешься, стоит ли делать человека руководителем, И ОН ТОЖЕ СОМНЕВАЕТСЯ — не надо этого делать. Скорее всего, он может приносить пользу иначе. Если уже сделал и понял, что, возможно, зря — звони :)

Ребята, прекратите писать юнит-тесты! Я где-то с 20-го года это говорю и количество людей, которым я это говорю на консультациях, почти не уменьшается (хотя умные люди, кажется, говорят года с 15-го) Если ты делаешь не рокет-саенс, а туда-сюда crud и просто бизнес-логику — не надо дрочить покрытие методов и строчек кода. Покрой тестами сценарии использования целиком. Например, в случае с бэкендом, тест должен быть написан на "вызов http-хендлера + проверку того, что случилось с базой + проверку того, что вернулось", не, блин, на функцию, которая под капотом в этом пайплайне заголовок парсит. Гугли component testing, Фаулер, кажется, лет 10 назад название специальное придумал. Если поставите сюда штук 50 лайков, напишу детальнее о том, почему модульные тесты для продуктовой команды — это не страховка от багов, а просто дыра в бюджете команды

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

Иногда у меня спрашивают, как я развлекаюсь в свободное время Так вот: в свободное время я делаю что-то, заставляющее меня держать "долгий" фокус. Например, рецензирую тексты. // Почему мои собственные посты при этом — такое говно с опечатками? Мои тексты не проходят никакого ревью, даже моего: если начну это делать, скорость выпуска замедлится в 5 раз. Например, за последние пару месяцев я отревьюил 362 работы, поданные на конкурс для публикации в одном...нетипичном сборнике русской литературы. Кто любит хоррор не-на-экране, поймёт, о какой книге я говорю :) Почему я решил написать об этом сейчас, а не утром? Потому что проклятое 362-е ревью я дописал только что, в 01:50 по местному времени. А вы как развлекаетесь?