25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
Анализ систем и распил монолитов
Оглядываясь на прошлое лето, когда мы решили сделать продолжение «Асинхронной Архитектуры», я чувствую себя продюсером «Безумного Макса 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.
Разработчик: Тимур Брачков.
Друзья, я знаю что среди вас здесь много тех, кто руководит программистами. Помогите пожалуйста хорошим людям с исследованием — пройдите небольшой опрос.
Там что-то вроде что-то разыгрывают среди ответивших, но наверное можно сделать и просто так.
Преимущество интровертов в коммуникации
Где-то слышал теорию, что стеснительным замкнутым интровертам в конечном счёте общение с людьми даётся легче, чем общительным экстравертам.
Идея в том, что экстраверты с детства умеют считывать движения тела, мимимку и интонацию — для них это такой же естественный навык, как жевать или ходить пешком. А интровертам приходится постигать всё это вручную: наблюдать, какое поведение за какой мимикой следует, как настроение у людей меняется в зависимости от внешних воздействий. Верю в это потому, что у меня происходит именно так — умение понимать эмоции людей пришло только с возрастом, тренировкой и психтерапией.
Получается, что интроверты умеют прокачивать эмпатию, а экстравертам — столько эмпатии дано, столько и останется: не будете же вы учиться точнее жевать или ходить, если уже делаете это на достаточном уровне.
Среди программистов очень много интровертов, и мне давно хотелось помочь им стать более общительными — чем лучше программист ведёт коммуникацию, тем более полезен он для бизнеса, да и для человечества в целом: быстрее закрывает задачи, пишет более релевантный бизнесу код, проще организует коллег. Самая свежа наша с Марьяной работа на эту тему — курс «Есть минутка», в котором целая неделя посвящена проблемам с коммуникацией (см. выше).
Это я всё к тому, что сегодня — последний день, чтобы запрыгнуть в групповой тариф и попасть в чат людей с такими же проблемами/задачами. С завтрашнего дня можно будет купить только самостоятельный тариф.
Приходите
Первый лонгрид «Есть минутка»: что вошло и ласт-колл в «Закрытый клуб»
Мы на финишной прямой с первым лонгридом «Есть минутка». Переписывали его втроем с нуля 4 раза. И еще не знаю сколько раз по кускам. Да и кого я обманываю — будем подкручивать пока не отправим. Собрались одни перфекционисты.
В один момент Ира Парфенова написала мне «Марьяна, надо созвониться, потому что мне кажется, что я книгу пишу, настолько он объемный». Я думала, что она шутит, но потом когда начала читать — подумала, что правда похоже на книгу. Как оказалось, это она только треть написала.
Нам важно, чтобы в лонгриде была концентрация пользы, ни на что не отвлекаться. Только читать и применять. Поэтому пришлось перебрать несколько вариантов подачи. В итоге пришли к простой форме сборника проблем-решений. Мне нравится, что можно прыгать сразу на нужную тему и не читать целиком, если в моменте нет потребности. Полностью отвечает нашему запросу «курс-аптечка». Бери только то, что нужно.
Всего получилось 6 ключевых проблем:
— Мы друг друга не понимаем. Причины: 1/ разные ожидания и вводные, 2/ разговор на разных уровнях коммуникации. Упоминаем модель 5 уровней коммуникации Джона Пауэла и учимся фиксировать и проговаривать ожидания.
— Мне сложно из-за непредсказуемости поступков людей. Причина: не понимаем свои и чужие эмоции и чувства. Учимся распознавать эмоции по модели Плутчика и привываем привычку не задавливать эмоции и выражать их, даже негативные. Как тоже рассказываем.
— Меня часто продавливают. Причина — личные границы: либо не определили, либо не умеете отстаивать. Даем инструкцию и шаблон как выстраивать личные границы и защищать их. Спойлер: сначала нужно разобраться со своими потребностями. Опираемся на книгу «Сила личных границ» Шэрон Мартин.
— Конфликты: часто избегаю и нападаю, когда уже нет сил терпеть. Причина: конфликт — это следствие того, что что-то не так с коммуникациями. Это либо слова тригеры либо вышеперечисленные проблемы. Учимся не бояться конфликтов и не чувствовать вину после. Разбираем круг конфликта Кристофера Мура и матрицу стратегий поведения в конфликте Томаса-Килмена.
— Мне сложно просить и говорить на неудобные темы, например о зарплате. Причина: страх оценки. Разбираем структуру неудобных разговоров и даем алгоритм действий, чтобы было не страшно просить.
— Я делаю работу на отлично, но этого никто не замечает. Причина: не умение рассказывать о своей работе. Разберём причину страха, последствия советского воспитания и расскажем о принципе «Покажи свою работу» Остина Клеона.
Этот лонгрид мы пришлем вам 1 февраля, остальные два с ритмом раз в неделю. А в этот четверг позовем в чатик участников Закрытого клуба (так называется один из тарифов), где будем знакомиться, обсуждать ваши проблемы, чтобы успеть скорректировать контент под вас. В процессе же обучения в чате будем отвечать на вопросы и делиться обратной связью. А в конце — устроим Q&A-сессию, чтобы обсудить то, что сложно было вынести в чат.
Этот тариф мы придумали, чтобы делать курс в диалоге с вами. Он же про коммуникацию, как не крути. Правда продается закрытый клуб только до 1 февраля. После мы закроем его и больше никогда не откроем для покупки. Поэтому если хотели получить обратную связь и повлиять на контент курса — велкам. Осталось меньше недели.
Тариф Аптечка и Юрик будут продаваться и позже, но скорее всего поднимем ценник, потому что пользы получается намного больше, чем мы планировали изначально.
Записаться →
Ночные рейсы
Одна из привычек, которая появилась у меня после 30 лет — не покупать ночные рейсы.
Идея ночных рейсов — довольно привлекательная: ты экономишь деньги, вылетая в 03:45, а аэропорт получает чуть более ровную загрузку. Но это же глупость! Во-первых, время — я, как дисциплинированный пассажир, приезжаю в аэропорт за два часа до вылета. Днём я трачу свободное время в аэропорте на работу — просто открываю ноутбук и делаю накопившиеся дела. В час ночи, я так сделать, увы, не могу — голова не работает.
Во-вторых — внимание к цели маршрута. После ночного перелёта всё, что хочет нормальный человек — это отоспаться. Получается, что если я лечу в отпуск, то отпуск должен быть на один день больше. Если лечу по делам — дела занимают на один «отсыпной» день больше. А я мог бы потратить этот день на что-нибудь полезное — хорошо отдохнуть и поработать.
Вряд ли разница в стоимости билетов (пусть она будет хоть 30%) стоит больше, чем деньги, которые я могу заработать за счёт того, что не перехожу в состояние сонной коровы.
Вечное преимущество того, кто не делает
Бывает такое — получаешь на код-ревью десятое замечание подряд и злишься на себя, типа нифига не шаришь. Вот ревьюер — крутой чел: вон сколько полезных замечаний даёт.
Такое бывает во всех сферах — когда ведёшь машину с инструктором, показываешь свежий текст напарнику, сдаёшь дизайн арт-директору. И всегда легко на себя разозлиться, особенно когда замечания справедливые — ну как же так, почему все понимают лучше меня.
Чтобы с этим справиться, мне помогает осознать, что у человека, который не делает, всегда есть нечестное преимущество — взгляд со стороны. Ревьюер не участвовал в работе: код, над которым ты страдал три дня, он увидел в первый раз — и конечно свежим взглядом ему легко находить проблемы. И конечно он не попадал в ловушку overthinking, когда три дня не думал над задачей.
Ты и сам с такой же лёгкостью будешь искать проблемы, если отложишь код\текст\дизайн на 3 дня и посмотришь заново.
Когда я даю десяток замечаний на один пулл-реквест, это не значит, что я какой-то супер-выдающийся программист: я просто смотрю свежим взглядом. И если нас с автором ПР поменять местами — далеко не факт, что я получу от него меньше замечаний, чем он от меня.
Срочный контент
Любое медиа существует для просмотров. Полная зависимость от трафика — это то, что объединяет Медузу и 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.
Конечно, по дороге мы решили несколько косяков оригинала — к примеру сделали удобные уведомления через телеграм.
Приходите на бета-тестирование — в течение первого месяца можно добавлять неограниченное число сервисов и уведомлений. Скоро добавим уведомления по СМС и оплату картами или по безналичному расчёту.
Посмотреть лендос →
#вопрос Возник вопрос философского характера: надо ли разработчику/тимлиду прям знать досконально язык программирования?
Меня часто мучает синдром самозванца, что я вроде что-то умею, а посади меня без интернета и ощущение, что я ничего не могу написать. Хотя вроде бы продукты делаются, работа ведется, клиенты довольны.
Я в основном работаю на питоне и, например, в pandas я знаю как она работает и что где искать, но на вскидку, с листа группировку с аггрегацией скорее всего не напишу. При этом это не вызывает какого-то рабочего дискомфорта. Скорее психологический.
———————
Ну, даже если вы напишете код без интернета, вряд ли вы сможете без интернета его задеплоить :-)
А если серьёзно — у вас всё отлично. Для тимлидской роли софтскиллы гораздо нужнее — лучше уметь планировать проекты, организовывать работу и договариваться с людьми, чем знать как ковариантность отличается от инвариантности в типизации динамических языков.
Для разработчика — тоже: широкий кругозор гораздо важнее глубоких знаний. Представьте, что вы досконально знаете какие-нибудь asyncio.queues из стандартной библиотеки питона, но не понимаете, чем распределённый лог отличается от распределённой очереди, и вообще ничего знаете про типизацию событий в асинхронных системах. Если действительно, не сажать людей кодить без интернета, то код программиста, знакомого с асинхронными системами в целом, будет гораздо лучше для бизнеса, чем код программиста, идеально знающего одну из реализаций.
В эмоциональном плане я разделяю вашу тревогу. Сам уже пару лет не писал фронтенд, и чувствую себя неуютно, глядя как наши ребята размахивают новыми тулзами вроде vite, pinia (да и composition API, что уж там говорить). Успокаиваю себя тем, что моя роль в компании — совсем другая: найти человека, который знает современный фронт гораздо легче, чем человека, который может отвечать за целый бизнес сразу, включая финпланирование и работу с госорганами.
Если паритесь по поводу своих знаний — попробуйте расписать на бумаге свои обязанности в компании. Вряд ли у вас получится много связанного с доскональным знанием ЯП, но вангую, что найдёте как минимум 2–3 пункта, которые кроме вас не может сделать вообще никто.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Марьяна у себя рассказала о первом письме курса.
Когда я работал над программой, представлял в голове собирательный образ из всех программистов, которых встретил за последние пару лет — и из нашей команды, и встреченных в консалтинге. И задаю себе вопрос — о чём бы мне хотелось им рассказать, чтобы облегчить их жизнь?
В очередной раз поняв, что большинство проблем — в голове, для первого письма мы с Марьяной пригласили Ирину Парфёнову, которая рабоатала с нами на курсе «Самому не проще». И вот что получается:
Косвенные расходы на встречи
Пустые встречи жрут ресурсы: календарное время и внимание, вырывая программистов из состояния потока. Это все знают и давно научились экономить, кто как может: назначают встречи покороче, ставят их впритык. Но кроме прямых расходов времени есть ещё и косвенные расходы — затраты внимания.
Для себя я называю это «календарь давит». Когда у меня в день назначено две встречи — одна на 14:00, другая, скажем на 18:00 — время между этими встречами я проведу в гораздо более неспокойном состоянии, чем обычно: не начну сложных задач (нафига, потом всё равно из потока вырвут); не уйду гулять (вдруг пробки, опоздаю!). Даже одна встреча в день уже сто́ит мне внимания и ухудшает концентрацию.
Чтобы календарь не давил, я делаю две вещи:
— Уменьшаю количество ad-hoc встреч. Вместо «давай созвонимся и обсудим» я назначаю регулярные встречи с теми, с кем часто созваниваюсь.
— Группирую такие встречи по дням. У меня это вторники и четверги.
Это позволяет мне иметь «дни встреч», в которые я занимаюсь только разговорами и разрешаю себе не делать ничего другого.
В школе у нас с Марьяной почти нет ad-hoc встреч — есть одна регулярка в неделю. В сложные периоды, к примеру когда готовим новые курсы — делаем две. В тихие периоды бывает отменяем регулярку и не разговариваем по две недели. В аутсорсе у меня вообще нет нерегулярных встреч с руководителями проектов: вместо этого я встречаюсь с ними раз в неделю, а с кем-то — и раз в две. Это позволяет мне поддерживать голову в чистоте и иметь дни, в которые я могу спокойно погулять\подумать или весь день потратить на потоковую работу.
О расходах на встречи и чаты, психологических причинах провала сложных встреч и способах максимально простого ведения коммуникации говорим на курсе «Есть минутка». В курсе 3 письма — одно теоретическое (эмоции, особенности восприятия) и два практических — о чатах и про встречах. Приходите до 1 февраля: тариф «закрытый клуб» с чатом и Q&A-сессиями мы продаём только сейчас, потом его не будет.
Смотреть программу →
Ещё немножко про авралы
Кстати, подтверждение мыслям из «Русской Модели Управления» о том, что люди не работают без авралов, я встречал в совершенно разных местах.
Вот, к примеру про крестьян до революции, у Акунина:
«Полевые работы в основном приходились на три напряженных, но довольно коротких периода: посев, покос, сбор урожая. В остальное время года, особенно зимой, наступал период затишья. Ключевский пишет: «Так великоросс приучался к чрезмерному кратковременному напряжению сил, привыкал работать скоро, лихорадочно и споро, а потом отдыхать в продолжение вынужденного осеннего и зимнего безделья. Ни один народ в Европе не способен к такому напряжению труда на короткое время, какое может развить великоросс; но и нигде в Европе, кажется, не найдем такой непривычки к ровному, умеренному и размеренному, постоянному труду, как в той же Великороссии»
Такой же крестьянский подход прививают традиционные ВУЗы: большую часть времени студент, особенно на старших курсах, бездельничает, чтобы во время сессии напрячься, прочитать все книги за ночь и кое-как сдать экзамен.
Я против авралов: даже если отбросить чисто человеческие чувства о том, что загонять людей в авралы — это унижение. Авралы плохо влияют на качество кода. Команда с ровной и спокойной нагрузкой без давления практически сразу даёт гораздо более короткий time2market, чем нагруженная и авральная.
Так что давайте не считать программистов крестьянами и студентами — скорее это марафонцы или рабочие на пятилетнем долгострое.