FEDOR BORSHEV

System Design на собеседованиях в большие компании наносит больше вреда, чем пользы. Алгоритмы хотя бы не заставляют делать ничего плохого — от того, что ты научился на бумажке находить пересекающиеся интервалы или обходить графы, ты хотя бы бизнесу не навредишь. А вот программист, который профессионально умеет городить сложные системы на ровном месте — навредит, особенно когда ему ещё на этапе собеседования показывают, что компания именно этого от него и ждёт. Системы с собеседований никак не связаны с реальными бизнес-требованиями: ведь собирать их и осмысливать явно дольше, чем длится время собеседования. Да и ценность хорошего архитектора не в том, чтобы делать сложные вещи, а в том, чтобы придумывать простые, когда бизнес настаивает на сложных. Мы запускаем третий поток курса «Анализ систем», который как раз об этом — как собирать бизнес-требования и делать максимально простые системы, которые их выполняют. Для этого мы много говорим о стратегическом анализе бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций, писать документацию. Изначально мы задумывали курс ради четвёртого урока, в котором мы дали пошаговые рекомендации по распилу монолитов, но сейчас поняли, что гораздо важнее мета-навык — умение слушать бизнес и не делать лишнего. Стартуем 13 июня, учимся 5 недель. Учиться рекомендуем в тусовке — наблюдая за чужими домашками, вы вынесете из курса гораздо больше знаний, чем если просто прочитаете материалы. До вечера четверга действует промокод SAD10 на 10% скидки. Если вы принимаете даже самые маленькие решения по организации кода или взаимодействию систем в организации — ждём вас на курсе. Если хоть чуть-чуть общаетесь с бизнесом — тоже. Джунам на курс рановато. Если сильно верите в себя — берите не выше самостоятельного тарифа.

Ненавижу Metabase Мы в школе активно используем Metabase — и для управленческой отчётности, и для операционки: взаиморасчётов с экпертами, проверки домашки и ещё кучи ad-hoc задач. Прежде, чем писать код для полноценных интерфейсов, всегда пробуем решить проблему на Metabase. Но вот как этот инструмент сделан для администратора — это просто отвратительно. К примеру их команда тратит кучу сил на то, чтобы данные можно было ковырять без знания SQL. Идея крутая — типа дадим пользователям все данные, а они уже сами себе соберут дешборды. Но вот реализация просто отвратительная — все эти инструменты не работают даже на нашем простом сетапе. К примеру, хочу отдать юзерам данные по покупкам, в этих данных должна быть довольно тривиальная штука — деньги, которые к нам реально пришли от покупки — за минусом комиссий эквайринга и налогов в стране, из которой он сделан. Вроде бы для этого есть Модели — такие материализованные вьюхи, куда можно зашить всю логику, а потом уже использовать их. Но эти модели не работают! Может быть один раз данные из них получить и можно, но вот построить из них более или менее полезный дешборд уже не получится. Данные в моделях нельзя нормально фильтровать, с ними не получается писать SQL: итоговые запросы получаются настолько корявыми, что когда они падают, нет никакого способа их отладить. То есть у ребят получились материализованные вьюхи, которые толком не работают, да ещё и материализуются где-то вне БД, то есть не контролируются миграциями. Кажется, что выходить с уровня БД на уровень приложения и описывать модельки на языке метабейза стоило бы ради довольно полезной функциональноси, которую умеют все крутые BI — джоинов из двух БД одновременно. Но этого похоже не будет никогда. В итоге так мы и пишем SQL-запросы, выводя их результаты в дешборды. Получается грустно — у нас нет нормального data lake, и мы делаем выборки просто с продовой базы, а значит не можем делать серьёзные изменения в структуре данных, не сломав всю аналитику. Раз в год я пытаюсь заюзать фишки метабейза, которые позволяют избавиться от этой зависимости, трачу на это 3–4 часа и бросаю. Может посоветуете замену, которая подходит маленьким ребятам, которые пока не доросли до выделенных ETL-пайплайнов? Или уже доросли и пора делать?

#вопрос Насколько вы часто пользуетесь электронной почтой? Кажется, что этот инструмент уже рудимент, покрытый десятками непрочитанных писем у миллионов пользователей. Почта — мой основной рабочий инструмент уже лет 15. Я исповедую пустой инбокс, и настроил всё так, что мне туда падают все рабочие уведомления: из гитхаба, бейскемпа, и даже из банка. Самое главное для меня в почте — это то, что она аггрегирует в одном месте вообще всё, что надо сделать. Не нужно проверять десяток чатов и открывать 3 задачника, чтобы посмотреть, что меня ждёт. А удаляя обработанные письма, я вообще достигаю кристальной чистоты: в этом канале нет вообще ничего лишнего — если я ответил на письмо или сделал задачу, я его никогда больше не увижу. Конечно, многие люди действительно относятся к почте, как к помойке — хранят в инбоксе по 20 000 пустых писем от маркетплейсов, сервисов и госуслуг, а для рабочего общения предпочитают рабочие чатики. Раньше я жёстко топил против рабочих чатов и даже пытался их запрещать в своей компании. Сейчас успокоился — если человек хочет работать с загаженным сознанием — не мне его отговаривать. Единственное, что я сейчас делаю — создаю среду, дружественную для таких, как я — плачу за бейскемп с его супер-удобным Hey (не почтой) и разделением синхронной а асинхронной коммуникации через Campfire, и за гитхаб, который позволяет гибко настраивать потоки уведомлений. Ну и периодически напоминаю, что срочно отвечать никому ни на что не нужно. Это был традиционный вопрос по понедельникам. Задавайте свои на [email protected]

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

#вопрос Расскажи, какие технологии и знания помогли уйти в собственный бизнес? Кажется это уже третий или четвёртый вопрос на тему перехода из работы по найму в собственный бизнес. Я не чувствую здесь серьёзной экспертизы и слабо понимаю, кому и как мой опыт может пригодиться — поэтому это точно последний ответ, простите. Знания хардовых технологий вроде python/js мне не помогли совсем — я очень мало написал коммерческого кода для клиентов: может быть за всё время потратил несколько недель. Причём, если бы умения писать код у меня не было — я бы обошёлся и без них. Возможно помогло понимание devops и любовь к DevEx — с самого начала существования аутсорса мы делали программистам удобно: юзали удобные хостинги вроде heroku\netlify (сейчас перешли на vercel), много вкладывались во внутреннюю разработку. За счёт этого достигли довольно высокой для аутсорса рентабельности — программисты у нас работают действительно эффективно. Больше всего наверное помог просто жизненный опыт — умение слышать бизнес и понимать желания программистов, умение отличать хороших исполнителей от плохих. Из нетехнических навыков здорово помогла общая продуктивность: приходилось делать много неочевидных, скучных, но очень важных задач, вроде общения с бухгалтерией и банками, финансового планирования и учёта. Самый неочевидный навык, который мне помог в аутсорсе — умение письменно выражать свои мысли. Использую его постоянно — от внутренних регламентов до публичных анонсов наших проектов (хотя последние пишут уже сами ребята). Без умения писать точно было бы гораздо сложнее. Это был традиционный вопрос по понедельникам. Задавайте свои на [email protected]