В этом эссе хочу рассказать про те вещи, которые формируют мою персональную систему знаний в Obsidian и из‑за которых я по сей день её активно веду, делаю заметки, ищу связи.
Оглавление
Движение между абстракцией и конкретизацией
Моя система знаний пронизана подходом, который проистекает из системного анализа и data science. При анализе чего-либо я стараюсь постоянно скользить между абстракцией и конкретикой, причем в обе стороны.
Это можно заметить на структурных элементах, которые у меня созданы в хранилище. Например, категории, метазаметки и проблемы. Это движение от глобального – категории, то есть некоторой абстракции, к чему-то конкретному – к проблеме.
Это же можно увидеть на том, как устроена система тегов, или на том, что определённые элементы являются частью композиции, то есть когда мы вкладываем одни элементы в другие. Похожий принцип работает в иерархических заметках, где задается какой-то основополагающий элемент, а потом через отступы происходит его детализация и конкретизация. То же самое видно и в дискурс-графе – сначала формируется некоторый общий вопрос, а далее приводятся частные доказательства.
На самом деле большинство заметкоделов, которые ведут систематически заметки, пользуются таким скольжением, просто не всегда отдают себе в этом отчет. Например, те же самые заметки являются частными проявлениями в виде идей или наблюдений. А теги или папки являются абстракцией, которая объединяет эти заметки по какому-то признаку.
Ещё один хороший пример конкретизации и абстракции – это когда у нас есть заметки, которые являются конкретными решениями определённых проблем. Тогда над этими заметками мы можем абстрагироваться и понять, какой класс задач они решают. В таком случае мы можем эти заметки объединить в отдельную категорию, или в отдельный класс, или вообще определить эти заметки как новый тип.
В следующий раз, когда мы будем решать проблемы, мы будем искать не конкретные заметки, а сначала определять класс проблем. Это очень сильно пересекается с классическим ТРИЗ.
Идея движения между абстракцией и конкретизацией мне нравится также за её универсальность. Например, этот подход можно очень легко применять в быту. Если словил в чём-то затык и не можешь понять, как связаны точечные факты – абстрагируйся. Слишком много теории, концептуализации – найди пример. Приземли теорию до конкретных выводов.
Не создаю чего не понимаю
Я не создаю структурных элементов, которые не понимаю, как можно использовать и развивать в долгосрочной перспективе.
Кажется, что это приводит к максимально статичной системе, в которой ничего не меняется.
Но на самом деле это приводит к тому, что я не создаю и не переобуваюсь в процессе, не меняю core-механики, которые определяют работоспособность моей системы.
Например, частью моей системы являются проекты.
Проекты у меня будут сегодня, завтра, послезавтра, и не случится такой ситуации, что я вдруг скажу – всё, теперь проектов у меня нет, теперь у меня effort, по аналогии с тем, что сделал Ник Майло.
Концепцию "effort" я не понимаю. Концепцию "проекта" я понимаю, поэтому могу её использовать эффективно и при этом развивать, углублять, обогащать другими механиками и так далее.
При этом не могу не отметить, что огромное количество концепций, которые у нас на слуху, но которые мы не воспринимаем как концепции, на самом деле глубоко прорабатываются и с теоретической точки зрения, и с практической.
Я не зря зацепился за концепцию проекта, потому что её можно легко найти в PMBOK, в софте по типу Linear или Todoist, в методологиях Waterfall или Agile. Во всех этих местах можно увидеть имплементации идеи проектов и так или иначе подхватить их и перенести в свою систему.
Понятное дело, что тот же Ник Майло, когда пропагандирует идею Effort, хочет сформировать у человека правильное ожидание. Но из-за того, что к этой идее сложно подвязывать другие идеи из реального окружающего нас мира, возникает проблема масштабируемости. Поэтому сам я стараюсь не злоупотреблять авторским глоссарием, а все-таки использовать общеупотребительные в индустрии слова.
Не могу не отметить и экзотические глоссарии школы Щедровицкого и его идейного продолжателя Левенчука. Мне это видится весьма карикатурным. Такой птичий язык может создать ощущение глубины, но едва ли его можно перенести и глубоко интегрировать в персональные рабочие процессы.
Когда-то я хотел подробно изучить эти подходы из академического интереса, но понял, что переводить с русского языка на русский – не самое продуктивное занятие.
Антихайп
Найти ценный материал в популярных источниках, который послужит для меня инсайтом, с каждым годом становится все более редким событием.
Поэтому, чтобы интеллектуально не скукситься в теме персональных систем знаний, приходится подпитывать себя научными статьями. Они зачастую на порядок более глубокие и интересные, там можно найти довольно нетривиальные идеи, и при этом они меня всегда держат в интеллектуальном тонусе, потому что их мне значительно сложнее быстро проанализировать, проскимить, бегло сделать умозаключения. Нет, они все-таки требуют сконцентрированной интеллектуальной работы.
Минус, правда, заключается в том, что, в отличие от популярных статей, в научных тебе значительно реже дают готовые, очень хорошо прожеванные знания, которые ты можешь тут же применить. В итоге фрикция, которая возникает при изучении статьи, накладывается на большие трудности преобразования научного академического знания в реальную практику. Но мне это нравится, потому что я занимаюсь подобным скорее как хобби и это является по сути продолжением моей основной деятельности.
Более того, в отличие от популярного знания, научное на порядки более скептичное. Этот скепсис пронизывает мозги, и любое новое улучшение в хранилище становится все более трудоемким. Ты начинаешь анализировать разные подходы, теории, разные техники, алгоритмы, и пока ты все это моделируешь в голове, у тебя она пухнет, и при этом тебе довольно сложно что-либо из этого превратить в свою регулярную практику, потому что ты не всегда уверен в целесообразности использования этой практики.
Это, конечно, не тот уровень проблем, когда ты выбираешь между двумя приложениями для чтения MD-файлов. Это глубже. Это сильно расходится с мейнстримным пониманием того, как нужно вести заметки и на какой результат стоит от них рассчитывать.
У меня даже возникает определённое сомнение. Если я при всём своём опыте ведения заметок всё равно испытываю трудности при добыче инсайтов из научной литературы, то насколько неосязаемым может быть выхлоп у людей, которые потребляют только лёгкие источники и делают заметки по тому, что и без базы знаний можно легко прожевать и потребить.
Архитектура и структурализм
Если в моей системе какой-то элемент не имеет формального описания, то значит, его не существует.
Это не сковывает меня в развитии системы, а напротив даёт надежную опору в её масштабировании и углублении.
Несомненно, у разных людей разные вещи являются фундаментом. Кто-то завязывает свою систему вокруг конкретных действий, кто-то вокруг конкретных артефактов, кто-то вокруг временных периодов.
У меня фундаментом выступает архитектура (логическая и смысловая взаимосвязь элементов), рабочие процессы (пайплайны/преобразования) и схема данных (формальное описание элементов).
Иначе говоря, мне важно, чтобы моя система не противоречила самой себе, чтобы в ней все элементы между собой стыковались, чтобы механики не конфликтовали и не дублировали друг друга.
Плюс для меня важно, чтобы были налажены рабочие процессы. Я уже давным-давно сам себе доказал, что невозможно, например, сразу сделать полноценный проект или сразу прочитать источник и достать из него максимум инсайтов. Это всё требует итеративности и последовательности.
В давней статье про маркеры хорошей базы знаний я довольно хорошо описал, какие процессы должна претерпевать информация. Хотя я написал это, основываясь на том, как у меня организованы процессы в заметках, в ней всё же есть явные пересечения с GTD, CODE, ENCODE. Думаю, это неспроста, потому что люди, которые так или иначе работают с информацией, понимают, что от неё невозможно получить пользу, если её вылить в бронзовую "статую", не делая с ней больше ничего.
Информация должна и валидироваться, и интерпретироваться. В информации нужно искать вариации, нужно искать противоречия. Нужно атаковать информацию и заниматься её демаркацией. В таком случае информация будет сопротивляться, и в сопротивлении будет рождаться понимание, а за пониманием будут появляться осознанные действия и результаты.
Не могу также не отметить, что сам по себе архитектурный подход мне нравится тем, что он формирует последовательность и преемственность. Я не являюсь в полном смысле детерминистом, но мне так или иначе нравится, когда я могу проследить свое мышление до каких-то конкретных архитектурных решений, которые воплощены в коде или в структуре хранилища.
Это всё создаёт глубинную связь, обозначает причинность между совершёнными действиями, инструментами и результатами.
Полезность такой взаимосвязи можно очень легко проследить на такой ситуации.
Если в процессе изучения не используется никакая система для интервального повторения, то фактически невозможно гарантировать, что ты усвоил на долгосрочный период новые для себя факты, концепции, термины и так далее.
Напротив же, когда ты видишь, что в твоей системе есть 500 карточек с группировкой по конкретной теме, то ты можешь легко самому себе дать отчет, что из этого ты хорошо помнишь, как много у тебя карточек по определенной подтеме, то есть насколько глубоко ты покопал, как много ты нашел полезного знания.
Можно сказать, что архитектурный подход создает возможность для измеримости. Кому-то это не нравится, но мне кажется, это очень полезное свойство. Да и чего греха таить. Когда метрики положительные, то ими не прочь похвалиться и те, кто к ним изначально относится скептически.
Кстати, я думаю, кого-то это расстроит, но структура хранилища в заметной степени определяет структуру мышления. Если ваше хранилище начинает сыпаться на 1000 заметок, значит, это ваш предел и в мышлении. И это не я придумал. Это просто следствие из теоретических положений системной кибернетики.
Минимализм и инкапсулированная сложность
Я думаю, некоторые из вас знают, что я являюсь адептом адского минимализма. Это выражается в интерфейсе, в оформлении, в минимизации точек входа в систему и т. д.
Сейчас я бы хотел отметить не такую очевидную, но важную грань моего минимализма, а именно инкапсулированную сложность.
В моей системе координат нет никакого смысла в приборных панелях, где есть много кнопочек, переключателей, потому что всякий раз, когда я с этим сталкивался или плотно работал с этим, это всегда провоцировало изощренную прокрастинацию.
Я считаю, что хорош тот инженер, который смог принять лучшие или хотя бы оптимальные решения за пользователя и смог все муки выбора и лишние крутилки скрыть от него.
Абстрактное кредо хорошего инженера должно звучать так: "Я в определённой теме за пользователя подумал настолько глубоко, что ему вовсе не придется в этом разбираться".
Именно это создает добавочную стоимость и разделение труда. Человеку не нужно глубоко разбираться в том, почему самолеты летают, как все их детали взаимодействуют между собой, но при этом он может легко пользоваться услугами авиаперелетов. Инженер открыл ему эту возможность, освободил его от необходимости во всем этом разбираться. Он инкапсулировал всю сложность. Пользователю лишь остается пристегнуть ремень.
Да, я понимаю, что это несколько утрированный пример. Так или иначе, самолет создал не только инженер, и авиаперелеты доступны не только благодаря изобретательству. Просто хотел сказать, что вываленная наружу сложность – это не та вещь, которую следовало бы преследовать и на которую нужно ориентироваться, если цель – создать долгосрочную систему, которая должна приносить пользу.
Итог
Если попытаться собрать всё это вместе, то для меня персональная система знаний держится не на количестве заметок и не на наборе модных практик. Она держится на возможности двигаться между абстракцией и конкретикой, не плодить непонятые сущности, сопротивляться хайпу, формализовать архитектуру и прятать лишнюю сложность. Именно эти принципы позволяют системе не распадаться по мере роста, а постепенно становиться более точной, связной, полезной и такой, с которой интересно работать.
На этом у меня всё.
Если вам не хватает хардкорных статей по PKM, загляните в мой Digital Garden. Там я, например, разбираю, как создать эпистемическую систему для упорядочивания и фильтрации источников в Zotero, и почему простой bottom-up подход в заметках плохо работает на длинной дистанции.
Новые материалы раньше всего появляются в моём Telegram-канале.
А на Boosty я публикую более глубокие разборы сложных кейсов по управлению знаниями и проектами. Там есть и теория, например, гибридная база знаний, и практика про то, как развивать конкретный проект как экосистему из 4 уровней. Ещё там выходят эссе.