Так получилось, что уже не раз люди, ратующие за "анализ сложных задач" и т.п., бросали мне упрёк, что я акцентирую внимание на "всякой ерунде, этого внимания не заслуживающего". На данном форуме это некогда делали и alexus, и Galkov, и другие.
Поскольку непонимание до сих пор имеет место быть... Возникло желание разъяснить данный вопрос.

1) В тех рабочих группах, с которыми мне приходится работать, решаются достаточно сложные и нетиповые задачи. Поэтому глупо меня обвинять в том, что мне нужны "кодеры". Хотя, конечно, на парах я стремлюсь научить всякой "рутине" и только "низкоуровневым" творческим и аналитическим элементам, потому что реально всё остальное у заинтересованной части аудитории потом формирую отдельными проектами, часто связанными с реальными. Посторонние к учебному процессу люди обычно не понимают, что часов всегда дефицит. И банально нет возможности очень далеко залезать, потому что без "фундамента" (банального с точки зрения критиков) их тоже не оставишь.
Хотя, признаю честно, я долго боялся активных форм обучения - и только сейчас, после того, как у нас в институте прошло повышение квалификации с приглашённым педагогом-психологом из Ростова, рискнул работать по активной схеме - с делением на команды, проблемными задачами - и потом только "догоняющей теорией". Пока идёт отлично.

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

Именно этих качеств я хочу от любого члена своей команды. Чтобы его творческая сила была сконцентрирована как раз на анализе задач и проектировании. А не этой рутине.

Эти задачи сегодня "залечены", фактически, по принципу "изоляции проблем программирования в малом". Этот принцип подобен изоляции процессов в ОС - когда до появления безопасных языков единственным способом получить защищённые друг от друга компоненты было разнесение их по разным адресным пространствам. Ошибки и разрушение памяти неизбежно - выстроим аппаратные барьеры, и пусть там компонент чудит как хочет. Надёжность обеспечим уровнем выше, на всём множестве изолированных компонентов.
Кстати, именно по такому принципу разрабатывется - и вполне успешно - софт в РКК "Энергия". В частности, для российского сегмента МКС. Недавно на одном отраслевом мероприятии они подробно рассказывали. Используется C++ и инфраструктура GNU, используются библиотеки типа boost, работает это всё на базе QNX и Винды. "Инженерный подход" имеется на уровне организации системы из изолированных компонентов, которые обмениваются данными по протоколам. Проблема кодинга и языка программирования "изолирована" в этих "резервациях". На вопрос: сравнивали ли С++ и Аду? - отвечали: да, конечно, но где нам брать программистов на Аде? И добавляли: "главное - правильная организация жизненного цикла ПО". И я полностью с ними здесь соглашусь. Но если ряд проблем можно решить ниже, ещё на уровне "программирования в малом", зачем тратить усилия на их парирование на организационном уровне?

Чтобы парировать "любой бред" на уровне модулей, используют модульное тестирование. Нет, я не против его - но я хочу, чтобы на тестирование выходил уже практически правильный модуль. Это позволяет нам иметь хорошее качество БЕЗ модульного тестирования, и просто отличное - если потратить дополнительные усилия на него (в ответственным случаях).

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

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

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

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