Об долларовый ИТ-аутсорсинг

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

Что происходило с нефтью и газом дальше? Если говорить грубо, дальше эта нефть поступала на заводы по переработке, которые превращали ее в пластик, индустриальные масла и другие высокоорганизованные субстанции с высокой добавленной стоимостью, которые за гораздо бОльшие доллары продавались обратно в Россию, откачивая таким образом гораздо больше денег, чем принося. Ведь сырая нефть стоит гораздо дешевле продуктов из нее. То есть по факту нефтяной экспорт работал как механизм ограбления населения в пользу нефтяников - деньги собираются со всей страны за заграничный импорт, а их малая часть отщепляется тем, кто продает нефтяной ресурс.

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

А теперь немного параллелей про валютный ИТ-аутсорсинг.

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

И по правде говоря, ИТ-аутсорсинг даже хуже, чем торговля сырой нефтью.

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

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

Об дефицит разработчиков

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

1. COVID. Эпидемия затворничества внезапно поспособствовала развитию удаленки, а это значит, что стало всё равно, где нанимать. Поэтому глобальный рынок ИТ нормализовался вокруг какой-то цифры, к какой и поехали зарплаты. Стало все равно, где нанимать разработчика, потому что платить ему предстоит одинаково, иначе он с завтрашнего дня начнет, не вставая с кресла, работать уже на другого работодателя. Вот такой баланс. И даже те, кто не может работать на Запад - на их запросы так же оказывает давление этой средней зарплаты сеньора, они тоже подтянулись. Кто там будет разбирать, пойдет конкретный разработчик работать за границу или нет?

2. COVID, но НЕСТАНДАРТНО. Дело в том, что мы все с вами говорим о низкой производительности труда в РФ. Это касается и разработки, а как вы думали - только шахтёр в России медленно кайлом машет? Нет, программисты тоже печатают неспешнее, чем их европейские коллеги /это шутка, если кто не понял/. Суть в том, что в большинстве банков - видел своими глазами - в доковидные времена конвейер разработки установился в 6-9 месяцев. То есть - ты ставишь задачу сейчас, а через 6-9 месяцев за нее только примутся. А куда было торопиться? У нас же самый прогрессивный финтех в мире! /нет/.
И тут вдруг Ковид показал - некоторые компании за эти 6-9 месяцев могут запустить 2 версии доставки продуктов до дома. А банк все еще даже не начал работу. "Эгегегегей!" - подумали в топ-менеджменте, нас же щас уделают - WB купил банк, Яндекс купил банк и т.п. - что будет с нами? И решили ЦИФРОВИЗИРОВАТЬСЯ: топ-10 банков, не считая бюджетов, нанимают людей, чтобы этот постыдный time-to-market (TTM) превратить во что-то приличное.
Будет ли эта разработка эффективной? Не уверен. Тут торгуют TTM в обмен на эффективность. Лучше неэффективно, но сейчас, чем эффективно тогда, когда остальные уже опередили. Цель одна -- катить быстрее. Печальная дихотомия, но другой не завезли.

(Для справки: одно только iOS приложение Сбера, по слухам, пишет около 550 человек. Вот такая "производительность" в обмен на TTM)

3. Agile. Как ни странно, да. Посмотрите на предыдущий пункт: TTM поставили во главу угла. Это значит: надо быстро, надо уже сейчас, если что -- переделаем. А где линейный и регулярный менеджмент? А его нет, за "жирные" годы его смыло, остались одни продакт менеджеры, задача которых - уж точно не воспитывать из слабой команды команду посильнее. А у некоторых C*O, по из словам, вообще задача - "мотивировать замов" (С).
Смогут ли недообученные, слабо адаптированные начинающие разработчики в команде в режиме Agile-разработки делать поставку? Не думаю. Поэтому дефицит, о котором мы говорим, носит ОЧЕНЬ специфический характер.
А) Все отрывают с руками синьористых разработчиков, и зарплаты растут именно у них;
Б) Но не слишком сеньористых: в режиме пар из задницы и постоянных авралов более старшие их товарищи работать не станут, нужны такие, чтобы глаза горели, как будто _специй_ принял, и вопросов лишних не задавал (то есть 4-8 лет опыта). А над ними поставят тимлида, как я уже писал. С этих людей сняли все компанейские обязанности, которые они в силу недостаточной своей зрелости способны выполнять - найм, бонусы, оценки адаптация - и отдали в специальные структуры. Отдельный вопрос - куда расти такому тимлиду? На него ответить я не могу.
В) На рынке мешками валяются резюме менее продвинутых разработчиков; HR-ы пишут, что на каждую вакансию просматривают тысячи (кроме шуток) резюме.
Разработчиков так-то полно, не хватает тех, кто сам и без менеджмента сможет делать суперкороткий TTM.

Всем интересно, что дальше будет? Мне тоже. Позже напишу, как и собирался, во что верю.

/забыл добавить: Agile и скрам сам по себе не то чтобы эффективный. Он гибкий, в смысле -- можно быстро развернуться, это правда, но - гибкость дается не бесплатно, в недельной итерации Scrum около 30% времени уходит на обязательные встречи (не спорьте, у меня цифры на руках - лучше посмотрите Селиховкина). С дистанционной работой это соотношение стало еще хуже. То есть мы работаем _медленнее_, поэтому надо больше, БОЛЬШЕ разработчиков, да не абы каких, а тех, кто умеет работать без менеджмента/

Советы лучших консультантов

Об работу на два фронта

Недавно посмотрел эпатажный доклад какого-то iOS разработчика, где докладчик предлагал (не скажу "агитировал") искать работу на 2 компании в одно и то же рабочее время, поясняя на примерах плюсы, минусы, первые шаги и другое обоснование,:
- как работать так мало, чтобы только не выгнали
- какие задачи брать, чтобы выглядеть занятым и подольше не "спалиться";
- куда стоит идти, а где заметят, что ты работаешь не только на них.
При этом призывает не работать больше 8 часов, то есть речь не о совместительстве.

Параллельно докладчик упомянул, что тема в ИТ-сообществе не особо обсуждаемая, зато после выступлений за кулисами к нему подходят несколько человек с просьбами пособить обустроиться именно так. Почему пишу "эпатажный" - после выступления какой-то из комитетов отказался выставлять запись на публику, руководствуясь, видимо, какими-то соображениями о добре и зле 🙂

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

Но в том, что касается основной темы доклада, я -- не одобряю, и вот почему.

--

Основной пойнт, вокруг которого все крутится: разработка - вещь ненормируемая. Это следствие и того, что задачи нередко друг от друга отличаются в десятки раз, и производительности двух разработчиков тоже могут заметно отличаться, и вообще двух похожих задач не бывает, сплошное RnD. В общем, каждая отдельная задача в разработке, если по-честному брать -- это маленький проект, и если ими управлять как проектом, то накладные расходы превысят любой профит.

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

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

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

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

На мой взгляд, некрасиво, поэтому не поддерживаю.

Рекрутер в ИТ это то препятствие, которое стоит между компанией, отчаянно нуждающейся в персонале, и высококлассными инженерами на рынке

Тут пятничный разговор зашёл, так что..

А похвастайтесь в комментариях самыми сложными и чудовищными тестовыми заданиями, которые вас просили сделать?

Щас будет странный вопрос, не переключайтесь.

А нет ли среди моих читателей теплых выходов на проверенные и крупные (20+ человек) аутсорсные ИТ-команды строго из Румынии и Молдавии? Есть долгоиграющий и перспективный заказ на разработку - с территориальными, к сожалению, ограничениями.

Если срастётся через рекомендацию — с меня хорошее вознаграждение: например, макбук.

Шутки про цыган и лошадей слать не надо

Никогда не знаешь, где найдешь, где потеряешь

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

Я собрал статьи, которые нашел, в подборку ниже по дате выхода. Надеюсь, вам будет так же интересно, как и мне.

Лебедев и МЭСМ
https://topwar.ru/182766-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-ii-lebedev-i-bruk.html

Брук и М-1
https://topwar.ru/182774-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-iii-bruk-i-m-1.html

"БЭСМ против Стрелы"
https://topwar.ru/182787-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-iv-bjesm-protiv-strely.html

Варшавский договор
https://topwar.ru/183309-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chehija-vstupaet-v-igru.html

Проект ЭПОС
https://topwar.ru/183401-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-vi-proekt-jepos.html

Назад в СССР
https://topwar.ru/183599-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-vozvraschaemsja-v-sssr.html

"Юдицкий строит суперкомпьютер"
https://topwar.ru/183763-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-judickij-stroit-superkompjuter.html

Кристадины, диоды и транзисторы
https://topwar.ru/184029-rozhdenie-sovetskoj-pro-kristadiny-triody-i-tranzistory.html

Транзисторные машины СССР
https://topwar.ru/184319-rozhdenie-sovetskoj-pro-tranzistornye-mashiny-sssr.html

"Долгий путь к ИС"
https://topwar.ru/184420-rozhdenie-sovetskoj-pro-dolgij-put-k-integralnym-shemam.html

"Осокин против Килби"
https://topwar.ru/184823-rozhdenie-sovetskoj-pro-osokin-protiv-kilbi-kto-na-samom-dele-izobrel-mikroshemu.html

"Зеленоград и Ленинград"
https://topwar.ru/184867-rozhdenie-sovetskoj-pro-zelenograd-i-leningrad.html

"Атака клонов"
https://topwar.ru/184877-rozhdenie-sovetskoj-pro-ataka-klonov.html

Модулярный компьютер
https://topwar.ru/185254-rozhdenie-sovetskoj-pro-velichajshij-moduljarnyj-kompjuter.html

Убийство 5Э53
https://topwar.ru/185282-rozhdenie-sovetskoj-pro-istorija-ubijstva-5je53.html

"Конец модулярных машин"
https://topwar.ru/186510-rozhdenie-sovetskoj-pro-konec-moduljarnyh-mashin.html

"Звездные войны"
https://topwar.ru/186782-rozhdenie-sovetskoj-pro-karcev-i-chelomej-strojat-zvezdnye-vojny.html

"Конец Юдицкого"
https://topwar.ru/186572-rozhdenie-sovetskoj-pro-konec-judickogo.html

"Кибернетика"
https://topwar.ru/187039-rozhdenie-sovetskoj-pro-ot-bitvy-za-britaniju-do-kibernetiki.html

"Механические мозги"
https://topwar.ru/187407-rozhdenie-sovetskoj-pro-mehanicheskie-mozgi.html

"Винер. Человек и миф"
https://topwar.ru/187844-rozhdenie-sovetskoj-pro-viner-chelovek-i-mif.html

"На пути к Киберкоммунизму"
https://topwar.ru/188128-rozhdenie-sovetskoj-pro-na-puti-k-kiberkommunizmu.html

"Конец Карцева"
https://topwar.ru/188689-rozhdenie-sovetskoj-pro-konec-karceva.html

Бэсм. Сага
https://topwar.ru/189578-rozhdenie-sovetskoj-pro-bjesm-saga-chast-i.html

"Величайший советский компьютер"
https://topwar.ru/189956-rozhdenie-sovetskoj-pro-bjesm-saga-chast-ii.html

За и против БЭСМ-6
https://topwar.ru/189960-rozhdenie-sovetskoj-pro-bjesm-saga-chast-iii.html

"БЭСМ-6. Итоги"
https://topwar.ru/189962-rozhdenie-sovetskoj-pro-bjesm-saga-chast-iv.html

"На пути к Единой Системе"
https://topwar.ru/190327-rozhdenie-sovetskoj-pro-na-puti-k-edinoj-sisteme.html

Конец советской компьютерной программы
https://topwar.ru/190377-rozhdenie-sovetskoj-pro-konec-sovetskoj-kompjuternoj-programmy.html

"Приключения С-300"
https://topwar.ru/190481-rozhdenie-sovetskoj-pro-prikljuchenija-s-300.html

Долгое восхождение на "Эльбрус"
https://topwar.ru/190990-rozhdenie-sovetskoj-pro-dolgoe-voshozhdenie-na-jelbrus.html

"При Сталине такого не было"
https://topwar.ru/190999-rozhdenie-sovetskoj-pro-pri-staline-takogo-ne-bylo.html

"Эль-Берроуз"
https://topwar.ru/191202-rozhdenie-sovetskoj-pro-jel-berrouz.html

"Как СССР копировал микросхемы"
https://topwar.ru/191630-rozhdenie-sovetskoj-pro-kak-sssr-kopiroval-mikroshemy.html

"Из чего построили Эльбрус-2?"
https://topwar.ru/191714-rozhdenie-sovetskoj-pro-iz-chego-postroili-jelbrus-2.html

Трезвая статья о 99% "невидимых" разработчиков и их проблемы

https://vc.ru/dev/368883-u-99-komand-staryy-kod-i-korobochnye-resheniya-net-byudzhetov-i-devops-a-my-slushaem-inflyuenserov-iz-facebook

Ладно, погнали дальше.

В последний раз тут была подборка про советские ЭВМ. Вот недостающие статьи из того цикла:

Битва советских министерств за микросхемы
https://topwar.ru/191867-rozhdenie-sovetskoj-pro-bitva-sovetskih-ministerstv-za-mikroshemy.html

Рождение советской ПРО. Как был создан и почему провалился компьютер «Эльбрус»
https://topwar.ru/192438-rozhdenie-sovetskoj-pro-kak-byl-sozdan-i-pochemu-provalilsja-kompjuter-jelbrus.html

Последний советский суперкомпьютер
https://topwar.ru/192565-rozhdenie-sovetskoj-pro-poslednij-sovetskij-superkompjuter.html

— * — * —

После чего, для контраста предлагаю нырнуть в увлекательную подборку "Made at Intel" от непосредственного участника:

"Architecture and religion"
https://habr.com/ru/articles/663070/

"Architecture and religion — 2"
https://habr.com/ru/articles/664116/

"Architecture and religion — 3"
https://habr.com/ru/articles/664682/

"Кризис среднего возраста"
https://habr.com/ru/articles/666098/

"Байки россыпью"
https://habr.com/ru/articles/666786/

"Acquisitions"
https://habr.com/ru/articles/683632/

"Acquisitions – 2"
https://habr.com/ru/articles/716956/

"Acquisitions – 3"
https://habr.com/ru/articles/723368/

"«Советские газеты»"
https://habr.com/ru/articles/696980/

"Пировали, веселились…"
https://habr.com/ru/articles/716208/

"Свой среди чужих, чужой среди своих"
https://habr.com/ru/articles/718734/

"Специалист по этике"
https://habr.com/ru/articles/719004/

"Дела продажные"
https://habr.com/ru/articles/724752/

"Молитвы, энтузиасты и разбитые лбы"
https://habr.com/ru/articles/724856/

"В поисках мессии"
https://habr.com/ru/articles/732544/

Приятного чтения.

Те, кто работают в крупных компаниях (энтерпрайзах всяких), наверняка сталкивались с ситуацией, когда разработчики заняты на каких-то "внутренних" задачах — пилят корпоративный портал или очередную систему бронирования всего на свете.
Редко это получается хорошо, но почти всегда — капец как долго.
 
С дизайнерами аналогичная история — не раз видел, как штатный дизайнер занят над проектами оформления некоторых внутренних артефактов компании. Почти всегда это плохая идея: тратят гору внутреннего ресурса, а получется шляпа какая-то. Но при этом обычно считают, что сделали невероятное одолжение компании (кроме самых скромных).
 
Но почему-то у Эппла не так. Вот пример внутренней почетной награды Sign of Excellence, которая вручается сотруднику за 5 лет работы в компании. Приятно смотреть и получить.
 
Как они это делают? Загадка.

Продолжая тему Apple.

Я нашёл в интернетах удивительный сайт https://vintageapple.org/
Там много разной архивной информации, так или иначе тематически относящейся к Macintosh. Лично мне больше всего были интересны старые выпуски журнала BYTE, ну и Inside Macintosh. Осторожнее, не повалите сайт :)

Пару картинок дальше.

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

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

За последние пару лет, кстати, ситуация упростилась сильно, развился пакетный менеджер, плагинчики, AdaCore смержили коммьюнити и про-версии GNAT и сделали их доступными как FSF, так что одной головной болью меньше. А из грустных новостей наблюдается то, что GNAT Studio, самая продвинутая IDE, больше не выпускается официально под MacOS, так что кодить будем в VS Code. Но ничего, пакетный менеджер поставит нам всё, что нужно для работы.

1. Итак, первым шагом необходимо отправиться на сайт https://ada-lang.io/ и качнуть оттуда Alire - пакетный менеджер Ada. Я качал для MacOS, разумеется. То, что скачали, разархивируем, снимает атрибут командой [$xattr -d com.apple.quarantine bin/alr]. Я рекомендую прописать путь к bin/alr в PATH

2. Устанавливаем редактор VS Code, проверяем, что запускается. В разделе Extensions находим Ada Language Server (тот, что без поддержки отладки), ставим. Даже не понадобится перезагружаться.

3. Генерируем тестовый проект. Для этого открываем Terminal, там отправляем команду [$alr get hello]. Данная команда должна скачать и инициализировать на диске тестовый проект hello в отдельной папке.

Если это первый запуск (а у вас так и будет), то запустится асистент выбора тулчейна. Вам предстоит выбрать два продукта:
- GNAT - компилятор, рантайм и т.п. - выбирайте под вашу платформу (native), с кросс-компиляцией потом разберетесь;
- GPRBuild - инструмент для сборки проектов - выбирайте посвежее.
Далее делаем [$cd hello] после успешного окончания команды.

4. В VS Code делаем Add Folder, и добавляем hello. Теперь можно походить, поизучать, что у вас там в проекте сгенерировалось. Обратите внимание на файлы .gpr, это файлы задания самого проекта и его настроек. Примечательно, что это не xml и не .ini, а само по себе обычный код на Ada.

5. Теперь делаем [$alr run]. Вы должны увидеть что-то:
ⓘ Building hello/hello.gpr...
Compile
[Ada] hello.adb
Bind
[gprbind] hello.bexch
[Ada] hello.ali
Link
[link] hello.adb
Build finished successfully in 0.14 seconds.
Hello, World!

6. Если что-то пошло не так -- а под MacOS с этим может быть связано что-то с X Code, то нужно добиться, чтобы у вас корректно заработал xcode, в том числе CommandLineTools, а потом вернуться к Ada. Суть в том, что GNAT, который настроен на использование GCC, может испытывать проблемы при использовании clang, который мимикрирует под gcc под MacOS. Не буду пересказывать документацию, в интернете много рекомендаций как обновить все до актуальной версии, рекомендую начать с этого.

7. Если у вас всё заработало, то дальше следует выполнить поучительные эксперименты. Во-первых, следует запустить команду [$alr exec -- gprconfig], и после короткого диалога посмотреть на сгенерированный файл default.cgpr, который визуализирует все настройки по-умолчанию. Его имеет смысл удалить, сгенерировать всегда сможете. Во-вторых, следует запустить [$alr] без аргументов, и ознакомиться с выводом, возможно, запросить [$alr help ....] по интересным командам.

Если всё работает, можно двигаться дальше: добро пожаловать на бесплатный обучающий курс Ada https://learn.adacore.com/courses/intro-to-ada/index.html. И теперь примеры из него можно будет компилировать не только в браузере, но и локально.

А документация на Alire тут: https://alire.ada.dev/docs/

Когда некоторое время назад я прочитал о методе ведения заметок Zettelkasten (ZK), то попробовал вести свои заметки, как описано в нём. Ничего не получалось, никакой пользы от этого я не увидел. Раз не видно никакой пользы -- я быстро оставлял попытки, хоть и начинал несколько раз.
 
Проблема оказалась не в методе ZK, проблема оказалась в том, что "продают" под этим названием. "Копи-переврайтерам" очень нравятся абстрактные темы, которые можно раскачать до нескольких тысяч знаков, поэтому весь интернет заполнен фантазиями на тему ZK. В самом деле, никакой новости нет в том, что куда-то можно откладывать карточки с информацией, ставить на них гиперссылки. Многие так или иначе собирают заметки, это не спасает от того, чтобы заметки в конце концов превратились в свалку.
 
Так продолжалось, пока я не нашел в интернете оригинальные описания, и не смог сопоставить, в чем же состоит метод. В ZK важны некоторые детали, но они не описаны даже в Wiki. ZK называют "системой", но как раз система там не возникает. Ниже я расскажу, как стал вести заметки я, и прокомментирую эти важные детали.
 
0. Я много лет использую MS OneNote, так что и карточки ZK стал вести в нем. Из минусов -- он не умеет проставлять обратные ссылки сам. Но я пока не особо увидел пользы от обратных ссылок, возможно, они не так и полезны. Слышал, что кто-то использует Notion или Obsidian, сравнить не могу, я не использовал других инструментов.
 
Теперь к самим деталям тезисно.
 
1. Первая и самая главная деталь, о чем в интернете не пишут: у вас непременно должен быть "отстойник" записок. Я называю его у себя исчезающие заметки. Туда я скидываю все, что хочу впоследствие развить и отработать. Я не добавляю туда ссылок, не пишу анализ, никак не оформляю, и так далее. Единственная цель отстойника -- снять информацию "вотпрямща". В течение недели я пишу и копипащу туда сырые мысли, не глядя на остальные карточки вовсе, это write-only хранилище. За неделю накапливается 10-50 заметок.
 
2. Раз в неделю, регулярно примерно в одно и то же время, я сажусь за разбор этих заметок. Понятно, почему они исчезают -- я одну за одной разбираю заметки, ищу дополнительную информацию в интернете и у себя в предыдущих карточках, раздумываю, часто переписывая своими словами то, что было зафиксировано, добавляю выводы, если могу. Нет цели превратить заметку в карточку как есть, поэтому часто несколько исчезающих заметок превращаются в одну карточку со связанными тезисами, либо одна, наоборот, разделяется, на несколько карточек. Как именно заводятся карточки, я опишу далее. Какие-то заметки я просто выбрасываю.
 
Вот так эти карточки исчезают из "отстойника", что и дало им название.
 
Пункты 1 и 2 здесь самые важные  -- это то, что помогает организовать процесс, систему ведения заметок, а не систему заметок.
 
3. По итогам разбора заметок создаётся карточка (а то и не одна), она и отправляется в ZK. Вот именно здесь и наступает самая ценная стадия осмысления, категоризации, работы с источниками и знаниями, добавление связей с другими мыслями.
 
Теперь напишу про категории и то, как это должно работать. Это будет уже техника, её в интернете и обсуждают, в основном.
 
3а. В интернете пишут про теги. Оригинальный ZK для этого использовал специальные "индексные карточки" -- это карточки-оглавления, куда добавлялись номера всех карточек,  касающихся той или иной темой. Карточки-оглавления по темам я веду, но никакие ссылки туда не добавляю, только ключевые слова -- если у вас есть полнотекстовый поиск, а не ящик бумажных карточек (а он в MS OneNote есть), то теги становятся излишними.

3б. В интернете яростно спорят про какую-то хитрую нумерацию карточек через косую черту. В оригинальном ZK в качестве категории было только одно -- то число, с которого начинается номер карточки. Скажем, 1000 означает материалы о бессмертии, а 200, скажем, о пятнах на Юпитере. Дальнейшая нумерация (например, "200/1а/2") в оригинальном ZK никак не связана с категориями, автор просто брал первый попавшийся свободный номер, за исключением того, что буква рядом с номером означает продолжение мысли, если оно вдруг нашлось. Я так не стал использовать буквы, так как в MS OneNote всегда можно отредактировать карточку, явно выделив перечеркнутым шрифтом то, что устарено, и дописав в конце новое. Лично вы можете делать как угодно.
 
3в. В интернете пишут, мол, карточка должна ссылаться на другие карточки, но как именно? Многие добавляют прямо в конце список ссылок на другие карточки (а в тех -- обратные ссылки), я делаю иначе -- просто выделяю слово и делаю его ссылкой, автор ZK примерно так и делал, для этого ему и нужны были точные номера. Так же автор ZK настойчиво рекомендовал рядом со ссылкой пояснить письменно, почему была добавлена та или иная ссылка. Тут помогает MS OneNote своими возможностями -- можно и дописать карточку, и ссылку встроить, и побродить поиском по существующим карточкам в процессе написания очередной карты, и картинку добавить.
 
Вот, собственно, и всё, что превращает записи в систему. Этот пост я тоже оформлю как карточку.
 
Надеюсь, тон заметки вышел не слишком поучающим. Пользуйтесь, и удачи вам в создании собственного экзокортекса.