Идеальная IT-компания. Как из гиков собрать команду программистов - стр. 19

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

С другой стороны, вам также необходимо учиться принимать критику. Это подразумевает не только скромность по отношению к собственным навыкам, но и доверие к тому, что другой человек искренне неравнодушен к вашим ключевым интересам (и интересам вашего проекта!) и не считает вас идиотом. Программирование – такой же навык, как и любой другой. Он совершенствуется с практикой. Если коллега указал вам на то, как можно усовершенствовать ваши приемы, то воспримете ли вы это как нападки на ваш характер и попытку унизить ваше достоинство? Надеемся, что нет. Аналогичным образом, ваша самооценка не должна быть связана с кодом, который вы пишете. Вы и ваш код – не одно и то же. Повторяйте это снова и снова. Вы и ваш код – не одно и то же. Вы должны не только сами поверить в это, но и заставить поверить в это ваших коллег по работе.

Не отождествляйте самооценку с качеством вашего кода

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

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