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

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

Напишите код.
Протестируйте код.
Ошибка в коде?
Промойте и повторите.

Вы здесь именно для этого, не так ли? Если продукт отражает потребности и обычаи в текущей области, это не ваше дело. Боже, помоги тем, кто бросает вызов различным божествам в предпринимательстве. Были темные времена.

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

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

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

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

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

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

Есть так много, чтобы сказать по этой теме, и так много еще предстоит в эту эпоху. Роль инженера-программиста меняется, и мы тоже. Старая картина мира будет неуклонно исчезать. Для тех, кто любит и понимает семантическое управление версиями, я должен сказать, что нам еще предстоит увидеть, как будет выглядеть Developer 2.0.0.