Многия знания - многия печали

Учиться, учиться и еще раз учиться” - так, по легендам ЦК КПСС, вещал товарищ Ульянов-Ленин с броневичков и в прочих своих сочинениях. Ну и потом случилось обязательное среднее образование для всех, ликбез, ПТУ, ВУЗы и университеты. В которых, по задумке, жаждущие знаний учащиеся должны усиленно грызть наногранит науки и постигать теорию относительности бабла в природе.

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

Ойти, и программирование в частности - это некая форма индустрии, согласно Большой Советской Энциклопедии. Ну как в начале прошлого века была индустриализация всего, так теперь есть айтипиздезация всего. Во всяком случае, определенные признаки, как-то - производство, обслуживание и продажа неких “благ” в виде программного обеспечения, либо же услуг по поддержке этого самого программного обеспечения (а лучше все вместе) - присутствуют в полном объеме.

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

Итак, если воспользоваться аналогиями, то в целом иерархия в замкнутой системе - это

  • менеджмент/тимлиды
  • архитекторы/сеньорные жабодевелоперы
  • программисты

Проводя параллели с производством железяк - получаем соответствия (иллюстративно)

  • мастер цеха/начальник участка
  • ИТР (инженеры-технологи и инженеры-конструкторы)
  • рабочие (разной квалификации)

Рассматривая производственную систему, можно провести четкую границу между инженерами и рабочими. В частности, инженеры должны знать предметную область, которая заключается в основных законах, формулах, теоремах и прочих нормах ЕСКД. Инженер должен также понимать принцип работы всех станков, которые есть на участке, но детальное знание всех винтиков и шпунтиков (и какая кнопка за что отвечает) - желательно, но не требуется. Потому как есть рабочие, для которых знание (и умение) работы со станком - это суть, писечька и мякотка собственно работы.

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

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

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

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

Тут же можно провести и такие аналогии

  • инженеры-конструкторы - это собственно программисты, которые создают новые языки, пишут библиотеки и прочие фреймворки
  • инженеры-технологи - это программисты, которые применяют эти инструменты для создания прикладных приложений
  • рабочие - это штат кодеров, которые выдается ТЗ и ожидается получение какого-то кода.

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

Я здесь специально не упомянул станки с ЧПУ и прочие 3Д-принтеры, потому как это скорее переходной этап между ойти и материальным производством, который в следующие лет 5-10 изменит мир.

Вернувшись к аналогям, становится ясно, что нельзя правила, выработанные десятилетиями производства ночных горшков, натягивать на программирование вообще. В частности, программисту категорически нельзя останавливаться на достингутом уровне познания, потому что ввиду относительной доступности средств производства - его знания и умения устареют крайне быстро. Но это если речь идет про инженера, который должен знать и уметь разрабатывать программные комплексы с учетом меняющихся требований окружающей среды. Если же речь идет про кодера - а в аналогии с материальным производством это будет рабочий - то его задача - знать свой станок, его особенности и все, что с ним можно сделать. Причем чем лучше человек знает используемый тул - тем выше его разряд как кодера. Здесь возникает парадокс найма, когда при приеме на работу программиста в качестве инженера - начинают задавать вопросы по поводу деталей конкретной реализации иерархии исключений в Java. С точки зрения программиста - это относительно бессмысленное знание. С точки зрения кодера - это краеугольный камень всего. Подавляющее большинство технических собеседований - это именно проверка вот этих вот знаний и умений, скажем из 10 вопросов 9 скорее всего будут только про инструментарий. Соответственно, классический ойти-пролетарий в виде среднего пхпвебпрограммиста - вполне может существовать и даже как-то процветать, используя технологии прошлого десятилетия (или даже века).

Объяснение этому факту простое - на любой товар есть свой покупатель, вопрос лишь в цене. Для определенных видов деятельности - как-то жабодепелопмент в инвестбанке - вполне бывает достаточно знать три шаблона проектирования, ACID и уровни изоляции плюс SOAP - чтобы уверенно перемешивать говно половником решать повседневные задачи редактирования CSV файлов и XML конфигов Hibernate. Более того, новые знания - что можно и без всего этого - они эмоционально вредны, потому как порождают сначала желание что-то поменять, а затем разочарование от того, что никто ничего менять не разрешит.

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

Это относится в равной мере и к так называемым архитекторам, под которыми обычно подразумевают рисователей UML в Rational Rose. Все эти красивые картинки остаются всего лишь красивыми картинками, и не дают ни малейшего представления о поведении и проблемах системы на реальном железе в реальных задачах. И порисовав эти картинки в течение полугода - есть крайне большой риск оказаться позади коллег, которые уже вовсю коммутируют монады, а эти ваши UML уже давно не имеют ни малейшего отношения к системе. Вам просто об этом не говорят.

Сейчас стыдно и позорно не знать чего-то и оправдывать это незнание “меня этому не учили”. В конце 90-х мы ксерили и переписывали редкую околокомпьютерную литературу. А сейчас всем доступна совершенно бесплатно, то есть даром - целая Coursera, где есть практически все.

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