Здравствуй, дорогой дневничок.
Есть одна популярная цитата: “кто владеет информацией, тот владеет миром”. Она же “знания - сила”. Чудесная и совершенно корректная фраза, которая только не учитывает одного момента: фрагментарность собственного знания о информации, которой владеешь, которая и делает ее в той или иной степени ценной. Потому что можно знать многое, но совершенно не обладать способностью видеть некорректность собственной интерпретации знания об этом. Не понимать того, что имеющееся знание является не тем, чем кажется.
Это, кстати, лежит в основе эффекта Даннинга-Крюгера, когда дилетанты принимают поспешные позитивные решения о сложности той или иной задачи, некорректно интерпретируя свойства тех или иных системных элементов, ее составляющих. В то время, как специалисты видят множество элементов всей системы, и понимают многомерность структуры и свойства связей и обобщений, позволяя тем самым иным образом ставить формулировки о том, что перед ним находится и как оно должно работать.
Грубо говоря, можно решать задачу о том, как красиво будет выглядеть автомобиль, и какими финтифлюшками будет увешан, или решать задачу, как эта красота будет вести себя на дороге, масштабироваться в производстве и быть заменяемой при ремонте или апгрейде.
В случае разработки ИТ-систем это особенно важно, потому что от того, как именно будет пониматься смысловая часть тех или иных фрагментов данных, они будут храниться, связываться друг с другом и комбинироваться. А следовательно, как эти данные будут храниться, в каких моделях и таблицах будут представлены, и какие статистические данные и закономерности из них можно будет получить. А также, как они смогут быть представлены на интерфейсах и показаны пользователю.
Таким образом структуры данных и дизайн непрерывно связаны между собой, и то, что именно расценивается как “приоритетное направление” определяет сложность и перспективность разработки. А следовательно, определяет количество ресурсов, требуемых на ее поддержку и адаптацию.
Хорошая ИТ-система всегда содержит недостаточное количество сущностей, таким образом, чтобы в ней оставалось место “добавить еще”. Плохая характерна избытком лишних и повторяющихся значений, которые надо менять одновременно во всех местах в случае каких-то адаптаций.
В моей практике самым частой причиной конфликта с заказчиком при разработке того или иного продукта было обсуждение контекста того, как именно должен использоваться тот или иной смысловой контекст данных, чтобы он корректно заработал в системе, и был максимально полезен. И главной моей задачей было не столько найти хорошее решение (я его как правило знал изначально), сколько доказать своему собеседнику то, что его точка зрения неверна, и его авторитет в данном случае никак не повлияет на мое мнение. Будучи специалистом, я точно знаю, как оно должно быть устроено, и как должно называться.
При этом моя формулировка никак не противоречила здравому смыслу, но являлась не тем, что хотел видеть в системе заказчик, и как он это хотел внедрить. Однако то ли чувство собственной важности или уверенности в своей компетенции, то ли что-то другое всегда становилось причиной, по которой происходил примерно такой диалог:
- Будем делать вот так!
- Нет, не будем.
- Почему?
- Потому что такое решение - неправильное. Оно должно быть организовано не так.
- А как?
- Вот так, так и так. Это на самом деле является одним и тем же с этим, просто имеет другой формальный признак. Поэтому его лучше показывать не здесь, а вот здесь, так как оно является по сути тем же самым.
- Нет, оно должно находиться здесь и называться так.
- Зачем?
- Так удобно и понятно.
- Воткнуть туда это можно, но логика применения должна быть другой.
- Нет, должна быть такой.
- Тогда ничего не получится.
- Надо сделать.
- Я не буду. Это неправильно, глупо, отнимет время и не будет расширяться. Вслед за этим скорее всего появятся вот такие и такие требования, которые не смогут быть применены к данному контексту. А если сделаем как я говорю, то мы сможем затем расширить функциональность ко всему множеству типовых значений.
- Это сейчас не надо. Сейчас надо сделать быстро вот так.
Дальше в зависимости от ситуации, я либо отказывался, либо соглашался за нужный мне прайс, либо, что бывало чаще всего, заказчик оказывался не таким глупым, каким казался, и в итоге давал общую формулировку идентичную моей, но подавал ее так, как будто сам к ней пришел.
Самые умные заказчики никогда со мной не спорили, и с первого раза получали нужный им продукт. А многие из тех, кто так или иначе разрывал партнерство со мной, через какое-то время возвращались с предложением нового контракта, чаще всего с моим же кодом, потому что никто из других программистов, которые с ним работали, не мог придумать корректное решение для стоящей задачи.
И самое главное, не решалась не потому, что мой код был плох и стоящая задача в него не влезала и для внедрения требовала глубинного рефакторинга и замены архитектуры. Все решалось, и где-то даже уже были нужные заготовки. Просто те, кто на нее смотрел, не могли понять, как это сделать. А когда я заглядывал в те правки, которые успели за время моего отсутствия внести в код, в голове возникала одна и та же мысль, самым гуманным образом звучащая как “дилетанты!”. Как правило, выражалась она вслух и матом.
В этом смысле самый геморрой всегда начинается с момента времени, когда заказчик обязательно хочет вписаться в некий красивый дизайн, начисто исключая из своего внимания то, что он видит перед собой в первую очередь не красивую картинку, а информацию о расположении определенных данных, которые надо особым образом хранить и предоставлять пользователю. И когда переделка дизайна начисто исключается, потому что “уже уплачено/нет времени/там все правильно сделано, ничего менять не надо”.
Агр-р-р! Ярость берсерка ничто по сравнению с тем чувством, которое накрывает меня в такие моменты. При этом до последнего момента считал, что они уже начисто исчезли из моей жизни, и моя репутация и квалификация уже являются достаточным основанием для того, чтобы верить мне на слово. Но нет, история ходит по кругу, и такое случается снова и снова. И хвала небесам, что я имею возможность делать выбор, и уходить из такого аттракциона, даже несмотря на возможные финансовые потери.
При этом с моей точки зрения всё, что происходит - это мое публичное выражение несогласия делать так, как я считаю неправильным, и буквальное приглашение к передаче мне всей ответственности за принятое решение, за которое, если вдруг оно не заработает, отвечать придется мне же, и мне же придется переделывать на “правильное”.
Фактически, я позволяю тем самым сказать в мой адрес справедливое обвинительное “я же говорил, что надо не так!”. Лучшая из форм наказания за проявленную инициативу: приговор к исполнению. А я совершаю самый гуманный на свете акт: заранее снимаю с заказчика вину за то, что он окажется в итоге неправ, и надо будет переделывать так, как я изначально и говорил, а он потом не будет выглядеть глупо, когда все упрется в ограничения, о которых я изначально предупреждал.
А меж тем, ментальные искажения, которые не позволяют людям увидеть те закономерности данных, которые как специалист и эксперт вижу я, присутствуют не только в контексте совместной работы со мной. Это остается с ними и после того, как я прекращаю свое наблюдение через взаимодействие. И они живут и продолжают так жить, твердо и точно веруя в то, что их точка зрения должна оставаться такой, какой была, и в этом их сила.
Но самое смешное здесь не столько в том, что кто-то думает об этом неправильно, или использует некорректную смысловую базу или искажается смысл термина. Весь конфликт строится чаще всего вокруг способа упаковки этих данных. Что в контексте действий, которые требуется выполнить в первую очередь мне, создав тот или иной программный код, сводится к тому или иному количеству справочников в системе, и поддержке целостности данных, которыми они связаны.
Грубо говоря, одну и ту же задачу можно решить либо создав несколько отдельных моделей или таблиц, либо создав компактный, опирающийся сам на себя справочник, записи которого будут характеризовать все множество общих признаков, которыми эти данные и являются.
Например, на кейсе одного и проектов, в котором я сейчас пишу код, задачу о типировании пользователя по расе, нации, социальной группе или особым статусам можно делать как за счет создания таблиц данных `races`, `groups`, `nations`, `achievements`, в которых будут +/- повторяющиеся свойства `name`, `description`, `image` и так далее, так и за счет общего справочника `attributes`, среди свойств которых будет некий `type`, означающий как раз принадлежность этого значения к тому или иному контексту.
При этом, показателем хорошего разработчика будет как раз-таки способность принимать корректные решения, чем будет тот или иной элемент данных в системе, и уметь “выжимать” из заказчика информацию о будущих применениях этих данных, чтобы не осталось “слепых зон”, и какие-то общие структуры были объединены заранее, и не нуждались в будущем рефакторинге и удалении ставших внезапно ненужными признаки `race_id`, `group_id` и так далее.
Хотя, как правило, проекты так или иначе эволюционно приходят к тому, чтобы переиначить те или иные смысловые элементы, и удалить ненужное, чтобы оставить только главное.
При этом, что характерно, то, как что-то из реального мира видится в первую очередь как проявление каких-то данных, которые надо хранить в качестве информационных структур, позволяет и делать выводы о том, что или кого перед собой я вижу. И как следствие, по речи собеседника определять степень отклонения от “оптимального” с моей точки зрения взгляда на приоритетность того или иного фактора в окружающей реальности для того, чтобы решить стоящую задачу.
Интересный, должен сказать, навык. Многое объясняет. Хотя кто-то называет его высокомерием, когда я имею смелость утверждать, что “только я точно знаю как надо, а другие не знают”. Собственно, именно поэтому я не часто выражаю свою точку зрения вслух относительно всего того, что я вижу и с чем сталкиваюсь. Себе дороже указывать кому-то без нужды, как правильно, а как нет.
Там же-ж, как обычно, снова неправильно поймут, а если самому после этого не делать предложенное, то без меня сделают неправильно, и меня же будут обвинять в том, что я неправильно что-то предложил, и меня послушали, а у них потом не получилось. На кой оно мне надо?
Вот и приходится, с умным видом делать глупое лицо там, где со всей силы тянут одеяло на себя, чтобы с какой-то скрытой от самих себя целью возложить потом ответственность за неудачу на тех, кто не смог решить изначально неправильно поставленную задачу. Сделав в итоге дураками других, а себя в собственных глазах выставить как непонятого гения, которого окружают посредственности, неспособные к самостоятельности в исправлении чужих недостатков.
А я, отказываясь их решать, весь праздник порчу.
Вот таков масштаб проблемы. И это не только в локальных стартапах. Это ведь повсеместно, и имя нам - Легион.
Вот так, дорогой дневничок, и живем, при возможности не привлекая внимания санитаров.