Databases in 2024: A Year in Review

Да, ещё один пост о базах :)

Любопытная, лёгкая и иногда захватывающая статья, посвящённая ретроспективе в области баз данных за 24 год.

Начинает автор с забавного: как Redis поменял лицензию более строгую, а Elasticsearch, наоборот, откатился на более открытую лицензию. Причиной всему облачные провайдеры, типа AWS, которые берут продукты и начинают их поставлять как сервис, тем самым мешая зарабатывать деньги компании-разработчику базы.

От себя добавлю, что уже давно есть более интересные альтернативы редису, о которых мы писали: DragonFly и KeyDB.

Продолжая статью, автор переходит в категорию "захватывающее" – о борьбе Snowflake и Databricks. Эти взаимоотношения можно описать, как в той самой поговорке про жабу и гадюку. В результате такой конкуренции продукты улучшаются и нам, как потребителям, это, конечно, на руку.

В этом году особенно часто на моём радаре появлялась DuckDB, которая упоминается в статье. Интересная база данных для аналитических запросов. Легко поднимается, написано куча расширений для Postgres, в результате достаточно просто начать использовать.

В оставшейся части статьи автор рассказывает набор новостей и фактов о самых различных базах, которые, наверняка, многие пропустили. Их тоже интересно посмотреть.

#database

Пятничное развлекательное – инди-игра Braid

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

В прошлом году вышло дополнение Braid, Anniversary Edition. Я пропустил, планирую наверстать. Обещали новую графику и музыку (блин, куда лучше-то? Изначально было идеально!), доп контент от разработчика, и даже новую локацию — но про новую локацию фактуры найти не смог, мб её и нет.

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

Мировой рекорд спидрана 22:56, а TAS 18:45 (Tool-assisted speedrun, когда кнопки жмёт бездушная машина). Но игра настолько красива, что её уж точно не хочется заканчивать быстрее.

#games

The implementation of Rewind in Braid

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

Предлагается занятный вариант реализации – давайте хранить весь мир и его состояние сериализовать. И дальше куча хаков для оптимизации: неизменяемые объекты хранить в единственном экземпляре, фоновые частицы (чисто визуал, условно листья на заднем фоне) перегенерировать в похожем виде на основе случайного числа и текущего времени. Состояние мира хранится в виде цепочек с опорными кадрами (похоже на кодирование видео). Тут я не совсем понял, он предлагает хранить состояние целиком, а не разницу кадров.

Потом обсуждается хранение звука при перемотке. Завершает доклад ещё одна хитрая оптимизация. В раунде с кольцом замедления его способ хранения "примерного" состояния фоновых частиц не работает. Пришлось отдельное решение делать. Приятного просмотра!

#youtube #systemdesign

Задача на собеседовании — проектируем динамическую фильтрацию

Проводили собеседование на разработчика. Задачу для технической части взяли из практики, то есть это прямо то, чем в будущем предстояло заниматься собеседуемому, разве что с упрощением предметной области для понятности. Задача такая:

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

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

После уточнения задачи получаем следующие вводные:
— имеется клиент-серверное приложение интернет-магазина с возможностью поиска товаров

— количество записей в результате поиска может доходить до 1кк

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

— у разных категорий товаров разный набор фильтров

— после применения конкретного фильтра появляется новая выборка и для нее также должны отображаться только актуальные фильтры
Рассмотрим пример. Для телефонов должны быть фильтры "производитель" и "операционная система". После применения фильтра "производитель: Apple" в фильтрах ОС уже не может быть значения Android.

— для каждого значения фильтра необходимо отображать количество подходящих товаров. После выбора одного фильтра все счетчики должны пересчитываться.
Было "производитель": "Apple: 10", "Xiaomi: 20", "Встроенная память": "128 Гб: 10", “256 Гб: 20". Выбрали "128 Гб", после применения станет, например, "производитель": "Apple: 7", "Xiaomi: 19". То есть 3 модели Apple и 1 модель Xiaomi не попали под выбранный фильтр.

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

Как на настоящем собеседовании, уточняющие вопросы можно задать в комментариях. Наше решение задачи в 15:00 понедельника.
#devfm #systemdesign #резюме

State of Developer Ecosystem Report 2024

С 2017 года JetBrains проводит опросы, на базе которых готовит отчёты о состоянии индустрии. В 2024 году опросили 23к разработчиков. В отчёте есть разное интересное, имеет смысл ознакомиться с ним целиком. Мы же с вами посмотрим на отдельные моменты, которые сами считаем самыми примечательными.

Наш разбор результатов 2024 года читайте в статье. Ниже часть выводов оттуда.

Интересен блок с планами про языки программирования. Основной язык Python у 35% разработчиков, ещё 6% планируют его использовать. Самые большие планы на внедрение у Go (10%) и Rust (11%). Интересно, реализуется ли это. На рынке РФ вроде Rust не очень востребован.

Не использует виртуализацию всего 25% респондентов. 50% живут с докером, дальше есть нюансы. Удивлён, что не 90%.

Проникновение искусственного интеллекта в разработку довольно сильное. 70% пробовали, а 50% постоянно используют ChatGPT. Можно позалипать на цифры постоянного использования у других игроков: 26% у GitHub Copilot, 7% Google Gemini, 5% JetBrains AI, 3% Anthropic, 1% Tabnine, 2% локальный AI, 3% Codeium, 1% Blackbox AI. 1% Llama, 1% Gemini, 1% Cursor. Есть куда расти. Про остальных игроков я не слышал.

Занятная статистика по профиту от ИИ. Теперь ИИ является не только чатботом, но и заменой поисковику, помощником кодера, автоматизатором рутинных задач. Интересно, а есть ли уже бот, который code review в MR проводит? Если кто такое видел или использовал, поделитесь впечатлениями.

В блоке Developers' Life интересная статистика про затраты времени на код и на коммуникацию (созвоны, чаты, почта). Вроде опрос разработчиков, но 5% ребят тратят на код меньше 20% времени.

Интересен вопрос "самая сложная часть вашей работы". 38% отмечают понимание потребностей пользователей, 34% коммуникацию с командой (и ещё 16% с другими разработчиками). Проблема 32% в разборе чужого кода, и у 16% проблема в отладке. Непосредственно в написании кода сложности только у 15%, и в первую очередь эту часть сможет взять на себя ИИ. Остальные сложности, вероятно, пока останутся. А вообще всё выше подводит нас к важности софт скиллов, и об этом мы стали чаще писать. При этом 50% разработчиков работают в команде всего лишь из 2-7 человек. Одиночек 8%.

А в 2022 году мы обсуждали Stack Overflow Developer Survey.

#trends

Когда ИИ заменит разработчиков, то...

Татьяна aka IT DIVA пишет о негативных последствиях замены миддл-инженеров на ИИ. О таких планах заявил Цукерберг на интервью у Джо Рогана (новость, оригинал подкаста на ютубе на 02:07:32). Конкретно прогнозам Цукерберга я бы особо не верил, потому что его мета-вселенные провалились. Но указанная тенденция действительно существует.

Если кратко резюмировать прогнозируемые Татьяной последствия от замены миддлов на ИИ, то получим примерно следующее (рекомендую прочитать пост целиком):
1. Если убрать с рынка джунов и миддлов, то мы усложняем будущий найм сеньоров.

2. Текущая кодовая база и так сложная, а написанный ИИ код будет ещё сложнее. Плюс на большом проекте добиться от ИИ результата будет сложнее.

По первому вопросу полностью согласен. Компаниям в среднем не нужны джуны, потому что обычно не способны выдавать результат, они отвлекают более опытных товарищей и джуны являются скорее инвестицией в будущего сотрудника, чем рабочими руками. Если будет ИИ-джун или ИИ-миддл, то компании предпочтут его. Это ещё и сокращает накладные расходы на коммуникацию, потому что команды нет, есть один условный сениор и его ИИ-ассистент.

Но, вероятно, это можно решить с помощью образования. Институт должен готовить пригодных для работы сотрудников. И крупные компании активно вовлекаются в образовательную движуху. Теперь нужно будет готовить разработчика, который умеет эксплуатировать ИИ для написания кода. Порог входа в профессию вырастет. Но он и сейчас довольно большой. Для разработки нужно знать много технологий, и чем дальше, тем больше. Если классическое образование не справится, то на помощь придут разные книги, курсы (в том числе бесплатные) и другие источники знаний.

А по второму вопросу совсем не могу согласиться. Описывается модель, словно ИИ будет рулить кодовой базой и компанией в целом. Но это не так, если остаются senior developer и прочие квалифицированные кадры. ИИ на текущем этапе может генерировать код, но решение о его внедрении принимает человек. Если эта практика сохранится, то и источник кода не важен, писал ли его человек или ИИ. Важно, чтобы принимающий решение субьект пропускал только качественный код. Тогда и проблем не будет. Причём ИИ может выступать ещё и в качестве высокоуровнего линтера, то есть стать ещё одной ступенькой обеспечения качества результата.

#edu

Работаем со связанными ветками в Git

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

Автор предлагает делить работу над задачей на несколько логически связанных частей. Каждая часть оформляется в виде отдельной ветки и сопровождается merge request-ом. При этом каждая ветка бранчуется от предыдущей. Например, feature-xyz/part-2 от feature-xyz/part-1, а feature-xyz/part-3 от part-2. Получается такой стек из веток.

Такой подход позволяет упростить ревью – каждый MR охватывает минимальный объем изменений, и создать историю коммитов, которая позволит читать изменения кода по шагам, понимая логику их внесения.

И всё выглядит хорошо до тех пор, пока не нужно внести изменения в part-1 по результатам ревью, а потом влить эти изменения в ветки part-2 и part-3. Или когда в основной dev-ветке появятся изменения, нужно также их затащить во все свои маленькие веточки. Тут приходит на помощь rebase со всеми сопутствующими приседаниями.

Чтобы избежать приседаний, автор предлагает решение: использовать опцию --update-refs команды rebase. В этом случае при ребейзе самой последней вашей ветки git сам обновит все родительские ветки.

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

#skills #teamwork

Ответ на задачу — проектируем динамическую фильтрацию

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

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

💡В postgres можно спроектировать схему для хранения фильтров в связке со списком товаров, к которым эти фильтры можно применять.
🚫 Здесь не стали приводить конкретики, но отметим, что при таком подходе будут проблемы с динамическим обновлением счетчиков. А ещё такое решение несёт сложную ментальную нагрузку на разработчика.

💡Можно взять Elasticsearch или Manticore Search и подобное реализовать там.
❓По задаче требуется остаться с PostgreSQL и не вводить доп сущностей. Если можно поднять эластик, решение нормальное и можно обсудить детали.

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

Пример реализации такого решения с использованием полнотекстового поиска в postgres приведен в статье Faceted search using PostgreSQL full text search.

#database #skills #резюме

Справляемся с рисками

Две совсем несложные статьи (раз, два), посвящённые риску и управлению рисками.

В первой даётся определение риска – это сочетание возможности получить выгоду и вероятности потерь. Мы принимаем риск не ради него самого, а ради целей, которые хотим достичь.

Для анализа риска автор разделяет его на два компонента:
– Вероятность: насколько возможно, что негативное событие произойдёт?
– Последствия: какие убытки или проблемы оно принесёт?

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

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

Вторая статья посвящена управлению рисками – действиям, направленным на снижение риска.

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

Автор приводит не айтишный пример, но, в целом, неплохо демонстрирующий суть.
Нужно переправиться через реку:

Для снижения вероятности падения в воду мы можем:
– Использовать командные техники переправы
– Искать более мелкий участок реки для перехода

Для снижения последствий попадания в воду мы можем:
– Запаковать вещи в водонепроницаемые мешки, чтобы предотвратить их повреждение
– Разместить спасателей ниже по течению, чтобы минимизировать риск травм или утопления

#teamwork

DevFM подкаст 3: Роли в ИТ-проекте (youtube / podster / yandex)

В часовом видеоподкасте мы обсудили роли в ИТ-проекте из ~25 человек, занятых разработкой крупного веб-сервиса со сложной бизнес областью. Бизнес аналитики, системные аналитики, тим лиды, разработчики – кто на ком стоял и чем все эти люди занимаются. Представлен достаточно высокоуровневый взгляд на команду, если вы в таком не участвовали – вам точно будет интересно. В конце обсуждаем, можно ли малой командой делать большие проекты и, наоборот, делать большой командой малые проекты.

Подкаст 2. Кто такой тимлид тимлидов
Подкаст 1. Ретроспектива силами команды разработки
#devfm #podcast #teamwork

Наш бесплатный курс "Командная строка для разработчиков"

Мы много лет готовим python-разработчиков. Подготовку начинаем с базовых знаний Linux, где прививаем желание и умение работать в терминале. Вдохновляясь курсом "Поколения Python" на степике, сделали бесплатный курс Командная строка для разработчиков, посвящённый терминалу в Linux. Начинающим разработчикам поможем преодолеть неловкость перед текстовым терминалом, опытным разработчикам покажем неочевидные и полезные в работе фишки для увеличения продуктивности.

Уроки курса:
— Команды и работа с файловой системой из терминала
— Модифицируем файловую систему
— Управляем сотнями файлов и пишем первый скрипт
— Знакомимся с текстовыми редакторами nano, mcedit, gedit, vim
— Разбираемся с процессами, jobs, fg, bg, ps, grep и конвейером
— Настраиваем терминал "под себя"
— Разграничение прав доступа и работа с учётными записями

#devfm

Простой приём: Как ускорить принятие решений в команде

Если вы руководите людьми, то наверняка сталкивались с ситуацией, когда два специалиста застревают в споре. У каждого есть свои правильные аргументы, но к какому-то окончательному решению прийти не могут.

В этом случае может помочь простой приём — попробуйте предложить радикальное, обоим сторонам неудобное решение.

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

И в один момент я абсолютно серьёзно предложил использовать нереляционную базу. Также серьёзно обосновал своё предложение, почему это может быть хорошим вариантом. И тут случилось чудо – уже через минуту инженеры дружно доказывали мне, что это плохая идея, а заодно быстро пришли к устраивающему всех решению.

В итоге решение найдено, хотя в глазах ребят я предлагаю очень странные идеи.

#teamwork #devfm

Годные авторские каналы

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

– Сиолошная: отсюда узнаю подробности о событиях в мире ml
– Системный сдвиг: тема системного анализа и любого другого анализа близка к разработке, и здесь черпаю информацию о происходящем в мире анализа
– Инжиниринг Данных: тут все просто, автор рассказывает за инжиниринг данных
– addmeto: узнаю о действительно значимых и интересных событиях в мире технологий
– Книжный куб: интересные разборы книг и white papers, беру на заметку, что стоит прочитать
– Чем докажешь и Кнопочка: в области ui/ux существует много интересных исследований, а ещё иногда нужно поставить на место самоуверенного дизайнера

И совсем немного около развлекательного:
– Эргономика жилья: я достаточно сильно заморачиваюсь по комфорту и удобству быта, а этот канал как раз посвящен эргономике вокруг нас
– Ряды Фурье: ребята простым языком раскрывают сложные научные и технологические темы. Позабавила их реклама на Таймс-сквер в Нью-Йорке
– Игорь Кузнецов о темных паттернах: отсюда узнаю, какие дикости творят продакты в своих продуктах, дабы добиться желаемого результата и подкрутить нужные продуктовые метрики

Ну, а как организовать этот бесконечный поток информации в телеграме у нас был отдельный пост.

Если ведёте классный авторский канал – делитесь в комментах.

Обзор способов защиты контейнеров Docker

Докеры мы любим, а думать о безопасности докеров — не всегда.

Неплохая обзорная статья о том, что вы можете сделать для повышения безопасности, чтобы не попасть впросак :)

Автор начинает с актуальности в виде известных инцидентов за 2024 год и, в целом, видов угроз для контейнеров.

Итак, переходим к делу:
🔹 Ограничивайте привилегии контейнеров — по умолчанию они могут запускаться с избыточными правами, что создает новые вектора для атак. Отключайте ненужные привилегии.
🔹 Запускайте rootless-контейнеры — пусть они работают от имени обычного пользователя, а не от root'а.
🔹 Настраивайте сетевую изоляцию — не давайте контейнерам бесконтрольно общаться друг с другом и с внешним миром. Чётко определяйте, кто с кем может взаимодействовать.
🔹 Используйте специальные инструменты — AppArmor, Seccomp и SELinux, они помогут ограничивать системные вызовы и предотвращать несанкционированный доступ к критическим ресурсам.
🔹 Сканируйте образы на уязвимости — Trivy, Docker Scout и аналогичные инструменты помогут обнаружить проблемные зависимости ещё на этапе сборки. Встраивайте эти инструменты в свой CI/CD.
🔹 И, самое базовое, что может делать каждый разработчик — минимизируйте образы, убирайте лишние зависимости, не тяните за собой ненужные файлы, следите за обновлениями базовых образов, запускайте контейнеры от не привилегированных пользователей.

#tools #docker

Пятничное развлекательное

No Vehicles in the Park — необычная инди-игра, которая на самом деле не про транспорт, а про контент-модерацию.

Как установить простые правила для сложных явлений? Где границы допустимого? И можно ли вообще создать систему, которая не сломается об исключения и контекст?

Разработчик вдохновился гипотетическим кейсом "No vehicles in the park" (H.L.A. Hart, 1958) и решил показать, что контент-модерация — это не просто вопрос скорости обработки жалоб, а фундаментальная проблема неопределённости.

В итоге получился интерактивный эксперимент: какие "транспортные средства" вы запретите в парке? Где проходит грань между велосипедом и инвалидной коляской, игрушечной машинкой и электросамокатом?

Стоит ли пытаться вписать хаос в жёсткие правила или проще отказаться от модерирования совсем?

#fun #edu

Как проводить skip level 1-1

Любопытная статья, посвящённая проведению 1-1 встреч с коллегами на два и более уровня ниже вас. Такие встречи называются один-на-один, или one-to-one, сокращённо 121.

Я не знаю термина, обозначающего такие встречи на русском языке, но в английском есть емкое название skip level 1-1.

С моей точки зрения, начало статьи достаточно банальное, но в разделе с советами автор даёт несколько действительно полезных рекомендаций.

По части организации таких встреч:
— Встречи должны быть прозрачными. Важно заранее обозначить для собеседника формат встречи, её цели, подготовить примерный набор вопросов и ожиданий от встречи.
— Желательно, чтобы такие встречи проводились регулярно. Это позволит избежать нежданчиков и стресса для коллег.
— Руководители людей, с кем вы проводите встречи, также должны быть в курсе таких встреч и их целей.

По части проведения встреч:
— Добавьте в общение какой-то персонализации, заранее узнайте что-то о человеке и его достижениях, это позволит установить более тёплые и честные взаимоотношения.
— Вопросы должны быть конкретными. Если задавать абстрактные вопросы, то ответы, скорее всего, будут размытыми, вроде "да, в целом, всё нормально".
— На таких встречах можно получить фидбек из первых уст по внедрённым недавно изменениям или новым практикам. Также может оказаться, что какие-то инициативы были внедрены, но сотрудники либо понимают их по-разному, либо вообще не в курсе. В итоге получается такой отличный heartbeat.
— На таких встречах можно получить фидбек об их руководителе (вашем подчинённом), чтобы посмотреть на работу вашего непосредственного подчинённого под другим углом.
— Фиксируйте повторяющиеся темы и паттерны. Если одна и та же проблема всплывает у разных людей, это важный сигнал.

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

#teamwork #edu

Таки посмотрите на uv

Мы уже писали о быстром пакетном менеджере для Python — uv. Кто-то уже успел его пощупать? Я затащил его в несколько своих проектов — полёт нормальный. В продакшн хотели затащить, но так и не нашли весомых причин.

На днях вышла статья — A year of uv: pros, cons, and should you migrate. Автор в восторге от uv, и когда постарался упомянуть минусы, то даже от них скорее в восторге. В итоге текст — отличный вариант вдохновиться на использование этого инструмента. А если хотите узнать про подводные камни — залетайте в комменты, там автору уже насували.

#tools #python

Пятничное развлекательное

Ребята из Ряды Фурье рассказали о супер интересных исследованиях: оказывается, можно "напихать" трезвому здоровому человеку новые воспоминания!

А ещё у них был пост о том, что человеческая память — это нечто вроде write-only: записать можно, но вот прочитать — только с искажениями и перезаписью.

#fun

The 37signals Guide to Internal Communication

Мы уже писали про замечательную книгу Getting Real от ребят из 37signals.

Давно хотел написать про ещё один классный гайдлайн от ребят — The 37signals Guide to Internal Communication.

Мы внедряем различные практики разработки — как пишем код, какие линтеры используем, как проводим ревью и т.д. А вот как правильно коммуницировать, чтобы были единые, всем понятные правила? На моей практике с этим аспектом не всё так гладко.

В гайде вас ждёт набор очень ёмко сформулированных правил коммуникации. Приведу без перевода особенно откликнувшиеся мне:
— Real-time sometimes, asynchronous most of the time.
— Meetings are the last resort, not the first option.
— Speaking only helps who’s in the room, writing helps everyone.
— If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.
— Never expect or require someone to get back to you immediately unless it’s a true emergency. The expectation of immediate response is toxic.
— Five people in a room for an hour isn’t a one hour meeting, it’s a five hour meeting. Be mindful of the tradeoffs.
— “Now” is often the wrong time to say what just popped into your head. It’s better to let it filter it through the sieve of time. What’s left is the part worth saying.
— Urgency is overrated, ASAP is poison.
— Ask if things are clear. Ask what you left out. Ask if there was anything someone was expecting that you didn’t cover. Address the gaps before they widen with time.

#teamwork #edu

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

▫️Замечательный своей концептуальностью доклад Александра Поломодова “Архитектура в Т-Банке: вчера, сегодня, завтра”
▫️И очень практический доклад Виталия Минко “Архитектурные практики на практике”

#youtube