[gl00mie]

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

Цитата:

Суть в том, что плюсом считалось знание библиотеки. Вот это и была ОНА, экономика ЗНАНИЯ. Знаешь эту вонючую библиотеку до последней запятой – молодец. Конечно, если она хоть кому-то еще зачем-то нужна. А не знаешь – бяка, плохой девелопер. Кака. Все просто, правда?

По ходу, автору трагически не везло с работодателями, см., например, статью Искусство проведения интервью Джоэла Спольски, датированную мартом 2000-го года:

Цитата:

Закончив интервью, вы должны принять четкое решение. Возможных вариантов только два: нанимать или не нанимать. Но как же принять это самое решение? Нужно постоянно спрашивать себя во время интервью: А он толковый? Он способен нормально довести до конца? Чтобы получить ответ, нужно задавать правильные вопросы. Вот вам, смеха ради, отвратительный вопрос для интервью: «В чем разница между varchar и varchar2 в Oracle 8i?» Задавать такой вопрос совершенно бессмысленно: между людьми, знающими эту бесполезную мелочь, и людьми, действительно нужными нашей компании, нет ни малейшей корреляции. Кого волнует, в чем эта разница? Ответ ищется в Интернете за 15 секунд!

Далее, Эльдар пишет:

Цитата:

Вот только с JDK 2.0, и еще больше с .Net ситуация изменилась. Библиотеки разрослись настолько, что даже идиоты с очень хорошей памятью не могли их запомнить полностью... Начиная с .Net, хороший программист – это не тот, кто помнит наизусть все интерфейсы, а тот кто знаком с кнопкой F1 и знает как ее использвать... Знание сменилось открытием. Ты уже не знаешь как что-то сделать, но ты знаешь как найти знание, как это сделать. В просторечье, "найти знание" называется "открыть".

Ну да, опять метания из крайности в крайность: знать библиотеки теперь не нужно, ведь на все вопросы есть ответы в справке. Тут можно вспомнить статьи того же Джоэла Назад, к основам (2001-й год):

Цитата:

Мы тратим здесь кучу времени, рассуждая о высокоуровневых вопросах как, например, .NET против Java, использование XML, удерживание клиентов, стратегия конкуренции, архитектура ПО и так далее. Все это как слои пирога. На самом верхнем уровне у нас стратегия продукта в целом. Уровнем ниже мы думаем об архитектурных решениях вроде .NET, а еще ниже - отдельные продукты: средства разработки типа Java или платформы как Windows.
А копнём ещё глубже. DLL'ки? Объекты? Функции? Нет. Еще ниже! В какой-то момент мы увидим строки программного кода. Это еще не достаточно глубоко. Сегодня мне хочется подумать о процессорах. Небольшой кусочек кремния, двигающий байты. Представим, что вы - начинающий программист. Забудем все накопленные знания о программировании, программном обеспечении, управлении проектами и вернемся на нижний фундаментальный уровень - машины Фон Неймана. Выкиньте из головы J2EE на это время. Подумаем о байтах.
Зачем нам все это? Мне кажется, некоторые фатальные ошибки на уровне архитектуры люди делают из-за непонимания простейших вещей на самых низких уровнях. Как будто строишь замечательный дворец, совсем не позаботившись о его фундаменте. Вместо отлитого цементного раствора там, например, песок. Так что в результате дворец выглядит отлично, но в стенах изредка появляются трещины в кулак, и вы не можете понять, что происходит.

А также Закон Дырявых Абстракций (2002-й год):

Цитата:

Закон дырявых абстракций означает, к сожалению, что абстракции не так сильно упрощают нашу жизнь, как должны бы. Если я обучаю программистов C++, было бы здорово, если бы мне не нужно было рассказывать им про char* и арифметику указателей, а можно было сразу перейти к строкам из STL. Но в один прекрасный день они напишут "foo"+"bar", и возникнут странные проблемы, а мне придётся всё равно объяснить им, что такое char*. Или они попытаются вызвать функцию Windows с параметром типа LPTSTR и не смогут, пока не выучат char* и указатели и Юникод и wchar_t и хедерные файлы TCHAR — все то, что просвечивает через дырки в абстракциях.
Когда я обучаю кого-то программированию COM, было бы здорово ограничиться визардами Visual Studio и автоматической генерацией кода, но если что-то выйдет не так, у них не будет ни малейшего понятия, что случилось и как это исправить. Значит, надо рассказывать им про IUnknown и CLSID и ProgIDS и... о боги!
При обучении программистов ASP.NET было бы здорово сказать: мол, дважды кликните мышкой на штучку, а затем пишите код, который будет обрабатываться на сервере, когда пользователь кликнет на эту штучку. И правда, ASP.NET абстрагирует разницу между написанием кода HTML для отработки нажатия на гиперссылку (<a>) и кода для отработки нажатия на кнопку. Проблема: разработчикам ASP.NET пришлось скрыть тот факт, что в HTML нету способа отсылать форму из гиперссылки. Они обходят это, генерируя несколько строчек на JavaScript и добавляя к гиперссылке функцию onclick. Но эта абстракция дырява. Если пользователь отключит JavaScript, то приложение на ASP.NET не будет правильно работать; и если программист не знает, что именно абстрагировалось ASP.NET'ом, он не поймёт, в чём там дело.

Так что если экономика открытий и пришла на смену экномике знаний, то это вовсе не означает, что знания тех же библиотек стали не нужны, просто появились новые уровни абстракции, но знать от этого стало нужно еще больше. См. также Лорд Палмерстон в программировании (2002-й год):

Цитата:

Дырявые абстракции означают, что мы живем с очень резкой кривой обучения: вы можете выучить 90% того, что вы используете каждый день, за неделю обучения. Но на то, чтобы разобраться в остальных 10%, уйдет еще пара лет. Это то, чем по-настоящему опытные программисты отличаются от людей, которые говорят ”не важно, что вы хотите, что бы я сделал, я могу открыть книгу и научиться делать это”. Если вы создаете команду, нормально иметь множество менее опытных программистов для написания больших участков кода с использованием обобщенных инструментов, но команда не удастся, если у вас нет нескольких по-настоящему опытных членов команды для выполнения действительно сложной работы.

В конце статьи Эльдар пишет:

Цитата:

Мда-м... опять никто не услышит, а если услышит, то сопрет, и никто так и не узнает, что я первый об этом рассказал... А вообще-то больно, просто больно. Представьте себе Креза, которому говорят, "ты – парень, просто страдаешь манией величия. Это все золото и так тут было. Видишь – оно есть, значит и было! Ты что, действительно хочешь чтоб мы поверили, что твое прикосновение превращает все в золото? Ты, давай, того, не выпендривайся. Мы тебя так и быть потерпим, но ты вокруг ничего не трогай. А если найдешь еще золото, не притворяйся, что сам его создал, а позови нас! Не твое, отдай начальству! И не мудри, ты тут – совершенно ни причем."

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