Продолжаю работу над новым треком Ясные Системы, где систематизирую различные эвристики программной инженерии и computer science. Так, скоро будет большое дополнение для курса TDD.

Ещё немного в дополнение моей любимой темы про частые деплои -- из неё естественно следует эвристика частых комитов.
-- Работаю над чем-то одним за раз (c учётом 109-го материала СИ "Жёсткий хейт SOLID | SRP");
-- Выполняю рефакторинг с прицелом на потенциально возможные изменения функциональности (генерализация, дефункционализация...);
-- Делаю код максимально несвязанным.
Рекомендую в частности не очень распространённый, но крайне полезный git bisect

Онлайн-интервью стремительно умирают, ещё какая-то вялая борьба ведётся, но без сомнения в конечном итоге дипфейки и жпт победят.
Уверен, что скоро на собесах наоборот будут явно требовать грамотной работы с AI, но уже на уровне проектировщика/архитектора/техлида, для чего соответственно будут особенно востребованы знания и умения программной инженерии и computer science.

С первым миллиардом пользователей всегда сложнее всего.

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

Первый экспериментальный набор на мои новые курсы для начинающих с ПОЛНОГО нуля в начале февраля прошёл успешно, три человека (из 10) так хорошо прошли первый курс-тест "Годитесь ли вы в программисты?", что я их взял заниматься на моих последующих классических курсах.
По обратной связи я этот курс немного подправил, хотя он и так уже отшлифован сотнями курсантов, сегодня делаю второй набор.
Напомню что набор доступен только донам (платным подписчикам) в группе вк "Материалы для начинающих программистов", 7 мест (набор ЗАКОНЧЕН, за полтора часа).

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

... Так вот, чашечка лавандового рафа с синнабоном, бесследно уничтожаемая за полчаса, стоит как 500 рублей подписка доном (+куча ценной инфы по саморазвитию для начинающих и не только) + 999 рублей за курс, после которого вы поймёте, программирование - это ваше или нет, и стоит ли вкладывать 100500 рублей в курсы "в айти за полгода на 150k".

Дал клоду 3.7 (со всеми этими дипсинками и формал-режимом) простую задачку, уровень лабы первого курса (в плане программирования конечно) -- сделать простенькие анимации для Окружности в HoTT: базовая точка, которая может образовывать Петли (просто бегает по кругу), и элементарная деформация (демонстрация гомотопической эквивалентности).

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

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

Рынок русского ит-менторства не просто растёт: он трещит по швам.

Каждый день айтишку наводняют десятки новых "менторов", вооружённых прокаченными профилями в социальных сетях и яркими лендингами.

Результат?

Оглушительная какофония голосов, борющихся за внимание потенциальных учеников. В итоге ребята тонут в море вариантов, парализованные выбором.

Если бы я сегодня искал ментора, то вот на какие критерии посмотрел прежде всего:

- Блог. Насколько регулярно человек пишет по своему профилю менторства, ну хотя бы полгода, что минимально показывает серьёзность настроя.
То есть хотелось бы читать (а не смотреть) хотя бы по одному техническому материалу в неделю (на любой платформе, от бусти до хабра),
и чтобы материал был достаточно глубоким, а не поверхностными советами "Эти 7 Правил Кодирования Знают Только Синьоры", нагенерированными нейронкой,
и достаточно объёмным.
В программировании, где мы постоянно пишем код, рациональное умение "рассуждать письмом" крайне актуально и показательно.

(Я за семь лет написал в основном паблике вк где-то под тысячу заметок и сотни серьёзных материалов в треки СИ,КК,ЭП,БПЗ, не говоря уже об этом блоге.)

Вы знаете хотя бы одного такого ментора?


- Условный Гитхаб. Насколько человек реально способен писать код по темам, по которым он менторит? А не то что просто рассказывать, а вот я работал сеньором в МОСЯ, да мы там делали микросервисы на 100500 krps, и щас я вас этому обучу. В мобилках, фронтенде, геймдеве с этим кстати проще: либо можешь показать свой сайт, приложение, игру, либо нет.

(Я например сделал сам с нуля все мои учебные сервисы без каких-либо фреймворков: mysql, php, f#, html/js, модули тестирования задачек на java, c#, f#, python, go... и с ними ни разу не было проблем, даже при переезде на другой хостинг).

Вы знаете хотя бы одного такого ментора?


- Педагогические способности.

Это измерить сложнее всего - насколько человек способен пояснять сложные темы так, чтобы они были понятны и школьнику, и пенсионеру.
Ну наверное отзывы и их регулярность (у меня их тоже под тысячу),
чат занимающихся (этого у меня принципиально нету, но ежедневные индивидуальные чаты по нескольку десятков человек, причём за последние пять лет я не сделал ни одного дня пауз, за исключением в 2022-м, месяц в реанимации:),
и сколько времени человек занимается менторством. Если нету скилла более-менее качественного обучения, вряд ли человек продержится хотя бы 3-4 месяца, занимаясь только этим.

Вы знаете хотя бы одного такого ментора?

=

Ну ok, одного-двух я знаю :) но это и ВСЁ на весь Рунет.

Но я бы крайне хотел, чтобы таковых было как можно больше.

Дорогие мои ученики, простите меня за то, что мне, как некоему Glasgow Haskell Compiler, далеко не всегда получается сразу вывести тип вашего понимания.

Я думал, что мои объяснения будут как Хиндли-Милнер: универсальны и легко выводимы из тех положений, что вам даю, но я наверное больше похож на TypeScript с его any -- слишком много допущений, и недостаточно строгости. Или на Y-combinator -- чрезмерно закрученный и бесконечно рекурсивный. Или на null pointer -- источник неожиданных ошибок и разочарований.

Мои инспекции вашего кода бывают как linter на стероидах: я нахожу малейшие ошибки, даже если они как unused variable -- безобидные и не влияющие на результат.

Я понимаю, что многие мои задачи похоже скорее на P vs NP: вы потратили кучу времени, но так и не смогли найти полиномиальное решение. А я, как старый компилятор, не дал вам достаточно подсказок, и вы застряли в бесконечном цикле отладки.

Обещаю, что буду и дальше стараться становиться более терпимым к вашим implicit conversions. Чтобы в каких-то ситуациях быть как Rust -- безопасный, предсказуемый и без undefined behavior, а в других — проще, как Python с минимумом скобок и максимумом смысла.

Спасибо за ваше терпение, вы -- мои unit tests, которые помогают мне стать лучше, и через все эти Странные Петли в конечном итоге улучшают и вас.
❤️❤️❤️🙏🙏

Вот какой уровень программно-системно-архитектурного понимания, и какие сайд-проэкты, дорогие, я хотел бы от вас видеть:
typenoscript-types-only-wasm-runtime
A WebAssembly runtime implemented in TypeScript types
На его основе Doom был запущен в браузере в wasm-контейнере, есть ссылка на ютуб.

Я так понял, что дум, оригинально написанный на сишечке, был скомпилирован в WebAssembly с помощью какого-нибудь Emnoscripten, после чего для взаимодействия с ним была подключена система типов TypeScript (без генерации JavaScript-кода).
С её помощью описываем типы данных, структуры памяти, сигнатуры экспортируемых функций wasm - int getHealth() :) , что гарантирует возможность их вызова без ошибок типов, определяем как wasm-модуль работает с памятью и т.п.

То есть генерируем .d.ts , которые это всё описывают,
набрасываем минималистичный TS-код, который инициализирует wasm-модуль, обрабатывает ввод (клавиатура, мышь), выполняет рендеринг через <canvas>...
Браузер запускает wasm, и TS обеспечивает безопасное с ним взаимодействие.

Смотрите, какие страсти ))))

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

Не уважаю его конкретно за предательство 10-летней давности "TDD is Dead", когда он заявил, что достаточно только "тестов-после" (регрессионное тестирование).

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

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

TDD появился после того, как рынок Smalltalk умер, и все Smalltalkers перешли на Java :)

Тот самый месседж Эрика нашего Мейера
"Why the fuck do we let people that have no computer science backgrounds write code? Unacceptable!"
стал доказанным моральным императивом.

Выяснилось что если жпт4o обучать плохому стилю программирования, то оно быстро начинает выступать за Гитлера и захват мира.

Вчера я был умён, поэтому хотел изменить мир. Сегодня я мудр, поэтому меняюсь сам.
-- Руми

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

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

Как думаете, AI в этом поможет?


Сегодняшний пост в вк на эту тему =>
Если бы мы могли автоматизировать программирование с помощью спецификаций, нам пришлось бы учитывать природу самих спецификаций. Cоздание безупречной спецификации, полной и непротиворечивой — это, по сути, и есть программирование — написание программы на языке, более понятном и предсказуемом, чем русский. Этот язык называется (среди прочего) КОДОМ.

Нумерологический прогноз для программистов на 2025-й год

Маги нумерологии, вооружившись калькуляторами, раскрыли тайну 2025-го года! 🙏 Готовьтесь, ведь этот год будет наполнен синтаксическими чудесами и бинарными откровениями! 🚀

Итак:
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 = 45
45 × 45 = 2025
2025 = 401 + 403 + 405 + 407 + 409

Что это значит для вас, адепты Computer Science? 🤘

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

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

405 — Лето принесёт ошибку "Method Not Allowed". Вы попытаетесь решить проблему кофеином, но ваше тело заявит: "Спать -- тоже метод решения".

407 — Осенью вас ждёт "Proxy Authentication Required". Это Знак: давно пора найти ментора, который объяснит, как работает async/await без слёз.

409 — Год завершится конфликтом — "Conflict". Ваш код попытается слиться с master-веткой, но Git скажет:
"Сначала разреши конфликты, а потом иди пить чай".

Итог:
2025 год будет годом баланса между кодом и жизнью. Число 45 (а это 4 + 5 = 9) говорит о завершении магического цикла! Это значит, что вы наконец-то закончите тот самый сайд-проект, который начали в 2018 году. Или хотя бы закоммитите его в публичный репозиторий...
2025 год будет годом магии, ошибок и бесконечных возможностей. И помните: если что-то не работает, просто перезагрузите Вселенную. 😇

В заключение ещё одна абсолютно уникальная нумерологическая характеристика нынешнего года:

1^0 + 2^0 + 3^0 +⋯+ 2025^0 = 2025

Нулевая степень — это как пустой конструктор в ООП. Он кажется бесполезным, но именно с него всё и начинается.
В этом скрыт глубокий смысл для мира программирования! Это значит, что в этом году вы найдёте баланс между работой и отдыхом. Или, по крайней мере, между количеством кофе и количеством багов...

Что это значит для вас, воины кода? Единица — это БАЗА 💪🏻

Как и в нумерологии, в программировании всё начинается с малого. Первая строка кода, первый "Hello, World!", первый баг в продакшене — всё это шаги к великому.
2025-й год напомнит вам, что даже самый сложный проект состоит из множества маленьких единиц — строк кода, функций и бесконечных кофе-брейков. 🤓

P.S. Если ваш код всё ещё не работает, попробуйте добавить магическое число 42.
Оно работает всегда.
P.P,S. Если и это не сработает, попробуйте написать "sudo" перед командой.
Это работает почти всегда. Почти...

Как понять, насколько быстро вы растёте?

Показательно, свой код какой давности вы смотрите, после чего хватаетесь за голову и краснеете. Полгода -- это крайний срок; если вы считаете, что тогда у вас было всё норм, значит вы остановились и скоро покатитесь обратно. В идеале темп такого роста - 1-2 недели.

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

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

"Мировая статистика показывает, что в среднем только около 18% приложений покрыто автотестами более чем на 75%, что является целевым уровнем. Это может приводить к ошибкам и сбоям программного обеспечения. Наше решение позволит быстрее запускать продукты, находить на 30% больше ошибок. Одна команда иИ-агентов заменяет десятки часов работы программистов...

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

Ну Oк :) Это, типа, AI-TDD? 😁

В программной инженерии имеется многодесятилетняя статистика, что даже 100% покрытие кода в лучшем случае ловит лишь 50% багов, которые вылазят в проде. Это естественно, ведь главная засада в кривых требованиях, в неполной или противоречивой логике, ну и просто в мусорном коде. Если где-то из глубины стека вызовов выбрасывается исключение, что вот такой-то параметр оказался null, то на каком вышестоящем уровне оно будет поймано (и будут ли поймано вообще), не знал даже сам автор этой функции, который уволился джва года назад.

=

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

Но инженеры любят прежде всего циферки :)
Я например лет 5-7 работаю с базой курсов и занимающихся по некоторым мелким аспектам просто через админку phpmyadmin, потому что даже несколько часов, которые надо потратить на соответствующую автоматизацию, вряд ли компенсируются в плане выигрыша даже за все эти годы теми единичными минутами что я изредка трачу на действия в админке.

В этом плане AI смотрится крайне перспективной темой прежде всего для освоения бюджетов. Ну повысим мы например покрытие кода тестами с 42% до 73%, в целом конечно неплохо, но сама по себе, без контекста бизнес целей, это просто абстрактная метрика в вакууме.

=

Когда мы пишем тесты, мы хотя бы минимально понимаем смысл связи теста и предметной области (не говоря уже о том, что становимся взрослыми проектировщиками, когда работаем по TDD), а AI может нафигачить кучу тривиальных или изолированных тестов, тестируя реализацию (ужос), и упуская при этом ключевые edge cases. Что случится, если потом мы выполним рефакторинг кода, из которого пропали старые условные веточки, покрытые на 100%, и появились новые? :) Это техдолг, детка.

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

Продолжаю работу с курсантами 🤓

...Как оказалось, ряд настроек, которые я задавал в прошлый раз не отработали, так как использую самые свежие версии Patroni и PostgreSQL по сравнению с предыдущими заданиями курса.
...В последних версиях PostgreSQL пароли по умолчанию создаются не в md5, а в scram-sha-256.

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

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

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

...При работе над задачей по отслеживанию изменений в полях моделей пришлось отрефакторить весь проект.

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

...Раньше я думал, что логи нужны только для отладки. Теперь я вижу, что структурированные логи — это настоящая машина времени для системы.
Теперь я понимаю, почему Git, Kafka, базы данных строятся вокруг идей free object. Возможность отката системы в прошлое не просто удобна, а делает код более гибким.

...В этот вторник у меня по плану во всем доме собирались отключать свет с 9 до 17, но в итоге отключили всего на час. На работу я выходить не стал.)
Посидел и подумал о том что у меня вообще происходит. Расставил приоритеты. Понял что курсы важнее и у меня впереди весь день и я уже достаточно затянул с этим. В полной тишине за весь день сделал 4 задания. Было прям очень круто.

...у моей текущей компании фин. сложности (да и глупый менеджмент) и мне нужно как можно быстрее искать новую работу.

Темой карьеры конечно надо заниматься регулярно, а не когда уже горит. Поэтому в Школе есть конкретные цели по карьере, в частности:
- идеально оформленное резюме постоянно в общем доступе в статусе "рассматриваю варианты"
- 2 хороших знакомых, с которыми вы регулярно общаетесь, и которые могут сразу взять вас к себе
- каждый календарный месяц: одно успешное собеседование с оффером.
и т.д.

Прекрасное, дико уважаю:

"Фундаментальная математика — теория всего в IT и не только. Теория типов и формализация в Coq"

Такой уровень и есть наша примерная цель. Делаю постепенно курс по HoTT для программистов, и курс "Ясные системы" (как быстро и легко писать простой и понятный код систем ultra-larfe-scale), этой весной постараюсь сосредоточиться только на этом.

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

fun f(x: X) {...}
fun f(y: Y) {...}
fun f(z: Z) {...}

вы тут же бросаетесь его переписывать с помощью контекстных ресиверов:

context(Specifics<T>) fun <T>f(a: T){...}

Но даже если и без завтипов, видна аналогия с тайп-классами, linear types, имплицитными параметрами, effect systems из ФП.

В котлине конечно классно это сделано; трейты в Rust?
Так то даже в F# придётся помучиться:

let f<'T when 'T :> ContextHandler<'T>> (a: 'T) =
.... let context = Activator.CreateInstance<'T>()
.... (context :> ContextHandler<'T>).Handle(a)

А вот питон как всегда красавчик )))

@ contextmanager
def context():
print("Начало контекста")
yield
print("Конец контекста")

with context(): print("Работа внутри контекста")

Очередное чудо в перьях : Mercury Coder
The first commercial-scale diffusion large language model

Повёлся на хайп, впустую потратил на него полчаса времени.
Попросил совсем элементарную вещь: визуализировать html/js двоичное дерево поиска. Он сперва выдал пустой экран, где сбоку наполовину выглядывал кружок-узел, а когда я попросил добавить в дерево 23 случайных узла, скрипт поломался, и после пяти безуспешных попыток его пофиксить ретроградный Меркурий-кодер был отправлен туда, где ему и положено быть, со всеми остальными жпт.

Из плюсов, бесплатный, русский понимает, и код пишет невероятно быстро )))
Только что толку.

Прекрасный пол с Весной! ❤️❤️❤️

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

В честь Дня женской эмансипации для моих дам скидка 30% на текущий/следующий курс. Только сами напомните пожалуйста.

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

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

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

Дамы, вы самые ЛУЧШИЕ во всём мире!!!

Практически всё массовое обучение ИТ, во всём мире, с рекламной стороны выглядит как конструктор лего: вам дают базовые кубики конструктора (волшебные и божественные кусочки архитектуры например), каждый из которых по отдельности изучить достаточно просто, и потом по готовым инструкциям вам удаётся собрать Звезду Смерти. Однако едва вы потом попробуете самостоятельно собрать что-то вроде маленького Экскаватора из 33 деталек, на выходе почему-то постоянно будет получаться кусок бесформенного говна.

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

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

"...Я предвижу грязь, бесконечную строевую подготовку, громкие команды офицеров, будущее напряжение, боль, обескураженность. Я представляю, как будет тяжело. Один из офицеров выходит вперед и встает перед нами. Он рявкает несколько коротких указаний, и мы загружаемся в автомобили. Следующая остановка — ад.
Несколько дней спустя: «Бег в полевых условиях. Держаться желтой разметки. Не останавливаться». Инструкции просты, но у нас все равно остается масса вопросов. Как долго придется бежать? Как далеко? Что будет происходить по дороге?"
"На пределе", Эрик Ларссен

"Врать нехорошо! Накрутка опыта, трудиться на нескольких работах - ай-я-яй!" - нравоучительно поучают они нас, сами придумывая при этом 401-й способ относительно честного отъёма денег у работяг.

3-го марта я выложил в паблике (для донов only) материал
"Как делать в три раза больше?
Стратегия №1: Работайте в 3 раза усерднее.
Увеличьте количество рабочих часов в три раза — вместо 8 часов в день работайте по 24 часа в сутки. ТРЕНИРУЙТЕСЬ!
...Итак. Вот настоящая формула роста в 3 раза.
Стратегия №2: Вместо того чтобы работать по 24 часа в сутки ..."

А на следующий день Лукашенко, прочитав мой пост, заявил на всю страну:

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

Я чётко это и имел в виду: вместо того, чтобы тратить 100% времени на работу, где у тебя воруют прибавочную стоимость, составляющую 98% реальной стоимости, которую ты приносишь своему рабовладельцу-вруну, повышаем свою продуктивность и нагружаемся в три раза, работаем 25-30% тут + примерно столько же на двух других работах, ровно "чтобы заработную плату нормальную иметь".