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

Я подозреваю, что именно поэтому в наши дни люди всегда ищут «кодеров». Даже термины «дизайн» и «дизайнер» были заимствованы художниками-графиками и теперь обозначают людей, которые работают с функциями пользовательского интерфейса, а не с внутренним дизайном программного обеспечения. Кодировщики изучают чужую идею и «дизайн», а затем пишут код для ее реализации. Неважно, что это может потребовать некоторых навыков архитектуры и внутреннего дизайна… кажется, никто больше не заботится об этой части — предполагается, что это часть набора навыков каждого программиста. К сожалению, обычно это не так. Большинство программистов мыслят преимущественно левым полушарием, и такие люди, как правило, очень плохо справляются с абстракциями и визуализацией «больших картинок».

Таким образом, для большинства рабочих мест сегодня работодатели ищут людей, которые владеют ИНСТРУМЕНТАМИ, а не понимают лежащие в их основе принципы. Я предполагаю, что опыт работы с инструментами теперь служит заместителем некоторого рудиментарного понимания задействованных принципов.

Жизненный цикл разработки программного обеспечения (SDLC)

Практически каждое требование к так называемым «старшим» разработчикам (имеется в виду 5–10 лет опыта), которое я встречаю сегодня, говорит что-то о «имеет большой опыт работы со всем SDLC». (Эй, никто не рекламирует «старших», как 50+ лет или 20+ лет опыта!)

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

Обратите внимание на надпись внизу: «Процесс управления изменениями»? Это тот, который был вокруг навсегда. Многие компании предпочитают игнорировать это, мотивируя это тем, что «разработчики все равно этим занимаются». Так почему же для этого были выделены группы специалистов? Что ж, получается, что без большой автоматизации выделенные группы специалистов гораздо более эффективны и точны, чем случайная группа программистов, выполняющая те же задачи. Многие, если не большинство компаний, никогда не были готовы признать это. К счастью, на помощь пришла автоматизация.

Однако, как только задействуется автоматизация, вам понадобится команда разработчиков для управления инструментами, а не для выполнения работы. Что ж, по крайней мере, работа была снята с рук разработчиков и стала более последовательной!

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

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

Через некоторое время это стало называться «управление сборкой», «управление конфигурацией программного обеспечения», «управление сборкой и выпуском». Сегодня это называется «DevOps», сокращение от «Операции разработчиков».

Это все та же дисциплина, использующая те же методы для достижения тех же целей с помощью тех же инструментов. Используемые инструменты менялись каждые 5–7 лет.

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

Затем на какое-то время стали доминировать системы контроля версий (VCS), и вам нужно было иметь опыт работы с тем или иным конкретным инструментом, чтобы получить работу, даже несмотря на то, что все они делали одно и то же.

Сегодня используется еще больше различных инструментов, таких как повар и марионетка. И вместо того, чтобы знать конкретную VCS, вам нужен опыт работы с размещенной системой, такой как github. И поскольку они в основном с открытым исходным кодом, они используют несколько разных языков и механизмов вместо того, чтобы быть единой монолитной платформой, предоставляемой одним поставщиком (если вы не «чистый» магазин Microsoft).

Сегодня все дело в инструментах, а мы, «кодеры», всего лишь механики, создающие чужие вещи. В мире DevOps эти «материалы» определяются каким-либо ИТ-менеджером для обеспечения соблюдения корпоративных политик. Я мог бы прочесть импровизированную 6-часовую лекцию о принципах, лежащих в основе этого материала, и о лежащих в основе выборах, с которыми сталкивается организация с точки зрения того, как они могут управлять своими процессами. Но без нескольких лет практического опыта работы с конкретными инструментами, которые использует данная команда, у вас не будет работы.

Это странный побочный эффект от того, что мы проработали в этой области более 30 лет… это дает нам, «старшим разработчикам» с опытом работы в несколько десятков лет, истинное видение вещей с высоты птичьего полета, чего люди, имеющие всего один десяток лет, просто не видят. т есть. Я не могу сказать вам, что делают различные инструменты на этом рисунке конкретно; но я могу определить пару десятков конкретных задач, которые необходимо выполнить, в каком порядке и насколько сильно они зависят друг от друга. Вы можете подключить свой любимый инструмент к каждому слоту. Покажи мне инструмент; изучив его в течение нескольких минут, я могу сказать вам, какое место он занимает в спектре процессов SDLC/DevOps и большинство функций, которые он будет предоставлять.

У меня такой вопрос: когда мы начнем видеть вакансиях о том, что они ищут людей с 20+ годами опыта, а не только с 5-10? И когда компании начнут нанимать в качестве «наставников» людей, у которых опыт работы со всеми остальными как минимум на десять лет больше, чем всего на пару лет?