Баги, баги, баги... Как же их много... Немудрено и фобию заиметь. И ведь никогда не знаешь, чем обернётся очередная ошибка в коде. Страх перед неизвестным, желание держать всё под контролем — закономерные спутники магического мышления. Но подождите, какие ещё магические ритуалы в 21 веке? Тем более у программистов...

"Всуе" мы не верим

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

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

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

Но к народной мудрости прислушиваемся

Казалось бы, искать реальные "программистские" суеверия — идея изначально провальная. Однако некоторые программисты всё-таки делятся своими приметами и практическими ритуалами (пусть и в шутку). Так может стоит взглянуть на это с другого ракурса и рассмотреть профессиональное мифотворчество как таковое? На этой почве возникла идея отправиться в небольшую "этнографическую экспедицию" по отделам разработки офиса PVS-Studio аналогично тому, как фольклористы исследуют полузаброшенные деревни, по крупицам собирая народные предания.

Со сбором универсальных мудростей помог архимаг архитектор C++ анализатора PVS-Studio:

• Ежели код с первого раза скомпилировался — жди лиха.

• Коли тесты с первого раза прошли — не видать добра.

• Было код ревью с тимлидом — жди скорого прогона тестов.

• Тесты падать не будут, коли писать их не станешь.

• Пред самым релизом всё враз обрушится.

• Таска на пять минут на месяц растянется.

• Что не ломко, то сломится.

• Начал дело какое — обязательно кто отвлечёт.

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

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

Мы не знаем, что это такое

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

• Путеводитель C++ программиста по неопределённому поведению: часть 1 из 11

• Путеводитель C++ программиста по неопределённому поведению: часть 2 из 11

• Сколько UB в моём компиляторе?

• FreeCAD и C++ код с неопределённым поведением для медитации

• Пример проявления неопределённого поведения из-за отсутствия return

• Undefined behavior ближе, чем вы думаете

Другое явление, также предполагающее появление у машины якобы собственной воли по неизвестной причине, – ghosts in the machine. Этот изначально философский концепт приобрёл современное значение с развитием компьютеров и искусственного интеллекта. Термин метафорически используется в контексте технологий для описания необъяснимых сбоев, неполадок или аномалий в системе. Эти явления кажутся лишёнными рационального объяснения, словно внутри технологии действует какая-то таинственная сила, вызывающая такое неожиданное поведение. Вызывайте охотников за привидениями!

Камлай, шамань

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

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

В углу притаился неприметный серый ящик. Мне пояснили, что это "ящик с говнокодом", и, по аналогии с ящиком Пандоры, запретили его открывать, особенно в предрелизную неделю.

Lucky charm

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

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

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

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

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

Так может дело в том, что магические ритуалы у программистов — это в большей степени весьма рациональные практики, применимые в работе? Да нет, бред какой-то.

Три ctrl-c, чтоб править всеми

Программист из отдела разработки C# анализатора поделился ритуалом, передаваемым из поколения в поколение, от тимлида к разработчикам. Никто не знает, когда именно зародилась эта практика и кто первым пал её жертвой. Ясно одно: в наше время каждый C# разработчик в компании подчиняется этому обычаю. Зажимая ctrl, они с непоколебимой настойчивостью нажимают C ровно трижды.

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

Понедельник — день бездельник, пятница — ... вы знаете

Внесём толику здравого смысла. Отдел веб-разработки рассказал о своём нерушимом правиле: не деплоить в продакшн в пятницу тринадцатого. Суеверие? Едва ли.

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

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

Сисадмины определённо с этим согласны:

Read-only Fridays are not superstition, they are a Religious Observance.

"17 On the 5th day, The Great Administrator monitored all the changes They had made and knew that they were good. 18 They looked down upon them and documented all Their blessed works, and each was given over to Automation as they had need. 19 The songs of blessed scripting and tasks-schedulers rang from the firmaments, and all was as it should be. 20 For upon that 5th day, no Changes did They make."

-from The Book of Automations, Chapter 1, verses 17-20

Также встречалось мнение, что при налаженных CI/CD пайплайнах, процессах тестирования и баг-трекерах ничего страшного в деплое в пятницу нет, ведь все баги обязательно отловят до продакшена. Можно, конечно, попробовать отловить некоторые ошибки с помощью статического анализа кода. А можно просто не искушать судьбу пятничным деплоем :)

Ритуалы и суеверия разработчиков, обсуждаемые в сети

Как ни удивительно, в суеверия, связанные с несчастливыми числами, верят даже разработчики. На dev.to пользователь поделился, что побаивается 13-й строчки кода:

Put a line break or a comment at the 13th line of the code

Забавно, что "несчастливые числа в коде" всё-таки есть, и это точно не 13.

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

I have a collection of weird things I find in the office, random desk toys, swag from vendors and other companies. I call it the gremlin shrine. You can appease the gremlins with offerings to the gremlin shrine.

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

На всякий случай:

Compile project, then compile again just to be sure.

Не отворачивайся от компилятора:

If you walk away from a compile, it will break.

The longer the compile, the higher the probability.

Note: Browsing reddit doesn't count. :)

На всякий случай х2:

I knew a programmer who, if compilation error happened, immediately reran compilation to make sure this is not some random error in compiler. Only after this he looked for reasons in his code.

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

Place your mouse cursor at the edge of a progress bar, just so it knows you're watching it, making sure it doesn't go backwards.

А кто-то убеждён в совершенно обратном:

A watched process always fails. Just... look away.

Многие разделяют суеверия медиков и предпочитают не говорить: "Что-то тихо у нас сегодня".

The Q word

About 2 weeks into my first ever IT job (also my current job but a level higher now) we were sitting in the office with an empty queue and silent phones. Being the naieve technician's assistant that I was, I said "huh, sure is quiet today"

What followed later that evening was a full scale POS outage for our restaurants on the busiest night of the week.

Learned my lesson there, that's for sure

И вообще, стоит быть аккуратнее в выражениях:

NEVER trust someone who is confident in their fix

The more confident someone in what they fixed worked, the more likely it is to blow up in their face

Has roots in the not speaking in certainties (i.e. "This will fix the issue" vs. "This should fix it")

And don't say it will be a quick fix because that will be the ticket that will haunt you way past SLA

Ещё один довольно распространённый "ритуал":

Click "Apply" before "OK." :P

Сразу несколько суеверий касаются определённой офисной еды. Оказывается, не стоит бездумно заказывать пиццу просто абы откуда:

My company's network services people will outright revolt if pizza from a certain pizza place is brought in for a lunch meeting, because ordering from that pizza place WILL cause a massive network outage.

Да и пончики тоже:

We are not allowed bagels in our office. Every time people bring in bagels, the network goes down. Apparently our equipment is bagelphobia

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

I don't know why, but programming at night is better than all day!

И вот вам ещё капелька сисадминских премудростей:

When you approach a desktop to fix it as an IT person, you have to let the machine know you're not there to hurt it by gently stroking the side of the monitor to comfort it. It's suprisingly effective at fixing problems.

Заключение

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

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

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