Между прочим, каналу -- год 🎂

Спасибище всем, кто читает, ставит реакции, комментирует. С вами гораздо лучше, чем без вас.

Как думаете, о чем стоит больше писать дальше? Отмечайте реакциями, пишите комментариями!

💯 про математику
🧑‍💻 про техническое
🤝 про управленческое
✍️ про фасилитацию
🔥 про что угодно

Какие курсы по базам данных посоветуешь?
-- спросили тут меня.
Контекст -- коммерческая разработка.

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

🧑‍💻🧑‍💻🧑‍💻
"Найти курсы" -- это выглядит уже решением, а проблема внутри какая-то другая.

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

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

И что делать?

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

Но если дотошного анализа проблемы еще не было -- я бы вложилась в анализ. Сначала в одиночку, потом с командой/заинтересованными лицами.
По формату начала бы с факторов, которые участвуют в ситуации, и как они друг на друга влияют.
🧑‍💻🧑‍💻🧑‍💻

Про использование MySQL в Яндекс.Директе: https://youtu.be/x03CwcLLDW4

А это мой давний доклад на Я.Субботнике про БД.

Рассказ 2017 года, но там уже десятки шардов и десятки терабайт данных; а клёвые инструменты в Директе были вообще всегда.

Три части в рассказе:
🔹Шардинг
🔹DDL на больших и гигантских таблицах
🔹 История обновления данных на основе обработки бинлогов

Противоречие обучения: незнание ступенчато, а узнавание постепенно.

Когда сравниваешь неумеющего себя с умеющим кем-нибудь — видишь разрыв, большую ступеньку: "вот это он умеет, а я нет".

Легко начать мечтать "вот буду учиться, научусь и перепрыгну этот разрыв".

Когда сравниваешь учащегося себя сегодняшнего с собой вчерашним — часто видишь не ступеньку, а маленький кусочек плавного прогресса: "вроде ничего такого не умею сегодня, чего не умел вчера, ну разве что спотыкаюсь меньше". Может быть даже и этого не видишь, а только "не получается, не получается, не получается".

Результат? Перепрыгивания, о котором мечталось, не происходит и не происходит. Мечта "научусь" не сбывается. Грустно!

(Вообще-то не просто грустно, а надо менять этот паттерн. Но про это в другой раз)

Разные перспективы

Верхний кадр:
Изучаю новый фреймворк
Ты можешь, ты уже делал это

Нижний кадр:
Смотрю, как кто-то другой изучает фреймворк, который я знаю.
Сюда / Ну давай уже

И этот комикс тоже о том же противоречии обучения: смотришь вперед -- надо преодолевать большое и страшное незнание. Смотришь назад -- вроде ничего такого и не сделал

Припозднившаяся #пятничная_картинка

Отметьте все картинки, где есть человеки.

Про шестерых я знаю, кто они; про троих -- нет ((

SaintTeamLeadConf -- съездила на конференцию

Записала недодюжину коротеньких находок.

Интересно, можно по ним угадать, на какие секции я ходила? ))
Программа здесь, если что: https://teamleadconf.ru/spb/2023/schedule

1🔹 Новое применение ценностям.
Если выбирать, чтобы убежать от нежелательного -- об этом выборе потом часто жалеют. Если выбирать из ценностей -- это выбор, который потом воспринимается хорошо.

2🔹 Если какая-то мысль захватывает, не отпускает и не дает больше ни на что посмотреть. Упражнение.
Включить мысль во все более и более широкий контекст. Произносить отчетливо вслух или про себя:
* "какие же смежники упыри"
* "я думаю, что смежники большие упыри"
* "я замечаю, что я думаю, что смежники большие упыри"
* "это интересно, что я могу заметить, что я думаю, что смежники..."
* "могу рассказать, как интересно, что я могу заметить, что я думаю..."
На каждом шаге обращать внимание на свои ощущения. На 2-3-4 итерации обычно отпускает.

3🔹 Ткнуть пальцем в проблему часто важнее-полезнее, чем помогать с решением.

4🔹 Говорят, что люди узнают, что происходит, по эмоциям, которые испытывают. Не "просходит страшное, поэтому боюсь", а "боюсь, и из этого понимаю, что происходит страшное".

5🔹 Частенько проблемы "здесь в моменте" показывают на систематические изъяны: нет ретроспектив, нет ясных целей, нет общепринятых правил, сломана коммуникация... Но (некоторые? многие?) тимлиды в аудитории все равно хотят лекарство в моменте.

6🔹 Полезная замена: вместо "Я не могу на это повлиять" говорить "Мне сложно на это повлиять, потому что ..."

7🔹 Видеоблог надо заводить за два года до того, как он понадобится.

8🔹 Если выходишь на сцену и видишь мрачные лица в аудитории.
Это не потому, что ты — лох, а потому что слушатели живут здесь.

9🔹 Формула изменений с удовольствием:
* прошлое, на которое можно опереться
* неидеальное, но приличное настоящее
* ясный и завлекательный образ будущего
* убрать риск облажаться публично
* побольше привычных мест, людей и действий

10🔹 Фрирайтинг и сторителлинг усиливают эмоции, лейбеллинг приглушает.

11🔹 Самые популярные советы, которые люди дают себе после дистального моделирования (из позиции кого-то другого): (1) просто делай уже; (2) забей и не делай.

А в тетрадочке еще под сотню страниц подробных записей. В общем, интересно 👍

Двое дипломников защитились в этом году на материале сервиса для документирования устройства сервисов, который я придумала.

Если по порядку, то так:
🔹 составить, опубликовать и посмотреть схему сложного сервиса — непростое занятие, с инструментами не все гладко
🔹 во всех сервисах, где я работала, я постоянно рисовала какие-нибудь схемы и постоянно думала, как это делать лучше
🔹 с год назад я собрала все материалы и мысли, какие были, и синтезировала идею: какой новый инструмент надо бы разработать, чтобы стало лучше
🔹 но перспективы разработать такой инструмент были не очень — ресурсов разработки видно не было
🔹 а потом один за другим у нас в отделе оказались два студента-дипломника, которые хотели делать дипломы на рабочих задачах
🔹 и тут мы согласовали этот самый сервис схем как парт-тайм экспериментальный проект, на котором коллеги сделали бы дипломы
🔹весь прошедший учебный год я понемногу прорабатывала юзер-стори, декомпозировала функциональность, приоритизировала, а коллеги-дипломники программировали, дебажили, конфигурировали и деплоили
🔹и вот в только что закончившемся июне оба защитились
🔹 а у нас в отделе появился новый клёвый сервис-инструмент
🔹 ура ))

История с "делать схемы сервисов" — важная для меня, я хотела бы писать об этом больше.

А на картинке — USM, по которой работали этот год

#пятничная_картинка

👾 -- понимаю, что тут происходит
👀 -- не понимаю
👍 -- неважно что происходит, поддерживаю картиночки

Архитектура инцидента

Рассказ — следующим сообщением

Архитектура инцидента

Однажды на встрече разработки нашего сервиса обсуждали инцидент (аварию), случившийся в смежном сервисе, и затрагивающий нас тоже.

Пока обсуждали, нарисовали схему. Хочу поделиться ее очищенным от конкретных названий вариантом — см. предыдущее сообщение.

Итак, инцидент.

Участвуют несколько постоянно работающих сервисов и одна регулярная процедура сверки.

Взаимодействие между сервисами-участниками идет так (номера соответствуют схеме):

1. Пользователь выполняет действие в веб-интерфейсе. Этот запрос попадает в Сервис #1

2. Сервис #1 по некоторой логике определяет, в какой из сервисов-бэкендов следует отправить запрос

3. Сервис #1 отправляет запрос на обработку в выбранный бэкенд

4. Параллельно в природе появляется лог "такой-то пользовательский запрос подлежит обработке таким-то бэкендом".
Кто именно генерирует этот лог -- внезапно не вполне ясно. То ли сам Сервис #1 пишет, то ли какая-то прокси перед ним

5. Лог из п.4 проходит через несколько сервисов: #2, #3, #4, #5

6. Время от времени запускается сверка: какие запросы распределялись по бэкендам по данным самим бэкендов и по данным, накопленным в сервисе #5

7. Если сверка находит расхождения — разбираются все-все-все, в том числе и наш сервис #3

Так как какое-то время лог в п.4 был неправильный — предвидим при очередной сверке расхождения, которые будут объясняться этой проблемой с логом.

Чем мне нравится схема?

На схеме легче обнаруживаются неясные места:
- Действительно ли проблема была только в записи лога, или в выборе бэкенда тоже? Как это узнать?
- Каков все-таки механизм генерации лога? Насколько этот механизм подвержен поломкам?
- Можно ли сверять лог и данные бэкендов непосредственно, без цепочки сервисов #2-#5?
- А как проверяется и мониторится, что выбор сервиса-бэкенда делается правильно, без систематических ошибок?

На схеме можно поместить десяток объектов и связи между ними, и разумно рассуждать обо всех них. Без схемы это (1) трудно даже в одиночку; (2) а если внесколькером — никогда не понятно, одинаковая ли картинка сложилась в головах у разных людей.

Составляйте схемы инцидентов, если еще не!

#в_продакшене_только_и_разговоров_что_об_инцидентах

Из точки A в точку B, ч.1

Немного выбралась из ловушки незаметного прогресса и поосознала разное, что поменялось в моих скилах/знаниях за последние пару лет.

Делюсь первой дельтой:

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

2. Три года назад я этого не делала. У меня были практики про встречи и про записи, но другие, и выхлоп от них был совсем другой.

Как получилось перейти из одного состояния в другое? Постепенно, незаметно и незапланированно. Много практики и ясное понимание, что запомнить все или хотя бы многое я не смогу.

TLDR: "Слушать, электронно записывать и осмыслять одновременно" -- это удобно-полезно, мне нравится; и начала это делать я совсем недавно

Инструменты и процессы -- как вантовые оттяжки

1. Должны поддерживать
и
2. Чтобы выполнять свою функцию, должны создавать напряжение

#пятничная_картинка

Отметьте все квадраты, в которых есть баги

Вечная недостаточность ненужного

Теория
Невозможно получить достаточно того, что тебе не нужно.
(It’s impossible to get enough of what you don’t need — увидела формулировку когда-то давно в Твиттере.)

Практическое приложение
Если видишь, что получаешь и получаешь что-то, но этого все недостаточно и недостаточно — стоит проверить, а действительно ли это нужное? Или может быть на самом деле нужно совсем другое?

Действует в личной жизни, в отношениях, в работе, где угодно.

Вещи, знания, знаки внимания, фичи, релизы, проекты, метрики — если их не хватает и не хватает, то вопрос: они ли нужны?

Это сложный и трудный вопрос, если что. Но полезный — ведет к большему счастью

Начала писать заметочку с броским заголовком "Что не так с экзокортексом".

Остановилась. Задумалась: а насколько "экзокортекс" -- общеизвестное понятие?

👾 -- знаю слово "экзокортекс"
👀 -- не знаю такого слова
✍ -- не знаю, знаю ли, но расскажи, что с ним не так

Экзокортексом называют инструменты, которые делают человека когнитивно сильнее.

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

Делать человека когнитивно сильнее за счет внешних инструментов -- да, очень нравится (так и живу).

Не нравится мне название "экзокортекс", потому что отсылает к устройству, а не к выполняемой функции. Cortex -- это кора (больших полушарий головного мозга), экзокортекс -- как бы внешняя кора. Посмотрите на кору и постройте такое же, но снаружи.

Second brain, второй мозг -- тоже намекает скорее на "как устроено", чем на "что оно делает".

А мне хочется название в духе "что оно делает". Как "средство передвижения" или "транспорт".

Красиво и в одно слово пока не нашла, а многословно и описательно получается как-то так:
* внешний исполнитель когнитивных функций
* или внешний когнитивный сопроцессор
* или внешняя когнитивная система

Продолжение про имя для внешней когнитивной системы

Поискала в англоязычном интернете, какие есть синонимы и альтернативы слову "экзокортекс".

Нашла пост Тиаго Форте, который читаю как "часть выращивания своей внешней когнитивной системы -- это выбор имени для нее".

Мне нравится такой взгяд на вещи: построй систему, назови ее.

А Тиаго Форте -- это как будто именно тот, кто придумал термин second brain в смысле "когнитивные орудия".

И цитата:

What do you call your Second Brain?

A system of personal knowledge management, which I call a “Second Brain,” is an indispensable part of any modern professional’s toolkit.
Because it is such a personal tool, it’s important to give it a name that evokes the special relationship you have with it. Here is a collection of alternative names for a Second Brain you can draw inspiration from.

Перевод:

Как вы называете свой второй мозг?

Система управления личными знаниями, которую я называю «Второй мозг», — неотъемлемая часть инструментария любого современного профессионала. Это глубоко личный инструмент, поэтому важно дать ему имя, которое будет отражать именно ваше отношение к нему. Вот коллекция других названий для второго мозга, можете ими вдохновляться.

Список:

Zettelkasten
Exocortex/Exobrain
Extended mind/External brain
Digital twin
Augmented memory
Peripheral brain
Digital commonplace book
Mind palace
Networked knowledge system
Thought pot
Think tank
Pensieve (from Harry Potter)
Personal knowledge stack
Personal cloud
Synaptic journal
Ideaspace
Mirrormind
Field notes
Digitized memory
Personal knowledge system
Personal search engine
LMS (Life Management System)
Mindbase/Mindvault
Digital distillery
Metabrain
Imagination engine
Cognitive prosthetics
Memex
Streamcatcher
Knowledge graph
Mind sieve
Idea lab
Thought library
Searchable thought dumpster
Digital garden
Digital detritus
Alternate memory
Personal documentation
Compendium of self-knowledge
Self-documentation

Источник: https://fortelabs.com/blog/what-do-you-call-your-second-brain/

#пятничная_картинка

Отметьте все квадраты с программами, которые останавливаются

🧑‍💻 -- знаю, что такое проблема останова
👀 -- не знаю, что такое проблема останова
👍 -- неважно что за проблема, одобряю картинки

Дорогие читатели,
собираюсь устроить экспериментальную лекцию про вторую (еще неопубликованную) версию ШСМ-ного интеллект-стека.

ШСМ-ный интеллект-стек -- это некоторая модель "из чего состоит мышление человека".

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

Время еще выбираю; вероятно будет вечер рабочего дня или воскресенья в ближайшие 2 недели.

Кто хотел бы поучаствовать -- напишите мне в личку, пожалуйста, "Хочу на лекцию по интеллект-модели" (@liruoko)

Однажды я четыре с половиной года была координатором инцидентов в моем тогдашнем сервисе.

Было много всего. Как-то пересчитала отчеты об инцидентах, которые я писала или помогала писать — получилось больше 400 штук.

С того времени у меня на диске лежит неопубликованный документ "Инструменты и активности координатора инцидента" из 50+ пунктов; нарисованная и опять же неопубликованная схема "решение сложного инцидента: модель"; наброски к лекции или статье "Инцидент: проект в быстрой перемотке" (вариант: "Проект: инцидент в slow motion").

А на днях осознала, что исследование инцидентов оставило мне определенную модель "Какие вопросы бывают и как ими пользоваться".

Делюсь.
Взгляд на вопросы из роли координатора и исследователя инцидентов:

🔹 вопросы бывают закрытые (ответ да/нет) и открытые (остальное)
🔹 "что", "когда", "где", "сколько"  — нормальные понятные вопросы о фактах
🔹 "кто" — пограничный вопрос. Годный ответ на него — роль. Если конкретное имя — это подозрительно, возможно двигает разговор в сторону распределения вины (но не всегда. "Кто это сделает" предполагает конкретное имя)
🔹 "почему" — ужасно подозрительный вопрос, часто агрессивный, особенно в варианте "почему не". И в любом варианте у него подозрительно непонятная форма. Лучше не использовать
🔹 "как" — продуктивный вопрос. Если хочешь спросить "почему", лучше переосознайся и найди подходящий вопрос "как"
🔹 "какова природа этой причинно-следственной связи" — специфический, но продуктивный вопрос. Заменяет собой вопрос "почему из вот этого следует вон то"

🦋🦋🦋