25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
Тимлидская папка
Тут в ребята собрали папку с 15 телеграм-каналами для тимлидов. Я там тоже есть — кайф! Почитав папку, немного улучшил кругозор — кажется теперь я больше знаю, о чём болит голова у русскоязычных тимлидов и сочувствующих.
По ссылке можно сразу подписаться на все. Если беситесь от красных кружочков — выделите 30 минут, почитайте все каналы и подпишитесь на те, в которых найдёте что-нибудь непривычное или непонятное. Привычные и понятные каналы точно добавлять не стоит — нафига вам красные кружочки с тем, что вы уже знаете? :-)
Анализ систем: стартуем в пятницу!
12 мая, в эту пятницу, мы стартуем новый курс с Антоном Давыдовым — Анализ Систем.
Для меня курс — об осознанном проектировании систем. Каждый программист рано или поздно проектирует системы, но единицы делают это, понимая что происходит: большинство почему-то думает не от бизнеса, а от технологий, которые услышали на последней конференции.
На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникации, работать со стейкхолдерами и писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков. Отдельная гордость Антона — несколько сотен ссылок на дополнительные материалы, если захотите углубиться в какую-то из тем. Хватит на год вперед.
Джунам курс не подойдёт. Мидлам подойдёт. Если есть, где применить полученные знания, или просто очень интересуетесь проектированиям — обязательно берите тарифы с обратной связью. Синьёрам, помидорам, принципалам и CTO пойдёт в любом случае.
Стартуем в пятницу, есть ещё одно VIP-место с личной обратной связью и консультацией.
Смотреть программу →
Достоен ли я асинхронной коммуникации?
Все хотят работать асинхронно — не быть постоянно на связи с коллегами, отвечать когда удобно, а не когда спросили, иметь большие промежутки времени на творческую работу. Но не все этого достойны.
Вообще-то начать работать асинхронно можно в любой команде — если телега\слак установлены у вас на компьютере, значит вы всегда можете их выключить или хотя бы отключить уведомления. Вопрос в том, что будет происходить во время вашего отсутствия.
Попробуйте честно ответить для себя — а достойны ли вы асинхроннной работы? Не нужно ли вас пинать, чтобы вы делали задачи вовремя? Когда вы говорите «сделал» это означает «создал пул-ревест» или «код работает на проде и влияет на метрики»? Достаточно ли ваших знаний находятся в общем пространстве, или коллегам без вас ничего не понятно?
Если что-то из этого в беспорядке — будет тяжело даже отключить уведомления: вас всё равно найдут и заставят общаться. А если всё в порядке — скорее всего никто и не заметит вашего отсутствия. Серьёзно — я видел ребят, которые асинхронно работают в совершенно синхронных офисных командах просто потому, что свято соблюдают принцип «пацан сказал — пацан сделал».
Аргумент как продавать мониторинг
Недавно убеждал одну команду установить себе нормальный APM. Основной аргумент против был «у нас есть <отечественный сервис-пинговалка>, если что-то случится, он нам сообщит».
Нормальный мониторинг по сравнению с пинговалками (не важно, отечественными или нет) — это как превентивный медосмотр против сообщения «поздравляем, вы умерли».
Мониторинг показывает проблемы в приложении задолго до того, как они выстреливают: если у вас 20% пользователей получают 500 ошибку, то с пинговалкой вы об этом не узнаете, пока она не попадёт в эти 20%. Если у вас потихоньку растёт latency у базы, вы не узнаете об этом, пока пинговалка, вместе с нормальными пользователями, не начнёт отваливаться по таймауту. Datadog, к примеру, позволяет даже не настраивать никакие триггеры — просто запускаете в нём watchdog, и он сам напишет, если что-то не так.
В общем сбор данных — это про проактивность, а алёрты «сайт упал» — про реактивность. Если у вас на работе всё ещё настроены пинговалки вместо нормального мониторинга — обязательно поговорите с CTO об этом.
Анализ систем и распил монолитов
Оглядываясь на прошлое лето, когда мы решили сделать продолжение «Асинхронной Архитектуры», я чувствую себя продюсером «Безумного Макса 4». И не потому, что у нас в качестве эксперта выступает Том Харди (уверен, Антон разбирается в архитектуре лучше), а потому, что мы делали этот курс почти год.
Причина простая — задумали слишком много: хотели так же, как «Стать Тимлидом», сделать курс «Стать Архитектором». Мы не учли, что этим двум профессиям нужно учить по-разному: тимлидам нужно дать практический фреймворк для развития и немного попинать, а вот архитекторам нужна ТЕОРИЯ в огромном количестве. Собственно, весь год мы и пробовали разные подходы, чтобы отжать и упаковать ТЕОРИЮ так, чтобы её можно было прочитать и не умереть.
В итоге остановились 5 уроках, в ~50 страниц A4, построенных на «кругах профессионализма» — каждый новый урок учит решать ту же задачу, что и предыдущий, но на новом уровне и для бизнеса с новым скейлом, с учётом предыдущих ошибок. Получается, как прогрессивный джипег: можно прочитать и половину курса, и уже стать сносным архитектором для не очень сложных систем. Чтобы мысли Антона легко воспринимались в тексте, мы позвали Тимура Зарудного: это первый раз, когда мы зовём пишущего редактора, до этого были только корректоры, а редактировали мы с Марьяной.
На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций, писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков.
Стартуем 12 мая, 5 уроков, 4 круга профессионализма, Q&A, чатик с Антоном и десяток котов в каждом уроке. Если дойдёте до конца — получите достаточно знаний и инструментов, чтобы проектировать системы для большинства крупных работодателей.
До 26 апреля действует промокод K1F3N на 10% скидки. C 1 мая — повышаем цены.
Смотреть программу →
Начинаем! Го на ютуб — https://www.youtube.com/live/DNwt6GqPPRU?feature=share
Читать полностью…
А давайте поговорим?
Что-то давно мы с вами не разговаривали, надо исправляться. В эту пятницу в 18:00 MSK делаем с Марьяной двухчасовой стрим на ютубе. Можно будет задать любой вопрос — про управление проектами, образование, профессиональный рост, питон, школу или аутсорс.
Ссылку на стрим опубликуем прямо здесь в пятницу.
Это я или моё окружение?
Человек — существо социальное. Часто настолько социальное, что даже внутренний диалог происходит не с самим собой, а с социумом. Хороший пример — недвижимость: мы годами видим баннеры с счастливыми семьями и эмоциональными посылами вроде «построй своё место» или «получи московскую прописку» и привыкаем к ним настолько, что покупка квартиры превращается из обычного в общем-то финансового инструмента в самоцель. Отпадают рациональные вопросы вроде «а что будет на этом месте через 10 лет» или «не ухудшит ли эта ипотека качество моей жизни?» — мы просто хотим квартиру. А как родители обрадуются!
Важный скилл, который который приходит с возрастом — это умение честно разговаривать с собой о своих желаниях. Хочу ли я стать айтишником, или может всё-таки менее трендовым, зато подходящим дизайнером интерьеров? Хочу ли я переезжать в Казахстан, или просто следую за новостями? Выбираю мерседес потому, что это самое лучшее редложение на рынке, или потому что у соседа такой?
Этот софт-скилл здорово помогает и в работе программиста. Хочу ли я писать на nuxt потому, что считаю его качественным фреймворком с внятным будущим, или потому, что так принято? Хочу ли я разбираться в ChatGPT, или она просто на хайпе сейчас?
Сделав сложный выбор, всегда проверяйте — а сами ли вы сделали этот выбор? Или может общество подсказало?
#вопрос начиная стратап, какую "техническую гигиену" стоит ввести? О чем стоит задуматься с самых первых дней?
Мне не хочется в очередной раз рассказывать про автотесты, линтеры, ci\cd и докер, поэтому я буду считать что это вопрос от фаундера, а не CTO.
Самое главное, что вы как фаундер можете сделать с первых дней — это научить свою разработку _писать как можно меньше кода_. Каждая фича, которую вы закодите руками программистов стоит денег и внимания. Даже если её никто не использует. Тестируйте гипотезы на nocode-решениях. Если всё-таки пилите фичи — прямо в задачах фиксируйте гипотезы, которые проверяете этими фичами и учите разработку совершать минимум телодвижений, нужных чтобы эту гипотезу проверить. Если гипотеза выстреливает — тогда уже пишите хороший код. Если нет — выпиливайте весь написанный код. Чем меньше тратите сил на поддержку — тем больше остаётся для новых фич, и тем меньше денег стоит вам разработка.
Если вдруг гипотезы — это не ваша история, и для запуска вашего стартапа нужно запилить кучу кода не меньше кинопоиска, тогда первая ваша задача — отсеять плохих программистов. К сожалению, собрав рандомную команду с рынка, вряд ли вы получите людей, способных самостоятельно организовать свою работу. Скорее всего они довольно сильно вас замедлят, нагородив сложности вроде микросервисов с кафкой, или настроив лишних процессов вроде ручного тестирования с релизными поездами.
Чтобы поймать замедление на самом раннем этапе — выстройте обязательный еженедельный контроль: когда команда по понедельникам строит понятный бизнесу план, а через неделю отчитывается по нему. Если на протяжением 2–3 недель больше 20% плана не выполняется — скорее всего у вас уже есть проблемы с качеством, и пора честно поговорить об этом с командой (кстати мы с Саматом это умеем, пишите).
Это был традиционный вопрос по понедельникам. Задайте свой на fborshev@pm.me
Точить пилу
Когда на собеседованиях говорят, что не писали тестов на предыдущей работе — я всегда спрашиваю, что помешало это сделать. Если отбросить радикальные варианты, когда программисты сами считают, что без тестов — быстрее, самый частый ответ — «нам не дают времени».
Я всегда в такие моменты представляю себе застройщика, который жалеет денег рабочим на каски и с умным лицом рассуждает, что это экономит ресурсы. Правда иногда строителям на голову падают кирпичи — но ничего страшного: теперь на территории есть специальная больница, где таких людей откачивают. Экономия же! К тому же пока никто не умер — есть пара инвалидов, но их пенсия ничтожна по сравнению с экономией на касках.
Таких застройщиков, к счастью не бывает. Так же, как не бывает глупых руководителей бизнеса. Если хорошо объяснить — согласится даже мерзкий капиталист-владелец аутсорса. В основном инженеры не могут объяснить потому, что до конца и сами не верят в эффективность автотестов — попробовали пару раз и не получилось: тесты падали, тормозили, или бесконечно жрали время на поддержку.
Именно таким людям я помогаю уже несколько лет — провожу стримы, где пишу по TDD, постоянно пишу о тестах в канале. К сожалению, это всё не работает, пока инженеры не разрешают себе «заточить пилу». Кажется, научить этому извне невозможно — можно дойти только самому.
Если вы пишете на питоне и уже научились — приходите на наш курс по тестированию с Никитой Соболевым: расскажем и покажем все актуальные способы наточить свою пилу и показать коллегам, как это делать. Кроме вебинара про базовые инструменты (который вы получите в записи) будет ещё три — о читаемости, о скорости/надёжности и о том, как всё это живёт в реальной жизни.
Стартуем сегодня в 18:00 MSK, ещё можно успеть. Есть рассрочка, а если хорошо побегать — можно даже успеть от юрлица.
Смотреть программу →
#вопрос Взял задачу, назначил срок 4–5 дней. Сделал за 4, отправил на ревью, и выяснилось, что неверно понял задачу. Теперь задача требует ещё 4 дня, то есть в два раза больше.
Всегда ли возможно сразу сказать, сколько времени займет задача, учитывая такие моменты? Какие другие ошибки я сделал?
——————
Я вижу тут две ошибки. Во-первых, вы даже будучи уверенными в задаче, когда оценивали её в первый раз, вы ошиблись как минимум в два раза. Вы оценили задачу в 5 дней, а отправили на ревью только через 4, то есть практически в конце срока. А после ревью ещё наверняка будет QA, релизный поезд, служба безопасности или ещё чего пострашнее. И даже если все эти препятствия работают чётко, дня 4 они добавят, это уж точно. Получится уже 8, и это в лучшем случае.
Во-вторых, вы нарушили принцип «исполнитель понимает задачу». Этот принцип хорошо сформулировали в Бюро Горбунова, гляньте. Идея простая — убеждаться в том, что ваш код решает именно ту проблему, которая стоит у бизнеса — это ваша задача. Не менеджера, который формулировал таску, не ревьюера\QA, который её проверяет — ваша. В соответствии с этим принципом нужно было запланировать MVP — может быть прототип решения, или хотя бы документ, где вы своими словами описываете задачу в том виде, как вы её поняли (гляньте «понимание задачи» по ссылке выше). MVP — это такая же часть работы, как и ревью, на неё нужно точно так же закладывать время при планировании. Забирая задачу на 4–5 дней, я бы как минимум взял один день на MVP, согласовал бы его с бизнесом, и только потом называл срок на оставшуюся часть задачи. Так вы никого не подведёте — все понимают, что предсказуемые сроки по задаче вполне стоят небольшого ожидания прототипа.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Тесты: доверяю себе
Я впервые познакомился с тестами чуть больше 12 лет назад — я тогда писал на Perl и задался вопросом нафига в opensource-модулях нужны все эти странные файлы с расширением .t. Мне повезло — я имел достаточно свободы, чтобы поработать с тестами на живых проектах (даже код остался, кек). С тех пор я вообще не пишу кода без тестов: стараюсь даже для ad-hoc скриптов собирать минимальные тестовые фреймворки.
В большинстве команд, которые я встретил с тех пор — сначала как сотрудник, потом как консультант — тестов не было. Стараясь ко всему подходить без ожиданий, я всякий раз думал, что им виднее: всё-таки люди годами так работают, и не мне, пришедшему со стороны, их судить. Каждый раз ошибался: во всех этих командах программисты были перегруженными и затюканными срочной работой, а бизнес злился на просранные сроки и постоянно падающий прод.
К слову, за всё время консалтинга я встретил только одну (!) команду, которая писала тесты — и мы прекратили работать с ними через месяц, убедившись, что проблема разработки лишь в том, что не хватает ещё 1–2 таких же хороших разработчиков, и познакомив их с хорошими HR. У остальных тестов либо не было вообще, либо было несколько десятков громоздких, давно отвалившихся тестов, которые даже в CI никто не гонял.
Очень надеюсь, что по крайней мере в моём нетворке ситуация изменится после того, как мы с Никитой Соболевым проведём курс по тестированию на Python: после вебинара в среду курс купило уже 80 человек, так что интерес, видимо, есть.
Никита Соболев — лучший русскоязычный эксперт, которого только можно найти: член команды pytest, core-разработчик CPython, GitHub Star и вообще известный опенсорсер. Никита расскажет всё о тестировании, начиная с базовых инструментов pytest, поговорит о правильной подготовке данных, читаемости, надёжности и скорости тестов. Я тоже участвую — рассказываю, как внедрять тесты в командах, где их ни разу не было.
Если вас ещё не заразили автоматическим тестированием ПО — обязательно приходите, поможем. После курса у вас останется весь набор инструментов, чтобы внедрить тесты где угодно.
Смотреть программу →
До 12 марта действует промокод PYTEST на 10% скидки. Будем ли повторять — пока не знаем, так что если актуально — лучше покупайте сейчас. Можно оплатить из-за рубежа, а рублями — ещё и в рассрочку. От юрлиц оплату тоже принимаем, предоставляя полный комплект документов.
#вопрос Ты как-то упоминал о том, что если вкуришь TDD, то происходит сдвиг мышления. Поделись опытом, какого рода сдвиг произошел у тебя? Я пытаюсь разрабатывать c TDD, но во-первых сложно думать о тестах изначально, а во-вторых — качественных изменений в реализации я пока что не вижу.
Забавное совпадение — вопрос задали в декабре, когда мы начали обсуждать курс с Никитой, и только сейчас до него дошли руки.
Возможно это прозвучит странно, но если у вас получается писать хорошие тесты без TDD, то TDD вам и не нужен. Я сам довольно редко пишу все тесты до кода — обычно сразу пишу 2–3 теста, покрывающих happy path, а остальное дописываю уже вместе с кодом, когда понимаю узкие места, в которых код скорее всего может развалится.
Конечно, есть код, который по TDD писать получается гораздо быстрее — к примеру всякие форматтеры для чисел или текста типа таких: там проще сразу описать все возможные варианты поведения, а затем уже писать код, который удовлетворяет тестам. Получится «разработка методом перебора»: сначала написал тесты, а потом нажимаешь кнопки до тех пор, пока красная лампочка не позеленеет. Я почти не шучу — в таких случаях тесты снимают когнитивную нагрузку настолько, что чувствуешь себя обезьянкой с лампочкой.
Самое главное для чего я использую TDD — это дать новичкам почувствовать эту разницу на себе: один раз пописав код перебором, как обезьянка, начинаешь чувствовать себя неуверенно везде, где нет тестов. И довольно быстро понимаешь, что проверка работоспособности ПО — это задача для роботов, а человеку лучше думать про бизнес-логику и читаемость кода.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Школа: запустили новую LMS
Когда мы только запускались, студенты читали материалы из писем со ссылками на Notion — всем было норм. Потом собрали на коленке LMS — рендерили те же материалы из ноушена, но уже с профилем студента (для диплома), минимальной навигацией и кнопочкой сапорта, чтобы можно было задать нам вопрос.
Та, первая LMS, была одним из самых стыдных моих проектов с точки зрения программирования — хреновый код без тестов, хреновая вёрстка. Серьёзно — отдавая код нашему программисту Тимуру я переживал, что потеряю авторитет как руководитель компании. Теперь про старое позорище можно забыть — материалы красиво рендерятся на всех платформах, со светлой и тёмной темой, код покрыт тестами и сделан на совесть.
Пока проект был в разработке, для меня он был одним из многих в «Феде и Самате» — я просто следил как идут дела и иногда помогал Тимуру договориться с Марьяной. Когда проект закончился, и из техдира я прерватился в счастливого заказчика — я осознал, насколько школе повезло: вряд ли при наших размерах мы могли бы себе позволить полноценный отдел разработки. А аутсорс по себестоимости — вполне смогли.
Если покупали у нас курсы последние полтора года — найдёте всё в lms.tough-dev.school. Код, как и все проекты школы, — в нашем гитхабе.
Технологии: vue3, pinia, vitest, playwright.
Разработчик: Тимур Брачков.
Друзья, я знаю что среди вас здесь много тех, кто руководит программистами. Помогите пожалуйста хорошим людям с исследованием — пройдите небольшой опрос.
Там что-то вроде что-то разыгрывают среди ответивших, но наверное можно сделать и просто так.
Марьяна завела себе прикольную традицию — одной строкой рассказывать, как у неё в проектах идут дела, что нового\интересного случилось. Давайте попробуем это здесь?
— С Саматом доросли до двух ключевых клиентов и 20 человек в компании. За год мы выросли в два раза и не упали в качестве. Хоть и прощаемся сейчас с одним из клиентов — будем расти дальше.
— Запустили обучение на выстраданном курс «Анализ Систем». Материалами я доволен, хотя и недоволен количеством усилий, которое мы на них потратили: за год над текстами поработало 6 (!) человек, для нас это очень много.
— LMS: новая LMS в школе работает офигенно — у студентов нет вопросов, материалы рендерятся приятно глазам. Конечно огрехи есть, но они понятные, и их список — конечен.
— Недавно мы со своим хождением в приватное API ноушена стали попадать под капчу клаудфлера. Справились быстро, немного посомневались в идее юзать ноушен как бекенд для LMS, но решили что всё делаем правильно. Сейчас планируем ещё ряд продуктовых доработок.
— Сделал бухгалтерское открытие — оказывается в нашей стране электронный документооборот работает не только для юрлиц. Внедряем Контур.КЭДО, чтобы без бумаг обмениваться документами с сотрудниками. Горжусь что спрятал от команды ещё один бюрократический препон.
#вопрос Почему ты делаешь из vim IDE, хотя есть готовые IDE, в которые можно вставить vim?
Вообще я уже сейчас уже совсем мало пишу кода, но попробую ответить из полугодичной давности.
Во-первых, потому что могу. Несмотря на любовь к программированию и то, что я сам себе выбираю задачи — эта работа бывает для меня скучной, а значит выматывающей. Когда я пользуюсь инструментов, в котором я сам сконфигурил все нюансы, я получаю гораздо больше удовольствия от процесса, а значит меньше скучаю и меньше трачу сил.
Во-вторых, мне очень важна скорость и энергоэффективность. Скорость — потому что я ненавижу системы с плохим дизайном, которые тратят моё время на свои проблемы. Проиндексировать проект или загрузить все плагины — это работа IDE, а не моя. Так почему я должен этого ждать?
С энергоэффективностью тоже всё просто — я люблю покодить в кафе. Возможно на M1 всё стало побыстрее, не знаю — ни разу не запускал на нём ничего тяжёлого.
В любом случае я не призываю никого использовать редакторы текста вместо IDE — у нас в fands, к примеру, больше половины сотрудников пользуются продуктами jetbrains. Главное, в обоих случаях, — не жалеть времени на настройку инструментов.
Это был традиционный ответ на вопрос по понедельникам. Задать свой — fborshev@pm.me
В этот четверг проводим с Антоном Давыдовым стрим про будущий курс «Анализ Систем».
Мы проводим такие встречи уже год, со времён первого потока «Вы приняты» с Димой Рожковым. Для студентов — это возможность сделать превью и убрать сомнения: поговорить о формате обучения и о содержимом курса. Для нас — выровняться со студентами: всё ли хорошо рассказали на лендинге? полностью ли покрывает программа запросы?
Если сомневаетесь, стоит ли покупать курс — приходите 4 мая в 19:00. Ссылку на трансляцию выложим сюда. Записи не будет.
#вопрос вот бывает пишешь какому-нибудь занятому чуваку, типа CEO, а он не отвечает. Как тактично напомнить о себе?
Неответ — это тоже ответ. Поищете проблемы не в занятом чуваке, а в письме. Их не так уж и много — ваше письмо скорее всего или неинтересное, или сложное.
К примеру я не отвечаю на предложения купить рекламу в этом канале — мне это просто неинтересно. Занятый CEO наверняка не ответит вам на просьбу встретиться, если подумает, что вы захотите поговорить про технологии — для него это зона ответственности CTO.
Вторая причина — на ваше письмо ответить сложно. К примеру известный блогер вряд ли ответит на предложение прийти на очередную конференцию, если из этого предложения не будет понимать, какая там аудитория, и какие спикеры уже согласились. Занятый CEO большой компании вряд ли посмотрит ваше резюме на джуниорскую позицию — он скорее всего даже не знает, куда его форварднуть.
Так что если вам не отвечают — первым делом перечитайте письмо. Как можно сделать ваше предложение более интересным? Как можно сделать ответ на ваше письмо более простым? И только после этого — напоминайте.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Срочный контент
Любое медиа существует для просмотров. Полная зависимость от трафика — это то, что объединяет Медузу и RT, ваш любимый канал с мемасами и редакцию Пивоварова, Википедию и сайты с гороскопами.
Весь контент всех медиа можно разделить на два вида — срочный и веченозелёный. Срочный контент — это новости, мемасы на злобу дня: в общем всё, что не будет иметь смысла через год-полтора. Вечнозелёный контент — это тексты\видео, польза которых не увядает со временем. Скорее всего любой медиасайт, который вы откроете, будет состоять из срочного контента, а большинство авторских блогов (как этот) — наоборот, вечнозелёные.
Срочный контент не несёт пользы — если не считать пользой (ложную) уверенность в том, что мы понимаем происходящее. Вечнозелёный контент, наоборот, более полезен — повышает кругозор, наводит на размышления. Срочный контент потреблять гораздо легче — если бы я писал пост не о том, как правильно потреблять медиа, о новом сенсационном заявлении американского президента, до этого места дочитало бы в два раза больше людей. Дело — в дофаминовой системе, если интересно, погуглите лекции Анны Обуховой.
Я почти всю жизнь обходился без срочного контента — просто не интересовался новостями. Это не было осознанным шагом — мне просто было не интересно. Ковид в 2020 году и война в 2022 довольно сильно поменяли мой формат потребления — начиная с обзоров политологов я к концу 2022 года скатился в чтение коммерсанта и даже периодически заходил на медузу. Осознав эту фигню, я осознанно взялся за формат потребления и наглухо заблокировал все медиа через /etc/hosts (тг-каналов, к счастью, у меня не было). Вот уже 4 месяца, как я не прочитал и не услышал ни одной единицы срочного контента.
Сознание прочистилось — появилось место для размышлений о будущем, осталось больше сил на личные проекты и игру на гитаре, я начал чаще писать в дневник. Думаю, это было лучшим решением как минимум за последние полгода.
Очень советую — заблокировать десяток сайтов и отписаться от кучки каналов вам почти ничего не стоит. Через пару недель пропадёт привычка хвататься за телефон, через месяц — почувствуете качественные изменения во внутреннем диалоге.
Сервисы: cloudflare zero trust
Недавно открыл для себя гениальную вещь — cloudflare zero trust: замену рабочего VPN для 2023 года.
Обычно всякие внутренние админки прячут не только за логины\пароли, но и за фаерволы. В общем-то логично — если сольют пароль, фаервол — это ещё один рубеж безопаснсоти. Чтобы пройти через эти фаерволы, пользователи и программисты вынуждены ставить себе корпоративные VPN-клиенты вроде tunnelblick, все как один — кривые.
Zero Trust убирает необходимость в фаерволлах и VPN — вместо настроек IP-адресов и портов, мы начинаем думать на уровень выше: настраиваем доступы пользователей к приложениям. Подключиться к продовому постгресу, авторизовавшись через корпоративный гитхаб? Пожалуйста. Разрешить доступы в your-app/admin/ только для пользователей с почтой @your-app.com? Пара кликов мышки.
В основе лежит простое требование — все сервисы, которые требуют ограничения доступа, отдавать через cloudflare, дальше всё происходит само. Нам это супер-удобно — уже почти год весь трафик отдаём наружу только через cloudflared. Заодно это даёт ещё и дубовый фаервол: поскольку трафик приходит в шифрованном туннеле, поэтому можно закрыть вообще все входящие порты, кроме 22.
Если прямо сейчас проектируете новую корпоративную сеть — горячо рекомендую заменить VPN на Zero Trust, до 50 живых пользователей система работает бесплатно. Правда лендос у них состоит из какого-то корпоративного буллшита — чтобы понять, что эта штука умеет, нужно региться и ковырять интерфейс, но оно того стоит.
#вопрос Приучаю себя читать и теряюсь из-за количества книг. Кажется, что интересных книг больше, чем я могу осилить. Расскажи, пожалуйста, как ты выбираешь книги? Какую информацию считаешь самой ценной? Как ты понимаешь, какая книга принесет больше пользы?
Круто, что вы спросили не «как читать больше книг», а «как выбирать книги». Я сам когда-то свалился в состояние, в котором гнался за количеством, а не за качеством — прочитал за два года около 100 книг, вёл даже публичный список прочитанного. Потом начал сбавлять темп потому, что постепенно переставал чувствовать пользу от чтения. Перелом случился в 2020 году, когда я ушёл в собственный бизнес, где важнее оказались базовые человеческие качества — умение много работать и не ссать в неопределённости: я практически перестал читать нон-фикшн, дойдя по 1–2 книг в год.
Сейчас, открывая книгу, я чётко формулирую ожидания, к примеру «я читаю эту книгу Адизеса, потому что хочу подумать о стратегии роста школы как организации» или «я читаю эту книгу по личной продуктивности, чтобы сделать ревизию своих рабочих привычек и добавить себе уверенности». Если я не чувствую, что ожидания выполняются за первые 100 страниц — книгу выкидываю: есть много гораздо более полезных способов потратить время.
Ещё в вашем случае я бы посоветовал привязывать знания из книг к плану роста: скорее всего ваша цель — не достигнуть количества прочитанных книг, а стать более сильным профессионалом, и гигантский беклог скорее в этом помешает, добавив чувство вины.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Выбирать только лучшее
Мы в «Феде и Самате» заканчиваем переход с fastmail на gmail. Пока рефлексировал, подтвердил для себя старый принцип «не изъёбываться» — KISS работает не только в коде, но и в организации.
Раз уж мы столько вкладываемся в DX и в асинхронную коммуникацию без дейлков — то почему бы не потратить силы и на удобные инструменты? Fastmail, к примеру, не работает по IMAP без VPN и имеет довольно непривычный интерфейс после знакомого всем Gmail. Разница как между Basecamp и YouTrack: второй вроде и функциональный, но об UX явно никто не думал, сервис делали программисты для программистов.
С ужасом представляю, как живётся пользователям адовых отечественных комбайнов вроде Битрикс24 (серьёзно, в нём ведут разработку!) или огородиков с корпоративным Postfix/dovecot и ужасными вебмордами. Сколько времени пользователи тратят на работу, а сколько — на борьбу с окружением и сисадминами.
Хочу, чтобы в моей компании не было даже минимальных барьеров к продуктивности, поэтому всегда буду выбирать самые лучшие сервисы, и не жалеть времени и денег на переход.
Письмо самому себе
Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.
Первые две вещи настолько банальны, что на них не стоит останавливаться. А вот про письма в будущее расскажу подробнее.
Вы когда-нибудь задумывались, почему маленькое сообщение в телеграме заставляет людей отвлечься от интересной беседы или важной работы? Все дело в распространенной логической ошибке, которая называется привлекательность новизны. Грубо говоря, каждая последующая мысль пришедшая в голову, кажется более важной, чем предыдущая.
Если не сохранять внезапные мысли, то они будут улетать в бездонную пропасть. А если постоянно на них переключаться, то вы просто ничего не будете успевать — ведь рано или поздно вместо важной мысли вам придет голову идея проверить личные сообщения в фейсбуке, и вы проснетесь вечером в обнимку с котиками или очередной петицией против кровавого режима.
Чтобы не терять важное, я пишу письма самому себе. Как только в голову приходит любая мысль, которая не имеет отношения к тому, чем я занят сейчас, я ее записываю и отсылаю себе на почту. Мысль из головы сразу же уходит, и я возвращаюсь обратно к тому, что делал. Мысль не проебется — почту я проверяю периодически и полностью вычищаю ящик.
Раньше для для отсылки писем я пользовался программой на айфоне, которая так и называлась — Mail to Self. Однако со временем пришло понимание, что каждый клик понижает вероятность того, что мысль будет записана. Особенно Mail to Self страдала, когда хотелось отправить себе скриншот или фотографию.
Поэтому я пошел дальше и написал себе бота для телеграма — @selfmailbot. Бот делает простую штуку — все что я ему пишу, оказывается у меня на почте. Привычный интерфейс телеграма помогает лениться еще меньше и записывать вообще все, что приходит в голову.
Бот бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь. Если хотите скинуться на хостинг бота и живёте не в России — у меня есть патреон.
Не обслуживайте срочность
Недавно на Q&A «Есть минутки» мне задали вопрос — как вести асинхронную коммуникацию, когда кто-то нужен срочно — типа стенд упал, ветка не мёрджится или просто нужно срочно сделать задачу.
Конечно, когда что-то действительно нужно срочно — никакая асинхронная коммуникация не работает: надо писать, звонить и вообще разыскивать всяческими доступными способами. Однако меня смущает, что большинство людей воспринимают срочность как некую аксиому, типа «нам нужен чатик с девопсами, потому что они бывают нам срочно необходимы». Конечно, если системно не работать над происходящим в компании, все будут друг-другу срочно нужны.
Работа менеджера\тимлида состоит не в том, чтобы обслуживать срочность, создавая больше чатиков, а в том, чтобы её убивать: выделять время, чтобы сделать неломаемые стенды; внедрять gitflow, чтобы не было немёрджащихся веток; бить по рукам тем менеджерам, которые выдумывают срочность, потому что не доверяют людям. Такие причины устранить реально — у нас с Саматом в команде на 20 человек и несколько крупных проектов срочность бывает два раза в год при крупных релизах.
Не обслуживайте срочность — убивайте её.
Почему автоформаттеры — хорошо
Недавно обсуждал с одной командой внедрение prettier в один большой старый проект и услышал такое мнение — «автоформаттеры — плохо: когда никто за тебя не форматирует код, привыкаешь писать код сразу красиво, и они становятся не нужны». Я долгое время был приверженцем такого же мнения, поэтому не могу не написать об этом здесь.
Я передумал после того, как вспомнил, что бизнес платит программистам не за их умение писать код красиво (а ещё понятно, без ошибок компиляции и с правилами git-гигиены), а за решённые задачи. В идеальном мире — чем больше бизнес-задач решает разработка в момент времени — тем дороже она сто́ит. Как конвейер на заводе — чем больше он выпускает автомобилей в день, тем больше прибыли.
Как и на конвейере, в разработке работает бездушная автоматизация: пусть в кодовой базе будут некрасивые тернарные операторы и местами нелогичные переносы строк, зато любой новый джун может не тратить неделю на привыкание к кодовому стилю, и может сразу же писать код, который так же легко читается как код старичков.
К счастью, в отличие от конвейера, выгоду от автоматизации забирает себе не только бездушный капиталист. Всё-таки работа у нас творческая, и когда программист освобождает голову от форматирования, в ней появляется больше места на профессиональный рост или просто хороший отдых с близкими.
Так что внедряйте авторформаттеры — чем жёстче и бескомпромиснее, тем лучше.
Перестаньте ставить людей в копию
Часто руководители проектов жалуются, что их игнорируют: типа пишут клиенту в бейскемпе/на почту, а он не отвечает. При личной встрече вообще выясняется, что клиент и не открывал эти письма.
Скорее всего дело в том, что клиент не ожидает увидеть в письме ничего важного. Вот представьте, что коллега назначил вам встречу. Даже если нет повестки — вы всё равно понимаете, что человек не стал бы просто так тратить своё время. Наверняка у него и без вас куча дел, так что если он нашёл на вас 30 минут в календаре — скорее всего хочет чего-то важного. А теперь представьте, что этот же человек назначает вам не одну встречу, а сразу 40. Скорее всего вы решите, что он сошёл с ума и не придёте ни на одну из них.
То же самое работает с письмами. Если клиенту прилетает по 30 писем в день, в которых вы ставите его в копию, просто «чтобы был» — на третий день он начнёт эти письма игнорировать. Добавите его в чат со 100 сообщениями в день — он перестанет его читать. Начнёте звонить по 10 раз в день — перестанет брать трубку.
Приучайте людей, что ваши сообщения стоят дорого — если уж вы что-то написали, то пусть это будет важным. Если ставите людей в копию — проследите, чтобы они понимали, что вы от них хотите: «Иван, пожалуйста посмотрите юзер-стори — это то, что вы ожидали?»; «Ольга, скажите пожалуйста, это не противоречит требованиям юристов?». Если не можете объяснить, но твёрдо уверены, что человек должен увидеть ваше письмо, попробуйте формулу «вы в копии потому что ...»: «Сергей, вы в копии потому, что это касается информационной безопасности». «Ксения, вы в копии потому, что это касается новостного раздела сайта».
За последние 4 года я глубоко погружался в работу двух десятков команд: говорил с бизнесом, тимлидами и программистами, анализировал проблемы, что-то менял. Где-то получалось успешно, где-то — не очень, но что я точно приобрёл за это время — это насмотренность и умение отличать настроенные команды от разболтанных.
Для бизнеса настроенная команда выглядит почти как конвейер: ставишь задачу, получаешь сроки. В течение этих сроков тебе прозрачно рассказывают, что происходит и заранее предупреждают, если что-то идёт не так. Даже если сроки смещаются — в конце ты получаешь результат с предсказуемым качеством. Разболтанная команда похожа на фрилансера: с лёгкостью принимает задачи, обещает сделать до завтра, а потом у неё заболевает бабушка и команда сдаёт говно или просто пропадает.
О разнице в устройстве настроенных и назболтанных команд можно говорить бесконечно — тут и техдолг, и контроль ритма, и инженерная культура. Но если бы мне нужно было отличить настроенную команду от разболтанный, задав всего один вопрос — я спросил бы как у них дела с тестами.
Тесты говорят одновременно и о качестве кода (без тестов легче писать лапшу), и об уровне планирования (у плохого руководства тесты первом делом летят под нож). Но самое главное, что гарантируют тесты — предсказуемость. Когда один человек пишет код, а работоспособность его решения проверяет другой — у команды нет однозначного индикатора, что задача решена: он повисает где-то а коммуникации между этими двумя людьми. Другое дело — зелёная галочка в гитхабе: запушил код и сразу видишь, насколько он работает. Больше не возьмёшься за новые задачи, не закончив старые — а значит не будешь переключать контексты и (в очередной раз) обманывать бизнес.
3 года назад я сделал вебинар о тестах, который просмотрело несколько сотен человек, делал много стримов, где в живую показывал TDD, а сейчас мы с Никитой Соболевым запускаем большой курс о тестировании в Python.
Первый урок курса — бесплатный, проводим его в эту среду. Сделали его бесплатным, потому что вебинар содержит базовые знания, которые должны быть вообще у всех питонистов. Никита расскажет о моках и стабах, фикстурах и параметризации. Я расскажу о менее измеримых штуках: для чего мы пишем тесты, почему люди думают, что без тестов быстрее, и что вообще такое хороший тест.
Запись будет доступна только тем, кто придёт на курс. Если хотите просто посмотреть — приходите вживую в эту среду в 18:00 MSK, только сначала запишитесь у @tough_dev_bot — он пришлёт вам ссылку на вебинар.
Как я могу сделать себе интересно?
Бывает нужно сделать задачу, а она — ну вот совсем скучная: досконально знаешь технологию, представляешь все подводные камни, знаешь даже как лучше поговорить с бизнесом, чтобы задача не раздувалась. Я обычно в таких ситуациях чувствую отвращение — кажется, что трачу свою жизнь на что-то неважное.
Такое бывает не только на работе — дома тоже нужно делать скучные линейные бытовые дела.
Самый хороший способ справиться с этим — сделать себе интересно. Если мне нужно в пятый раз написать похожий плейбук в Ansible — я не стану монотонно повторять работу, а изучу новую тулзу вроде mitogen или придумаю какую-нибудь элегантную автозамену для новых правил ansible-lint. Если надо помыть посуду — можно придумать, какой подкаст послушать. Чтобы не скучать при уборке — посидеть и повыбирать самый подходящий в мире пылесос, чтобы его использование всегда приносило радость.
Буквально — задаём себе вопрос: «а как я могу сделать эту работу для себя интереснее?». Главное — не перестараться: на работе мы всё-таки находимся не чтобы нам было интересно, а чтобы решать задачи работодателя. Но если дать себе правильную дозу интереса — задачи решаются гораздо быстрее и лучше.
Сейф Бекап
Мы с Саматом запустили новый сервис для мониторинга бекапов — safe-backup.ru.
Это такая замена healthchecks.io для тех, у кого серверы стоят в России. Кто не знает, healthchecks.io — это сервис мониторинга бекапов, который работает по принципу мёртвой руки: скрипт бекапа периодически уведомляет нас, что всё хорошо, а если уведомления перестают приходить — мы присылаем алёрт.
Такая система позволяет с большой вероятностью отловить типичные ошибки: пропало соединение с хранилищем бекапов, закончилось место на диске, сменились креденшелы доступа к базе, — всё это ведёт к тому, что скрипт бекапа не дорабатывает, а значит не присылает нам уведомление.
Пока автор оригинального сервиса не сошёл с ума, я использовал его во всех своих системах, адаптировав несколько опенсорс-решений — для PostgreSQL или для файлов на диске. Сейчас везде, включая borg, я просто поменял адреса вебхуков — сервисы совместимы на уровне API.
Конечно, по дороге мы решили несколько косяков оригинала — к примеру сделали удобные уведомления через телеграм.
Приходите на бета-тестирование — в течение первого месяца можно добавлять неограниченное число сервисов и уведомлений. Скоро добавим уведомления по СМС и оплату картами или по безналичному расчёту.
Посмотреть лендос →