Passive-Aggressive Programmer: история болезни

Сам я практически не интересуюсь психологией. Но иногда она сама интересуется образом жизни программиста. Как достоверно известно, большинство компьютерщиков — хронические интроверты. Следствие ли это длительной монотонной сосредоточенности на задаче, или это вытекает из порождающей склонность к одиночеству привычки тщательно продумывать все явления реальности — но факт остается фактом: исследователи констатируют, что именно компьютерщикам-программистам свойственна современная абберирующая модель поведения, часто обозначаемая психологами как «Passive-Aggressive».

Появился даже такой профессиональный жаргон как The Passive-Aggressive Programmer (PAP). Но кто такой этот PAP, что это за зверь офисный? Являетесь ли вы носителем этой опасной заразы модели поведения? Давайте попробуем разобраться вместе с этой статьей.

Есть такая профессия — «на нервы капать»…

Fail to agree

Но начнем со знакомства и базового определения — что это за феномен? Для порядка дам сначала ссылки на описание этой модели поведения на Вики или на About.

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

Типичные признаки

Давайте присмотримся к своим коллегам (только не к самому себе) и подумаем, свойственно ли нам подобное поведение — вот типичный диалог для примера.

 — (коллега) Мы тут посовещались и решили сделать X, чтобы решить проблемы в твоем софте.
— (PAP, продолжает смотреть в монитор) Я вообще не понимаю, в чем проблема…
— (коллега) Ну, мы же на прошлой неделе все обсудили, мы составили список всех проблем и багов, которые…
— (PAP, наконец, отвлекаясь от монитора) Ладно-ладно. Что вам от меня надо?
— (коллега) Ну, нужно сделать X, чтобы покончить со всем этим.
— (PAP, устало, откидываясь на спинку) Если честно, я просто не понимаю, как X может решить эти проблемы, на самом деле всё намного сложнее…
— (коллега) Хм… ну мы же обсуждали это уже… (пауза) ладно, какое решение предлагаешь ты?
— (PAP, раздраженно) Это не так просто, мне нужно все хорошо обдумать …
— (коллега) Как мы можем все-таки решить эту проблему? У меня проблемы из-за X.
— (PAP, отворачиваясь снова к монитору) Извини, у меня слишком много работы сегодня.

Этот диалог может принимать множество форм, но общее для них всех следующее:

• разработчик не хочет, чтобы ему кто-то диктовал условия (сознательно или подсознательно — неважно), и это дело принципа, поэтому все подобные решения-предложения автоматически саботируются;
• если на разработчика «нажимают», он, как правило, склоняется к эмоционально-эксцентричным выходкам или подлостям;
• для всех этих случаев общим является именно умышленное бездействие как способ завуалированного отстаивания своей точки зрения. Вместо непосредственно решения проблемы (или поиска компромисса) любое такое взаимодействие намерено переводится в плоскость изматывающего противостояния двух сторон;
• святая, глубинная уверенность PAP-разработчика в том, что он лучше понимает, как нужно правильно решать проблему, именно поэтому он… ничего не делает;
• наиболее часто подобные напряжения возникают именно на равнозначных позициях, когда вы просите коллегу исправить баг, т. е. указываете ему на проблему в общем проекте, которую может решить только он. Если начальник может просто заставить, то «равнозначному» коллеге, сталкиваясь с PAP, часто приходиться нервничать и нарываться на игнорирование общих для проекта интересов;
• специалисты отмечают, что образование и уровень культуры часто демпфируют негативные проявления PAP–поведения, в этих случаях свое несогласие PAP часто выражает через подколы и сарказм в отношении предлагаемого (-гающего). Формально «оставаясь на линии» в процессе коммуникации, PAP постоянно принижает и нивелирует ваши попытки решить общую проблему;
• также характерно неявное или анонимное противодействие/обвинения, например, написание безличных записок или посланий, или гневное публичное обличение неких мировых деструктивных сил — так, чтобы присутствующий при этом коллега точно понял, что речь идет именно о нем.

Психологи отмечают, что большинство PAP истерически боятся потери любой креативности и самостоятельности. Любое принуждение, неважно, конструктивное оно или нет по отношению к решаемой проблеме — разрушает субъективное ощущение «творческого полета» или «ценностной идентичности самовосприятия» у современной офисной личности. Например, любые далеко идущие рассуждения боссов о жизни, своим контекстом невольно задвигающие офисного креакла на свое (заднее) место, заводят и провоцируют PAP на брюзжание слюной, что повышает уровень офисной турбулентности.

Passive aggressive compliment for a programmer: «You are an excellent typist!

 — Michael Feathers (@mfeathers) 20 августа 2009

Чаще всего именно подобные ситуации является спусковым крючком passive-agressive, а вовсе не банальная лень или прокрастинация. У классического PAP’а всегда есть свой собственный план решения всех проблем, но время для решения именно вашей проблемы еще по какой-либо причине не пришло. Настоящий пассивно-агрессивный программист вообще никогда не согласен — даже со своими собственными предложениями недельной давности.

Пример 1. Интерферировать до последней капли крови

Пожалуй, стоит привести первый подкрепляющий пример классической Passive-Aggressive. В качестве такого наглядного примера я выбрал американскую компанию Brookfield Office, которая владеет недвижимостью во многих точках мира. Ее ИТ-департамент годами игнорирует самые разные воззвания принять меры на «своей территории». Так их подсветка от самого высокого здания в Лос-Анджелесе Ernst & Young Plaza интерферирует на частотах связи (high levels of RF interference), на которых работает мобильная сеть Verizon Wireless 700MHz network — ведущего LTE-оператора региона. Уже два года длится вязкая борьба мобильного оператора с технической службой этого небоскреба. Все просьбы, постановления и предложения о помощи отправляются в /dev/null/ игнорируются, при этом адресатом демонстрируется неимоверное упорство в попытках избежать любой коммуникации.

Любопытно, что подсветка зданий, принадлежащих Brookfield, в свое время была лицензирована, но никто не тестировал ее на столь специфические помехи, даже гипотетически не предполагая, что она способна настолько эффективно глушить мобильную связь в округе в темное время суток. Verizon Wireless даже готов оплатить весь необходимый ремонт, связанный с модификацией освещения, но гордый риэлтор сохраняет глухую оборону, затаившись где-то глубоко в полумраке бесконечных коридоров своего гигантского небоскреба. С тех пор Verizon прошла семь кругов ада, прежде чем смогла совместно со специалистами государственной комиссии FCC задокументировать саму проблему, что дало основания попытаться хотя бы через суд вынудить Brookfield к сотрудничеству. И даже последовавшие недавно угрозы от государственного регулятора FCC пока не возымели своего действия — техотдел компании лишь уверил обеспокоенную общественность, что «проблема изучается». После чего снова ушел в глухую оборону, продолжая преступно наслаждаться своей иезуитской ночной подсветкой.

Логически понять стратегию Passive-Aggressive порой довольно сложно, ведь решение данной проблемы займет буквально 2-3 часа. Сторонняя компания сама провела нужные исследования, выявила техническую проблему и даже готова оплатить ее устранение. Но в таких ситуациях для противостоящей стороны очень важно доказать, что «они не сломлены» и поэтому готовы выдерживать прессинг врага и дальше. Впрочем, в этом затяжном противостоянии скоро точно будет повышен градус драмы, ведь за тормошение за грудки нерадивого владельца зданий решил лично взяться федеральный регулятор коммуникаций и связи FCC (разрешительную лицензию от которого крепко сжимает в своих руках техсуппорт владельца здания).

Но это скучный пример, где, вероятно, так и не появятся «сакральные жертвы» трупы, поэтому давайте рассмотрим эту коварную стратегию сразу в граничных (экстремальных) условиях, ведь именно так и проверяются серьезные теории в науке. Для этого представим себе некий проект доверху набитый PAP-программистами, «которые никому ничем не обязаны» и у которых прошито «единственно верное мнение». У них много времени, много сил, и они принципиально не согласны…

Пример 2. Бей первым, Адриан!

Итак, самое интересное — это лобовое противостояние двух подобных моделей. Порой именно так запускается цикл самоуничтожения всего офиса или проекта. Это наиболее радикальный вариант проявления PAP, это свой собственный офисный вариант небольшой «битвы за Сталинград».

Недавно разработчик Linux Debian публично пригрозил соратнику по проекту замочить его физической расправой. Один из самых горячих разработчиков проекта Маас Верри (Maas Verri) разместил в профильной технической рассылке lists.debian.org жуткий оффтопик — призыв физически расправиться с другим участником сообщества Адрианом (Adrian) и его приспешниками.

В частности, он аргументирует свой скорый «джихад» примерно так:

Таких людей, как Адриан, которые настаивают на том, чтобы systemd стала единственной системой инициализации в Debian, нужно физически наказать. Это диктатура… Они говорят, что хотят «помочь Debian». Видимо, так же, как церковь в средние века «помогала» людским душам, пытая и сжигая людей заживо. Debian существует для людей. Это не религия. И это не скульптура. Они говорят, что хотят «улучшить Debian». Но Debian существует не ради самого себя, а ради всех нас. Адриан и другие сторонники Systemd пытаются отобрать Debian у нас и отдать его своим «пользователям».

И пока одна часть разработчиков-перфекционистов «сгорает заживо» в огне адского демона инициализации systemd, я попробую прояснить запутанную суть самого конфликта. Разработчик Адриан, игнорируя альтернативные мнения, выступил с инициативой лишить пользователей выбора системы инициализации в Linux Debian, оставив возможность пользоваться одной-единственной — Systemd. В конечном счете, после долгих бурлений и угроз с обеих сторон, этот вопрос довели до голосования.

Последняя лоханка однопроцентников-элитистов опрокинулась. «@l_o_r: Дефолтной системой инициализации для GNU Debian стала systemd. #linux

 — Изверг-табакерка (@doloresanto) 10 февраля 2014

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

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

Подождите, это лишь часть истории — дело в том, что под занавес балагана один из лидеров проекта, Ian Jackson, заявил, что проведенное не должным порядком последнее голосование подрывает процесс принятия решений и высказался за осуществление действий по отмене результатов данного голосования. Более того, он поднял вопрос о смещении Bdale Garbee с поста председателя Технического комитета проекта, «действующего вопреки принятым правилам», призвав провести еще одно голосование и за это тоже («чтоб два раза не вставать»).

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

С решения основного вопроса основные силы самообороны проекта теперь перегруппированы против Garbee, ретиво продвигавшего Systemd, и теперь его попытаются демократически «уйти». По ходу, судя по всему, они развалят в труху Технический комитет проекта Debian. И хотя высадку таинственных снайперов я не обещаю, но призывы «kill’em all», как видите, уже публично прозвучали.

Reading some mailinglist posts of trolls regarding systemd in Debian — soooo much facepalming #hatersgonnahate

 — Markus Frosch (@lazyfrosch) 3 Март 2014

Симптоматично, что часть оппозиционных к ненавистной Systemd программистов в знак протеста решила спешно покинуть проект Debian. В частности, некоторые бежавшие от ужасов новой системы инициализации примкнули к лагерю Ubuntu.

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

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

А все из-за чего?

Никакая демократия не поможет сообществу Debian, если при этом PAP’ы сами не будут придерживаться своих же демократических принципов. Часть сообщества уперлась в нежелании считаться с любой другой альтернативой «кочкой зрения», застряв в хронической неспособности договариваться и находить компромиссы, как-то уважать и учитывать чужое мнение. Попытка подавлять все иные мнения, в том числе силой — это не демократия.

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

Что же делать с тактикой Passive-Aggressive?

Как вести себя правильно, если ваш коллега или работодатель не решает вопрос, используя встречные аргументы или отмашки, а провоцирует вас и разжигает конфликт «на межофисной почве» вместо реальной помощи? Психологи считают, что негативная модель поведения Passive-Aggressive постепенно завоевывает офисные пространства, и бороться с этим нужно начинать еще со школы, объясняя подросткам, что такое конструктивное, уважительное и продуктивное поведение. Для этого на ныне ненавистном многими Западе издается специальная разъяснительная литература, как для детей…

… так и для взрослых:

Безусловно, эффективное противодействие PAP — это тема отдельного разговора.

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.