Чтобы продолжить рассуждения о том, как ИИ может повлиять на будущее профессии "программист" (начатые здесь и продолженные здесь) придется озвучить одну из классификаций программистов, которой придерживаюсь в последние годы.
Прикладные программисты делают то, что нужно пользователю. Причем не важно, о каком именно продукте идет речь -- это может быть какая-то сделанная на коленке под заказ система складского учета для провинциальной конторы "Рога и Копыта", пакет Microsoft Office или же сервер реляционной СУБД. Суть в том, что есть продукт, есть требования к нему, есть список фич, которые нужно выкатить, есть сроки, есть бюджеты, есть обязательства и т.д., и т.п. И появляется конкретный продукт для конкретного пользователя именно благодаря труду прикладных программистов.
Инфраструктурные программисты делают инструменты, которые используют прикладные программисты в своей работе. Самыми яркими примерами таких инструментов являются фреймворки и библиотеки. Как общего назначения (вроде Qt, JDK или .NET Framework), так и какие-то специализированные, заточенные под конкретный проект.
Хоть и те и другие до недавнего времени вроде как одинаково писали код, между ними были принципиальные отличия во многих вещах -- начиная от внимания к мелким деталям при написании кода, заканчивая мировоззрением. Или, может быть, правильнее было бы сказать начиная от мировоззрения и заканчивая мелкими деталями в коде.
Цель прикладного программиста -- решить конкретную задачу стоящую перед конкретным пользователем. Если решение будет работать и удовлетворять заказчика/покупателя продукта, то не суть важно, слеплено ли оно из говна и палок, скручено из разных костылей синей изолентой или же посажено на суперклей.
И это более чем правильный подход. Потому что решение нужно здесь и сейчас иначе не будет денег от заказчика/покупателя, а без денег не будет нужды ни в прикладных программистах, ни в инфраструктурных.
Тогда как задача инфраструктурного программиста в том, чтобы предоставить прикладному программисту как можно больше полезных инструментов, чтобы уменьшить количество синей изоленты в прикладном коде.
Яркий пример, демонстрирующий разность в подходах, довелось увидеть буквально пару дней назад в докладе «Опыт перехода проекта „Авито.Доставка“ с Java на Go» / Илья Лапин, Сергей Поляков (Avito), который мне YouTube зачем-то подсунул в рекомендациях (но оказалось довольно любопытно, благо доклад короткий и толковый):
Суть в том, что на момент доклада (2018-й год) в стандартной библиотеке Go (как и в самом языке) не было такого понятия как "множество" (оно же Set). Понятие "словарь" встроенное в сам язык было (в виде штатного типа map), а вот "множества" -- нет.
Прикладной программист: ну OK, раз нет "множества", то сойдет и "словарь", просто в качестве значения для ключа будет использоваться экземпляр пустой структуры. Не, ну а чё, работает же.
Тогда как инфраструктурный программист от подобного впадает в ступор. Типа: "а почему этот самый Set нельзя было взять и сделать?" 😉
PS. Убедительная просьба не воспринимать этот текст как попытку ранжирования программистов по их качеству. Типа "прикладные" программисты -- не настоящие программисты вовсе, тогда как "инфраструктурные" -- соль профессии и настоящая илитарная илита. Как раз жизнь учит тому, что все программирование живет и зарабатывает исключительно благодаря "прикладным" программистам, тогда как "инфраструктурые" являются всего лишь обслуживающим персоналом (но без этого обслуживающего персонала тоже нельзя).
4 комментария:
А хорошо ли такое разделение? Грубо говоря "инфраструктурный" программист справится с задачами "прикладного", а вот наоборот уже наврядли.
@Stanislav Mischenko
ИМХО, большинство разработчиков одинаково плохи (или хороши, тут уж как судить) в обоих ипостасях. Но есть крайние случаи, в которых явно видно, что вот у этого программиста мышление прикладника, а вот у этого -- инфраструктурника. Это важно для того, чтобы не поручать людям работу, с которой они не справятся.
Грубо говоря, посади меня клепать формочки и ничего хорошего из этого не выйдет. Точно так же напрасно ждать хорошей библиотеки от прикладника, который не только с удовольствием формочки клепает, но еще и с интересом разбирается с особенностью прикладной области, которая за этими формочками стоит.
Т.е. каждому инструменту свое место. Конечно же, шуруп забитый молотком будет держать лучше, чем гвоздь, закрученный отверткой, но если хочется избежать таких экстремумов, то хорошо бы проектные команды формировать из подходящих людей.
@eao197
Я понял вашу мысль, но я всё же о другом. Скажем так, какой-нибудь фирме, решаюшей свои исключительно бизнес задачи, "инфрастуктурные" программисты не нужны. По сути им подходит любой человек прошедший онлайн курсы "формошлёпства". Такой человек в принципе set от map не отличает (ладно шучу, но HashMap от LinkedMap уж точно). И вот такие люди успешно строят карьеру и становятся синиор, принципал, и чего там ещё есть, девелоперами. И внезапно таких становится большинство, такие люди начинают возглавлять индустрию, и, почувстовав свою силу, они начинают шпунять "инфраструктурных" программистов. Условные Старуструп и Торвальдс для них выжившие из ума маразматики. Если раньше ты допустил ошибку, то ты сам дурак, надо учить язык. Теперь виноват инструмент, это он неправильно сделан, не безопасен, не предупредил, не поправил. Вот собственно, что меня пугает.
@Stanislav Mischenko
Я к такому спокойно отношусь. Это обычная эволюция. Если вверх по карьеной лестнице выносит адекватного человека (не важно "прикладник" он или "инфраструктурник"), то он начнет осознавать свою неполноту (пробелы в знаниях/умениях/опыте) и будет либо учиться, либо делегировать какие-то задачи, либо подтягивать к себе специалистов, которые будут компенсировать его недостатки. А если неадекватный, то это начнет сказываться (например, загниванием проекта/компании) и кто-то затем вынесет для себя уроки из этого негативного опыта.
Отправить комментарий