Привет, Хабр!

Меня зовут @momentics. Я строю HW/SW команды, процессы производства, делаю реинвент технологий, починяю старые и создаю новые HW/SW продукты.

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

Чего нельзя узнать по одной неуверенности

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

В работе Крюгера и Даннинга участники выполняли задания на юмор, грамматику и логику, а затем оценивали, насколько хорошо справились. Те, кто получил низкие результаты, заметно их переоценивали. Авторы предположили, что человеку может не хватать одних и тех же навыков и для правильного решения, и для понимания того, где он ошибся. Когда часть участников обучили, они смогли точнее оценить свои прежние результаты.

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

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

Сначала посмотрим на ситуации, в которых чувство собственной неэффективности связано с тем, как изменилась работа. Затем вернёмся к ошибкам, самооценке и реакции коллег.

Как после повышения меняется оценка своей работы

Собственных задач стало меньше

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

Но дело может быть не только во времени. Помогать другому человеку бывает труднее, чем написать код самому. Нужно понять, где он запутался, объяснить решение и проверить, одинаково ли вы поняли требования. Разработчик мог почти не заниматься этим до повышения. Поэтому я не стал бы считать первые затруднения доказательством неудачного назначения. Ему поручили работу, которой ещё предстоит научиться.

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

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

Прежних навыков может не хватить

Здесь уместно вспомнить принцип Питера. Согласно этой идее, успешного сотрудника продолжают повышать, пока он не займёт должность, с которой уже не справляется. Benson, Li и Shue изучили повышения работников продаж в 214 компаниях. Хорошие продавцы чаще становились руководителями, хотя другие характеристики лучше предсказывали успех в управленческой работе. Результаты показывают, почему при повышении недостаточно смотреть только на прежние достижения.

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

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

Быстрое решение кажется слишком простым

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

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

Почему трудно объяснить очевидное для себя

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

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

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

Почему ошибка заслоняет остальные результаты

Успехи списываются на обстоятельства

Я вижу проблему не в том, что разработчик сомневается в своих знаниях. Проверять себя полезно. Труднее, когда он по-разному оценивает удачи и ошибки. Если задача решена, значит, помогли коллеги или повезло. Если решение оказалось неверным, значит, не хватает способностей. При таком подходе человек не может убедиться, что чему-то научился. Любой хороший результат он объясняет обстоятельствами, а плохой принимает на свой счёт.

В исследованиях феномена самозванца описывают в том числе такую трудность с признанием своих достижений. В обзоре Bravata собраны 62 исследования с участием 14 161 человека. Доля участников с выраженными переживаниями самозванца в разных работах составляла от 9 до 82 процентов. Такой разброс не стоит понимать как разногласие о том, существуют ли эти переживания. Авторы работ использовали разные опросники и по-разному определяли, при каком результате считать их выраженными. Они измеряли не совсем одно и то же.

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

Прошлая авария вспоминается первой

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

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

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

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

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

Когда сомнения поддерживает окружение

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

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

После вопроса становится страшнее спрашивать

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

Совсем другой ответ звучит как «с твоим стажем стыдно этого не знать». После него разработчик всё ещё не понимает, как проверить совместимость, но уже знает, что за такой вопрос его могут унизить. В следующий раз он может промолчать и продолжить работу без проверки. Я считаю, что команде это вредит независимо от того, действительно ли у сотрудника есть пробел в знаниях. Если пробел есть, его нужно устранить, а для этого о нём сначала должны узнать.

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

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

Если начальник отвечает «это даже школьник знает»

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

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

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

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

Если команду заранее настроили против новичка

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

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

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

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

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

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

Что проверить на конкретной задаче

Если вы считаете, что не соответствуете своей должности, я предлагаю начать с задачи, которая заставила вас так подумать. Что именно не получилось? Вы не смогли найти решение, пропустили требование или получили замечание на ревью? Я считаю, что прежде всего нужно ответить на эти вопросы. Тогда станет понятнее, есть ли в работе ошибка, которую нужно исправить, и каких знаний для этого не хватает. Само ощущение «я плохой специалист» эту задачу не решает. При этом я не предлагаю таким способом избавляться от тревоги. Здесь мы пытаемся проверить, насколько обоснованы претензии к выполненной работе. Если ошибка есть, её можно разобрать. Если работа сделана правильно, это тоже важно установить. Но человек может продолжать переживать и после такой проверки. Я бы не считал это поводом снова искать недостатки в уже проверенном решении.

Если поведение руководителя само стало причиной страха, его мнение не стоит использовать как единственную проверку своих знаний. Спорное техническое решение можно обсудить с коллегой, который знает предмет и готов объяснить замечания. Это не даст оценки всей вашей карьеры, но поможет проверить конкретную претензию.

Допустим, на ревью коллега заметил, что после изменения сервер перестанет принимать запросы старого клиента. Автор исправляет код, но считает, что сеньор должен был предусмотреть это сам. Я бы сначала уточнил, обязана ли система поддерживать этот клиент и откуда разработчик должен был об этом узнать. От этого зависит, какую ошибку мы вообще разбираем.

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

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

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

Что полезно оставлять в done.md

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

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

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

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

Как понять замечания руководителя

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

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

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

Когда рабочего разбора недостаточно

Приведённые выше рабочие приёмы я предлагаю для разбора задач, а не как проверенное лечение тревоги.

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

Чего я жду от опытного разработчика

Если перед выпуском сеньор скажет: «На новой версии всё работает, а старые клиенты я не проверял», я не стану считать это признаком слабости. Теперь у команды есть возможность проверить совместимость до релиза. Меня бы больше насторожило уверенное «всё работает», если за ним стоит тот же неполный тест.

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

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

А вам удавалось понять, почему вы считаете себя недостаточно хорошим специалистом?

Что помогло: мнение коллеги, разговор с руководителем, обучение или смена команды?

Интересно, после чего изменилась сама работа, а после чего стало легче к ней относиться?