Сколько времени нужно, чтобы добавить 2 пробела?

Сколько программистов нужно,
чтобы вкрутить лампочку?
Ни одного, это аппаратная проблема.
(анекдот)

Вот какая история произошла со мной одним летом на одном проекте.

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

function f()

{

код

//комментарий

код

}

Без отступа и пробела после слешей.

Я исправил этот комментарий, чтобы он соответствовал стилю кода. Вот так:

function f()

{

код

// комментарий

код

}

Добавил пробелы перед и после слешей, на что ушло 5 секунд. После чего залил данное изменение в репозитарий вместе с изменениями, соответствующими задаче.

Что тут началось.

Руководитель проекта (РП) отклонил мои изменения, а к строке с исправлением комментария написал замечание "Это не имеет отношения к задаче".

После этого между нами произошла следующая переписка.

Я: Нужно выравнивание кода.

РП: Не нужно.

Я: Почему?

РП: Потому что изменения не связаны кодом, который меняют.

Я: Т.е. комментарии можно писать как угодно?

РП: Нет. Но комментарий, который мы проглядели, не стоит рабочего времени.

Я: На него ушло секунд 10.

РП: Это вряд ли.

Я: Обидно, что тратится время на бюрократию из-за одного комментария.

РП: Это не бюрократия. Это попытка делать работу, о которой никто не просит.

Я: Раз работа уже сделана, зачем ее откатывать?

РП: Чтобы в дальнейшем не возникало желания придумывать себе задачки.

Увы, разумные аргументы не возымели действия, и мне пришлось откатить исправления комментария и перезалить код повторно.

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

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

Приведенные примеры – лишь малая часть всех бюрократических случаев. При этом претензий к работоспособности кода практически нет. Но именно после случая с комментарием терпение лопнуло.

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

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