Найти тему

А КАКОЕ САМОЕ ГЛАВНОЕ СВОЙСТВО В ПРОГРАММИСТЕ?

Воображение - даю мгновенный ответ, так как думал об этом раньше... (из разговора пятилетней давности).
Как было дело?
А что самое важное для программиста? Логика? - надо мной навис менеджер по продажам, только вернувшийся "с полей", со спины рассматривая экран компьютера, уткнувшись в который, стучу по клавиатуре..
Уже задавал себе подобный вопрос и выдаю рефлекторно, не отрываясь от монитора: "
Воображение!".
Продажник, явно ожидая другое, напряженно умолк, осмысливая и пытаясь понять, говорю с подвохом или всерьёз?

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

Так думал несколько лет назад. Даже натренировывал себя, вычерчивая объёмные блок-схемы, чтобы "перед внутренним взором" удерживать особо громоздкие конструкции.
Сейчас бы ответил по другому... Но одним словом уже не получится 😊

Говоря про программистов сегодня, бывает упускается, что зачастую речь идёт о разных специальностях:

  1. программистах-эксплутационщиках (специализация - на особенностях функционирования того-иного готового софта), их задачи: внедрение, консультации-обучение, профилактика, мелкий ремонт и настройка; несут ответственность за работоспособность софта, готовность софта к работе;
  2. программистах-кодерах, чьё главное знание - знание языков и приёмов программирования, берущихся по готовому ТЗ, или по готовому шаблону, создать работающий код небольшой программы;
  3. программистах-разработчиках, чьё главное знание - знание операций на предприятии/отрасли, знание когда и в каком виде нужные данные необходимо предоставить;
  4. программистах-проектировщиках, знающих о природе данных, существующих в отрасли, их движении и их взаимосвязи между собой.
  5. межотраслевых инженерах, решающих вопросы взаимодействия данных между несколькими отраслями, собственно - это переход на другую ступеньку, где оперируют концептами, идеологиями, принципами. смыслами и другими "абстракциями"...

Было время жарких баталий - "какой язык программирования самый лучший, тот или этот?".

Все равно, что вести спор: какой язык лучше для написания стихов - персидский или португальский?
Ответ: хорош тот, которым лучше владеешь, на котором быстрее воплотить свой замысел.
Можно говорить о распространенности языков программирования, о рыночных предпочтениях, о моде.. и только об этом. По возможностям языки программирования стали одинаковы. Ну да, освоение заложенных возможностей языка приходится натренировывать, но знания только языков программирования для программиста становится уже маловато.

Знание алгоритмов?

Было время, когда исходными были простые данные (хоть и в больших количествах), при этом обрабатываемые архи-сложными алгоритмами... То время ушло, сегодня в обиходе простые алгоритмы над архи-сложно-структурированными данными (по прежнему - в больших количествах).


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

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


В последний год в инфополе много разговоров об искусственном интелекте (ИИ). Часть разговоров - про замену труда программистов.

Если взглянуть на уровни программистов, перечисленных выше, то ожидания, что ИИ заменит людей, распространяются на уровень 2) и 3), те, где меньше привязки к физическому миру, где возможно давать и воплощать "виртуальные" рецепты.

И программисты уровней 2) и 3) будут вынуждены сдвигаться либо на уровень 1), т.е. следить за нюансами новых версии софта, либо на уровень 4), начинать разбираться в деятельности фирмы/предприятия/отрасли.

Туда, где требуются большая адаптивность к конкретным контекстам, к индивидуальным особенностям среды. Здесь вряд ли можно говорить про замену машиной людей, но можно рассчитывать на машину как инструмент, справочно-рекомендательную систему, как подспорье.
И парадокс уровней 4) и 5) в том, что чем более "творчески" и менее прямолинейно человек будет полагаться на указания ИИ (которые будут генерироваться для всех "наилучшими", т.е. более-менее одинаковыми), тем более индивидуальной будет созданная человеко-машинная система, более конкурентной (эффективной) станет фирма, в которой он трудится. Кроме того, в задачах посложнее часто важно не ЧТО следует сделать (пример: "стать счастливым", для понимания чего и ИИ не нужен), а КАК это сделать? И тут вариантов - целая Вселенная, постижение которой для ИИ недосягаемо, а некоторые люди справляются...

И откуда набраться отраслевых знаний?
Конечно, есть общая теория "как учиться".
Есть подход DDD (domain-driven design), т.н. предметно-ориентированное проектирование, с которым знаком понаслышке, этот подход популярен на Западе.

В затылок ему дышит другой подход:
Системная инженерия, очередное поколение которой, на том же Западе, набирает популярность, да и в РФ системная инженерия, возникшая на базе т.н. "системного мышления", уже обзавелась историей. Этот подход мне ближе, но сейчас не о нем...

И есть т.н. "
кейс-менеджмент", по сути - ситуационный подход, накапливающий успешные решения в различных ситуациях.
Откуда же берутся успешные решения?
Ну только через метод проб и ошибок (как собственных, так и через мониторинг чужих) при реализации задач, циркулирующих в своей отрасли. Благодаря чему и возникает "опыт".

Возвращаясь к вопросу, из-за которого возник этот пост:
какие свойства являются главными (и останутся таковыми в будущем) для программиста?

  • понимание, а как происходят процессы на предприятии (в отрасли), где работаешь?
  • понимание того, а что на предприятии (в отрасли) меняется? что угасает, что нарождается?
  • понимание того, а что меняется в самой инженерии?

Да, и извините за банальность, эти понимания устаревают, "опыт" обесценивается и его стоит освежать.

В завершение хочу обратить внимание, что знания для разной квалификации программистов меняются с различной скоростью.
Д
ля уровня 1) версии софта могут меняться несколько раз в год; для 2) версии языка - раз в год-два; для 3) способы разработки - раз в 2-3 года; для 4) изменения в предметной отрасли - раз в 3-5 лет, а 5) концепции и взаимодействия между отраслями меняются раз в 5-10 лет. Т.е. "карабканье" вверх, наращивание квалификации можно рассматривать как способ защититься от девальвации собственных умений+пониманий (или, как стало принято их называть - компетенций).

Видите в этом какой-то смысл?

P. S.
Кажется, что сказанное относится не только к программистам, но и к любому инженеру.

P. P. S. Для себя определил сферой деятельности ритейл (включая всю цепь: производство, логистику, поставщиков, розницу, интернет-магазины и маркетинг), и ранее
написал почему...
___
Было ранее по теме:
ПРО ПОИСК ПОДХОДЯЩИХ СОТРУДНИКОВ.
___