У новому випуску подкасту The Pragmatic Engineer творець Ruby on Rails Девід Хайнемайєр Ханссон (DHH) ділиться доволі провокаційною тезою: індустрія вже пройшла «пік програмістів». Та замість апокаліптичних прогнозів про кінець професії він описує більш тонку трансформацію — зміну попиту на навички та ролі в розробці.
Менше «класичних» програмістів, але не менше роботи
Ханссон припускає, що кількість традиційно підготовлених розробників — тих, хто роками вчився в університетах або витрачав тисячі годин на відточування навичок програмування, — може вже не зростати так, як раніше. Причина — різке зростання продуктивності завдяки інструментам, включно з новими технологіями автоматизації.
Йдеться не про те, що програмісти більше не потрібні, а про те, що:
- для того самого обсягу роботи знадобиться менше людей;
- зростатиме тиск на вартість праці там, де розробка сприймається як витрата, а не як джерело зростання.
Компанії, які мають «нескінченний» простір для нових фіч і продуктів, можуть просто вкладати зекономлену продуктивність у «робити більше». Але є й інший великий сегмент — бізнеси, яким потрібно «просто зробити одну конкретну річ».
Коли розробка — витрата, а не інвестиція
Особливо відчутними зміни будуть у компаніях, де розробка — це cost center, тобто витратний підрозділ. За оцінкою Ханссона, саме так працює, ймовірно, більшість розробки у світі: програмісти потрібні для підтримки бізнес-процесів, а не для створення нового продукту як основи бізнесу.
У таких організаціях:
- завдання часто чітко окреслені й обмежені;
- головна мета — зробити те саме дешевше, а не вигадати щось радикально нове;
- якщо з’являється можливість виконати роботу «вдесятеро дешевше», це стає конкурентною перевагою.
У цьому контексті зростання продуктивності розробників неминуче призводить до питання: навіщо тримати стільки людей, якщо менша команда може зробити той самий обсяг?
Новий дефіцит: не код, а рішення «що і як будувати»
На тлі цих змін зростає цінність іншого типу роботи — не стільки написання коду, скільки визначення напряму: що саме варто будувати, як це має працювати, для кого це робиться і де зосередити зусилля.
Ханссон описує це як зміну «вузького місця» в розробці:
- не «як швидко ми можемо написати код»,
- а «наскільки правильно ми обираємо, що взагалі писати».
Ключові питання, які виходять на перший план:
- Що ми маємо будувати?
- Як це має бути побудовано?
- З якими клієнтами варто говорити?
- На яких проблемах фокусуватися?
Це зона відповідальності, яку зазвичай описують як продуктовий менеджмент. І показово, що сам Ханссон визнає: історично він не мав високої думки про цю функцію, але нині саме вона стає критично важливою.
Що це означає для кар’єри розробників
Якщо «пік програмістів» уже позаду, це не означає, що варто тікати з професії. Радше йдеться про зміну профілю затребуваних навичок:
- чисте програмування як ремесло стає більш продуктивним і, відповідно, дешевшим;
- уміння поєднувати технічну експертизу з продуктовим мисленням — дорожчає;
- розуміння бізнес-контексту, клієнтів і пріоритетів стає не менш важливим, ніж знання фреймворків.
У компаніях, де розробка — ключ до зростання, це відкриває шлях до ролей, які поєднують інженерію та продукт. У тих, де розробка — витрата, тиск на ставки й кількість позицій може посилюватися, особливо для вузько технічних ролей без бізнес-контексту.
Джерело
The Pragmatic Engineer Podcast — DHH: “We’ve seen peak programmer”