Здравствуйте, nigh, Вы писали:

S>>если не секрет не называя имен а что там такого
N>Медленно (по одному чекину раз в несколько месяцев) пилил какой-то второстепенный внутренний/тестерский компонент. На форуме при этом было очень много критики МСа и пафоса.
Ты думаешь, они медленно лепили по собственному выбору? Когда я там работал, процесс был построен примерно так:
1) Берем фичу, которую запросил скип и про которую напоминает каждый день
2) Неделю слушаем отговорки от PM, Senior PM и PM Lead, почему это надо сделать "не сейчас", пытаемся найти компромисс, убеждаем делать фичу
3) ДЕНЬ (!) пишем довольно простой код
4) Неделю проводим на абсолютно идиотском ревью, где 3-4 человека, не понимающих, как работают код, выдают около 50 правок, половина из которых даже собираться не будет (ага, try/catch в kernel-mode), а вторая половина не несет смысловой нагрузки (а-ля ветка с 10 комментами на тему, стоит ли переименовать void *Buffer в void *Data).
5) Коммитим. Даем людям, запросившим фичу, ссылку на временный билд.
6) Через пару месяцев узнаем, что changelist потеряли и не замерджили в основную ветку. Бегаем, ищем крайних.

Да, при этом команда постоянно скидывает баги в стиле "3 года назад автотест нашел, что если запустить тулзу с ключем -x longnameeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee, то она падает" или "при запуске с -a job1 -b job2 -c job3_that_depends_on_2 утекает 16 байт перед выходом из процесса", исправление которых опять таки занимает неделю, ибо все начинают обсуждать, что как лучше переименовать, можно ли для массивов использовать auto_ptr и обязан ли я после добавления тривиальной проверки в функцию из 100 строк, привести всю функцию в соответствие с новыми coding standards.

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

Сейчас, имея опыт ведения переговоров и управления, понимаю, что мог бы сэконосить 30% времени, дипломатично соглашаясь с недеструктивными вещами и отводя внимание от деструктивных. "Переименовать? Давай переименуем. Заменить в старой функции в 100 строк return и break на переменные? Давай заменим. Try/catch в кернеле? А может ну его, пошли лучше кофе пить, я пока успехам твой дочери в школе повосхищаюсь." Но согласитесь, люди, приходящие на программистские позиции, делать подобные вещи обычно не умеют

S>>как я понимаю ниже определенного уровня в MS упасть нельзя
N>Если вы про качество кода, то оно было вполне нормальным. Просто самого кода было с гулькин нос.
Ну да, логично. Человека, умеющего писать нормальный код, поставили в ситуацию, когда он писать толком ничего не может. В итоге время уходит, скиллы забываются, опыт устаревает. Еще бы он не возмущался. Меня именно это и бесило.