Сегодня профессия разработчика ПО находится в эпицентре потрясений. Никто не знает, к чему нас приведёт ИИ-революция, но ясно одно — многие аспекты работы и повседневной жизни изменятся, в том числе программирование.
В последнее время я часто слышу утверждения, которые сводятся к двум основным идеям: «LLM могут хорошо писать код, но программная часть никогда не являлась самой сложной» и «Программировать легко — сложно понять, что именно требуется напрограммировать».
Как по мне, так это явное оскорбление для всех программистов.
Если писать код легко…
Если это такое плёвое дело, то почему тогда долгие годы на программистов был столь высокий спрос, и они требовали высокую оплату (даже до эпохи нулевых процентных ставок ZIPR)? Почему было так много стресса, переработок и выгорания ещё до того, как ИИ начал штамповать пул-реквесты по 5 000 строк? Почему компании ищут эдаких ниндзя-программистов и мурыжат их собеседованиями на LeetСode — ведь если так всё просто, то и джуниор, едва окончивший колледж, наверняка сможет лихо стряпать что-нибудь дельное.
Если программировать легко, то откуда взялись такие фолианты, как «Clean Code» и «The Pragmatic Programmer»? Разве «The Art of Computer Programming» можно назвать лёгким летним чтивом, а «SICP» — книжкой для журнального столика? Зачем тогда этой профессии посвящаются буткемпы и даже целые направления в ВУЗах?
Если программировать легко, то Кармак тогда просто оказался в правильном месте в правильное время? Почему мы тогда считаем Фабриса Беллара гением?
Если программировать легко, почему люди злятся на ИИ (и на других), когда те копируют их код? Почему они ведут себя так, будто вложили в этот процесс кучу сил, времени и свою душу?
Если программировать легко, почему многие чувствуют, будто у них отнимают их идентичность и профессиональное призвание?
Если программировать легко, почему тогда ПО такое забагованое?
Если самое сложное — это выяснить, что именно нужно создать…
Если сложно именно понять, что именно требуется, то почему так много продакт-менеджеров кажутся некомпетентными? Почему для них не проводятся тщательные 10-этапные собеседования? Почему они не получают больше, чем разработчики?
Если сложно понять, что именно нужно, то почему исследователей рынка, экспертов по UX и специалистов поддержки в IT-компаниях не считают рок-звёздами? Если «понять клиента» сложнее, то почему тогда на бизнес-аналитиков смотрят свысока, как на обычных писарей?
Если реализовывать всё так просто, а находить реальный спрос сложно, то почему программисты бесятся, когда продажники для закрытия сделки обещают клиенту новую фичу? Они ведь нашли конкретный запрос, за который человек готов платить!
Если программировать так легко, почему все просто не создают по десять вариантов продукта, чтобы посмотреть, какая лучше взлетит?
Не существует понятия «среднего» программиста
Ещё одно избитое утверждение звучит так: «Основная работа при создании ПО заключается в общении со стейкхолдерами, понимании потребностей клиентов и прояснении приоритетов».
Я за свою карьеру встречал много всяких программистов, и редко кто из них горел желанием общаться со стейкхолдерами, тем более с клиентами. Исключением, разве что, являются фрилансеры и основатели бизнеса, особенно владельцы студий заказной разработки. А «прояснение приоритетов» сводится к «просто скажи мне, что делать, и не меняй видение каждые два дня».
Некоторые разработчики говорят: «Я не пишу код, я решаю проблемы клиентов». Но после этого они переключаются на обсуждение монад, безопасности памяти и принципов DRY. При этом всё их понимание клиента ограничивается вымышленным «портретом пользователя», а под словом «аффорданс» они понимают карманные деньги, которые им давали родители на выходные, чтобы погулять.
Другие же говорят: «Разработка ПО заключается в построении теорий». Для них программы сродни математическим доказательствам. Каждый коммит должен рассказывать историю. А решение проблемы клиента через заливку PHP-файла по FTP считается смертным грехом.
Я вовсе не хочу сказать, что нет разработчиков, которые одновременно глубоко преданы своему ремеслу и искренне сопереживают клиенту. Хотя мне кажется, что в таком случае им не помешало бы показаться специалисту по поводу раздвоения личности.
Примечание после публикации: с этим предложением я явно перегнул палку; это была лишь шутка в духе «мало кто на такое способен», и в следующем разделе я как раз к этому призываю. Каюсь.
А что реально важно?
Я тоже считаю, что общение с пользователями, понимание их чаяний, сопереживание, решение проблем и координация всех стейкхолдеров являются важнейшими аспектами успеха при разработке ПО.
Ещё я считаю, что создание качественного кода — это мастерство, требующее навыков, терпения, внимания к деталям, опыта и мудрости. Уверен, в ближайшем будущем всё это продолжит оставаться актуальным.
Так почему бы не выбрать оба варианта?
Думаю, что мы должны по возможности стремиться и к одному, и к другому, глубоко вникая в создаваемую систему и осознавая, почему мы её создаём.
Если же громко заявлять, что «код писать легко» или, напротив, что «программирование — это искусство, инструмент творческого самовыражения, который невозможно автоматизировать», то это будет означать слепое отрицание реальности.
Всё это не больше, чем самоутешение. Но вам нужно не самоутешение, а процветание.
И этим я не хочу сказать «устремитесь за волной ИИ-хайпа». Я не призываю вас становиться «погонщиком стай ИИ-агентов». И я не утверждаю, что «сгенерированный ИИ код — это ворованный низкосортный шлак, с которым нужно бороться всеми силами, и который вскоре всё равно лопнет».
Но нам важно осознать, что мы находимся в эпицентре тектонического сдвига всей индустрии. Нам нужно как-то адаптироваться. Нужно понять, какие аспекты нашей жизни изменятся наверняка, а какие — никогда.
Что не изменится?
ПО продолжит усложняться и всегда будет требовать обслуживания. Деградация кода — это суровая реальность. Как и энтропия. Технологии — как аппаратные, так и программные — будут развиваться, к худшему оно или к лучшему. Башня (может, уже небоскрёб?) абстракций будет расти всё выше.
Пользователи всегда будут хотеть получать всё больше, а платить всё меньше. Они по-прежнему не будут уметь грамотно изъяснять свои нужды и желания. Хуже того, они так и не смогут понять, чего же они действительно хотят. Этот разрыв между клиентами (которые реально платят за ПО) и пользователями (которые им пользуются) никуда не денется, как и напряжение между целями бизнеса и потребностями его клиентов.
Да и «продавцов змеиного масла» всегда будет хватать. Очередной писк технологической моды приходит и уходит (я всё ещё жду VR-ренессанса).
Что меняется?
Программисты с самого начала только и делали, что разрушали собственную индустрию. Никто больше не использует перфокарты. Мало у кого сегодня есть необходимость писать на ассемблере или COBOL. Десятилетия, потраченные на борьбу с багами памяти в C или C++, оставившие после себя глубокие шрамы, обесценились с появлением Rust, Go, Python и JavaScript.
Я достаточно стар, чтобы осознавать ценность Valgrind или помнить функцию mysql_real_escape_string() из эпохи PHP4 — вещи, которые мне больше никогда не понадобятся. А ведь это было не так уж давно! Я едва разминулся с dBase, Clipper, HyperCard и Access — технологиями, которые я до сих пор вижу в магазинах, кафе или на своём пыльном системном блоке, который из некогда бежевого уже стал золотисто-коричневым, но до сих пор счастливо крутит какое-то заказное бизнес-решение (бэкапы? Какие ещё бэкапы?).
Как нам процветать?
Принять, что происходят перемены. В равной степени проявлять к новшествам любопытство и критический анализ.
Понять, что сейчас в индустрии сильный хайп, и стараться не просто отличать пустые обещания разработчиков от реально полезных вещей, но и оценивать, до какой степени они полезны. Также не забывайте о постоянно меняющихся правилах игры: оглянитесь на прошлый год или последние пять лет и оцените скорость изменений — технологических, экономических и социальных.
Ваша роль, как и ваши должностные обязанности, будут меняться. Будьте готовы вложить своё время и силы в то, чтобы лучше понять сферы или роли, смежные с вашей текущей.
Если вы старший разработчик, не нужно искать спасение просто в углублении опыта. Изучайте нюансы UX, исследования потребностей клиентов и бизнес-стратегии компаний в вашей сфере деятельности. Это позволит вам более адекватно оценить весь труд, проделываемый для того, чтобы ПО или его отдельные фичи достигли конечного пользователя — вне зависимости от того, придётся ли вам когда-либо делать что-то из этого самому.
Если же вы только начинаете свою карьеру или пока являетесь джуниором, инвестируйте свои силы в более глубокое понимание принципов работы ПО. Разобравшись в механизмах указателей, рекурсии или иерархии памяти, вы начнёте увереннее чувствовать себя даже в роли JS-разработчика. Понимание сетевых протоколов и принципов HTTP окажется полезным, даже если вы создаёте плагины для WordPress. Практикуйтесь на задачках с LeetCode, изучайте алгоритмы и структуры данных, даже если всё это не является для вас необходимым. Не бойтесь спрашивать «Почему?» и «Как именно?».
Вот вам несколько книг и прочих источников, которые помогут на этом пути:
-
Structure and Interpretation of Computer Programs (PDF, в русском издании «Структура и интерпретация компьютерных программ»)
-
Cracking the Coding Interview (в русском издании «Карьера программиста»)
-
The Mythical Man-Month (в русском издании «Мифический человеко-месяц»)
-
Working Backwards (в русском издании «Стратегия Amazon»)
-
Team Topologies (в русском издании «Топология команд»)
-
7 Powers (на русском не издавалась)
-
The Soul of a New Machine (на русском не издавалась)
-
Obviously Awesome (на русском не издавалась)
-
The Design of Everyday Things (в русском издании «Дизайн привычных вещей»)
-
Don’t Make Me Think (в русском издании «Не заставляйте меня думать»)
-
Continuous Discovery Habits (на русском не издавалась)
-
The Mom Test (в русском издании «Спроси маму»)
И ещё кое-что
Какова бы ни была ваша роль, не делитесь своим пониманием, суждениями, эмпатией и вкусом с ИИ. Не пытайтесь переложить ответственность. Не становитесь бездумной «мясной прослойкой».
P. S. На Hacker News и Lobsters эта статья породила много глубоких и ярких комментариев — тема действительно оказалась острой. Поразительно, насколько разный опыт у людей и насколько разные определения они дают понятиям «кодинг», «программирование», «разработка» и «инженерия».
Автор: Bright_Translate
