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

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

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

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

Непонятно как разработчик должен исхитриться допустить ошибку?
Возьмем разработку блока. Схему проверяет его руководитель, а перед этим, что бы не позориться сам разработчика с товарищем. Затем нормоконтроль проверяет сопряжение различных документов. Дальше конструктор во время расположения и разводки платы. Дальше испытания - если баг не вылез - значит что-то несущественное. Еще будет этап написания инструкции по настройке-проверке. Там тоже проверяется каждый пункт функционирования. Сейчас все делает компьютер - но он может сравнить и проанализировать даже лучше человека.
Я помню моя ошибка настигла меня через год в лице вычислительной машины. Она просчитала все схемы и выдала, что в таком-то блоке превышено число разветвлений у микросхемы - много микросхем висит на выходе. Пришлось менять микросхему на более мощную.
Т.е. для того чтобы по вине разработчика выплыла ошибка и грубая - это надо постараться.

Типичнейший пример водолейства. Вода в каждой строчке. И  Соответствующий мыслительный процесс - по-больше чего-нибудь написАть  в отчёте- авось начальство не поймёт. (Студенчество так и прёт - как  в ПЗ побольше  накатать)  

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

Программа для космического аппарата non verpa caninus est (сложное изделие). Программист должен знать все особенности работы всего электронного оборудования в изделии, знать циклограмму работы изделия и понимать место программной логики в этой программе, он принимает непосредственное участие в разработке циклограммы. Грубо говоря, чтобы качественно написать программу управления для простенького кубсата, надо перелопатить тысячи страниц документации на составные электронные компоненты. Программист должен понимать, какие стандарты качества нужно использовать при разработке ПО, должен грамотно предсказывать объемы тестирования на этапе написания исходного текста программы, на этапе испытаний макетов, на этапе КДИ и ПСИ. В случае разработки КТ программист должен хорошо ориентироваться в РК-11, должен иметь представления о западных стандартах разработки. Все это идет параллельно разработке конструкторской документации, изготовлению деталей и узлов, испытаниям. Да, программу надлежит сразу писать правильно, с соблюдением правил написания исходного кода, с использованием средств тестирования, при постоянном обзоре текстов подпрограмм, которые пишут подчиненные. Если у кого-то на предприятиях делают "тяп-ляп", то это вопросы к этим предприятиям.

Еще я не пойму суть негативного отношения к студентам и их начинаниям. Я считаю, что опыт, доведение работы до результата, пусть и негативного, ценнее отсутствия такого опыта. И в сравнении со стандартным космическим образованием он в 10 раз ценнее. Простите, как студент может "прощупать" ракету или "прочуствовать" космическую технику? Одних лекционных занятий мало, очень мало, чрезвычайно мало. Пара занятий в демзале кафедры? Практика на ЦНИИМАШе или в РККЭ, где им грустного видя дядечки заунывно расскажут, как у них все плохо, и что на них опять который год вешают студентов? Поэтому такие проекты ценны именно своей образовательной составляющей.

Разумеется.