Почему быть программистом сегодня сложнее, чем 10-15 лет назад

Почему быть программистом стало сложнее, чем раньше?

На программерском форумце ДОУ недавно появилась очень показательная исповедь опытного программиста под заголовком «Ухудшение технологий программирования»:

«Уважаемые программисты, я хочу поделиться с вами подмеченной закономерностью развития ИТ. Я в ИТ уже более 14 лет, и заметил одну нехорошую особенность.

А именно: Наши технологии всё сложнее и сложнее! Освоить их при этом все труднее и труднее. И всё меньше времени остается на личную жизнь. Постоянное изучение этих гадостей плохо отражается на гормональном фоне рядового разработчика.

Я еще помню как писал на Джаве 1.4 и всё было прекрасно — ни тебе Hibernate дурного, ни прочей мути, и Struts простой до невозможности. Софтину разрабатывали по методологии Waterfall, никакого злобного и мучительного Скрама и в помине не было. Все было просто, лепо и понятно.

Проект собирали Мавеном, использовали простую многопоточность, а на фронте у нас был обычный document.getElementById. А сейчас — не успел я сборщик для веба Grunt освоить, так уже еще мильйон тулзовин вышел. Технологии успевают устареть до того, как их успевают выучить. Джава катится туда же, хотя на бекенде состояние получше. Мавен — чудесный же инструмент, всем хорош, но нет — хипстерам подавай демонический Гредл.

Я предлагаю разрабатывать проекты, опираясь на максимально простые и эффективные инструменты, для джавы — спринг, мавен, для фронта — jQuery.

DevOps технологии тоже ухудшились — раньше просто .war файл заливал в админ—консоли, на WebSphere какую—нибудь, а теперь подавай Docker, Kubernetes ужасный.

Как мы до этого докатились?»

Почему программировать сложнее, чем кажется Обаме

Программист, написавший сие признание, конечно прав
Можно сколько угодно съезжать на якобы типичные проблемы зрелых мужиков а-ля «раньше было лучше, и трава была зеленее», но это не отменит того факта, что раньше тебе нужно было знать намного меньше, чтобы зарабатывать столько же или немного меньше, чем сейчас. Нужно быть абсолютно слепым, чтоб не видеть то, как новые инструменты и технологии, при их кажущейся полезности и нацеленности на упрощение жизни разработчика, на самом деле всё усложняют. И нужно быть совсем уж юным (или темным), чтоб не помнить, как 10-15 лет назад, чтоб пройти на должность Junior Java Developer на 500-600$, достаточно было показать знания ООП и Java Core, да суметь связать два слова на английском. И всё — счастливый работодатель со светящимися глазами оформляет тебя в белую. О как он рад, что хоть кто-то хочет стать джуниор джава девелопером!

Только живущий в так называемом «манямирке», прикормившийся у IT-корыта и потому оборзевший и потерявший всякую связь с реальностью программист искренне считает, что он умнее современных «вайтишников», и что такого неподобства, когда джуны пашут по два года до «повышения», выполняя мидловые задачи (по факту сеньор-задачи уровня 2005-2006 года) — нет и в помине. Такие индивиды никогда не смогут признать тот факт, что им просто повезло, что раньше было проще. Кто-то может даже стыдится этого. Но что в этом такого? Пионеры-первооткрыватели всегда либо гибли первыми, либо первыми срывали золотой куш. Почему же в этом так сложно признаться?

В комментарии набежали хомячки, которые стали набрасываться на автора, мол «а раньше и бухгалтера на счетах работали, так что?». Однако не ведают ограниченные люди, что прогресс в любой области — нелинеен. Бывает так, что он банально зависит от времени, но бывают и времена застоя/деградации. Вполне возможно, что нечто подобное, мы наблюдаем сейчас в IT.

Как выглядит типичный ответ ботана, который верит в неумолимый прогресс:

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

На первый взгляд и не подкопаться. Однако если знать матчасть, то можно ответить так:

В 1900-м году придумали трактор, который проработал без особого ремонта 50 лет. В 1950 году его заменили новой моделью трактора, которая проработала 20 лет и была заменена на новый трактор, который проработал 10 лет, успешно был ушатан и чтобы не проводить капремонт — ушел на запчасти. В следующем месяце нам из Китая привезут новый трактор… ой погодите, пока его везли в контейнере, у него уже отвалилась фара, помялся бампер из фольги и глюканул бортовой компьютер.

15-20 лет назад, если нужно было решить задачу в коде, то решали ее в терминах «заюзать if for while». Сейчас то же самое решают в терминах «фреймворк 1, фреймворк 2, фабрика классов 3,4,5». При этом кричат это реюзабельность кода, но в итоге в 90% все эти нагромождения кода при первой же необходимости переписывается. В итоге код в проекте выглядит почти как в том меме, где десять менеджеров надзирают как один Вася с лопатой пашет.

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

В итоге ты стоишь перед выбором — либо ты как натренированная мартышка продолжаешь осваивать новые фреймворки и тулзовины по мере их появления, либо ты остаешься в удобном стеке технологий и живешь тем объемом знаний, который когда-то получил. В принципе, некоторые могут так существовать и их всё устраивает. Проблема лишь в том, что свежесть стека зачастую коррелирует с зарплатой. Если ты застрял в одной компании, освоил то, что там нужно, и в ус не дуешь, то во-первых — не жди существенного повышения зарплаты. Во-вторых, будь готов, что за бортом ты уже никому не интересен. Ведь пока ты спал, IT летело на всех парах и костылях вперед — в светлое будущее «айти-нации». А значит чтоб сменить работу, тебе таки придется освоить очередной набор непотребных мозгодробильных инструментов. Что ж, это IT, детка. Думали в сказку попали?

По мотивам DOU

  • Alex

    Потому и говорят, что программирование — для молодых. Я если и вижу в компаниях 40-50 летних разрабов и то, как их гоняют — не завидую им. К этому возрасту уже неплохо бы иметь другие источники дохода. А новыми фреймворками хай молодняк сушит мозг 🙂

    • Дядёк

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

  • Dunets Nickolay

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