Мне нравится писать код, когда я полностью осознаю, зачем он существует.
Когда я пишу для себя, это может быть "научиться пользоваться новым инструментом", "поделиться имеющимися у меня знаниями", "создать проект для хобби" или даже "просто для удовольствия". Когда я пишу код на работе, это может быть "решить проблему пользователя" или "упростить какой-то процесс".
Знание того, зачем я пишу программу, позволяет мне не тратить время и силы впустую. Когда я создаю проект для хобби или пишу код для развлечения, я знаю, что могу тратить столько времени, сколько захочу, изучая различные инструменты и техники. Но в профессиональной среде я осознаю, что стоит стремиться к эффективности (как лучше всего решить эту проблему?).
Но программы сложны, и сложность может быть обманчивой. Для выполнения какой-либо задачи часто кажется, что существует бесконечное количество инструментов и методов, которые можно использовать, и бесконечное количество способов их сочетания. И работа над трудными, сложными задачами может казаться прогрессом, даже если это не так.
Это может быть одной из причин, если не главной, чрезмерной инженерии – создание сложного программного обеспечения само по себе может приносить удовлетворение. Ориентироваться в сложностях может быть приятно. Но если цель – решить проблему пользователя, то мультикластерная, распараллеленная, автомасштабируемая, квантовая архитектура – лишь один из способов, а может быть, и не единственный, достичь этой цели. Но не сама цель.
Во время проведения собеседований часто слышу, что многим приходилось работать в небольшой команде, где руководитель разделял кодовую базу на несколько микросервисов в стиле Netflix и Revolut. Все остальные члены команды могли считать, что с такой архитектурой неудобно работать, но не могли ее изменить. Не потому, что на переписывание ушло бы много времени и сил. А потому, что руководителю казалось, что сложность дизайна важнее его эффективности, ведь архитектура продуманна и красива.
История о Дениске Драгунского, который обменял свой подаренный отцом большой, красивый самосвал на невзрачного светлячка, невольно заставляет вернуться к настоящим приоритетам в процессе создания программного обеспечения. Маленький и скромный проект обладает большей ценностью в глазах конечного пользователя, если он живет и выполняет свою функцию – будь то приглушение скуки в ожидании матери или реализация планов заказчика.
Часто самые значимые идеи не требуют создания громоздких и запутанных систем. Они могут быть выражены через простые, но животворящие проекты, ориентированные на выполнение конкретной задачи и привносящие удовлетворение в процессе работы над ними.
Успех и волшебство программирования заключаются не в умиротворении чувства собственной важности архитектора, а в их способности решать задачи и светить, принося пользу тем, для кого они были созданы.
Мысль проста и очевидна для многих, но все еще так часто забываема на практике; оставлена в качестве напоминания, что нам не стоит влюбляться в свою технологию. Напоминание, в том числе и себе.