Гнев на код: программисты и негатив

Я смотрю на кусок кода. Возможно, это худший код, что мне когда-либо встречался. Чтобы обновить всего одну запись в базе данных, он извлекает все записи в коллекции, а затем отправляет запрос на обновление каждой записи в базе, даже те, которые обновлять не требуется. Тут есть map-функция, которая просто возвращает переданное ей значение. Есть условные проверки переменных с очевидно одинаковым значением, просто поименованных в разных стилях (firstName и first_name). Для каждого UPDATE’а код отправляет сообщение в другую очередь, которая обрабатывается другой serverless-функцией, но которая выполняет всю работу для другой коллекции в той же базе данных. Я не упомянул, что эта serverless-функция из облачной «сервис-ориентированной архитектуры», содержащей более 100 функций в окружении?

Как вообще можно было такое сделать? Я закрываю лицо и явственно всхлипываю сквозь смех. Мои коллеги спрашивают, что случилось, и я в красках пересказываю Worst Hits Of BulkDataImporter.js 2018. Все сочувственно кивают мне и соглашаются: как они могли так с нами поступить?

Негатив: эмоциональный инструмент в программисткой культуре

Негатив играет в программировании важную роль. Он встроен в нашу культуру и используется для того, чтобы поделиться узнанным («ты не поверишь, на что был похож этот код!»), для выражения сочувствия через расстройство («господи, ЗАЧЕМ так делать?»), чтобы показать себя в выгодном свете («я бы никогда так не сделал»), чтобы взвалить вину на другого («мы зафейлились из-за его кода, который невозможно сопровождать»), или, как принято в самых «токсичных» организациях, чтобы управлять другими через чувство стыда («ты о чём вообще думал? исправляй»).

Негатив столь важен для программистов потому, что это очень эффективный способ передачи ценности. Когда-то я учился в лагере для программистов, и стандартной практикой прививки студентам цеховой культуры было щедрое снабжение мемами, историями и видео, самые популярные из которых эксплуатировали огорчение программистов, когда они сталкивались с непониманием людей. Хорошо, когда можно использовать эмоциональные инструменты для обозначения методик Хороших, Плохих, Ужасных, Никогда Так Не Делайте, Вообще Никогда. Нужно подготовить новичков к тому, что их наверняка будут понимать ошибочно коллеги, далёкие от IT. Что их друзья начнут втюхивать им идеи приложений «на миллион». Что им придётся блуждать в бесконечных лабиринтах устаревшего кода с кучей минотавров за углом.

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

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

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

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

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

Кстати, именно эта «эмоциональная разрядка» заставляет разработчиков называть код «секси», что редко бывает справедливым — если только вы не работаете в PornHub.

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

Неспокойная скользкая дорожка негатива

Несколько лет назад я был неформальным тимлидом и собеседовал одного разработчика. Он нам очень нравился: был умён, задавал хорошие вопросы, был технически подкован и прекрасно вписывался в нашу культуру. Мне особенно импонировала его позитивность и то, каким предприимчивым он казался. И я его нанял.

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

Так что не было ничего удивительного в том — хотя я удивился, — что несколько недель спустя тот самый новый разработчик высказался в том же негативном ключе, что и я (включая ругательство). Я понял, что он повёл бы себя иначе в другой компании с другой культурой. Он лишь подстроился под ту культуру, которую создал я. Меня накрыло чувство вины. Из-за своего субъективного опыта я привил пессимизм новичку, которого я воспринимал совсем другим. Даже если он на самом деле не был таким и лишь старался казаться, чтобы показать, что может влиться в коллектив, я навязал ему своё дерьмовое отношение. А всё сказанное, пусть даже в шутку или мимоходом, имеет дурную манеру превращаться то, во что верят.

Пути негатива

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

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

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

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

Вероятно, реальность находится где-то посередине между этими двумя крайностями.

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

Негатив — это инженерная поп-культура

Сегодня отношению инженеров уделяется столько внимания, как никогда. В инженерных организациях всё популярнее становится правило «Никаких овнюков«. В Твиттере появляется всё больше анекдотов и историй про людей, которые покинули эту профессию потому, что не смогли (не захотели) и дальше мириться с враждебностью и недоброжелательностью по отношению к посторонним. Даже Линус Торвальдс недавно извинился за годы своей враждебности и критики в адрес других Linux-разработчиков — это привело к дискуссии об эффективности такого подхода.

Кто-то до сих пор отстаивает право Линуса быть очень критичным — те, кто должен многое знать о преимуществах и недостатках «токсичного негатива». Да, корректность крайне важна (даже фундаментальна), но если резюмировать причины, по которым многие из нас позволяют выражению негативного мнения превратиться в «токсичность», то эти причины выглядят патерналистскими или подростковыми: «они заслуживают это, потому что идиоты», «он должен быть уверен, что они этого не повторят», «если бы они так не поступили, ему не пришлось бы на них орать», и так далее. Примером того, какое влияние эмоциональные реакции лидера оказывают на сообщество программистов, является аббревиатура MINASWAN в сообществе Ruby — «Matz is nice so we are nice» (Мац [создатель языка] хороший, значит и мы хорошие).

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

Мир программирования быстро растёт и упирается в границы своего контейнера — мира непрограммирования (или это мир программирования является контейнером для мира непрограммирования? хороший вопрос).

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

Что я узнал о негативе

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

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

Наконец, негатив буквально вредит вашему здоровью.

Мне кажется, так должен выглядеть мастер-класс по улыбкам.

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

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

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

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

Я получил новую возможность, когда занял должность руководителя по оценке персонала. Будучи бывшим главным инженером, я очень внимательно слежу за выражением своего мнения о нашем (постоянно улучшающемся) легаси-коде. Чтобы одобрить изменение, нужно представлять текущую ситуацию, но вы ни к чему не придёте, если погрязнете в стенаниях, нападках или чём-то подобном. В конечном счёте, я здесь для того, чтобы выполнить задачу, и не должен жаловаться на код, чтобы понять его, оценить или исправить.

Фактически, чем больше я сдерживаю свою эмоциональную реакцию на код, тем лучше понимаю, каким он мог бы стать, и тем меньше смятения испытываю. Когда я выражался сдержанно («здесь должны быть возможности для дальнейших улучшений»), то тем самым радовал себя и других и не принимал ситуацию слишком близко к сердцу. Я осознал, что могу стимулировать и понижать негатив в других, будучи идеально (раздражающе?) благоразумным («вы правы, этот код довольно плохой, но мы его улучшим»). Я рад тому, насколько далеко могу пройти по пути дзена.

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

Источник: habr.com