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

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

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

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

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

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

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

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

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

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

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