Странно, что, хотя я продаю большую часть своего времени в качестве старшего архитектора программного обеспечения, а также могу позволить себе покупку необходимого мне программного обеспечения, я все равно трачу много времени на программирование, написание кода. Двадцать пять лет назад люди чуть старше меня тогда часто говорили мне «я давно перестал писать код, ты, наверное, будешь таким же», но это оказалось совершенно неправдой. Дело даже не в том, что я делаю это только для хобби или личных проектов, я вношу некоторые практические разработки в большинство своих профессиональных занятий. Почему?

Рискуя неправильно процитировать Библию, ответ легион, ибо их много…

Чтобы получить функциональность, которую я хочу

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

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

Для изучения сложных проблем

Хотя я твердо верю в ценность анализа и моделирования, я признаю, что слова и диаграммы имеют свои пределы в случае наиболее сложных проблемных областей и могут быть принципиально трудными для формулирования и передачи для сложных и хаотических проблемных областей (с использованием все эти термины в их формальном смысле и в том, как они используются в структуре Cynefin, см. здесь).

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

Другой случай, когда я могу перейти к коду, — это когда динамическое поведение системы или процесса трудно смоделировать, и симуляция может быть подходящим способом его изучения. Это может быть просто реализация математической модели, например, симуляция Монте-Карло, но я также обнаружил, что строю динамические визуальные модели сложных взаимодействий.

Чтобы доказать мои идеи

Частью ценности, которую я приношу в профессиональные проекты, является опыт или знание ряда архитектурных решений, а также готовность использовать необычные подходы, если я считаю, что они хорошо подходят для решения задачи. Однако нет ничего необычного в том, что другие архитекторы или разработчики сопротивляются менее традиционным подходам или тем, которые находятся за пределами их зоны комфорта. В таких ситуациях модели и PowerPoint не могут продвинуться далеко вперед, а работающее доказательство концепции может быть очень убедительным инструментом. И наоборот, если я обнаружу, что это не так просто и не так эффективно, как я надеялся, то «доказать» приобретает свое прежнее значение слова «испытание», и, возможно, убедит меня. Я ученый по образованию, так что это тоже нормально.

Чтобы доказать или оценить технологию

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

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

Чтобы доказать, что я могу

Хотя я скептически отношусь к завышенным требованиям, я также подозрительно отношусь к тому, что я думаю, что что-то должно быть достижимо, а кто-то другой говорит «это невозможно». Многие проекты, как профессиональные, так и личные, начинались с утверждения, что «Х невозможно», и моего неверия в это. Я получаю огромное удовольствие от подчинения технологии своей воле. Цитируя известную грязную песню Deep Purple Knocking At Your Back Door, которая сама по себе является исследованием пределов возможностей (с цензурой), «это не убийство, это острые ощущения от погони».

В современном мире гибких процессов разработки роли архитектора и аналитика стираются с ролью «разработчика». Я всегда находился за этой границей, и подтверждение моих способностей к разработке может помочь мне завоевать доверие команд разработчиков, позволяя мне при необходимости работать на более низком уровне детализации. Моя способность программировать делает меня лучшим архитектором, в то время как знание архитектуры делает меня лучшим программистом.

Зарабатывать?

Это странно. Когда я изначально писал эту статью, в начале 2017 года, я начал этот раздел «возможно». Я объяснил, что, хотя я не против кодирования за деньги, большую часть времени « любая разработка, которую я делаю, является просто средством для достижения цели, которая является дизайном, доказательством концепции или измерением».

Затем я опубликовал статью, ее прочитал бывший коллега, он связался со мной и предоставил мне 6 месяцев практически чистой разработки в крупном банке. В то же время моя работа для другого клиента была в значительной степени сосредоточена на разработке.

Теперь я должен рассказать несколько другую историю…

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

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

С другой стороны, довольно многое из того, что я делаю, приносит мало денег или вообще не приносит их. Вещи, которые я создаю для своих собственных целей, обходятся мне недорого, но имеют значительные альтернативные издержки, если бы я мог использовать время по-другому, и я обычно покупаю коммерческое решение, если оно существует. Общий доход от разработки всех моих приложений и плагинов за эти годы составил несколько сотен фунтов, вероятно, меньше, чем я заплатил за соответствующие инструменты и компоненты. Эта работа — «хобби с пользой», а не источник дохода.

потому что мне это нравится

Это, пожалуй, суть дела: программирование — это то, чем я люблю заниматься. Это творческий акт, который переводит мой разум в состояние, которое мне нравится, когда я решаю проблемы, осваиваю технологии и создаю ценный артефакт из (обычно) чистого листа. Это хорошее умственное упражнение, и, как и любой навык, если вы хотите сохранить его, вы должны постоянно практиковаться. Задача состоит в том, чтобы делать это в нужных случаях и в нужное время, и помнить, что иногда я действительно должен делать что-то другое!