Здравствуйте, koandrew, Вы писали:
K>Как я и ожидал, ты путаешь технически сложные задачи со сложными с точки зрения бизнеса.
Я думаю, что для выведения дискуссии в более продуктивное русло тебе нужно:
1) Дать определение технически сложной задачи.
2) Привести примеры задач, удовлетворяющих твоему определению, которых нет в финансах, но есть в других предметных областях.
Мой опыт программирования включает достаточно широкий спектр задач от написание драйверов, программных патчей ядра винды, написания комплиляторов и высокооптимизированных функций под конкретные CPU до написания GUI и макросов на VBA. На основе своего опыта я сделал вывод, что техническая сложность задач не зависит от предметной области вообще. Любое программирование в конечном счете – это манипулирование структурами данных с помощью вызова нужных функций в правильном порядке.
Технически сложной задачу делают следующие факторы:
1) Отсутствие удобных инструментов
2) Отсутствие необходимых данных для анализа
3) Отсутствие информации о функциях и методологии их применения
Например, задача нахождения источника memory corruption технически сложна и в общем случае неразрешима, если у тебя есть только crash dump. Однако, она сводится к технически тривиальной, если есть возможность использовать какой-нибудь дебажный аллокатор и гонять программу до тех пор, пока проблема не воспроизведется (удобные инструменты)
Задача оптимизации на уровне микросекунд сложна среди прочего потому, что невозможно использовать существующие в природе профайлеры, что приводит к отсутствию данных для анализа. Однако ты можешь написать свои собственные маркеры, которые произведут нужные тебе данные и упростят задачу.
Задача патчей бинарного кода произвольной программы сложна потому, что в природе нет описания функций этой программы (отсутствие информации), а получение информации с помощью дизассемблера затруднено отсутствием удобных инструментов (сейчас, правда, слышал, с этим стало получше).
Задачи на взаимодействие потоков сложны, главным образом, в силу отсутствия эффективных инструментов отладки, однако могут быть сведены к тривиальным методом выбора соответствующей архитектуры кода.
Задача полного изменения архитектуры компонента может быть сложна, если компонент сложен сам по себе, или у него сложные зависимости. Это, однако, не является специфическим ни для какой конкретной предметной области.
Многие задачи, перечисленные мной, тем не менее, содержат в себе необходимость серьезного изменения архитектуры и/или организации сложного многопоточного взаимодействия.
Кроме того, задача быть самым быстрым компонентом на рынке очевидным образом сложна сама по себе, поскольку многие неглупые хорошо оплачиваемые люди решают ее одновременно с тобой. Утверждать, что она тривиальна, так же странно, как утверждать что выиграть олимпиаду по бегу тривиально в силу того, что даже трехлетний малыш умеет бегать.
K>Принимается, но часто ли ты разрабатываешь новые платформы с нуля? 
Мы постоянно пишем самые разные компоненты с нуля. Не знаю, что ты называешь платформой. К тому же в общем случае я считаю написание с нуля намного более простой задачей, чем изменение существующей архитектуры, на которую есть многочисленные зависимости. Именно в силу простоты данного подхода плохие программисты любят писать/переписывать вещи с нуля.
K>У нас дело было не в квалификации людей, а в том, что работы было объективно много для того количества людей, которые были в команде. Ну ещё и бизнес "помогал" со своей идиотской привычкой вспоминать в последний момент о том, что нужно сделать.
У нас тоже много работы. Я точно могу найти себе работу на ближайшие лет пять. Это, однако, не означает, что я буду сидеть на работе по 24 часа в сутки, пока работа не закончится. Работа приоритезируется и выполняется в рабочее время. При появлении срочных проблем должны существовать механизмы их митигирования до тех пор, пока не наступит рабочее время. Если таких механизмов нет, хороший программист может их предложить и убедить начальство, что данные механизмы необходимо реализовать с высоким приоритетом. Если убедить начальство не удается, то начальство ставится перед фактом, что работа во внерабочее время на постоянной основе выполняться не будет, если только это не прописано в контракте и специально не оговорено. Хорошие программисты в этом смысле имеют практически неограниченный потенциал убеждения, поскольку их увольнение принесет фирме намного больше проблем, чем самому программисту.
K>Ну значит тебе относительно повезло в том, что ты торгуешь на одной площадке.
Я торгую на многих площадках, но они все в северной Америке, поэтому в этом смысле да, повезло.
