Жизнь с генерализованным тревожным расстройством как разработчик

Я чувствовал тревогу в каждой клеточке своего тела - узелки в животе, внезапную дрожь в руках, тупость в веках и, что хуже всего, постоянные сверхкритические звуки в черепе.

Наивный шестнадцатилетний парень среди группы опытных разработчиков чувствовал себя вечным чужеземцем. Боясь, что меня «поймают», я отчаянно использовал жаргон вроде DOM, CI / CD и CLI, ничего о них не зная. Я думал, что либо получу этот концерт и отправлю его безупречно, либо провалится. Сегодня, когда я оглядываюсь на себя, я был катастрофой. Мой код был настолько ужасен, что я даже не могу его посмотреть. Но «неудачником» я не стал, по крайней мере, пока! Но по пути я многому научился.

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

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

Экспозиция и ответная терапия

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

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

1. Перечислите свои заботы.

Составьте список своих мыслей «а что, если». Чего ты боишься? Почему? Например, вы можете сказать: «Я боюсь отклонить нереалистичный крайний срок моего начальника. Что, если он уволит меня за отказ? »

2. Оцените, насколько вы обеспокоены каждым из них.

Теперь дайте своим страхам оценку от 1 до 10 в зависимости от того, насколько они провоцируют тревогу.

3. Определите свое поведение, связанное с безопасностью.

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

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

4. Проведите эксперимент, чтобы встретиться с ними лицом к лицу.

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

5. Запишите результат.

а. Что случилось? Произошла ли катастрофа? Ваш код сломан? Кто-нибудь высмеивал вас из-за того, что вы не знаете, как работает Docker?

б. Если катастрофа случилась, как вы с ней справились? Если вы написали неработающий код, как вы и ваши коллеги отреагировали на это? Что случилось после того, как пользователи Stackoverflow назвали ваш вопрос глупым? Если бы вы потратили больше времени на беспокойство, смогли бы вы предотвратить инцидент?

Меры безопасности разработчика

С тех пор, как я прошел курс ERP, я стал лучше осознавать вызывающую беспокойство динамику ИТ-профессий и порождаемое ими деструктивное поведение в области безопасности. В оставшейся части статьи я расскажу о некоторых правилах безопасности, которые я считаю наиболее распространенными и токсичными в отрасли.

Нечестность

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

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

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

В следующий раз, когда вас спросят, работали ли вы с новой технологией, о которой не слышали, ответьте «нет» и проявите любопытство. Затем запишите результат разговора. Вы, наверное, увидите, что мир не так опасен, как вы думаете!

Прокрастинация

Хотя многие считают прокрастинацию пассивным действием, я видел еще много примеров активной прокрастинации среди разработчиков. Хотя вы должны выполнять задачу, которая вас пугает, обычно из-за того, что она неоднозначна или нова, вы просто начинаете выполнять другую задачу, более простую, но менее срочную, чтобы чувствовать себя продуктивно и избежать столкновения со своими заботами (см .: https: // shouldideploy.today/ ). Это может показаться продуктивной стратегией, но постоянное избегание новых ситуаций принесет плохие новости.

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

Чрезмерная двойная проверка

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

Понимание трех моментов может помочь вам преодолеть парализующее беспокойство по поводу качества вашего кода:

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

Избегание

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

Многие опытные разработчики, верные предыдущим технологиям или опасающиеся снова почувствовать себя новичком, избегают изучения и использования новых технологий. Точно так же младшие разработчики, которым угрожает огромное море информации, не используют свои знания в новых проектах, ожидая, пока они «узнают достаточно». Однако отказ от новизны - верный способ опередить отрасль. Хотя овладевать всеми причудами не нужно и не полезно, прятаться в безопасной зоне вредит вашему психическому здоровью и продуктивности. Лично я считаю, что прятаться от таких концепций и инструментов, как ORM, бессерверная архитектура и PWA, опасаясь, что я могу почувствовать себя глупым, пытаясь их изучить, было одной из самых больших ошибок, которые я сделал в своей карьере.

Вывод

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