Недавно писал, что IT-рынок не рухнул, а расслоился.
Деньги в нем по-прежнему есть. Сильные инженеры по-прежнему нужны. Но все хуже работает старая формула:
еще несколько лет опыта → следующий грейд → следующая вилка.
И чем выше уровень разработчика, тем это заметнее.
Еще 5 лет назад все было довольно ясно:
• Учишься лучше писать код.
• Разбираешься глубже в своем стеке.
• Берешь более сложные задачи.
• Начинаешь видеть проблемы раньше других.
Но сейчас особенно явно возникает неприятный вопрос:
```
а что именно должно стать следующим уровнем?
```
• Еще лучше знать Spring?
• Еще глубже JVM?
• Выучить очередной фреймворк?
• Стать быстрее писать код?
Проблема в том, что именно производство кода сейчас дешевеет быстрее всего.
Не в смысле "разработчики завтра не нужны".
А в гораздо более приземленном смысле: все больше работы, которая еще недавно отличала сильного разработчика от среднего, становится проще выполнить с помощью инструментов.
• Написать реализацию.
• Разобраться в чужом коде.
• Провести рефакторинг.
• Добавить тесты.
• Подготовить документацию.
• Найти несколько вариантов решения.
Порог входа во все это постепенно снижается.
А значит, само по себе умение хорошо производить код все сложнее использовать как единственный профессиональный дифференциатор.
И вот здесь интересно посмотреть на другую сторону рынка.
Чем выше ответственность человека, тем меньше его ценность определяется количеством написанного кода.
От него ждут другого.
• Увидеть проблему до того, как она превратилась в инцидент.
• Понять ограничения системы.
• Отделить симптом от причины.
• Предложить несколько вариантов решения и объяснить цену каждого.
• Принять решение в условиях неполной информации.
• Провести его через реализацию.
• Проверить, что оно действительно решило исходную проблему.
• Понять, как решение будет вести себя под нагрузкой и при отказах.
А потом сделать так, чтобы через год команда все еще понимала, почему система устроена именно так.
И здесь для меня соединяются два последних наблюдения.
С одной стороны, рынок все внимательнее смотрит на зону ответственности инженера, а не просто на количество лет в профессии.
С другой - то же самое происходит с архитектурой.
Я недавно писал, что архитектура для меня давно перестала быть набором правильно нарисованных компонентов и паттернов.
Но есть еще один шаг.
Мало уметь принять хорошее архитектурное решение. Нужно уметь провести его через весь жизненный цикл.
Условно:
проблема → ограничения → гипотеза → решение → реализация → проверка → эксплуатация → наблюдение → изменение.
Причем самое интересное часто начинается после слова "решение".
Потому что схема может выглядеть прекрасно, при этом:
• реализация покажет скрытую связанность.
• нагрузочные тесты - неверное предположение.
• ПРОД - неожиданный режим деградации.
Через полгода код уйдет вперед, а архитектурная документация останется описывать систему, которой больше не существует.
Постепенно меняется само определение сильного инженера.
Раньше большой частью профессионального капитала было:
"я знаю, как это реализовать".
Сейчас все больший вес получает:
"я понимаю, какую проблему мы решаем, могу выбрать решение, довести его до работающей системы и отвечать за последствия".
Это не обязательно роль архитектора или новый тайтл.
Наоборот, думаю, что эта граница будет все сильнее проходить внутри обычной инженерной работы.
Это не значит, что завтра всех заменит ИИ и "нужно срочно переучиваться".
Моя основная мысль:
можно еще несколько лет становиться лучше в той части профессии, ценность которой относительно других частей постепенно снижается.
При этом следующая ступень находится совсем рядом - просто она уже не столько про написание кода.
Она про способность отвечать за техническое решение целиком.
И мне кажется, что в ближайшие несколько лет разница между этими двумя траекториями станет намного заметнее, чем сейчас.
Какие мысли будут у сообщества?
