The Programmers' Stone (Программистский камень)
ModernLib.Net / Carter Alan / The Programmers' Stone (Программистский камень) - Чтение
(стр. 1)
Автор:
|
Carter Alan |
Жанр:
|
|
-
Читать книгу полностью
(354 Кб)
- Скачать в формате fb2
(139 Кб)
- Скачать в формате doc
(141 Кб)
- Скачать в формате txt
(137 Кб)
- Скачать в формате html
(140 Кб)
- Страницы:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
|
|
The Programmers' Stone
Истоки подхода На эту работу нас подвигло желание узнать, почему в программной инженерии некоторые люди на порядок, а то и два, продуктивнее большинства людей. Если бы так было у каменщиков, то строительная индустрия очень заинтересовалась бы причиной. Проблема, конечно, в том, что о каменщике за работой можно снять фильм, а затем его действия проанализировать. Но невозможно увидеть, что делают великие программисты, да и они сами не смогли бы объяснить разницу, хотя большинство из них и захотело бы это сделать. Мы знали, что не помогут сами по себе элементы лучшего опыта индустрии. Не помогут ни инвестиционные вливания, ни обучение. Не помогут инновационные программы Качества, которые явно включают такие целостные концепции как "Дзен и Искусство ухода за мотоциклом" Роберта Персига (Robert Pirsig's
Zen and the Art of Motorcycle Maintenance), которые в большей части индустрии считают слишком радикальными, чтобы с ними экспериментировать. Не помогут ни многолетняя практика, ни многие годы академического образования. Мы посчитали, что имелся единственный способ продолжить исследования, если уж приверженная объективным метрикам индустрия не смогла найти этот X-фактор, -- рассмотреть субъективный опыт работающих в области программной инженерии людей. Достижение понимания происходящего заняло долгое время, хотя ключевые идеи большинству из нас уже давно известны. По пути мы изучили склад мышления достигших успеха программистов и смогли разработать упражнения, которые обязательно помогут многим. Этот материал создавался несколько лет и представляет собой смесь идей, эмпирически подправленных экспериментами и позднее собранных в единую логичную картинку, а также материал, полученный на основе этой картинки. Цель этой работы - донести элементы "опыта" или "взглядов", на которые повсеместно ссылаются, но редко описывают. Многие темы - это то, что программисты обсуждают за пивом. Кажется странным, что никто не стремится узнать, как проблемы, которые программисты считают наиболее важными, соотносятся с "формальными" структурами современной инженерии. Здесь мы делаем именно это. Если мы попали в точку, большинство программистов получает удобный случай поместить волновавшие их долгие годы проблемы в ясный рабочий контекст. Мы предлагаем расслабиться и хорошо провести время!
Картостроение и программная инженерия Программная инженерия находится в ужасно плачевном состоянии. Так называемый "кризис программного обеспечения" был осознан в 1968, но несмотря на тридцатилетние усилия и сотни опубликованных предположительно фундаментально новых концепций, общее состояние индустрии ужасающе. Проекты выходят за рамки бюджетов или превращаются в неразгребаемые кучи. Оценки - искусство черной магии. Многие проекты решают вчерашние проблемы пользователей, а не сегодняшние. Техническое качество большей части кода отвратительное, что вызывает проблемы сопровождения и высокие затраты на эксплуатацию. И в индустрии все еще есть отдельные программисты и группы, которым нравится модель водопада (staggering) и воспроизводимые успехи (repeatable successes). Хотя существует множество способов измерения продуктивности программистов, некоторые программисты оказываются в сотни раз более продуктивными, чем большинство, независимо от методов расчетов. Если бы вся индустрия работала также, как малая доля великолепных программистов, то экономика сразу бы это заметила. Если бы стало возможным писать сложные, надежные программы быстро и дешево, увеличился бы интеллектуальный потенциал общества и его благосостояние. В рамках предлагаемой модели эту проблему можно понять. То, что представляется как социально обусловленное общепринятое мышление (называемое
паковкой- packing), основано на действии. Чтобы быть хорошим каменщиком, паковщик должен знать, что делает каменщик. Но что же делает программист? Большинство разрабатываемых паковщиками моделей программирования являют собой концепцию Программной Фабрики. В ней пункты требований от заказчиков входят в одну дверь и обрабатываются рабочими по описанной в руководствах процедуре. Когда производственная линия завершает свою работу, программа выползает из другой двери. Это работает на автомобильных заводах. Беда в том, что аналогия с автозаводом неряшлива. Большая часть автозавода заполнена работниками, применяющими механизмы для производства автомобилей, но где-то на задворках есть небольшой офис, где другие работники определяют, как использовать ресурсы фабрики, чтобы сделать как можно больше похожих друг на друга автомобилей. Работники программной фирмы не похожи на работников в цехах автозавода. Сегодня работников в цехах можно заменить роботами, но по-прежнему нужны люди, использующие творческий подход к "настройке" фабрики. Программисты делают ту же работу, что и офис на заводских задворках, и мы не можем научиться этой работе, играя на полу цехов автозавода. Паковщики, бескомпромиссно защищающие ориентированные на процессы Программные Фабрики, действительно заявляют, что способны реализовать Искусственный Интеллект, имитирующий разработчика на конвейере, и сделать это, используя в качестве своего компьютера перемещающих листки бумаги людей. К сожалению, паковка не способствует пониманию производства программ и приводит к ужасной путанице. Это означает, что иногда паковщики произносят очень глупые вещи. Чтобы понять, что же на самом деле делают программисты, требуется альтернативная стратегия мышления (называемая
картостроение- mapping), поскольку программирование по сути - это процесс усвоения возможностей системы, природы задачи и желания, а затем выражение результатов исследования на языке программирования. Вся суть в исследовании деталей наших желаний и понимание их таким способом, что мы можем отследить всю их сложность. Решение проблемы картостроителем может привести к красивым, компактным, элегантным программам, в которых нет места для ошибок. Картостроение может осуществлять программирование, но способ, каким оно это делает, невозможно объяснить на языке паковщика (ориентированном на действия). Паковщики, таким образом, заключают, что хакеры "необъяснимы" и отвергают их работу, говоря, что сложность по своей внутренней сути необъяснима, и мы должны создавать все более сложные процедуры, чтобы избежать ответственности. К счастью, многие управленцы в организациях продолжают поощрять обдумывание на основе интуиции и эмпирического опыта, без попыток вложить их в прокрустово ложе процедурных (основанных на действии) инструкций. Это трудно сделать, но это единственный способ довести что-то до результата. Очень важно осознать, что картостроение - это не еще одна процедурная методология, которую нужно загрузить в голову паковщика. Это другой способ посмотреть на все вещи сразу. Необходимо осознать, что реально возможно принять личную ответственность за работу вместо того, чтобы уйти от нее, прячась за процедуру. Программирование настолько ближе к чистому картостроению, насколько вы сможете выбраться за пределы своего черепа. Именно поэтому это удовольствие. Это путь бесконечных открытий, понимания и учебы. Объектно-ориентированный подход (OOП) и картостроение очень интересно взаимосвязаны. ООП очень по-разному воспринимается картостроителями и паковщиками. Карта картостроителя - это вид объектной модели, в которой множество объектов и взаимосвязей. Картостроитель рассматривает ООП как элегантный способ разрабатывать программы, если они уже поняли проблему. Паковщик смотрит на ООП как на способ побродить вокруг проблемной области, создать программные объекты, а затем просто соединить их как получится. Таким образом, ООП воспринимается как процедурный механизм для перехода от проблемы к программе без вмешательства понимания. Если бы было возможно учесть абсолютно каждый аспект проблемной области и не нужно было заботиться об эффективности, то этот подход мог бы сработать. Но в действительности при проектировании объектов и их классификации всегда необходим хороший вкус, поскольку необходимо разрабатывать программные объекты, хорошо соответствующие объектам реального мира, но которые можно соединить вместе, чтобы получить жизнеспособную компьютерную систему. Это требует понимания и является строго работой картостроителя. Это проясняет, почему есть ОО проекты, которые заходят в тупик с результатом в виде смеси реальных и вспомогательных объектов, использующих множество избыточных схем адресации для взаимодействия
черезБрокеры Объектных Запросов (ORB), без ясной концептуальной целостности в инициации, выравнивании нагрузки и журналировании. Программисты-паковщики часто настолько слабо контролируют свои объекты, что вообще теряют их, и все заканчивается утечками памяти, что приводит к падению программы. Решение паковщика в этом случае -- покупка средств обнаружения утечек памяти, а не восстановление контроля над своими объектами, чтобы все работало как надо.
Картостроение и Тотальное Управление Качеством (TQM) После 2-й мировой войны американцы послали в Японию д-ра Деминга (W. Edwards Deming) помочь привести в порядок промышленность, которая была странной смесью средневековья и индустриальной эры и была разрушена войной. Деминг предложил идеи, включающие сбор статистики о деятельности при массовом производстве, просил занятых этой деятельностью рабочих подумать о способах ее совершенствования и требовал убедиться, что каждый работник понимает, что он делает. Эти идеи позднее развились в то, что мы сейчас называем "Тотальное Управление Качеством" (Total Quality Management - TQM). Результат (как нам говорят) получился сверхординарный. За одно поколение японская промышленность была восстановлена и продвинулась от изготовления в ограниченных количествах велосипедов до мирового лидерства в высокотехнологичных производствах - кораблестроении, автомобилестроении и электронике. "Японский метод" был реимпортирован на Запад и стандартизирован как ISO 9001, международный стандарт "Качества", на который равняется бизнес и который фокусируется на определении процедур для всего на основе хронометрирования и проверок (ticking & checking). Вообще-то, хотя предполагаемые преимущества еще никто не увидел, еще есть организации, применяющие идеи Деминга, и есть его последователи, которые выискивают эти преимущества. Осознавая важность картостроения, предложим другой взгляд на то, что произошло в Японии на самом деле. Картостроение определенно можно пробудить травмой. Вот возможные способы травмировать людей: Скинуть на них атомную бомбу. Дважды.Похоронить их застойное, предсказуемое феодальное общество.Сказать им, что завтра придут захватчики.Оставить их без ужина. Чтобы поесть, человек вынужден пробудить свою способность мыслить. Поэтому к тому времени, когда Деминг прибыл в Японию, народ, с которым ему пришлось работать, был уже картостроителями. Поголовно. Весь сразу. Возможно, все, что нужно было сделать Демингу, - это взять листок из "Необыкновенных приключений Билла и Теда", встать на чайной церемонии и закричать: "Будьте внимательнее друг к другу!" Когда это сработало так эффективно, то, естественно, произвело на Деминга и его коллег большое впечатление, поэтому они начали работать над методами, используя которые люди, создавая мощную индустриальную культуру, становились бы еще более внимательными. Но методы при этом имели скрытое требование, что все это работает только для картостроителей! Во времена ранних опытов переноса "японского метода" картостроители из Японии возвратились в Америку и с присущим энтузиазмом и привычками картостроителей они показали американским рабочим, как задавать интересные вопросы о своей работе, как собирать информацию, интерпретировать ее с пользой и улучшать процессы. Они показали им, как составлять описания своей деятельности, смотреть на эти описания и находить узкие места. Это работало прекрасно, но это были обученные по воле случая картостроители, которые делали реальную работу. Когда идеи TQM стали широкораспространенными, это обучение картостроению просто потерялось. Идеи продавались индустрии паковщиков, которая не могла распознать ключевых моментов - мудрости и размышления. Даже передовые менеджеры из индустрии высоких технологий наталкивались на коммуникационный барьер. Для многих работников TQM выглядело похожим на то, что провозглашал отец научного менеджмента Фредерик Тейлор (Frederic Taylor). Тейлор выдал нам массу результатов прежде чем у нас появились роботы, заставляя людей выполнять функции роботов. Вероятно, неправильно так смотреть на вещи, но в Лос Аламосе имитировали работу электронной таблицы, усаживая людей рядами за столами с арифмометрами! Он был таким наркоманом контроля, что имел привычку каждую ночь привязывать себя к кровати, чтобы противостоять своей патологической боязни выпасть из кровати. Его лозунг был: "Оставь свои мозги за дверью и внеси сюда только тело". Наша культура, от школы до законодательства, по-прежнему в тисках тейлоризма. В этой ситуации наихудшим результатом внедрения TQM без ясного понимания необходимости картостроения будет тупой тейлоризм. В лучшем случае мы удивимся, почему мы делаем то, что мы делаем. В некоторых организациях результат был трагичным. Заморочки с микробухгалтерией, крючкотворство в составлении отупляющих и путанных описаний работы заводили в безысходную колею. Все это приходилось делать в рамках конкурентной [в смысле подсиживания] модели паковки, а не в кооперативной [в смысле поощрения совместных действий] модели картостроения. На рабочих местах появились аудиторы ISO 9001 с внезапными проверками бумаготворчества, стремясь подловить работников на мелких нарушениях инструкций, совсем как у Кафки. В некоторых организациях работники стали больше озабочены тем, как избежать наказания за микронарушения правил составления бумажек, чем самой работой, которая полностью терялась в пришедших ритуалах. Вспомните о сказанном Фейнманом о шести строчках! Некоторые люди до сих пор считают, что это великая мысль. Хорошее Тотальное Управление Качеством собирает опыт на рабочих местах и концентрирует это знание в виде сжатых списков вещей, которые стоит рассматривать. Эти списки просто напоминают о проблемах, при рассмотрении которых картостроителю следует применить свой здравый смысл там, где это нужно. Недостаток паковщика в том, что он смотрит на эту работу просто как на простановку галочек в нужных клеточках как только для этого найдется оправдание. Сколько рассмотрения "достаточно" паковщику? Поскольку процедурная оргия распространилась под флагом "Качества" в слишком многих местах, это привело к тому, что реальное управление качеством, которое нацелено на выполнение для потребителя настолько лучшей работы, насколько можно себе представить, полностью выпало из поля зрения. Самое смешное, есть некоторые организации (которым, как им кажется, по плечу разумное использование информационных технологий), которые изобрели "настоящий процедурализм". Осуществляющие банковское обслуживание по телефону компании заявили, что им удалось отделить "разумное" обслуживание от реальных людей и в открытую подтверждают анонимную, процедурную природу своего бизнеса. Это позволило им ясно представлять свои процедуры и создавать очень хорошие процедуры, которые удовлетворяют потребности клиентов круглосуточно и без больших затрат. Это сильно контрастирует в глазах у многих с образом смурного клерка-столоначальника, считающего глупые "инструкции", которыми он руководствуется, проблемой его клиентов, а не своей собственной. Очень успешные финансовые организации осознали, что есть процедуры, которые хорошо выполняют компьютеры, а есть обстоятельства, в которых лучше проявляют себя опытные работники. Они анализируют свой рынок математическими методами с помощью компьютеров, а последнее слово оставляют за человеком. Они могут использовать различные критерии для описания обоих аспектов всей системы и оценивать эффективность различных алгоритмов и торговцев. Это дает возможность применить технику картостроителей. Если у нас есть "Настоящее TQM", "Ложное TQM" и "Настоящий процедурализм", то мы можем сказать: Настоящее TQMНастоящий процедурализмЛожное TQMЛожный процедурализм и спросить, имеются ли какие-нибудь примеры организаций с "ложным процедурализмом", которые слепо верят в то, что они безмозглые автоматы, а на самом деле предаются безумству картостроения? А как насчет операции британской армии в Порт Стенли в 1982? Вспомним, армия -- это организация, сталкивающаяся с очень сложными задачами. Даже те, кому отвратительны любые конфликты, могут извлечь урок того, как сделать свой мир более согласованным, поняв, что делает армию более сплоченной. Британские военные -- "ложные процедуралисты"? Вот интересный взгляд на эти вещи с позиций картостроителя, поскольку в таком случае мы можем увидеть сквозь эти строки, что делает эта организация. Идея, что все они все время следуют правилам, затрудняет понимание британской армии в действии. Но если мы предположим, что там много картостроителей, следующих правилам до того момента, пока они не увидят, что правила перестают действовать, тогда все становится яснее. Мы можем также сравнить поведение британской армии и армии США. Американцы всегда в открытую предпочитают подход, больше напоминающий "настоящий процедурализм" банковского обслуживания по телефону. Они явно предпочитают действовать по процедуре и заставляют своих картостроителей писать наилучшие процедуры. Когда это работает, то действительно работает очень хорошо, как на Полуострове ["Буря в пустыне"], но все это неустойчиво, поскольку не дает использующим процедуры паковщикам достаточно свободы, чтобы отреагировать на изменяющиеся условия. Это приводит к неэффективности, как при вторжении на Гренаду. Урок прост. Без лежащего в основе картостроения, TQM превращается в черную комедию. С картостроением методы Качества могут учить и побуждать, а энтузиазм и удовольствие от работы, о которых говорят защитники TQM - это ничто иное, как обычное настроение картостроителя! В этой модели Системное Мышление - подход, защищаемый Питером Сенге в "Пятой дисциплине" (Peter Senge
The Fifth Discipline), может рассматриваться как коллекция полезных концепций и технологий картостроения, оптимизированных для вопросов управления.
Заставь себя! В наше время живет гораздо больше паковщиков, чем картостроителей. Одна из целей этой работы - показать эффективные методы картостроения, но другая цель -- объяснить, почему озарения многих из нас кажутся непонятными для других. Мы должны осознать, когда наши представления творцов-программистов непонятны для коллег-паковщиков, чтобы дать им возможность освоиться со сложными явлениями, требующими некоторого времени на обдумывание. Мы также должны осознать, что быть правым -- это не значит быть популярным, а личная заинтересованность в качественной работе часто приносит больше удовлетворения и меньше стресса, чем страусиное поведение. Мы должны также осознать, что возможно эффективное взаимодействие с картостроителями, даже с теми, кто далек от нашей области. Признавая существование специфического коммуникационного барьера при общении с одними, мы также должны осознавать, что с другими взаимодействие часто оказывается гораздо проще, чем можно было бы предположить. Необходимо также четко осознавать границы нашей ответственности. Если при обсуждении с заказчиком оказывается, что он не ухватывает существенные моменты задачи, помните, что наша личная, поставленная нами самими цель -- найти наилучший ответ -- не обязательно означает заставить заказчика принять один лишь этот ответ. Любое размышление, которое допускает одну стратегию, обычно допускает несколько других стратегий, каждая из которых имеет свои достоинства и недостатки. Это всегда можно обобщить и получить удовлетворение от хорошо проделанной работы по изучению возможностей и обоснования своего выбора заказчику. Если, при полном понимании, заказчик делает выбор, который вам кажется глупым, то каким еще способом организация заказчика может чему-то научиться? Вы не должны спасать весь мир, только свой небольшой кусочек и еще чуть-чуть, если сможете!
Terra incognita В своей книге
PeoplewareТом де Марко (Tom de Marco) и Тим Листер (Tim Lister) наводят на мысль, что великие программы делают "однородные" (gelled) команды, и предлагают способы повысить сплоченность команд. Рассматривая "однородные" команды, мы можем заметить в них легкость общения и эффективность работы. Но добавим в уравнение концепцию картостроения, и картинка изменится. "Однородные" команды выглядят скорее как группы эффективно взаимодействующих друг с другом картостроителей, поскольку они могут ссылаться на общую мысленную карту ситуации с помощью нескольких, возможно странно звучащих слов. (Как-то раз разработчики назвали свою подсистему связи с гарантированной доставкой "Фабрикой спагетти". Дело было в неких колечках, свободно летающих в воздухе.) Они могут не просто быстро обмениваться информацией о своих картах - они могут отрывать кусочки своих карт и перемещать их. Они могут обмениваться кусочками своих карт. Они могут очень быстро реагировать все вместе, как команда. Все они знают, что происходит, они уже тщательно проработали все в своих умах. Они не петушатся и не теряют время на несинхронные действия. Они соответствуют друг другу, хотя у них могут отличаться вкусы в музыке, политике и еде. От роста производительности захватывает дух, тот, кому посчастливилось работать в такой команде, знает, о чем идет речь. Необходимо найти время для обеспечения понимания всеми того, с чем они имеют дело, и жить станет интереснее, поскольку в 17 часов каждый будет испытывать ощущение успеха. Попадание в эту ситуацию не случайно, оно воспроизводимо.
Пакеты знаний, фантазии, карты и понимание Как инженеры-программисты, мы могли бы описать обучение как формирование ассоциаций между референтами [referents - объекты и события, на которые делаются ссылки]. Небо голубое. Дождь в Испании выпадает главным образом на равнине. Эти факты, поддающиеся заучиванию, можно назвать "
пакетами знаний": маленькие кусочки истины (или заблуждений), которыми мы обладаем. Можно долго идти по пути собирания пакетов знаний. Раннее обучение (как оно направляется взрослыми) для большинства детей почти полностью фокусируется на добывании пакетов знаний. Вещи, которые следует и не следует делать. Методы выполнения задач. Данные, которые необходимо запомнить, чтобы потом вспомнить в нужный момент. Трюк с пакетами знаний состоит в идентификации ключевого свойства ситуации и определении действия, которое нужно предпринять. Кто-то может достигнуть высокого положения и степеней, управлять автомобилем, и даже знакомиться с представителями противоположного пола используя пакеты знаний. Особо талантливые пользователи пакетов знаний могут набить свои головы мегабайтами законов и умеют складывать в уме шестизначные числа. Некоторые политики опускают стадию распознавания паттерна и используют один единственный универсальный пакет знаний для всего. Конечно, мы не складываем пакеты знаний в своей голове стопкой, как тарелки. С самого раннего возраста наша естественная реакция на каждый новый пакет - это вопрос: "Почему?" Мы стремимся соединить пакеты знаний, чтобы создать структуру в нашем знании, мысленную карту, которая дает нам понимание причин и следствий в ситуации. Это понимание позволяет нам получать решение для любой проблемы в рамках этой ситуации, вместо попыток выбрать бездумно заученную реакцию. В дальнейшей жизни мы должны периодически проводить время в размышлениях, или фантазиях, исследуя отношения между тем, что мы знаем. Это расширяет нашу интегрированную карту и позволяет нам идентифицировать на карте структуры, которые применимы в различных областях. Затем мы можем получить более подробную карту, в которой то, что математики называют "изоморфизмом" (isomorphism), а программисты называют "наследованием" (inheritance), позволяет нам повторно применять знание. Мы реорганизуем наши мысленные карты, чтобы получить более простые выражения и иметь возможность удержать в уме больше знаний. Когда мы находим более простой способ посмотреть на вещи, то оказывается, что трудно вспомнить, на что это было похоже, когда предмет казался сложным, и мы сами подросли (вырос наш уровень познания). Если есть понимание, то где кончается личность и начинаются собственно данные? Если вспомнить о пакетах знаний, то граница очевидна. Мы становимся экспертами в применения методов рефлексии, позволяющих исследовать наши карты и пакеты знаний, которые мы еще не включили в эти карты. Вероятно, должны существовать нейрологические механизмы для того, что мы делаем при рефлексии, но в основе должна лежать некая деятельность по распознаванию абстрактных структур. Мы учимся использовать наши мозги. Без понимания не может быть разумных действий. Без мысленных карт не может быть понимания. Без размышлений (рефлексии) не может быть мысленных карт, только пакеты знаний. Существуют компьютерные структуры данных, называемые "онтологиями" (ontologies), содержащие массу утверждений (истин), связанных в сети некоторой формой логики предикатов. Например, база данных CYC может использовать карты значений для естественного языка, достаточно хорошие, чтобы интерпретировать подписи к фотографиям и подобрать из них те, которые требуются журналистам.
Картостроители и паковщики Или, по крайней мере, всему этому следует оказаться правдой. К сожалению, мы происходим из индустриальных или аграрных обществ, где один день был очень похож на другой. Эффективность зависела от согласованной работы в небольших группах. С другой стороны, не требовалось большой изобретательности. Мы создали общественный порядок, который учит людей собирать пакеты знаний и фокусироваться на действии. Размышление ("фантазии") подавляется еще в начальной школе. Мы тщательно присматриваемся к детям и замечаем отклонения от норм поведения, основанных на действии. Известно даже, что некоторые родители считают своих детей психически неполноценными, если те не желают заниматься определенным видом спорта. Нельзя легко научить ребенка размышлению (рефлексии). В отличие от активных физических упражнений, субъективный опыт должен обсуждаться. Нелегко установить, насколько хорошо личность умеет мыслить. Только в неторопливых беседах или наблюдая за ребенком длительное время, можно убедиться в том, что он может эффективно рассуждать. Итак, в нашей истории нет ничего, что побуждало бы родителей или учителей учить мышлению. Нет ничего, что сделало бы обучение размышлению приоритетом в школе. На самом деле верно обратное. Когда дети пытаются размышлять, являющееся следствием этого отсутствие проявлений физической активности наказывается. Когда ребенок пытается задавать вопросы в попытке что-то понять, занятые взрослые редко удовлетворяют их любопытство. И если мышление развивается, а понимание растет, то это может стать для ребенка проблемой. Если при выполнении еще пятнадцати простеньких примеров на сложение ребенок заскучал, то его наказывают и считают неспособным выполнить простые действия, хотя ничто не может быть дальше от истины. Отметим, что хотя взрослые в каждом конкретном случае наказывают за разные проступки, то, что дети делают в каждом таком случае -- размышление. Действительно, многие люди привыкли думать, что рефлективное мышление, само по себе, социально неприемлемо! Традиционно заблуждение, что мышлению учат в университетах, но при изучении полного курса обучения тридцатилетней давности, ужатого до одного года в современном курсе, как это происходит для большинства технических предметов, это происходит редко. На работе образованных людей до сих пор считают способными мыслить, и действительно, все программисты должны в какой-то степени уметь это делать хотя бы для того, чтобы выполнить хоть что-нибудь. Мы, программисты, - из числа наиболее мыслящих людей в обществе, но мы до сих пор очень далеки от однородной группы. Некоторые из нас достигли в этом большего, или меньше других переживают об этом. Еще раз - этому нельзя научить, а на встроенном в общество рабочем месте культурная среда часто остается основанной на пакетах знаний и действиях, а не мысленных картах и понимании. Это приводит к двум различным группам в обществе. Картостроители главным образом применяют когнитивную стратегию заполнения и интеграции мысленных карт, а затем считывания решения любой частной проблемы. Они быстро находят методы достижения своих целей, сверяясь со своими картами. Паковщики становятся экспертами в запоминании больших чисел или накоплении пакетов знаний. Их единственная цель - выполнить "правильное" действие. Стратегии для разрешения "переполнения хэша", когда условиям удовлетворяет несколько действий, - это особый случай (\ad hoc\).
Как восстановить картостроение Принципиальное преимущество нашего вида над другими - наша универсальность. Мы можем выживать в более широком интервале температур, чем прочие животные, но более важно, что мы изобретательны. Артур Кларк (Arthur C. Clarke) и Стенли Кубрик (Stanley Kubrick) отметили эту изобретательность в знаменитой заставке "от берцовой кости к космическому кораблю" в фильме "2001". Мы все картостроители, независимо от того, как мало мы используем эту способность. У тех из вас, кто проводя время в одиноких прогулках, барах для металлистов или где там еще, чувствует себя как-то дискомфортно до того момента, пока вдруг не падает, вы даже не знали чего искали, пенс, способность уже есть. Вы знаете, кто вы! [Вот как пояснил выражение "the penny dropped" (" упал пенс") Алан Картер: "Оно означает тот момент внезапного, вневременного стремительного движения (timeless rush), когда новая ментальная модель встает на место. После момента озаренияя (insight), именно так ты естественным образом "видишь" проблемы навсегда (или до следующего раза). Эти опыты (learnings) никогда не забываются. Человек (own person) "вырос", а линия раздела шифр / шифровальный блокнот (code/codebook) между личностью (self) и остальной вселенной сдвинулась. В новом переводе ["Евангелия от Фомы"] Иисус даже более отчетливо, чем в старом, говорит о той же самой модели, что и R. Это странное движение разделительной линии и необычный субъективный опыт действительно показывают, что когда мы это совершаем, происходит нечто очень интересное с точки зрения космологии и информации.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
|
|