Обсуждение начну с весьма печального твита Криса Аллена (Chris Allen, @bitemyapp):
«Мне немного грустно от того, что некоторые организации твердят мантру „Вы сможете использовать haskell“, чтобы заполучить толковых инженеров подешевке».
— Untyped is unsane (@bitemyapp) 3 июня 2014 г.
Для тех, кто не знает: Haskell — продуктивный и мощный язык, позволяющий программистам, по крайней мере талантливым, быстро писать правильный код. По сравнению с разработкой на Java скорость возрастает в 2–5 раз при сопоставимой производительности и меньшем количестве ошибок. Крис совершенно верно заметил, что разработчик, использующий Haskell, чаще всего не получает достойного вознаграждения. Если вы твердо решили использовать функциональное программирование, то будете зарабатывать меньше коллег, которые разгребают базы кода C++ в банках, накопленные за 30 лет. Как-то это все неправильно. Почему к программистам, применяющим более мощные инструменты, применяются экономические санкции? В отличие от управленцев, ставящих во главу угла выгоду, программисты действительно хотят сделать свою работу как можно лучше. Почему же вместо «пряника» за благие намерения они получают «кнут»?
Впредь я буду характеризовать эту ситуацию как «бремя Haskell». Едва ли это бремя обусловлено дешевизной услуг или жадностью компаний, использующих Haskell. Дело не в этом. На мой взгляд, это свойственно всей отрасли. Уровень зарплат начинающих программистов в 2014 году довольно высок, но при этом повышение по службе и прибавка к жалованию часто не соответствуют реальному приросту ценности программиста для бизнеса и даже его фактическим затратам (например, расходам на жилье, обучение и т. п.). Наиболее действенным оружием программиста в конкурентной борьбе является его репутация. А заслужить репутацию сложнее тому, кто концентрируется на каком-то одном конкретном языке. И в этом нет вины Haskell. Почти наверняка существует аналогичное бремя для Clojure, Erlang или Scala.
Помимо языков программирования, это относится к любому фактору, положительно влияющему на карьеру. В большинстве случаев программисты быстро достигают пика карьерного роста, зарывая свой талант, и работодателям это хорошо известно. Поэтому работа, связанная с какими-то интересными задачами, например машинным обучением, новыми проектами или передовыми инструментами, оплачивается ниже. Программистов обычно такой подход не удивляет, поскольку все уверены, что лучше оплачиваться должна именно малоприятная работа. Это настоящая катастрофа, долгосрочный эффект которой отражается не только на карьере программистов, но и на отрасли в целом. Рыночные сигналы должны повышать привлекательность наиболее выгодных инвестиций, но в сфере программного обеспечения, похоже, ситуация диаметрально противоположна. За работу, которая способствует карьерному росту программиста, зачастую платят необоснованно мало. Кроме того, такие задачи обычно распределяются в закрытом режиме и ревностно охраняются, решения же носят больше политический характер, а победитель, как правило, вынужден соглашаться на необоснованно высокие издержки.
Что плохого в бремени Haskell?
Как уже говорилось, явление, которое я назвал «бременем Haskell», присуще не только этому языку. Оно характерно для всех задач, связанных с программным обеспечением, если только это не «жарка рыбы». Поэтому специалист высокого уровня не может рассчитывать на зарплату, эквивалентную его квалификации. Однако, постоянно меняя вектор развития, вы не станете экспертом в своей области. Для этого нужна сосредоточенность, целеустремленность и упорный труд. Нужна специализация, и любые исключения лишь подтверждают это правило. Профессионал с пятилетним опытом может создавать в 3–50 раз больше ценности для своей компании, чем начинающий «мальчик на побегушках». Но какие дополнительные выгоды получает при этом опытный сотрудник? Да практически никаких. Необходимость «поддерживать форму» в рамках своей специализации (и отказываться от мало связанных с ней задач) ослабляет позиции такого профессионала. Со временем доступный «фронт работ» значительно сужается, что негативно отражается на доходах специалиста. С другой стороны, при смене специальности профессионал высокого класса переходит в разряд новичков на конкурентном рынке труда, поэтому выйти на желаемый уровень зарплаты ему также не удастся. Вот вам и заколдованный круг.
Именно поэтому закрытое распределение имеет, помимо моральных, еще и экономические аспекты. Такой подход лишает компанию возможности реализовать львиную долю потенциальной ценности, которую могли бы создавать ее сотрудники. Кроме того, это делает людей менее мобильными, поскольку на другую работу они могут перейти только при наличии заранее определенной роли, соответствующей их специальности. В долгосрочной перспективе это выльется в отрицание необходимости приобретения экспертных знаний, навыки талантливых программистов окажутся невостребованными, а отрасль в целом скатится на уровень посредственности.
Программируйте для богатых и живите с бедными. Программируйте для бедных и живите… с бедными
Художники и писатели любят повторять: «Продавай массовому потребителю – будешь жить богато. Продавай богатым – будешь сам среди массовых потребителей». Это расхожее выражение относится не столько к социальным классам, сколько к низкому финансовому результату высококлассной работы. Поэты зарабатывают много меньше «писателей-стахановцев», выдающих в рекордные сроки тонны низкопробной литературы. «Бремя Haskell» — это экстраполяция этого принципа. Программисты, которые берутся только за высококлассные задачи («программируют для богатых»), вероятно, часто сидят без работы или продают свои услуги по заниженной цене.
Означает ли это, что каждый программист должен года за два погрузиться, например, в Java и остановиться на этом? Оптимален ли такой подход с экономической точки зрения? «Продавать бедным» значит выполнять скучные и однообразные специализированные задачи, с которыми справился бы и новичок. Программисты, которые придерживаются этой тактики, до сих пор живут с бедными. В рамках такого подхода к программированию (узкоспециализированная бизнес-логика) невозможно масштабирование. Объем и подходы к работе писателя не изменятся, даже если количество «пользователей» его романа возрастет с 10 до 10 миллионов человек. Программистам такая масштабируемость недоступна, а проекты, предоставляющие возможности для масштабирования, роста и приумножения отдачи от трудозатрат, представляют собой задачи «для богатых», к которым охотно подключается любой программист (мы уже обсуждали, почему такие проекты не окупаются). Поэтому, придерживаясь стратегии программирования для масс, вы также быстро упретесь в свой потолок, если только не сделаете политический ход и не станете руководителем. Но руководители продают, а не создают программные продукты. Это экс-технари с устоявшимися методами управления и решения технических задач. Когда-то эти методы были верны, но теперь устарели, поэтому они настолько же далеки от оптимума, насколько от него далеки методы нетехнарей.
Иными словами, с точки зрения программиста проблема «бедных» и «богатых» будет выглядеть следующим образом: можно решать задачи высокого класса и полностью отдаться на милость работодателей, поскольку таких задач мало, а можно заняться «ширпотребом», который практически не масштабируется. Ни один из двух предложенных маршрутов не приведет программиста к покупке собственного дома в Сан-Франциско.
Многомерность
Возможно, самое интересное в работе программиста — это разнообразие решаемых задач. Появляются новые технологии, и программисты должны их изучать, даже если работодатели, которые не приемлют риска и придерживаются концепции антиинтеллектуализма, не будут за это платить. Что нужно, чтобы стать хорошим программистом? Тридцать лет назад для этого достаточно было освоить язык C и изучить подходы к разработке структуры программы. Пять лет назад инженер-программист должен был знать основы Linux и MySQL, несколько языков (Python, Java, C++, Shell), а также компромиссные решения. В 2014 году концепция «полного стека» вобрала в себя настолько широкий круг технологий, что всеми ими владеют лишь единицы. Энди Шора (Andy Shora), автор эссе по ссылке выше, дает красивое определение для таких уникумов, называя их «мачо-программистами все-в-одном»:
Я понимаю, почему компании отчаянно пытаются нанимать профессионалов такого уровня. Дело в том, что реально высококлассные специалисты часто теряются в серой массе недоучек, которые думают, что знают всё.
Тридцать лет назад для оценки мастерства программиста был вполне применим метод линейного упорядочения. Идеальный портрет тогдашнего программиста: может написать компилятор C, имеет понятие о численной устойчивости, может освоить новый язык или платформу по мануалу. Если вам периодически требовалась помощь или ваши алгоритмы показывали низкую эффективность, вас резонно считали начинающим или посредственным программистом. В 2014-м все уже далеко не так. Слишком много всего нужно знать и уметь! К примеру, я понятия не имею, как создать визуально привлекательную казуальную игру. Я на «ты» с линейной алгеброй, поэтому с искусственным интеллектом и игровым процессом справлюсь без особых усилий, а вот с графикой и окончательный «доводкой» все будет намного сложнее, поскольку я не вижу принципиальной разницы между Candy Crush и практически аналогичными, но гораздо менее успешными играми. Здесь нужен спец по пользовательскому интерфейсу и пользовательскому опыту.
Линейное упорядочение больше не поможет вам нарисовать портрет хорошего программиста. Теперь легче сказать, чем программист НЕ занимается. Поле его деятельности стало N-мерным. Это одна из причин, обусловивших низкую толерантность к новичкам, женщинам и просто толковым, но неопытным начинающим специалистам. Вопрос о том, какая из этих мерностей имеет значение, а какая — нет, является политическим и субъективным, он не имеет точного устоявшегося ответа. Сегодня лузерами будут те, кто не знает скриптового языка. Завтра будут косо смотреть на всех, кто не разбирается в начинке JVM. У каждой компании свои стандарты, которые постоянно изменяются, и наши коллеги часто не только не знают, насколько они хороши как программисты, но и не могут понять, по каким именно критериям это оценивается. Это также объясняет ужасающую неразбериху, связанную с требованиями к разработке программного обеспечения. По большей части «работа» софтверной компании направлена на собственное определение «хорошего программиста» и, соответственно, отбор оптимальных инструментов.
Я вовсе не утверждаю, что многомерность — это плохо. Напротив, это свидетельствует о зрелости и разнообразии этой сферы деятельности. Проблема заключается в том, что мы допустили антиинтеллектуалов и нетехнарей к рычагам управления в своей отрасли. Они настаивают на применении метода линейного упорядочения для оценки компетентности в основном ради достижения собственных меркантильных целей. Именно на стыке меркантилизма и многомерности и возникают главные «болевые точки».
В дополнение ко всему наблюдается фундаментальное лицемерие работодателей, из-за которого программисту ужасно трудно планировать свой карьерный рост. Принимая программиста на работу, компания требует, чтобы тот четко охарактеризовал свою специализацию. Если специализация расплывчата и имеются пробелы в вашем послужном списке, с вами даже разговаривать не станут. А после того как кандидат стал сотрудником, компания просто отказывается принимать во внимание его специализацию. Если же программист будет настаивать на том, что какие-то задачи не относятся к его компетенции, то есть будет так же четко определять свою специализацию, как того требовал работодатель в самом начале, то на него повесят ярлык «не умеет работать в команде». Десять лет занимался машинным обучением? Отлично, но сейчас исправь-ка унаследованную базу кода Rails. Это было бы смешно, если бы не было так грустно. Компании предъявляют к работникам неограниченные требования, но не предоставляют им возможности для накопления необходимого опыта. В результате выбор делается из политических соображений, или же «всплывают» специалисты в области самопиара, но ни те, ни другие в действительности не умеют программировать.
Нескончаемое бремя Haskell
«Бремя Haskell» — это не просто проблема языка программирования. Любой программист, настаивающий на своей специализации, значительно сужает свой потенциальный фронт работ. Он не сможет достичь желаемого уровня доходов. Поскольку в софтверной индустрии появляются все новые специализации и измерения, бремя Haskell взваливает на себя все большее количество людей. Лорд Бизнес вводит сегодня такие автономные области как DevOps и «Обработка и анализ данных», которые, несмотря на лежащие в их основе позитивные намерения, работают на наших антиинтеллектуальных колонизаторов и отделяют нас друг от друга. Идея (абсолютно верная, между прочим) о том, что, если программист хорошо владеет языком Haskell, он может стать превосходным аналитиком или инженером-эксплуатационником, почему-то их пугает. Им не нужен динамичный рынок труда. Лорд Бизнес испытывает стойкую неприязнь к специализации, когда мы защищаем свои основные компетенции, он хочет сделать нас взаимозаменяемыми специалистами широкого профиля («полный стек»). Однако сам он не делает абсолютно ничего для устранения путаницы и изолированности, вытекающих из многомерности. Эти облеченные властью идиоты могут позволить себе по своему усмотрению отстранить от работы 90 % ведущих программистов на основании поверхностных знаний о различиях в технологиях. То есть они могут контролировать нас, особенно если в их компетенции находится распределение проектов в закрытом режиме. Но что еще важнее, от них зависит величина нашего вознаграждения.
Вот как им удалось взвалить на нас бремя Haskell, которому не видно конца. Если такова рыночная конъюнктура, то младшие инженеры могут получать сравнительно большую зарплату. Но искусственные препятствия, связанные с закрытым распределением заданий и лицемерием работодателей, заставляют нас мириться с неадекватной специализацией и разделенностью, в результате чего у старших инженеров уже не остается практически никаких перспектив. Инженеры, которые создают в 10 раз большую ценность для компании, чем их младшие коллеги, могут получать всего на 25 % больше. При этом они, как утверждает Лорд Бизнес, должны радоваться тому, что им «дают» реальные проекты!
Если мы хотим исправить сложившуюся ситуацию, то мы должны сделать шаг вперед и начать самостоятельно управлять собственными делами. Мы должны называть вещи своими именами, отвечая на лицемерие Лорда Бизнеса, который требует четко определять специализацию при приеме на работу, но отказывается учитывать ее в дальнейшем. Мы должны сказать свое решительное «нет» закрытому распределению проектов и искусственному дефициту в целом. Многомерность и специализация — неплохие вещи сами по себе (даже весьма полезные), но только при должном уровне управления. Мы не можем доверить эту задачу антиинтеллектуалам из «колониального правительства», которые в настоящее время контролируют софтверную индустрию и играют против нас при каждом удобном случае. Настало время взять дело в свои руки.
Автор: denisfrolov
