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

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

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

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

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

Появление в моей жизни компьютера открыло совершенно новые горизонты, о которых ранее я не мог даже мечтать, утоляя мою сильную тягу к изучению и исследованию нового. Отсюда 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. Поддержка знаний постоянной практикой в виде пет-проектов для уменьшения забывания. Пет-проект не предотвращает временных потерь при возобновлении активного использования инструмента, но сильно их снижает. Однако проблема поддержки никуда не исчезла: каждый язык программирования очень трудоёмок и содержит в себе огромнейшее количество нюансов, которые нужно помнить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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