На протяжении моего опыта работы программистом у меня уже сменилось три варианта представления о моей дисциплине.

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

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

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

Через некоторое (долгое) время после того, как я дольше стал заниматься данными, до меня дошло, что IT — это Information Technology (я не очень умный). И что программы манипулируют информацией. Информацией о человеческой деятельности. Например, вот обжарщики кофе, у них там свои процессы какие-то происходят — обжаривают кофе на разных температурах, закупают сырье, продают обжаренный кофе оптом и в розницу. И задача программиста — хорошо это дело смоделировать и зафиксировать у себя важные параметры процесса, чтобы потом кто-то мог посмотреть на прошлые записи или на какую-то общую картину в целом.

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

Это изменение парадигмы было стимулировано книжками: BORO и Domain-Driven Design. И размышлениями о бухгалтерском учете.

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

Этот подход трудно объяснить, не ругайтесь на меня, если я сейчас приведу непонятный пример. Часто есть системы, где есть разделение между пользователями и обслуживающим персоналом. Вот допустим вы можете писать тексты в телеге и вы тогда контролируете внешний вид вашего канала очень мало — только текст, при этом есть люди, которые это дело контролируют и думают о всех нас: и о читателях и о писателях (и о себе). А есть вариант использовать какой-нибудь генератор блогов, типа Hugo или Jekyll — там уже больше контроля, но пользователь должен быть IT-специалистом, чтобы этим нормально пользоваться. И читателей к тебе никто не приведет.

Эта парадигма применима к любому технологическому артефакту, не только к IT. Я ее напрямую позаимствовал из социологии техники и акторно-сетевой теории в частности.