Чувство прекрасного

[ermouth]

Такая сложно формализуемая штука, особенно для айтишников. Лорд Кельвин говорил – “что нельзя измерить, то нельзя улучшить”. Не уверен, что каждый инженер эту фразу знает, но подспудно верит в неё, кмк, едва ли не каждый.

Вера эта ложная, и чем дальше в XXI век, тем всё сильней это проявляется. И дело тут вот в чём.

Задачки инженерные – те которые задачки, а не просто на движок картинку натянуть или придумать куда выключатель поставить – с каждым днём становятся сложнее. Мы очень круто научились не изобретать велосипедики – и хорошие решения запоминаем всем миром разом. И поверх них генерим новое.

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

Хуже того, не вдруг поймёшь, какие из них “вчера”. Я думаю, многие сталкивались с тем, что всеобъемлющая память гугла стала доставлять проблемы – читаешь, бывает, какую-то инфу и только к концу понимаешь, что это старьё. Если вообще понимаешь.

По этой же причине стало практически бесполезно читать учебники по продвинутым развивающимся дисциплинам – за то время, что они писались и издавались, они безнадёжно устарели.

Как же быть? Как принимать решения без метрик или без веры в них?

Чувство прекрасного обладает серьёзной предсказательной силой. Не вообще везде, а нашем мире – потому что наш мир очень зависит от людей, вполне отличающих красивое от некрасивого. Понятие репутации – прямое следствие такого умения, например.

У меня есть наблюдение. Если программист одевается как чучело и в целом неухожен – это скорее всего пустышка. Исключение составляют “системщики” и “оптимизаторы” – но это очень редкие люди и их сияние сразу совершенно затмевает то, как они одеты.

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

Если вернуться к лорду Кельвину, понятно становится, в чём в его фразе подвох. Само понятие “улучшить” – двойственное. Улучшать можно количественно, а можно качественно.

И при качественном улучшении применять количественные метрики, основанные на старой модели – это просто самообман. Даже не подсказка, чаще предсказательная сила монетки получается.

С другой стороны это не всегда бессмысленно – хоть такой подход и загоняет неизбежно в тупик, он даёт возможность появляться редким “рекордным” зверушкам. Это когда вытягивали до предела одну-две какие-то метрики. Например SR-71 и U-2, рекордные самолёты – и нереально сложная посадка и пилотирование при дозаправке, даже в симуляторе.

Замечу, правда, что на них глядя моё чувство прекрасного от восторга верещит )

Comments

[ermouth.livejournal.com]

Я же на js пишу, он у большинства второй язык. И первый язык конкретного автора накладывает на стиль письма на js существенное влияние. js гибкий же, на нём как угодно можно.

У меня есть наблюдение, что форкать exec flow константами и вообще конфигурировать константами – обычная практика для махровых сишников (или долбоёбов пэхэпистов). Для первых пересобрать проект с вкомпиляцией какогонить дебуг-кода – нормалды, вторые что такое сборка проекта воообще не знают обычно.

Я бы тут скорее смотрел на то, как константы названы. Если чёнить типа F1_OK или ONOFF – сразу убивать )