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

Для начала зайдём со стороны обычного опыта разработчика. Когда я набирал себе языки в стек, то с удивлением обнаружил, что некоторые хорошие задумки: D, Groovy, Vala и т.п. не обладают высокой популярностью.

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

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

GRASP вводит понятие Информационного эксперта (Information Expert), определение которого звучит примерно так: ответственность должна быть назначена тому, кто владеет максимумом необходимой информации для исполнения — информационному эксперту, интуитивный и простой закон нашей жизни.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На уровне фирмы:

• Заказ статей на специализированные ресурсы:
  • Об успешно решенных задачах с помощью технологии для повышения её популярности.
  • О проваленных задачах с помощью конкурентной технологии, показательных переездах и решениях проблем.
  • О благоприятной атмосфере для разработчика, коллективе и т.п.
  • О проведении мероприятий, направленных на улучшение инфраструктуры в т.ч. и конкурентной.
• Всяческая поддержка авторов статей, связанных с технологией. Отслеживание и упоминание их для стимуляции к написанию в дальнейшем.
• Работа с негативом в социальных сетях и в поиске: понижение в выдаче, вмешательство в дискуссию с целью уменьшить её последствия, удаление прецедентов и т.п. Построение коммьюнити "адвокатов" - людей, наиболее лояльных технологии с целью защиты репутации. Отвлечение внимания и попытка утопить дискуссию о проблемах.
• Совместные акции или мероприятия с другими компаниями с общей аудиторией.
• Подрыв инфраструктуры конкурента: переманивание разработчиков, акцент недостатков и т.п.
• Перенос успеха одного продукта на другой (т.н brand leverage, family branding). В этом случае может сработать принцип: раз эта фирма делает качественно, то и новая технология будет тоже очень качественной. Может также сработать и взаимодополнение продуктов.
• Искусственно созданный конкурс с высокой долей отсева соискателей или сложностью собеседований для создания лояльности, понижения планки зарплат и т.п.
• Введение различных сертификаций и подтверждений соответствия, не соответствующих скорости изменения продукта, изменчивости рынка или сути выполняемых задач. Влияя на рынок, это можно также использовать и через правовую систему, например, лоббируя принятие правовых актов об обязательной сертификации и т.п. Сюда же можно отнести и другие правовые рычаги воздействия на рынок и конкурентов, что намекает на существование еще более высоких уровней - рынка, а также государства в целом.

На уровне инструментов:

• Различные бонусы или внимание к разработчикам библиотек с целью последующей интеграции в неё продвигаемой технологии. Использования их статуса или авторитета в рекламных материалах.
• Использование OpenSource:
  • С целью бесплатно заполучить разработчиков, сэкономив на тестировании и сопровождении.
  • С расчетом на последующую смену лицензирования.
  • С целью создания продукта, который практически неработоспособен без платных компонентов.
• Создание издержек перехода на другую технологию:
  • Излишне сложный продукт, которые требует большого вложения времени. Тем больше человек теряет времени, тем труднее перейти на альтернативу, тем больше возрастает ценность из-за потраченных усилий.
  • Привязка продукта к специфическим библиотекам, компонентам или железу.
  • Отсутствующий функционал, который способствует заменяемости, легкому экспорту данных или переходу на другой продукт.
  • Смена методов авторизации, ограничение функционала или сторонних api под разными предлогами, например, улучшение безопасности, сохранности данных и т.п.
• Исправление ошибочных стратегий развития языка или платформы на фоне развития конкурентов, которые приводят к обширной поломке совместимости или изменению принципов разработки.
• Многочисленные, частые и незначительные обновления наперегонки с конкурентами, для демонстрации активной деятельности и т.п.
• Создание психологической атмосферы уникальности инструмента или коммьюнити, четкое разделение на мы\они.

На уровне кода:

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

На уровне железа:

• Сотрудничество с производителем для обеспечения совместимости.
• Ограничения доступа конкурентов и т.п.

Еще раз напомню, что некоторые ситуации относятся к задачам разных разделов экономики, например, формирование мнения групп скорее задача PR (Public Relations), что часто рассматривается в контексте рекламной деятельности и т.п.

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

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

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

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

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

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

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

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

Однако тут можно вспомнить введение данной статьи о дилетантстве: отсутствие решения с базисом на неглубоких знаниях может быть лучше принятого. С этим трудно поспорить и тут уж каждый выбирает сам чем рисковать. Можно, например, попробовать снизить риски специализированными инструментами с помощью Event tree analysis или подобных, здесь все средства хороши до которых возможно дотянуться. Например, дихотомией можно предположить сначала два грубых варианта: язык умрет и не умрет (хотя бы понятие смерти и достаточно размытое). Если умрет, то переходить на другой, если не умрет, то его развитие может: улучшаться, не улучшаться и т.п.

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

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

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

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