Эволюция сеньоров

В прошлой статье затронута тема требований к сеньору, выдвигавшихся в разные годы. Но, на мой взгляд, тема не раскрыта, а объяснение происходящего «пузырем цифровизации» — неполное. Попробую дать свое понимание эволюции сеньоров.

Сеньор, с точки зрения бизнеса, это тот, кто в состоянии самостоятельно решать поставленные перед ним задачи в IT:

Бойцовый Кот есть боевая единица сама в себе… способная справиться с любой мыслимой и немыслимой неожиданностью.

— "Парень из преисподней", братья Стругацкие

Исходя из этого, требования и определялись к его знаниям, навыкам и опыту.

Эпоха глубины (конец 90-х – "нулевые")

В конце прошлого века и первом десятилетии нынешнего найти нужную информацию в сети было крайне сложно. Главным источником информации были книги (но они иногда запаздывали по отношению к технологиям), документация (которую в доинтернетную эпоху еще требовалось искать) и исходники программ. Если возникали сложности — нельзя было просто «загуглить». Надо было понимать, как и что устроено «под капотом». Причем, чем лучше человек знал «кишки» технологий, тем быстрее он мог докопаться до истоков проблемы. Отсюда — ценность опыта (человек уже набил шишки, разобрался и будет работать быстрее) и ценность глубокого понимания того, как все устроено. Плюс — «коробочные» решения были далеко не коробочными. Даже поставляемые библиотеки порой приходилось собирать самому, настраивать сервера и т.д.

Эпоха Google и демократизации (конец "нулевых" – "десятые")

Постепенно, к концу 00-х – в 10-х картина менялась. Интернет наполнялся знаниями, накопленный сеньорами опыт оседал на страницах StackOverFlow — и все чаще для решения проблемы достаточно было просто погуглить. Конечно, для того чтобы погуглить, надо было понимать, что гуглить, и иметь представление об используемой технологии. Но тут как раз появилось множество видеокурсов самого разного уровня по всем возможным технологиям, которые разжевывали и клали в рот суть. Далеко не все курсы были полезными, но лучшие из них точно заменяли многие часы над документацией. Плюс — «коробочные решения» и настройки становились проще.

Освоение технологий до уровня, когда с ней можно работать, ускорилось в несколько раз.

• Тогда ("нулевые"): чтение 2-х книг («... для чайников», «... для профессионалов») – 40 часов; параллельный кодинг – 40 часов; чтение документации – 20 часов; реальный опыт работы с параллельным заглядыванием в доки – 100 часов. Итого: ~200 часов.

• Теперь ("десятые"): курс – 5 часов; пробежать глазами книгу («... in Action») – 5 часов; немного поиграться с кодом, параллельно загугливая на StackOverFlow ошибки – 20 часов. Итого: 30-50 часов.

Если раньше «путь к сеньорству» занимал лет 10, то теперь освоение необходимых технологий (при наличии мозга и упорства) сократилось лет до трех. И, что интересно, «тридцатилетние сеньоры», вооруженные гуглом, часто на самом деле справлялись с задачами быстрее. Айти стало сферой, где всего за несколько лет можно было стать «профессионалом» и начать писать промышленный код, неплохо на этом зарабатывая. Тем более что рынок вмещал всех — до поры до времени. Это стало одним из поводов массового желания «войти в айти» — ведь путь до «сеньора» стал таким коротким: не надо читать тонны мануалов, достаточно пройти курсы и уметь гуглить.

Разумеется, с точки зрения «настоящих сеньоров» молодые были самозванцами (ведь они же не могли, не гугля, ответить, чем ConcurrentHashMap лучше SynchronizedMap). И, пользуясь тем, что в силу возраста занимали более высокие должности, «старики» взялись топить молодых на собесах, спрашивая про тонкости технологий. Что с точки зрения старшего поколения было к тому же оправданно — в их картине мира сеньор обязан знать все тонкости! Молодежь, впрочем, достаточно быстро освоилась — появились курсы и статьи «топ 100 вопросов на собеседовании» — выжимка того, что спрашивают на собесах «гуру технологий». При должном умении работать с информацией и определенном упорстве «100 вопросов» прорабатывались за пару недель — месяц, и «молодой сеньор» становился готовым к интервью. Это вызвало «войну брони и снаряда» — вопросы становились все более сложными и оторванными от реальности, а «молодежь» училась узнавать вопросы собеседования заранее.

Эпоха ИИ и изобилия кода ("двадцатые" годы)

Тренд "десятых" продолжился и в "двадцатых" годах. Накопленный в Сети опыт сеньоров перекочевал в Copilot и GigaChat, еще больше упростив поиск ответов. А коробочные решения стали действительно коробочными — достаточно создать пустой проект и включить в него зависимости (что делается в несколько кликов мышью) — и вы получаете готовый к сборке проект, в котором уже есть готовые и сконфигурированные объекты. Остается только брать и писать логику. А как писать — подскажет ИИ. Теперь человек со средними навыками и минимальным опытом часто решает чисто технические проблемы лучше, чем с ними справлялся гуру десять лет назад.

Людей, умеющих писать рабочий код и быстро найти ответ на вопрос «как заинжектить prototype в singleton», — стало много. Сеньоры перестали быть людьми, за которыми идет охота на рынке, зарплаты начали проседать. Казалось бы — изобилие хороших спецов обязано было привести к тому, что корпоративное ПО станет работать идеально. Но на деле этого не происходит: количество багов по-прежнему высокое, сервисы работают не так как надо. А специалистов, которые в состоянии взять на себя ответственность за работу корпоративного ПО, гарантировать и обеспечить результат, — по-прежнему не сказать чтобы очень много.

Почему так? Две ключевые причины.

• Невероятная сложность экосистем. Если 15 лет назад корпоративное ПО — это одна-две базы данных (в одной — сканы документов, в другой — данные о заказчиках и процессах), сервер и клиент (веб или десктопный), то сегодня это зоопарк: сервисы интеграции с партнерскими системами, OLAP и сервисы генерации отчетов, поисковая платформа, онлайн-прием и обработка платежей, сервисы, рассылающие почту, пуш-уведомления, несколько брокеров очередей, системы мониторинга и т.д. и т.п. Все это строилось годами, часто под сиюминутные хотелки руководства, часто людьми с недостаточным опытом. Почти всегда — без документации. И никакой ИИ не распутает сложное переплетение цепочек вызовов между системами, не разберется, почему это так «исторически сложилось».

• Смена фокуса с технологии на бизнес. Технический аспект в разработке — важный, но не единственный. Нужно глубоко вникать в то, что хочет пользователь. А часто бывает, что пользователи хотят разное или говорят об одном и том же, но придают словам разное значение. Работа во многом сводится к общению с ними, к вниканию в нормативные документы, к «челночной дипломатии» между пользователями, к разработке и переделыванию прототипов приложений.

От сеньора теперь не требуется настолько глубокое знание технологии, как 20 лет назад, — но зато требуется:

• Знание бизнес-процессов компании.

• Знание того, как и почему сейчас работает ПО, с кем и как интегрируется, как проходят информационные потоки.

• Умение слушать и понимать пользователей-заказчиков.

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

Вывод

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

А вот тем, кто просто может хорошо отвечать на технические вопросы, — уже будет на рынке тесно. Как «вкатились на изи», так и «выкатятся».