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

Все так или почти так, но не совсем. Помнишь, откуда складывается надежность некоего комплекса (неважно, софтового или железячного)? — Она складывается из "ненадежности" отдельных его составляющих. Чем больше составляющих, тем, априори, ниже надежность (при константной надежности составляющих, если сравнивать).

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

Талант тех спецов, о которых все время говоришь ты, тратиться на разработку тех самых кирпичиков тех самых фреймворков. Небольших кирпичиков, надо сказать. На подобной работе практически негде развернуться и никакого полета фантазии. И я даже не знаю что хуже — разрабатывать подобные кирпичики, или строить системы на их основе. Еще пару лет назад мне казалось что я знаю ответ на этот вопрос. (Я не беру в расчет тех 4-х человек, которые продумали концепции, к примеру, того же .Net. Их всего 4 этих вакансии, и каждый из выбранных до этого отличился на своей стезе)

Далее. Трудность задач. Вот покажи мне трудную задачу из имеющихся на рынке труда. Их практически нет, а если есть, то они из разряда "полу/бесплатных для собственного развития". Остальные т.н. "сложные" задачи суть лишь объемны. По мне — это несколько иное. Думаю, по тебе тоже.

Ну и куда ведет такой перенос акцентов? Озвучить? — Когда речь идет о большом количестве несложных понятий, тут самое время вспомнить как раз про административную сторону дела. И о твоих нелюбимых менеджерах. Почему самое время вспомнить? Потому как нет ни одного человека, способного удержать этот потрясающий объем никому не нужной ерунды в памяти. Да и не требуется этого. Требуется поставить "производственный процесс". Именно, он самый, так громко звучащий и так режущий тебе слух. А на деле — расписать роли и следить за их исполнением. При правильной организации дела в распоряжении каждого участника проекта будут срезы произвольных уровней абстракций каждой подсистемы (и системы в целом). Нормальная дока, в порядке репозиторий с исходниками, нормальное вертикальное и горизонтальное взаимодействие участников проекта и т.д. и т.п. и еще куча других вещей, которые обычно не сильно нужны при "индивидуальном" подходе к разработке, но без которых загнется любая коллективная разработка.

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

------
И я ей-богу не хочу обсуждать некий слой программистов, у которых и память течет на ровном месте, или программы на C# или Дельфи ужасают своими внутренностями и наружностями. Это не показатели и не точки отсчета. Это либо новички, либо они еще не поняли, что очутились здесь случайно.

А у всех остальных, даже будь многократная разница в "мастерстве", фактическая наблюдаемая отдача отличается не так сильно (это я заодно отвечаю на твои мысли в "О жизни"). ИМХО, это происходит потому что и те и другие заняты не сильно отличающимися по сложности задачами. И я часто наблюдаю, как на этих несложных задачах "менее одаренные" личности работают гораздо эффективнее. Т.е. быстрее и качественнее. Не знакома такая ситуация? Объяснить, почему так происходит?

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