изобретаем велосипед

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

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

Оно же подсказывает и путь к тому, как тренировать навык. Для общего переносимого навыка замечательной тренировкой будут игры типа давешней The Incredible Machine, где из заданных компонентов нужно построить механизм имени Руба Голдберга для выполнения некоей задачи. Как в реальной жизни, там могли присутствовать лишние компоненты, которые в-принципе дают надежду на их использование, но в реальности оказываются бесполезными, а также множественные пути достижения цели. Ну, а для конкретно программирования - рассказывать примеры построения в виде лекционного материала, и аналог таких голдберговских головоломок - задачки с подсказками про их фрагменты в виде практики.

P.S. В-принципе, есть уже и книжка на подобную тему: Jon Bentley's "Programming pearls".