NoSQL → Not Only SQL

NoSQL сейчас употребляется в смысле anti-SQL, как противопоставление доминирующим ораклам и постягрям с их ненавистной реляционной моделью.

Хотя изначально смысл закладывался другой — не прямое противопоставление, а как ещё один вариант, алтернатива. В Книге С Кабанчиком™ Мартин Клеппманн приводит ссылку на заметку из 2009 года.

https://web.archive.org/web/20190623045155/http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.html

Действительно это был просто хэштег для митапа по альтернативным базам данных. Хештег потом прилепился, но смысл его постепенно стал более категоричным.

А изначально было действительно в значение Not Only SQL.

и ещё вот твит от фаундера графовой БД Neo4j из того же 2009
https://twitter.com/emileifrem/status/5200345765

Легенды базостроительства в подкасте от dbt

Mike Stonebraker занимается базами данных с 1970-х. Тогда он написал реляционную БД Ingress, за три года до того как Ларри Эллисон выпустил Oracle. После этого Майкл приложил руку к Postgres (название отсылает к Ingres).

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

В 2005 они выпустили Вертику. Понравилась байка как они пришли показывать Вертику в большой тогдашний е-ком. Там был инстанс Оракла за миллион долларов, который обрабатывал аналитический запрос сутки. Команда Майка установила им Вертику, закачала туда их данные и тот же запрос отработал уже за секунды. Вот она вся прелесть DWH.

Ещё Майк очень сожалеет, что не выложили тогда Вертику в опенсорс — он уверен, что сегодня это было бы дефолтное решение для многих проектов.

Вообще, судя по Википедии, дядьке 79 лет! Он уже как полвека что-то делает полезное, написал несколько популярных движков бд и кажется не планирует останавливаться. Вот сейчас мутит очередной дата-стартап. Говорит, что ему скучно просто лежать на пляже =)

https://roundup.getdbt.com/p/ep38-a-romp-through-database-history

в каждом меме есть доля шутки — в далёком 2020 я присматривался куда пойти… и не пошёл в ML 🙃 типа ща я тут по-быстрому с аналитикой сперва разберусь, а там до мл уже шапкой докинуть!

короткой строкой про дата-инженерские вакансии в Яндексе:

1. открыта вакансия в Практикум. Судя по описанию, всё довольно стандартно: там собрать, сюда положить, сверху витрины; ждут кандидатов с 3+ годами опыта. Если я ничего не путаю, Практикум работает удалённо, а ещё там супер душевная команда ❤️

2. а ещё случайно узнал, что 4-5 марта (это уже ЗАВТРА!) можно получить фаст оффер в DWH Яндекс Маркета. Про требования к кандидатам всё написано общо́. Маркет использует подходы к двх-строению как у нас в Go, поэтому там должно быть круто. Я б сходил чисто по фану — часто перетереть за данные с умными людьми без каких-то обязательств 😉

3. ну и к нам в Доставку тоже ищут инженера. У нас YT (Hadoop) + Greenplum, свой etl-фрейморк, работающий data mesh и свой анкор-моделинг для дата-ценителей. Тут уже могу рассказать всё в деталях, если будет интересно.

деньги-денежки-деньжата

так-так-так, что тут у нас? это же зарплаты дата-профессий в Европе!

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

ребята собрали статистику по 500 вакансиям, сконвертили всё в доллары и сделали разрезы по синьорности, стране и компаниям.


⌘ что интересного увидели:

1. по синьорности: зп есть прямая корреляция на первых 6 лет карьеры, дальше всё по-разному

2. по локациям: в Берлина в среднем зп ниже, объясняют наличием там офисов Delivery Hero и Zalando, где зп чуть ниже рынка. А вот в Дублине, кажется, собрались сеньёристые ребята и там явный перекос зп в сторону высоких грейдов.

3. по компаниям: Delivery Hero и Zalando находятся где-то слева на распределении зп (см. п2 про них). А вот в Мете, Амазоне и Букинге есть выбросы по зп даже для мидлов — вот кому хорошо)


⌘ для нашего рынка раньше такое делали Хабр в 2021 и New.HR в 2019

за ссылку спасибо подборке от дата-кофе

#послушано

доклад Ивана Ямщикова на TechTrain про практические применения МЛ — от банальных до продвинутых. Медицина, легал и прочие отрасли. В конце общее (позитивное!) напутствие.

> Какие сейчас перед нами сценарии развития искусственного интеллекта? Ждет ли нас еще одна «зима»? Как машинное обучение меняет рынки, общества и планету?

iTunes, YouTube

⌘⌘⌘

В яндексовый подкаст позвали двух директоров Такси (и одного таксиста-блогера). Поговорили об актуальном: распределение загрузки сервиса по часам и месяцам, цены на поездки, как внедряют новые фичи. Ещё из подкаста можно узнать, что СЕО Яндекс Такси регулярно таксует в Саратове (до чего работа довела человека!)

iTunes, YouTube

⌘⌘⌘

Спотифай делает аккуратный шажочек в голосовые помощники. Там взяли крутого диджея, заперлись с ним в студии и сделали персонального диджея для каждого пользователя Спотифай. МЛ-диджей объявляет следующие треки и иногда делает вставки с фан-фактами об исполнителе. Примечательно, что диджей интегрирован с рекомендательной системой и может комментировать почему та или иная песня попала именно в твой плейлист.

iTunes

#подкаст

студенты есть? там открыли конкурс на стажировки, где за деньги можно поконтрибьютить в разный опенсорс: CatBoost, YDB и наш любимый YTsaurus

https://foss.kruzhok.org/code-for-all

Промпт-инженеры

Зацепила фраза Григория Бакунова (bobuk) про промт для GitHub Copilot (работает на ChatGPT):

> Для тех кто не программирует, посмотрите на картинку — вот так выглядит будущее программирование искусственного интеллекта.

Действительно эти ~25 предложений можно представить как ~25 абзацев кода для какого-то приложения.

Продолжая аналогию с программированием, можно вспомнить с чего начинается почти каждый урок — тот самый Hello world! И то же самое происходит с тем, кто впервые сталкивается с гот-моделями — их промты простые и односложные.

А вот продвинутые юзеры гпт-моделей через пробы и ошибки учатся улучшают свои промты и некоторые уже даже не помещаются на страницу. Чем не продвинутая программа уже?

Получается, придумали весь этот МЛ, чтобы не писать кучу IF’ов — и теперь пишем эти же ифы, только теперь на естественном языке.

потрёпанный жизнью книжным клубом Кабанчик

Книжный клуб + Кабанчик = 🖤

Два года назад как начинающий и ответственный дата-инженер заказал оригинал книги Мартина Клеппманна Designing Data-Intensive Applications с Амазона. Но книга так и лежала у меня с тех пор, не смотря на рейтинг 5.0 и рекомендации со всех сторон.

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

План был максимальной простой: одна глава = одна неделя. Встречаемся каждый четверг, обсуждаем прочитанное, вспоминаем байки из опыта (если есть), находим аналоги в нашей инфраструктуре. И вот спустя 12 недель Кабанчик прочитан, книга исчёркана карандашными заметками, в заметках осталось 12 относительно структурированных конспектов.

В общем идею можно признать успешной: паблик комитент работает плюс в компании единомышленников читать веселее. Сами обсуждения тоже были полезными: приносил темы что остались непонятными, а коллеги подсказывали что упустил — профит!

Заметки на будущее: сложность материала возрастает к последним главам. В первых Мартин описывает базовые концепции и повествование в следующих главах строит уже поверх них. Последние несколько глав можно смело делить на два захода, потому как 50-60 страниц технического текста за неделю осилить уже сложновато.

Отдельно стоит отметить примечания к каждой главе. Мартин скрупулёзно собирал источники для каждого тезиса. В заметках можно найти научные работы, датированные начиная с 1960-х и до 2018 (года публикации книги). Для желающих копнуть глубже можно всегда обратиться к оригиналам.

🤓 data-архитектуры: Lamda vs Kappa

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

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

стриминг — это быстро, но сложно: данные льются потоком, их надо успевать читать и записывать. Если воркер упал, что происходит с данными? если для трансформации нужен стейт или джойн, то сколько держать событие в памяти? поначалу решения были неконсистентными by design

но всем хотелось сейчас и сразу, поэтому придумали как совместить эти два подхода

🔵 Lambda-архитектура

идея простая: когда хочется стриминг, но он ещё ненадёжный, делаем два потока данных:
1. текущий инкремент бежит через стриминг
2. а потом по старинке сверху накатываем батч

получается и быстро (но не надёжно), и eventually надёжно — после того как накатился следующий батч.

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

http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

🟡 Kappa-архитектура

тогда другие умные люди подумали и предложили альтернативный подход: давайте держать единую версию трансформаций и пускай главным будет стриминг-реализация.

А если (когда!) надо будет пересчитать историю, то мы просто будем держать в памяти данные за нужный период и запускать новые версию джобов поверх них. Автор приводит пример что они в Линкедине таким образом держат в памяти 30 дней и для отдельных сущностей это может быть «терабайты».

http://radar.oreilly.com/2014/07/questioning-the-lambda-architecture.html

Звучит интересно, но пока не понял, как при каппа-архитектуре работают бекфилы? что делать, если надо пересчитать не 30 дней, а все данные за всю историю?

👆 Минутка кибербезопасности

Регулярно появляются новости, что взломали очередную компанию, поэтому тема актуальная. Кажется, что проблема где-то на другом уровне, но часто взломы начинаются с отдельного человека, который решил, что qwerty — сильный и надёжный пароль.

В подкаст «Запуск завтра» пришёл хакер-предприниматель, компания которого проводит аудит безопасности: за деньги пытаются сломать компании с последующим отчётом и предложениями по улучшению.

кулстори: для одной компании делали аудит, сделали скан и нашли забытый всеми почтовый сервис, торчащий наружу. Спарсили с Линкедина сотрудников, сгенерерили почтовые адреса и по всем прошлись проверкой на базовые пароли — нашёлся один с условным qwerty. Зашли внутрь и пошли гулять там по внутренней сети по соседним сервисам, наткнулись на незашифрованный бекап хранилища паролей. Редкий случай, но довольно показательный.

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

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

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

https://news.1rj.ru/str/ctodaily/1684

там завтра наши хэды из платформы данных будут рассказывать как ворочать петабайтами в YTsaurus (он же Ыть, он же а-ля Хадуп)

https://news.1rj.ru/str/ytsaurus_ru/2869

🤓️️Практикум: английский для разработчиков

Спустя 6 месяцев закончил курс, куда записался на панике сразу после мобилизации. На самом деле записался сразу на два английских от Практикума: общий и для разработчиков.

Общий порадовал короткими кусочками — в любое свободное время за 15 минут проходишь теорию и после неё записываешься на практику на через-5-минут. Можно не держать в голове расписание, а заниматься по свободности.

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

⌘ Процесс

В самом начале был небольшой скрининг, проверяли мой английский (видимо, что я смогу общаться с преподом без русского)

А дальше занятия 1-1 по зуму. Преподаватель шарит экран с уроками из Ноушена и мы вместе проходим. Там на понимание, на чтение и много на пересказ и прочие болталки.

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

Каждое 8-е занятие идёт с носителем. За время обучения у меня были разные ребята из Милана, Австралии, Турции, США и Сингапура. У них был разный уровень английского — двое точно не нейтивы. Но в целом норм, они типа те самые айтишники, об которых можно потренироваться: отработать поведенческие и технические интервью.

Ещё мне очень повезло с преподом. Хоть её и зовут Елена, но английский у неё на уровне нейтива — кажется это из-за того, что она долго жила где-то заграницей. Прям приятно её слушать и подмечать разные интересные фразы. Если вдруг у вас будет возможность выбора, рекомендую спросить можно ли заниматься с Elena Shoshkina

полгода назад было два курса: для разработчиков и аналитиков. Сейчас вижу добавили третий (и расширили старые):
1. для разработчиков и QA
2. для продактов и прожектов
3. для аналитиков и DS

https://practicum.yandex.ru/english/english_for_career-1/

ClickHouse: стриминг для бедных

достался в поддержку проект по реалтайм обработке данных на основе КХ — чем больше в него погружаюсь, тем больше он нравится!

смысл простой: из брокера сообщений инсёртим данные в КХ и там через материализованные представления раскладываем их в одну широкую денормализованную витрину.

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

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

1. колоночное хранение
2. движки таблиц семейства MergeTree
3. матвьюхи, работающие по принципу стриминга

1/ колоночное хранение

данные в таблицах базы — это файлы на диске (довольно очевидно, но до меня это дошло только когда читал Кабанчика)

Когда в одном файле лежат полные строки, то в них могут быть нуллы, т.е. лишняя информация. Если хранение повернуть на 90° и хранить в файлах колонки, то там ничего лишнего не будет; а дополнительно получаешь плюшки в виде более эффективного сжатия и аналитических запросов.

И тогда мы можем инсёртить в нашу широкую витрину на 100+ атрибутов из разных загрузчиков — каждый загрузчик наполняет только своё подмножество атрибутов. При такой вставке в остальных атрибутах не прорастают лишние нуллы.

Чем-то похоже на принцип загрузки в анкор-датаволт: у нас есть «хаб» с первичным ключом и набор отдельных атрибутов-сателлитов; только не на уровне таблиц в базе, а на уровне файлов на диске.


2/ таблицы MergeTree

ещё в Кабанчике читал про разницу между разными методами хранения данных в базе данных: B-Tree и LSM Tree.

B-Tree хранит данные в дереве — это очень удобно для чтения, потому что можно до любой ячейки дойти за пару шагов по этому дереву. Но записывать такое дерево сложно — перед записью надо найти конкретное место, куда положить твои байтики. А если лист дерева переполнен, нужно создать новый.

Log-Structered Merge (LSM) Tree же наоборот оптимизирует запись. Все входящий байтики пишутся тупо в конец последнего файла. Это очень быстро для записи.

Но читать такое сложно — при доступе по ключу записи надо проверить все файлы от последнего к первому (самые плохие кейсы, когда такого ключа нет).

В ClickHouse есть целое семейство из движков таблиц — MergeTree, поэтому туда можно быстро и много инсёртить. А под капотом уже происходит merge — наваленные в порядке записи файлики раскладываются в сортированном порядке, удаляя лишние данные. Что позволяет читать ваши терабайты за секунды.


3/ «стриминг» матвью

интересная особенность матвьюх в КХ — они «присоединяются» к таблице-источник и их логика трансформации применяется к каждому входящему в эту таблицу куску данных.

благодаря этой особенности можно налету «парсить» прилетающие из брокера сообщений инсёрты и раскладывать в нужные колонки нашей широкой витрины.

напоминает триггеры из других баз — типа на каждый инсерт в таблицу Т1 делаем набор действий с таблицами Т2..Т99.

И тут история делает полный круг — на первом своём проекте по дох-строению я сделал условный ЕТЛ на триггерах внутри Постгрес (про Эйрфлоу я тогда ещё не знал =). Как прототип это работало, но развивать и поддерживать это было сложно.

В самом КХ это поддерживать тоже трудновато, надо запросы и DDL выносить куда-то во вне. Но по крайней мере оно всё работает на продавшен объёмах и не загибается; подозреваю, что благодаря пунктам 1. и 2. (и техническому гению Алексея Миловидова и команды КХ)

#послушано


🎧 Rework: AI! GPT! What a time to be alive!

речи фаундеров 37 Signals просто как бальзам на мою fomo-душу!

Для тех, кто переживает, что «поезд AI ушёл» и его уже не догнать, ребята предлагают взглянуть с другой стороны: в этой отрасли настолько быстро всё меняется, что период полураспада навыков — 48 часов!

Если вы были мастером по MidJourney версии 3, то в пятой версии уже всё поменялось и буквально надо вкатываться заново. Поэтому можно смело начинать вкатываться с версии 5 (или 10!) — и все будут примерно на том же уровне.

Главный совет от ребят — Have fun!

Apple Podcasts


🎧 Moscow Python: Пайтон в мире анализа данных

Мой бывший СТО из агентства Epoch8 — Андрей Татаринов — заглянул в подкаст Moscow Python рассказать про использование Python для анализа данных и ML.

Андрей рассказал что там под капотом у Pandas и чем он отличается от Polars, который активно пиариться за счёт своей скорости.

Интересно было про ускорение работы Python за счёт переноса куска вычислений на Rust. Получилось быстро и удивительно мало итераций до работающего прототипа.

Общий совет — в начале писать наивную реализацию на Пайтон как быстрый прототип. И потом когда какие-то места упираются в производительность (problems nice to have) — точечно оптимизировать. А не наоборот =)

Всегда приятно послушать хорошо структурированные рассуждения Андрея и анекдоты из его опыта.


Apple Podcasts

YouTube (c таймингами!)


🎧 Проветримся: Системное мышление (из 2020)

к следующая книга в нашем книжном клубе будет «Системное мышление» Левенчука; в качестве подготовки переслушал эпизод подкаста с автором из 2020. Делюсь заметками:


- Удачный полёт на Марс с первой попытки как результат науки «системная инженерии».

- pretrain + finetune: чтобы поставить обучение танцам, можно прокачать «танцевальное мышление», понять куда смотреть — и тогда новый танец можно будет выучить за 2 часа, а не за дни-недели.

- «машинка с типами» — уметь мыслить абстракциями и моделями. Проверка через простой вопрос «Лидер — это роль. Какие роли у лидера?»

- утверждение, что «у стада коров есть хвост» валидно с точки зрения математики (через вхождение в подмножество), но невалидно с точки зрения систем, потому что оперирует разными уровнями систем.

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

- программирование как подобласть системной инженерии (утверждено NASA в 1968)

- «наши требования это их потребности» — наш конченый продукт куда-то вставляется (в следующую систему) и, чтобы оно там работало, надо понимать как его будут применять. Нет смысла делать шестерёнки для часов полностью под размер, но из пластмассы.

ссылки на платформы и сам файл с записью в канале подкаста
https://news.1rj.ru/str/progulka/128

Нет правильных решений

в школе было просто: тебе дают пример, ты что-то там решаешь на листочке и выдаёшь ответ — «42!». И сссразу получаешь обратную связь «правильно / неправильно».

дальше всё получается сложнее.

возьмём кластер Кликхауса, которому плоховато от нагрузки. Что с этим можно сделать? можно добавить ещё хостов, можно апнуть текущие хосты, можно добавить шардирование.

с другой стороны можно проверить нагрузку; что больше грузит систему — запись или чтение? может мы пишем что-то лишнее, т.е. оптимизировать запись. Или у нас Даталенс с Графаной спамят по стопицот одинаковых запросов в секунду?

здесь нет «правильного» ответа. По-хорошему надо бы зарыться в логи и разобраться что происходит, составить план и его придерживаться. Скорее всего придём не к одному решению, а к комбинации из нескольких.

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

и даже после того, как сделан анализ текущей нагрузки, проработы альтернативные варианты, сделала приоритезация и первые изменения пошли в прод, не придёт никакая технофея и не скажет «молодец! всё правильно сделал» — ничего подобного!

просто продолжаешь наблюдать растущую нагрузку и как предыдущие решения на неё влияют. Оп! — один хост ушёл в maintenance, как система держится? CPU на живых машинах ушло в полочку на 100%, но лаг по данным не растёт. Уже неплохо! Если бы не предыдущие оптимизациия, было бы точно хуже.

нет «правильных» решений — есть только более оптимальные в текущем контексте.

Польза вопросов

Последние пару месяцев активно копаю в сторону стриминга. Последний проект — перевод одной отдельновзятой поставки данных на Flink.

В какой-то момент настолько увлёкся и закопался, что потерял общий ориентир; ви́дение стало слишком узким и застал себя за тем, что «искал ключи где светло, а не там где их мог потерять»

Благо дело было перед регулярной встрече 1-1 и на помощь пришёл наш бравый лид (привет, Саша!). Через ряд последовательных вопросов у него получилось упорядочить хаос в моей голове: вспомнить о цели проекта, предстоящих этапах и когда это должно быть сделано.

прошли от обратного:
дедлайн условно 1 сентября — значит, 31 августа должен быть релиз? нет, релиз нужен минимум за неделю до этого, чтобы посмотреть как работает на продовых данных и отловить возможные косяки

окей, значит релиз нужен за неделю до этого. Что должно быть в релизе? парсинг входящих джейсонов по схеме и пара джойнов со стейтом (плюс сопутствующий обвес из Графины, настроенных доступов, алертов и пр.)

я был сосредоточен на парсинге, потому что это самое простое 🤡

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

в результате беседы был готов расписанный план со всеми промежуточными этапами от сейчас и до дедлайна

интересно, что Саша мог вообще быть не в курсе проекта — все технические и проектные вводные были от меня как участника процесса; он просто задавал нужные вопросы в правильном порядке

О приоритизации задач

Дорогой читатель Алексей Махоткин @squadette в коментах к прошлому посту прислал релевантную заметку (спасибо большое! люблю такое, шлите ещё).

Мой ограниченный опыт подтверждается богатым (подозреваю) опытом автора из ЖЖ — ошибка довольно распространённая.

https://gaperton.livejournal.com/36144.html

⁃ неопределённость в проектах есть всегда; ей можно управлять (хотя бы наблюдать и иметь в виду).

⁃ неопределённость к концу проекта должна снижаться

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

⁃ вместе с тем, в сложных задачах скрыто куча потенциальной неопределённости — и лучше бы узнать о них пораньше

⁃ иначе неопределённость проявится на 90% готовности проекта (тот случай когда внезапно появляются «вторые 90% проекта»).

👆

🥸 про коучинг

наша встречу по наведению порядка в проекте через вопросы (два поста выше ↑) напомнила мне профессиональные коучинговые сессии — недавно я попробывал новый для себя инструмент для пары личных проектов.

роль коуча как раз в безоценочной помощи в наведении порядка в хотелках и стремлениях (= проектах). Получается это такой инструмент для диагностики — прикладываешь его к нужному месту, отвечаешь на его вопросы → профит.

ключевой фактор здесь именно в отсутствии оценки, т.е. коуч убирает себя как личность из процесса; он не оперирует терминами «хорошо» и «плохо» — только задаёт вопросы и пытается вместе с тобой найти твои конечные цели и приложить их к какому-то плану (а потом и к сделанным делам по этому плану)

по себе знаю, насколько это сложно не пытаться давать совет после каждой реплики собеседника (ведь я же ЗНАЮ КАК ЛУЧШЕ!!1)

я занимался с Димой Черненьковым и могу его смело рекомендовать. Дима — мой добрый приятель и по совместительству сертифицированный коуч (а ещё фанат кулинарии, спикер, участник подкастов и жонглёр примерно восьмью способами)

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

Начать можно с его канала, где встречаются советы о прокрастинации, заметки из книг и конспекты лекций (отдельный лайк за тематические мемы между)

🖤