С появлением LLM люди разделились на три лагеря: тех, кто верит в повышение КПД при помощи автодополнения и тех, кто относится к хайпу крайне скептически. Третий лагерь — это сами LLM, они же тоже что-то там про себя думают, наверное.
За долгие годы работы с кодом я привык слышать от среднего уровня разработчиков (и от тех, кто выбрал языки, которым требуется бесконечная генерация бойлерплейта): «Продуктивность программиста напрямую зависит от IDE». При том, что я всегда производил в несколько раз больше самого сложного в компании кода, используя vim с минимумом плагинов. Подсветка синтаксиса мне помогает, тут (как, впрочем, и почти везде) я с Пайком не согласен. Автодополнение — уже нет, я его иногда включаю «еще раз попробовать, вдруг это со мной что-то не так», и когда читаю курсы — но в основном мне мешают выскакивающие окошки: отвлекают, распыляют внимание, наталкивают на ложный путь.
Так вот, IDE. Если IDE способно помочь вам сделать рефакторинг — это не рефакторинг. Выделение интерфейса, или перенос функции из одного модуля в другой — не рефакторинг. Интерфейсы надо определять на этапе проектирования, а не выделять когда-то потом. Функцию быстрее и надежнее перенести копипастой и грепом — в дороге вы заодно получите шанс удостовериться, что перенос того сто́ит. Рефакторинг — это изменение структуры вашего кода, а не выделение интерфейсов, и тут никакое автодополнение не сможет вам помочь по очевидным причинам: только вы понимаете, что, как и куда надо изменить. Я готов проставиться тому, кто сможет отучить разработчиков от двух самых бессмысленных вещей в программировании: автоматического переноса функций из одного модуля в другой и гонкой за стопроцентным покрытием тестами. Ладно.
Сегодня евангелисты автодополнения переключились с IDE на LLM. «Оно избавляет нас от рутины! Оно пишет бойлерплейт! Оно экономит тучу времени!». Алё, гараж. От рутины прекрасно избавляет карьерный рост, от бойлерплейта — выбор адекватного языка, а от траты недель на написание кода — час обдумывания его структуры.
Если LLM создало вам приложульку с поиском рецепта по фотографии — это значит только то, что таких приложений на рынке уже миллион. У Хинтона и Лекуна есть причины восторгаться таким развитием автодополнения, но у нас с вами — вроде бы никаких. Даже денег это не принесет, что уж говорить о моральном удовлетворении. Любая мало-мальски сложная задача поставит LLM в тупик, а простая — растренирует ваши профессиональные навыки (уровня немного выше переформатирования джейсона). Попробуйте поездить несколько лет кряду на автоматической коробке передач, а потом в гористой местности арендовать механику, сразу поймете, о чем я говорю.
Если ваша цель — просто спокойно до старости ковырять круды за бабло — это прекрасно, у вас высвободится куча свободного времени, которое можно потратить на сёрфинг или хиддинг. Просто этот текст не для вас.
Оно напишет, я проверю, в чем проблема?
Проблема в принятой во многих местах ущербной карьерной лестнице. Условный синьёр видит для себя два варианта развития карьеры: тупик и менеджмент. Работать с людьми — это специальный навык, во многом ортогональный умению решать сложные задачи и писать хороший код. Есть еще полуабстрактная позиция «архитектор», но мне никогда не доводилось видеть хорошего архитектора, не пишущего код хотя бы половину своего рабочего времени. Что ты мне там наархитектуришь, если ты банально не знаешь, насколько это просто и удобно реализовывать, чувак?
Остаётся тупик. Но это не так! Во многих компаниях карьерная лестница не заканчивается синьёром (скорее — только начинается). Продолжается она (с вариациями) вот так: Staff, Principal, Distinguished, Fella. Позиция Principal, например, подразумевает, что вас зовут на все важные совещания о развитии продукта, у вас есть голос в выборе архитектуры (а часто — и стека) проекта, и так далее. Distinguished просто занимается чем хочет, за зарплату (а компания надеется, что его ковыряния принесут пользу в будущем). У меня много кода в опенсорсе, и фактически весь он оплачен моими работодателями: им было выгодно, чтобы я делал то, что хочу. Это вполне себе достижимая позиция, если есть желание и усердие. И ночами впахивать не нужно.
Но на этом уровне LLM — враг, а не помощник. От вас ожидаются свежие идеи, а не пережеванный силос, срыгнутый средними разработчиками в публичное пространство.
И, тем не менее, жизнь после синьёра есть, и она — прекрасна, если вы действительно хороший разработчик (сиречь, получаете удовольствие от написания кода, любопытны, жадны до знаний и по велению души интересуетесь всяким неизведанным). Действительно хорошие разработчики, по моему наблюдению, никогда не хотят в менеджмент и управление. Хотя чаще всего — показательно могут (это видно хотя бы по CR, которые они делают), и им приходится прикладывать много усилий, чтобы увернуться от естественного желания руководства пристегнуть к ним команду. Появилось даже насквозь лживое понятие «тимлид», используемое для подкормки надежд не слишком умудренных корпоративно разработчиков: мол, ты будешь писать код, не волнуйся, никто твой код у тебя не отберет, просто ну вот было бы здорово, если твои навыки и таланты не будут пропадать зря, только часик по понедельникам, бла-бла-бла.
И вот бывший очень хороший разработчик уже выкраивает время по вечерам и субботам, чтобы заниматься любимым делом.
Зато, говорят они сквозь сдерживаемые рыдания, глядя на собеседника поверх пивного бокала, — платят больше. Херня это. Хорошему (действительно хорошему) разработчику платят больше, чем тимлидам и архитекторам. Потому что действительно хороший разработчик — как идеальная жена: королева на кухне (кодревью), и шлюха в постели (архитектура).
А эрудиция тут каким боком?
Хорошим разработчиком практически невозможно стать, не покидая пределы своего стека. «Java Developer», «Программист на руби», «Javascript Fullstack» — это всё про позиции «мидл» и ниже.
Синьёр, особенно тот, который метит в Staff/Principal, обязан — хотя бы на уровне старших классов средней школы — понимать различия между разными парадигмами, читать средней сложности код на хаскеле, уметь набросать круд на объектах и не шарахаться от слов «акторная модель», «завтипы», «рефлексия».
Сейчас модно писать на расте и давать примеры на расте. Я лично от раста не в восторге, мне не нравится ни вектор развития, ни приоритеты мейнтейнеров, но я — любознательный засранец. Кроме того, иногда приходится написать что-то низкоуровневое через биндинги там, где производительность очень уж важна. Поэтому я пролистал пару страниц из их гайда на сайте и даже установил компилятор на свой ноутбук.
Когда я наткнулся на реальный пример в одном из текстов на хабре — банальная эрудиция тут же подсказала мне, что код — нерабочий. Вот мой комментарий под тем текстом с исправленным кодом, если интересно.
Точно так же, знакомство с хаскелем и идрисом (и шапочное — с агдой и лином) — позволяет мне предметно критиковать строгую типизацию там, где она только мешает. Знакомство (любовный мезальянс) с LISP’ами — помогает судить о необходимости нативного представления AST на уровне стандартной библиотеки. Я даже способен ткнуть пальцем в то место кода на Go, который приведет к гонке или дедлоку, хотя на Go не писал вообще никогда, и надеюсь не обнищать настолько, чтобы пришлось.
Все эти навыки делают из меня (надеюсь) неплохого архитектора: широкий кругозор позволяет найти «идеальное» решение в рамках существующих парадигм и реализаций, а потом уж думать, как его поженить с текущим стеком, и возможно ли это в принципе. Будучи специалистом только в забивании гвоздей, довольно сложно даже вообразить повешение полки с использованием дюбелей и шурупов.
Как ни странно, расширение кругозора не отнимает много времени: мне любопытно, что там как происходит у коллег в параллельных цехах. И не пора ли нам что-то оттуда потырить в свою кладовку. Для человека, желающего развиваться по инженерной карьерной лестнице — это необходимый (на мой облыжный взгляд) навык. Или уж смириться (или возгордиться) — и идти в менеджеры.
Удачных карьерных лестниц!
