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

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

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

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

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

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

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

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

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

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

Эти проблемы корнями уходят в эффект Даннинга — Крюгера и прочие похожие, избежать которых совершенно невозможно, что даже можно вспомнить Козьму Пруткова: "нельзя объять необъятное". Невозможно выучить всё на свете, всегда нужно жертвовать какими-то знаниями, а эти эффекты будут бить в эти пропущенные области с наибольшей силой, выбирая самое слабое место и нанося самый большой урон результату. Поиск наиболее выгодного баланса в знаниях требует постоянных экспериментов, проб и ошибок, что завтра может сильно поменять и меняет набор рабочих инструментов, как и способы его использования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В общем случае это создаёт перенос всех проблем на конечное звено в цепи использования продукта: если A создал язык программирования, B написал на нём библиотеку, C сделал на этой библиотеке фреймворк, а D построил приложение, то все ошибки, просчёты и недоделки суммируются и переносятся по цепочке на последнего: A->B->C->D.

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

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

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

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

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

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

Здесь можно уловить абстрактные пересечения с Single responsibility principle в SOLID, а также с паттерном Information Expert в GRASP, как и другими похожими: в части получения дохода информационным экспертом является экономика, а не программирование. Нарушение зон ответственности и ошибки в информационных экспертах ведут к печальным последствиям, что в IT, что в реальной жизни.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В-четвёртых, язык должен быть схож с синтаксисом С-семейства для переиспользования между языками идей и кода. В более сложных проектах нужно собирать код по всему IT, портируя его с C, C++, Java, C#, JavaScript и прочих языков, накопивших за долгие годы огромные кодовые базы.

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

На данный момент всем моим требованиям отвечает лишь единственный язык - Dlang.

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

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

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

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

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

Наличие JavaFX позволило заполучить достаточно мощный десктопный фреймворк, не отставая от наиболее технологически продвинутых конкурентов из мира C#. GUI-тулкиты крайне универсальны и способны улучшить практически любой класс задач, начиная от экономии времени в быту и заканчивая рабочими инструментами. Без JavaFX всё могло сложиться совершенно иначе, ибо GUI-тулкит с юзабилити контролов старой школы, отделением вью от кода и GUI-билдером для меня очень и очень критичен.

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

Так, в последние годы меня заинтересовал Dart: легковесный и мощный тулчейн, JIT\AOT из коробки, а относительно высокая схожесть синтаксиса с С-семейством сильно понижает затраты времени на поддержку языка в стеке, облегчая обмен кодом между другими моими С-подобными языками. К сожалению, любое добавление языка в стек приводит к уменьшению времени на какой-то другой, иного пути здесь не усматривается. Поскольку я не могу жертвовать системными языками, то это время было снято с Java, что привело к сворачиванию многих проектов и экспериментов.

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

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

Как видно, выстраивание стека и сочетание языков друг с другом создаёт множество сложных системных эффектов между ними, со своими преимуществами и недостатками, которые всегда нужно учитывать. Поэтому снова напоминаю - не нужно ориентироваться на инструменты и языки программирования, которые я использую.

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

Много проблем создаёт подверженность рассуждений и выводов различным когнитивным искажениям, коих бесконечное количество. В IT знаменит "синдром утёнка", от которого очень сложно избавиться, а может быть и вообще невозможно. Но его, как и другие искажения, можно стараться ослабить, например, рассматривая предмет диалектически - в противоречиях.

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

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

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

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

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

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

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

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

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

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

Кроме того, нельзя забывать и ещё об одной фундаментальной проблеме, сопровождающей всех и каждого: errare humanum est - человеку свойственно ошибаться и с этим тоже трудно что-то сделать.

Поэтому снова напоминаю, что характер блога - исследовательский, не более.