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

[ermouth]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comments

[morfizm.livejournal.com]

Я сейчас сильно занят, просто хотел отметиться, что я через пару дней вернусь и буду развёрнуто возражать! :)

[xenos popandopulos (from livejournal.com)]

Кейс: сделать форму логина в веб-приложение.

Проджект-менеджер (ПМ) согласовывает вопрос с заказчиком и далее выдает его дизайнеру в виде: "нужна страница логина с формой, логин, пароль, все стандартно".

Дизайнер, не грузясь, рисует страницу и форму с полями логина, пароля и кнопкой "Войти". Проявляет свое "чувство прекрасного" и добавляет в поле логина плейсхолдер, а поле пароля помечает звездочками. И передает макет программисту.

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

Чуть менее опытный программист, прокрутив все потенциальные геморрои в уме (сделаю по-своему, а вдруг потом переделывать придется, а платят мне сдельно...), просто реализует форму и отметит таску как выполненную.

Вся беда в том, что точно так же поступит и программист-пустышка, который работает "от забора и до обеда". Выполнит таску, ни о чем не задумываясь. А впоследствии огребет от ПМ: почему нет галочки "запомнить меня"? почему нельзя восстановить пароль? где твое чувство прекрасного?!

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

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

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

Программисты не дизайнеры.

Если используемый фреймворк позволяет, то они с удовольствием добавят всякие ништяки, заранее не оговоренные в ТЗ, к любой форме. Хороший программист - ленивый программист, он добавляет ништяки в фреймворк так, чтобы они были из коробки. Если только дизайн-ориентированный ПМ не представит такой список взаимоисключающих характеристик к каждой форме, что унифицировать его станет невозможно. Этим страдают и ПМ, и рядовые дизайнеры тоже. Программист, ни разу не слышавший об унификации UX, интуитивно понимает, что выебоны идут во вред юзабилити, а пользователей лучше натаскивать на стандартизированный интерфейс, как мартышек.

Пример - посмотрите на Мегаплан, что программеры, вдогонку нагруженные версткой, сделали с оригинальным дизом от Лебедева :)

В общем, не все так однозначно. Если подобные недоразумения все же возникают, то чаще всего виноват оказывается сам ПМ.

[xenos popandopulos (from livejournal.com)]

Ок, допустим, у нас маленькая студия, состоящая из директора, он же ПМ, дизайнера, программера, вечно где-то проебывающегося верстальщика и симпатичной SMM-щицы.
Тут начинает проявляться своя специфика, а именно, никто из этих персонажей не имеет четких границ ответственности (ну, разве что начальство обязано вовремя выдавать зарплату, сцуко).
Когда прижимает дедлайн, все средства хороши: и программер доверстывает макет, и дизайнер пишет тексты для рыбы, и SMM-щица договаривается с заказчиком о встрече.
Пространства для отговорок становится гораздо меньше. Так что на самом деле микро-студии состоят из менеджеров: менеджера по заказчикам, менеджера по разработке и т.д., а значит,
им просто вменяется в обязанности справляться (manage) со всей херней более-менее самостоятельно.

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

[mark-y.livejournal.com]

В контексте этот отрывок ещё больше подходит, но так тоже вполне подходит.

Roark smiled. It was not a happy smile, it was not a grateful one. It was a simple, easy smile and it was amused.
"I don't think you understood me," said Roark. "What made you suppose that I want to come back?"
"Eh?"
"I won't be back. I have nothing further to learn here."
"I don't understand you," said the Dean stiffly.
"Is there any point in explaining? It's of no interest to you any longer."
"You will kindly explain yourself."
"If you wish. I want to be an architect, not an archeologist. I see no purpose in doing Renaissance villas. Why learn to design them, when I'll never build them?"
"My dear boy, the great style of the Renaissance is far from dead. Houses of that style are being erected every day."
"They are. And they will be. But not by me."
"Come, come, now, this is childish."
"I came here to learn about building. When I was given a project, its only value to me was to learn to solve it as I would solve a real one in the future. I did them the way I'll build them. I've learned all I could learn here--in the structural sciences of which you don't approve. One more year of drawing Italian post cards would give me nothing."
An hour ago the Dean had wished that this interview would proceed as calmly as possible. Now he wished that Roark would display some emotion; it seemed unnatural for him to be so quietly natural in the circumstances.
"Do you mean to tell me that you're thinking seriously of building that way, when and if you are an architect?"
"Yes."
"My dear fellow, who will let you?"
"That's not the point. The point is, who will stop me?"

[skorm.livejournal.com]

Согласен. Чувство прекрасного является признаком гармонично и многогранно развитой личности. Как человек выглядит, в плане той же самой одежды, так он и думает. Бытие тут в некотором смысле определяет сознание. Неряшливость в одежде часто есть признак неряшливости в мыслях. Более того, меняя свой внешний вид можно менять и ход своих мыслей. Недельно небритый, в грязных джинсах и мятой полудырявой футболке программер реально вызывает подозрения. И чаще всего они оправдываются. Вообще, недаром говорят "красивая архитектура", когда имеют в виду архитектуру софтверных продуктов.
Сейчас у меня есть возможность общаться с относительно большим количеством программистов, совершенно разных людей. И при этом еще есть возможность читать программный код, который пишут эти люди. Так что можно перефразировать - как человек выглядит, как и что он говорит, очень сильно влияет на то, как выглядит и его программный код и какая логика в нем содержится. Возможно, это некая профессиональная деформация у меня, но иногда я стал составлять мнение о человеке именно как о человеке только по чтению его кода. Например, я с осторожностью отношусь к людям, которые сами определяют static final константы, а потом используют сравнение этих констант в if/else для определения хода работы кода )
Ну а узкие крутые спецы чаще всего - всесторонне развитые личности, которые выбрали своей профессией только один конкретный вид деятельности. Обычно это люди сильно увлеченные. Некоторые, конечно, теряют эту увлеченность, когда вовремя не происходит левел апа.