Автор: Хромой Рысь

Программисты и тревожность

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


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

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

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

По мотивам "Психологическая деформация программистов. Взгляд с обеих сторон баррикад"

Гиперконцентрация

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

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

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

Мне нравится еще один пример этого "чувства правильности", который к сожалению мне еще не довелось проверить на других людях. Есть такой роман "Сфера" (The Circle) Дейва Эггерса и одноименная экранизация. Вначале я посмотрел фильм и он вызвал очень странные чувства. А потом уже прочитал книгу и все встало на свои места. Я чувствовал расхождения с оригинальной моделью, привнесенные сценаристами, даже не видя исходную задумку. Неудивительно, что фильм по сути провалился. А вот книга замечательная, хоть и реально пугающая.

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

Причинно-следственные связи

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

Вторая статья "Что такое «синдром айтишника»? Психолог о проблемах IT-специалистов" приглянулась неожиданно точными описаниями, хоть и изрядно разбавленными, как мне кажется все же больше надуманными шаблонами и стереотипами. С критикой я в завязке, так что переходим сразу к понравившемуся.

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


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

Неумение хитрить и изворачиваться. Профессия требует быть честным и реалистичным — «код работает или нет»! Другие варианты отсутствуют. Это качество распространяется не только на работу, но и на все взаимоотношения, на другие сферы деятельности.


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

Чрезмерное волнение за результат, что может спровоцировать синдром повышенной тревожности.


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

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


Фактически та же проблема недетерминированности. Действия с неопределенным результатом. Новая работа, а будет ли она лучше? Если в целом нет доверия к миру людей, как можно верить, что будет место, где вдруг все будут нормальными?


Не хотел включать этот пункт, но жизнь ткнула в него мордой: привыкание к формализованной постановке задач. Не задумывался откуда это взялось у меня, но эта простая казалось бы идея чуть ли не основополагающая и от этого кажется такой простой и базовой, что даже не хочется её вспоминать или как-то выделять. Для меня четкость постановки задачи это нечто само собой разумеющееся, как связанная речь или здравый смысл. К сожалению, так думают далеко не все. немного нытья на тему буднейНа той неделе подходит ко мне начальник, сует бумажку, скидывает файл и говорит: посмотри там в файлике, нас все в нем устраивает? Смотрю и радуюсь, что пью таблеточки. Неадекватную структуру почти 80 страничного документа еще как-то можно понять - большие начальники ничего не видят кроме этой привычной им структуры и суют ее куда ни попадя. Тоже в каком-то смысле профдеформация. Содержание же просто убивает. Чуть ли не каждый пункт - смешанные чувства. Глупость такая, что думаешь, что это все шутка, местами даже смешная. А потом вспоминаешь, что это все всерьез и исходит от людей с которыми работаешь и становится страшно. Иду уточнять у начальника, что все же конкретно от меня требуется, потому что файл меня мягко говоря шокировал и комментарии к нему сплошь нецензурные. В ответ получаю: ну посмотри может замечания какие-нибудь. Уточняю, что замечаний там чуть ли не к каждой букве, но если кратко, то за день постараюсь успеть. "Да не срочно, несколько замечаний хватит". Отдельный вопрос, зачем я в это опять полез, но молчать тоже тяжело. Последние 7 лет, чуть ли не каждые 1.5 года у нас пишут такой документ. Я каждый раз трачу уйму времени на объяснения зачем, почему и как надо делать, а как не делать, потому что ну не работает так ни у кого в мире, это глупость, например мерить сложность программы в количестве операторов. Это все равно что писателю платить посимвольно или построчно. Но воз и ныне там, и снова "посмотри". В итоге убиваю три дня на перекрестный анализ 4 документов и 9 листов заключения по ним. Иду сдавать, но начальник уже убегает, а так как его на следующий день не будет, - отдать заму, который будет собирать итоговый документ. Наступает новый день, связываю с замом и с удивлением обнаруживаю, что ему начальник сказал зеркально противоположное, что это я буду собирать итоговый документ. Ладно, подождем еще денек, выйдет начальник - рассудит. А нет! Сюрприз! Начальник ушел в отпуск на неизвестный срок. И вот как с такими людьми можно работать без жесткой формализации и документирования указаний? Вишенкой на торте то, что меня этот документ вообще никак не касается. Нормы определяемые в нем я использовал последний раз больше 5 лет назад и не по основной деятельности, а по доброте душевной и за интерес, с которого мне перепал только горький опыт - больше не связываться с такими людьми и работами.

Работа программиста и шамана имеет много общего - оба бормочут непонятные слова, совершают непонятные действия и не могут объяснить как это работает.


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

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

Не верьте ничему, независимо от того, где вы это прочитали, или кто это сказал, даже если это сказал я, если это не согласуется с вашим собственным рассудком и вашим собственным здравым смыслом.
Сиддхартха Гаутама (Будда)


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

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

К этим же "а что если" относятся и "заблуждения" программиста. Ошибки неопытности или не заданного вовремя вопроса. Большая часть проверок в программе производится оператором "если" (if) и чаще всего он устроен так, что работает с булевой логикой. Иначе говоря проверяет утверждение на истину или ложь и в зависимости от результата переходит к тому или иному блоку кода. Есть программа, которая красит экран в заданный пользователем цвет и есть такая проверка в ней: "то что ввел пользователь является 'красным'?" Если "ответ" истина - закрашиваем экран красным, если ложь - синим. Так? А вот и нет. Строго говоря "не красный" не значит синий. На примере с цветами это очевидно и глупо, а на реальных данных бывает совсем не очевидно и вызывает ошибки. Мы отчего-то тяготеем к бинарной логике. Если не друг - значит враг. Но цифр больше, чем 1 и 0. Не единица, не значит ноль. Все конечно зависит от постановки задачи, здравый смысл должен определять тип и количество проверок, но все же хочется выпендриться и заявить, что цифр то не 10. Десятка только арабских, привычных нам цифр. А есть же еще римские, или шестнадцатиричные и вот беда, D в этих двух системах значит совершенно разные количества. И за этим тоже надо следить, помнить, учитывать. А что если у числа будет десятичный разделитель точка, а не запятая? Но что-то я увлекся и не в ту степь забрел. Я хотел сказать о другом. Вот то самое "не значит" о котором я говорил выше, может быть и неплохим помошником. Мне сложно это объяснить. Это что-то вроде логической проверки через отрицание. Все васильки синие. А если цветок не синий, может ли он быть васильком?

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

Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство.
Джеральд Вейнберг "The Psychology of Computer Programming"


Финальным штрихом мне хочется высказать еще одну мысль. Мне нравится играться с моделями. В каком-то смысле в этом вся моя жизнь. Странные чувства, которые невозможно описать словами. Мне действительно порой доставляет удовольствие разрушить чужую концепцию. В идеале парой метких вопросов, все тех же "а что если". Наслаждаться скрипом мозгов при переосмыслении. В этом есть небольшой налет вредности и быть может садизма, но эмоции возникающего у собеседника когнитивного диссонанса просто изумительны. И в то же время, привычка видеть недостатки порой очень тяготит. Куда ни посмотри - что-нибудь да не так, а порой все не так, что случайно попавшийся кусочек "нормального" кажется чудом. Бессилие что-либо исправить сродни проклятью. И хуже всего, пожалуй то, что среди встречавшихся мне моделей, да и десятков своих, я так и не нашел ответа на простой вопрос: как сделать утопию, которую не сможет погубить всего один современный человек?
1

Комментарии


Лучшее   Правила сайта   Вход   Регистрация   Восстановление пароля

Материалы сайта предназначены для лиц старше 16 лет (16+)