На реддите выложили и запихали вверх по рейтингу статью "О вреде (от) сослуживцев":

http://internetducttape.com/2007/10/15/coworkers-considered-harmful

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

Итак, некто Энгтек (engtech) запостил следующий список мероприятий, осуществляемых коллегами-вредителями (перевод на русский - мой):

*** Заливание на сервер абсолютно неработоспособных исходников;

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

*** Заливание исходников, которые порождают трудноисправимые баги в смежных модулях;

Открою секрет: так можно охарактеризовать 90 процентов всех вообще заливок исходников, и автор статьи не является исключением. Еще можно пожаловаться, что вода - мокрая.

*** Отвлекают меня, когда я "в потоке творчества";

Если результаты этого потока творчества хоть кому-то важны, коллеги поразительно адекватно реагируют на классическое "я занят, позвоните попозже". Вообще, частое появление коллег у рабочего стола - это нонсенс; у них чего, email, bugzilla и irc сдохли напрочь?

*** Играют в отпускную рулетку: планируют отпуск за границей сразу после релиза;

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

*** Убеждают начальника дать тебе "более приоритетное" задание по исправлению чужих багов, хотя "твои" фичи на самом деле куда важнее;

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

*** Сообщают мне, что мой код не работает, хотя на самом деле они неправильно его используют;

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

*** Убеждают меня (чужими руками) в собственной интерпретации спеки, мотивируя своим бОльшим опытом и убежденностью в своей позиции;

Какие-то странные споры у автора на фирме. Спор должен вестись аргументами, относящимися к делу, а не мерянием различными частями тела вроде опыта и "убежденности". При первом же аргументе не по делу участие в обсуждении следует прекратить с помощью начальника или служебного ноутбука. (Сегодня у меня не было ноутбука - его отлично заменила распечатанная перед совещанием на принтере 20-страничная статья об особенностях применения генериков в джаве).

*** Выдают мне инструкции, которые не работают, когда я им следую;

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

*** Пишут комментарии, которые в корне неверно описывают работу кода;

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

*** Я думал, что когда начальник мне что-то говорит напрямую, это задание обязательно входит в 20 процентов самых важных...;

Бред. Как еще, кроме как _напрямую_ начальник может что-то говорить? Через секретаря, что ли? Так это см. выше - про неудачный выбор начальника. Но вообще-то в программистских конторах секретаря у начальника нет, он дает задания исключительно напрямую, и выделить 20 процентов заданий только по признаку "прямости" никак нельзя.

Далее автор углубляется в поскипанную мною философию и приводит перечень контрмер, которые конечно, помогут делу. Итак, автор решил, что отныне он будет ...

*** Всегда держать начальника в курсе того, чем занимается;

Это вредная иллюзия - что начальнику интересно, чем занимается работник. Начальнику интересны два факта:

ф1. Оплата проекта заказчиком
ф2. Получение премии

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

*** Надевать наушники, выключать телефон и емэйл на время "работы в потоке";

Главное - не забыть отключить и пожарную сигнализацию. Емэйлы в цивилизованных местах самосортируются (из 50 ежедневных писем срочному прочтению подлежит одно в неделю, если не в месяц), а если звонит телефон (раз в квартал) - честное слово, лучше взять трубку, пока не поздно. Когда на моем столе звонит телефон, обычно это означает, что случилось НЕЧТО, и результат написания мною кода уже никому совершенно неинтересен. Если звонят по каждому пустяку, всегда можно переадресовать звонки начальнику. Если звонят заказчики или горячая линия, можно организовать посменное дежурство как в "СКБ Контур", но игнорировать телефон так же глупо, как и пожарную сигнализацию, ибо функция у них одна и та же: информировать программиста об экстренном изменении текущих приоритетов.

*** Никогда, ни за что не чекаутить чужой код, находясь в процессе отладки своего кода;

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

*** Брать с сервера только стабильную версию исходников;

Интересно, как автор без билдбота собрался отличать стабильную версию от нестабильной? А если у него есть билдбот - как вообще может произойти чекаут нестабильной версии? Где-то нас дурят.

*** Всегда читать код, использовать комментарии только как аннотации;

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

*** Всегда писать тесты на чужие интерфейсы, чтобы легко ловить неправильность использования моего кода;

Совет из серии "в огороде бузина". Тесты нужно писать ВСЕГДА, и всегда - на СВОЙ код. На чужой код тесты должны писать его авторы. Я, конечно, только за, если кто-то будет писать тесты на мой код через интерфейсы - но трудно, чертовски трудно найти таких добровольных рабов в цивилизованной фирме.

*** Всегда писать регрессионные тесты на свой код, чтобы быть уверенным, что проблема не в нем, и что заливка моего кода не принесет побочных эффектов;

Я поражен, что автор до сих пор этого не делал. Что вообще, кроме тестов, позволяет ему надеяться, что его код работает? А про побочные эффекты он себе льстит - их смогут выявить только тесты других сотрудников, если они их пишут.

*** Считать багу несуществующей, пока мне не продемонстрировали, что она воспроизводится вместе с сообщением об ошибке

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

*** Не соглашаться, что моя интерпретация спеки не верна, пока я не вдумаюсь в обсуждаемый вопрос основательно;

Усугубляет мои подозрения о бессмысленных спорах на фирме автора. Я страшно рад, когда находится человек, который готов объяснить мне спеку, чтобы мне не тратить время на самовникание. Компания, кстати, нанимает специальных людей, которые умеют доходчиво объяснить спеку, и у которых опыт работы в авиаотрасли больше 20 лет. Такие люди на вес золота, и когда у них находится для меня время, я просто от счастья прыгаю, а не пытаюсь изобретать "собственные интерпретации спеки". Как минимум, такой подход позволяет мне не выглядеть идиотом на встречах с заказчиками, а это уже немало.

*** Вникать во все, что делаю, никогда не следовать чужим инструкциям, не поняв досконально их смысл;

Закончим на мажорной ноте: здесь я частично согласен с автором, но в приложении не к инструкциям, а к скриптам. Когда я пришел на работу в ИТА, мне выдали скрипт и сказали - запусти, он поставит тебе сервер. Ну типа такая резунская учебная ложка с дыркой. Линукса я не знал, и скрипт по дурости запустил. Последствия сказываются до сих пор, через полтора года (впрочем, я по-прежнему практически не знаю линукса). Потом мне, конечно, выдали нормальную инструкцию и я научился и ставить и собирать сервер. Но что интересно, люди, которые в момент приема на работу знали линукс, и как следствие, смогли запустить скрипт правильно, через полгода-год часто (да, есть заметный процент исключений) разбираются в нюансах сборки и установки сервера хуже тех, кому со скриптом не повезло. Так что инструкции жжут, даже если в них не особо разбираешься. А вот наугад запускать скрипты - недолго и без работы остаться.