Точка зрения

Меня часто спрашивают - "если человек не может аргументировать свою точку зрения, значит он не прав?".

Давайте я классифицирую это. Какие выражения люди используют, чтобы доказать свою правоту.

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

"Я более опытный". Вы просто еще не поняли, что из-за своего опыта Вы ошибаетесь чаще, чем оказываетесь правы. В большинстве случаев это означает, что Вы помните вещи, какими они были 10-15 лет назад. Эти вещи сейчас либо не действуют, либо претерпели существенные изменения. Если вы имеете привычку по своему опыту судить о других людях - на основе каких метрик вы это делаете? Другой человек - это другой мир, он живет в другом измерении, Ваши мерки не действуют в нём. Судите о себе только самих себя. Вам необходимо умение видеть причину и все сопутствующие факторы - только тогда вы сможете делать правильные выводы.

"У меня есть сертификат". Отлично, вы знаете некоторые факты, что дальше? Вы знаете, как проектировать системы? Вы знаете, как их эксплуатировать? Как их масштабировать?

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

"Я директор XXX на протяжении NNN лет". Ну и что?

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

О чем вы знаете

Знания и пути их приобретения. Как узнать что-то, когда вы даже не знаете, что конкретно вы не знаете?

Недавно в поле моего зрения попала интересная концепция, которая называется куб Rumsfeld'а. Выглядит она следующим образом:

"Неизвестные неизвестности". Этап приобретения знаний начинается с правого нижнего угла. В это время у вас нет ни понимания предмета, который вы собрались изучать, ни представления о поведении этого предмета в реальной жизни.

"Известные неизвестности". Вы провели несколько практических исследований, но не знаете, что означают результаты. Вы видите поведение объекта в рельном мире, но пока не понимаете на каких законах оно основывается.

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

На пути приобретения знаний вы можете двигаться либо вдоль нижней, либо вдоль правой грани. "Понимание" без соответствующего практического подтверждения может оказаться неверным (не соотвствующим действительности). Результаты экспериментов без теоретического обоснования могут ввести в заблуждение.

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

Рекомендации или....

Я могу продолжить заголовок - "... или как не надо писать рекомендации".

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

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

Недавно мне на глаза попался документ с рекомендациями по настройке сервера 1С, авторы которого перед написанием явно приняли что-то забавное. Поступили следующие рекомендации:

1. Регулярная перестройка индексов. Попытка таким образом бороться с деградацией индексов в современных СУБД равносильная борьбе с ветряными мельницами. В 99% процентах случаев индекс достаточно быстро вернётся к своему изначальному состоянию - затратив на это достаточно большое количество ресурсов. Вы потратите время на его перестройку, затем получите замедление операций DML, пока индекс возвращается к своему первоначальному состоянию - чтобы в конечно итоге получить то, с чего начинали. Решение оказывается намного хуже проблемы, которое оно пытается решить. Оставшийся 1%, когда непрекращающаяся деградация индекса действительно имеет место быть - указывает на явные недостатки в дизайне модели данных. В этом случае, вместо того чтобы заниматься бесконечными перестройками индексов, вам лучше устранить причину, по которой их вообще необходимо перестраивать.
2. Дефрагментация файловой системы. В многопользовательской системе фрагментация никогда не влияла на производительность - просто потому что головки диска никогда не будут там, где вы их только что оставили. С учетом современных дисковых массивов, накладывающих достаточно большую степень абстракции на физическое расположение данных, понятие фрагментации теряет свой смысл.
3. Дефрагментация данных в СУБД. Под фрагментацией в СУБД (в частности, в Oracle) понимается наличие в одном табличном пространстве экстентов различного размера. В итоге, по мере того как вы добавляете и удаляете данные, между экстентами начинает образовываться свободное место "странного" размера, которое не может быть повторно использовано СУБД для размещения новых экстентов. Эта проблема раз и навсегда решается использованием экстентов либо одинакового размера, либо кратных друг другу. Решать эту проблему постоянным перемещением данных в СУБД - точно такой же абсурд, как и постоянная перестройка индексов. В итоге, вы точно так же закончите там, где начинали.

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

О чём я здесь так долго говорю, на западе называют evidence - то, что позволяет явно убедить человека в том, что Вы правы. Всегда оспаривайте точку зрения, которая не подкреплена соответствующими доказательствами. Особенно, если эта точка зрения исходит от так называемых "экспертов".