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

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

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

почему разработчики пишут такой код? причины, из-за которых именно авторы кода создают высокую когнитивную нагрузку?

Вы рассматриваете только одну причину, и не факт - что главную. Главная причина, на мой взгляд - в том, что когда программист создает программу, он находится в процессе решения, а не записывает уже готовое решение. Естественно, это относится только к сколь-нибудь нетривиальным программам, а не к воплощению чего-нибудь по давно известному образцу, типа формошлепства или перекладывания джейсонов. Поэтому он записывает промежуточное решение, а потом дополняет его, чтобы оно таки решало задачу. Отсюда, в основном, и возникает избыточная, не обусловленная задачей сложность программы. А названное вами стремление предусмотреть всё (over-engineering) - это причина вторичная, не всегда присутствующая - к примеру, сложность программы, полной "обходных решений" (в терминологии ITSM, по жизни их называют костылями), никак не вызвана стремлением что-нибудь предусмотреть.

А понижать сложностьпрограммы после ее написания - это отдельная работа, в которой наемный программист, кстати, совсем не заинтересован.

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

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

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

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

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

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

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

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

А почему снижает возможность?

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

Это же не юридический документ, это джентельменское соглашение о намерениях

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

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

А мне вот интересно, скажут ли что-нибудь местные поклонники идеи профсоюза - @it_union - по этому поводу. По моему разумению, эта статья должна оказаться в сфере их интересов, потому как она - про взаимотношения работодателя (точнее, его представителя-менеджера) и наемных работников.

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

Ну и да, дело было на 2003 домене)

Ну да, дела давно минувших дней. А, вон, в домене NT принтеры вообще негде публиковать было.

Но мы-то сейчас живем в более прогрессивные времена, не так ли?

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

"Но как, Холмс?"(с). Как вы закроете этот разрыв? Для этого надо хранить связанное с логикой состояние. В десктопном приложении это делается просто, почти автоматически. А веб-приложения хранить контекст между запросами, вообще говоря, не позволяют. Единственная известная мне попытка сделать фреймворк, хранящий контекст приложения, чтобы упростить разработку для web и сделать ее похожей на разработку для ПК - WebForms в ASP.NET от Microsoft - к успеху не привела. Как вы намерились решить эту проблему (не в конкретном приложении, а систематически)?

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

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

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

Способ снижения сложности заменой вложенных if на ранние return тоже сомнителен. Потому что он коварен: эти ранние return можно не заметить вовремя. И если потребуется дописать в конце какой-то общий код, их легко упустить. На заметку теоретикам: по факту, эти return - ничто иное, как скрытые goto (они тоже нарушают естестественную связь между последовательностью написания и последовательностью выполнения), а теоретикам еще Дейкстра заповедовал "GOTO считать вредным". Есть, конечно, надежный способ ничего не упустить - конструкция try ... finally, но, во-первых, она есть не везде, а во-вторых - предназначена для решения другой задачи и может оказаться излишне тяжелой в процессе выполнения.

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

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

ещё один подключал пользователю нужные ему принтера в зависимости от данных в AD

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

Я не менеджер. Также бегу в общей упряжке с другими, просто впереди (я техлид).И я стараюсь работать над важными вещами (как для бизнеса, так и для меня) и окунаться в них с головой.

Чем именно занимается техлид в конкретной компании - это вопрос сложный, но предположим, что он занимается технической стороной эффективности процесса разработки: выбор используемой платформы, стандартами написания кода (всякий там "чистый код", солиды и прочая), организацией процессов контроля качества (код-ревью и т.п.). То есть его область ответственности - это качество и эффективность производства ПО на первичном уровне. Короче, он отвечает в какой-то степени за продукт и получает за это некоторые деньги. В результате техлид объективно (т.е. материально) заинтересован в эффективности производства и качестенности продукта. Занимается ли он в дополнение к этому разработкой - это вопрос вторичный, не определяющий его место в системе производства.

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

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

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

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

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

PS И да, наемный работник свою душу не продает - он ее сдает в аренду, на оговоренных условиях ;-)

Мне, как твоему коллеге, неважно, сколько ты зарабатываешь.

...

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

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

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

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

В общем-от да.

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

Так вот, приступим. Если вы прочтете фразу "Он шел между мафами со своей старой кравчучкой", то вы ведь легко поймете, о чем речь, не так ли? А вот для большинства хаброжителей это будет сильно труднее IMHO. Или - о ком и о чем идет речь в фразе "Бене никуда уезжать нельзя: по нем кича скучает что в России, что в Америке". Нет, практически любой носитель русского языка поймет, что Беню хотят посадить в тюрьму в обоих названных государствах, но поймет ли он, кто такой этот Беня (ведь из контекста ясно же, что речь тут не о персонаже Бабеля), и заслужил ли он такую участь?

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

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

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

Как-то так.

Немного теории.

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

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

Предыдущая часто встречающаяся фраза - обычно используемая иллюстрация того, что наемные работники и предприниматели обладают разными возможностями. И поэтому, на стабильном рынке рабочей силы, без ее дефицита, зарплата устанавливается на уровне цены ее воспроизводства: работники работают буквально за еду и крышу над головой для себя и семьи (семьи - потому что без нее воспроизводства рабочей силы в долговременной перспективе не будет). А все производимые обществом сверх этого блага оказываются в руках предпринимателей. Это все извстно с середины XIX века, со времен Маркса.
Выглядит такое расределение благ несправедливо хотя бы с точки зрения тех самых наемных работников, а потому в обществе возникает нестабильность.
Профсоюзы же, как раз выравнивают (отчасти) возможности наемных работников и предпринимателей, позволяя добиться более справедливого, с точки зрения наемных работников, распределения произведенных благ. А государство им часто, как минимум, не мешает: потому что нестабильность общества - это для государства большая проблема. Потому государство и принимает законы вроде ТК РФ, дающие наемным работникам дополнительные права, позволяющие им получить лучшее условия сделки с нанимателем.

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

Да, собственно про это MS и пишет, когда упоминает JS, что он давно поддерживается.

По правде говоря, тот JS, который был в WSH вместе VBScript и современный JS, который, к примеру, в браузерах - это небо и земля. Я где-то год назад освежал свои знания по JS и этому поразился.

сетевой стек, который у Linux гораздо понятнее, и лучше проработан.

Вопрос спорный. Вообще-то сетевой стек там идет от одного и того же корня - Berkley Sockets. У Windows там ищначально было преимущество в поддержке асинхроннности (ибо в кооперативно-многозадачной Windows for WorkGroups 3.11 без этого было нельзя). Ну а в NT (и выросшейей из нее современной Windows) архитектура ввода/вывода изначально была асинхронной, а потому костыли типа epoll или WSA-функций из WfWG там изначально не требовались. Но, к примеру, Netfilter, таки да, в Linux появился на несколько лет раньше, чем его аналог в Windows - Windows Filtering Platform в Vista/Server 2K8. Насчет виртуализации сетевого стека для приложений, когда она появилась - не скажу, для пользовательских приложений она была без надобности. В современных Windows Container она есть, AFAIK - на базе связки виртуального коммутатора HyperV и WFP, я эту связку я по Server 2012 ещё помню, а когда появилась - не выяснял, может ещё и в Server2K8 R2.

Дело тут IMHO в другом: в стратегическом решении MS отказаться от развития Windows Server как универсальной платформы для приложений "на земле", без Azure, вне зависимости от его технических достоинств - потому что это не соответствовало базовой стратегии преобразования в облачную компанию (где по оценке менеджмента бабла можно поднимать больше). В результате имеем, к примеру, что в ASP.NET Core мультиплатформеннный стек на Kestrel оптимизирован куда лучше, чем базирующийся на уникальной для Windows функциональности драйвера режима ядра протокола HTTP и связанных с ним очередей (банально, к примеру, нет такого кэширования и пула контекстов обработки (это чисто внутренняя штука, не HttContext известый пользователям фреймворка), как для Kestrel - ну, а без пула и кэша в .NET плохо - GC сильно напрягается).

PS Kubernets в Windows Server в варианте работы с Windows Container таки есть, но слово Azure в названии там намекает, что это нам объедки с барского стола после облаков кинули. Насколько ему нужен WSL2 - не разбирался.

Но я еще не уточнил, от Рудя или от Булдакова.

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

Но главное, я немного не про то спрашивал. Мне казалось что тут есть куда лучшие участники Спецолимпиад, которым понятие "проект" доджно быть знакомо. Неужелии их нет. Или они выработали иммунитет к нытью?

Что-то я тут этого не вижу, да и до того что Лейтан, что Поданс, что Нагаев тут не особо писали.

А чо, Поданс (AKA Camelot, для уверенности что мы говорим об одном и том же человеке) разве по-русски ещё что-то пишет? Он же, вроде как, более 10 лет назад с этим завязал.

Но дело даже не в этом. С коллегами-админами-то я могу и у ПП на зеленом пообщаться, но вот где в рунетах общаться с коллегами-программистами?

Все немного не так. То есть - совсем не так.

Просто уже есть WSL2, поэтому первый не нужен.

Первый - сильно легче. Потому что он - это подсистема. Примерно такая же, как Win32: Win32API ведь не является родным API Windows (современной, ведущей свое происхождение от Windows NT) , то есть интерфейс ядра имеет совсем другой набор функций (т.н. Native API). Эта концепция подсистем со своими API была заложена изначально в проект Windows NT. Но с концепция подсистем работает только в пользовательском пространстве и не совместима с приложениями, тесно связанными с ядром - вот и появился WSL2, который основан уже на виртуальной машине.

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

Виртуализация приложений в Windows существует примерно с тех же пор, что и в Linux. В частности, современная WIndows без виртуализации пространства имен работать просто не может: изначально в Windows NT не было сессий со своим виртуальным пространством имен системных объектов (они появились в AFAIK уже в WinNT 4.0 TSE, для потребностей многопользовательского терминального доступа), а в сколько нибудь современных версиях Windows (начиная с Vista) сессии не просто есть, а необходимы: сервисы ОС и программы пользователей (даже локально зарегистрированных с клавиатуры/монитора) выполняются в разных сессиях. А сессии как раз основаны на виртуализации пространства имен ОС - не только объектов файловых систем, а вообще всех именованых объектов. А в терминальных решениях от той же CItrix виртуализация приложений использовалась еще шире. Да и сейчас в версии Docker, адаптированной для Windows, есть поддержка Windows-специфических контейнеров. Другое дело, что MS решила не переносить управляющие компоненты Docker под Win32 а предпочла запускать их через WSL2, видимо, решив, что переносить не выгодно (да и не соответсвует стратегии MS по переводу своего бизнеса в облака), но технически это можно было бы сделать.

Вместо VBScript есть множество решений, включая тот же встроенный повершелл. Или просто ставишь питон/перл/JS/bash и понеслась.

Что ещё интереснее, в Windows параллельно с VBScript и примерно на тех же правах всегда существовала и версия JavaScript - по крайней мере, я не помню версию Windows Scripting Host, (WSH) в которой его не было. И вообще, WSH был штукой изначально расширяемой - например, кто-то когда-то сделал под него версию Perl - ибо WSH был основан на стандартном API COM (так же, как, к примеру, Powershell основан на стандартном API .NET CLR, под который можно и другие языки перенести - и, по крайней мере, Python, работающий с CLR, точно есть).

Уважаемый, вас я тоже попрошу не втягивать меня на Хабре в Специальную Олимпиаду. Ибо мне действительно пофиг, кто тут бот, и сколько ему платят. Ибо, в конце концов, сколько бота не корми, а у айтишника толще (я про кошелек, а не про то, что вы могли подумать ;-) ).

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

TLDR: Кароче, "мне очень важно ваше мнение", но избавьте, пожалуйста, лично меня от его созерцания. А если вас такое мое отношение обидело, можете утешиться Писанием, Мф.7:6.
Я же буду только читать то, что было написано в комментариях, и отвечать на них так, как нам было завещано древними греками: используя чисто рациональных рассуждения и не используя argumenta ad personam

Теперь целиком.

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

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

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

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

Мне было важно, что он высказал мнение, противоречащее моим интересам как наемного работника сферы IT. И потому я ответил ему, опираясь чисто на логику.

вырос до руководителя отдела разработки

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

PS А бояться попасть под раздачу в нынешних условиях разработчикам совершенно точно не надо - разве что они попали на теплое место в бизнес типа "хрючить", по классификации Белоусова.

Кстати стал искать ссылку на исследование. Небыли такого эксперимента.

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