Десятилетнее сидение в офисе и перекладывание бумажек не сделают вас мастером программирования. На это способно только написание программ.
В свете недавних событий, связанных с производительностью терминала Windows [см. https://github.com/microsoft/terminal/issues/10362], я решил, что стоит немного порассуждать на эту тему, поскольку она раскрывает некоторые проблемы, мучающие отрасль разработки ПО.
Ситуация представляет собой стандартную мыльную интернет-оперу, запечатлённую на Github. Опытный программист опубликовал баг-репорт о медленном рендеринге текста в терминале и после долгого общения с мейнтейнерами один из них выдал следующее заявление:
Я считаю то, что вы называете целый исследовательский проект на соискание докторской степени в эмуляции высокопроизводительного терминала «чрезвычайно простой» работой, выглядит довольно агрессивно...
Несколько часов спустя ещё один программист опубликовал прототип гораздо более быстрого рендерера терминала, доказав тем самым, что для опытного программиста рендерер терминала — это просто забавный проект на выходные, совсем не требующий многолетних долгих исследований. Как бы ни унизительно это было для Microsoft, которая, несмотря на владение платформой и API, по-прежнему испытывает трудности в создании ПО с удовлетворительной скоростью, мне кажется, что частично эта проблема вызвана корпоративной системой стимулов.
На основании моих ограниченных знаний, сложившихся из услышанных историй, я считаю, что отрасль разработки ПО не так сильно ценит совершенство навыков, как она ценит количество рабочей силы. Это, в свою очередь, ограничивает объём опыта, который может получать среднестатистический программист при работе с большими проектами, просто потому, что у него есть стимул как можно скорее уйти с должности создателя реализаций на какую-нибудь руководящую должность.
Тем не менее, крупные корпоративные проекты расширяются быстрее, чем наша Вселенная, и кому-то всё равно приходится программировать все новые фичи. Но кто же будет выполнять всю эту работу?
Цикл жизни программиста
Чтобы ответить на предыдущий вопрос, нам нужно понять цикл жизни профессионального программиста. Мне кажется, программистов можно грубо разделить на три категории:
Молодо-зелено: те, кто только что начали работать профессиональными программистами; над ними требуется сильный надсмотр.
Примерно понимающие, что они делают: профессиональные программисты, вроде бы разобравшиеся с тем, что они делают, и чаще всего способные выполнять собственные задачи.
Опытные: те, кто уже давно в строю и, скорее всего, влияют на все серьёзные решения в крупном проекте по разработке ПО. Коллеги обычно обращаются к ним, когда требуется совет по сложной технической проблеме. Некоторые программисты никогда не достигнут этого уровня, несмотря на официальное название их должности (подробнее об этом ниже).
Очевидно, что такая разбивка очень приблизительна, и о признаках категорий можно спорить бесконечно, но для нашего небольшого обсуждения этой условности вполне достаточно. Я специально решил не добавлять в эти категории упоминание длительности опыта работы, потому что считаю, что интерес и любопытство важнее, чем годы, потраченные на написание геттеров и сеттеров в соответствии с каким-нибудь корпоративным руководством по стилю.
Когда вы входите в мир работы профессиональным программистом, то скорее всего получаете самый нижний ранг — так называемую категорию «молодо-зелено». Вероятно, вам назначат ментора, который будет контролировать вашу работу и обеспечивать её соответствие стандартам и нормам компании. У вас не будет особого выбора в том, что вы делаете, и вам придётся выполнять всевозможные задачи; и интересные, и довольно скучные, к которым никто не хочет прикасаться.
Спустя несколько лет протирания полов на уровне «молодо-зелено» ваш начальник наконец понимает, что вы уже много раз подтвердили свои способности и готовы к большему. Вы получаете почётный титул «примерно понимает, что делает».
С великой зарплатой приходит и великая ответственность. На этом этапе от вас ожидают более-менее независимой работы, без необходимости стороннего контроля каждого принятого вами решения. Возможно, вам доверят проектирование небольшой части проекта. Возможно, вы возьмёте на себя задачи более опытного разработчика, пока он находится в заслуженном отпуске. Возможно, вам поручат проверять результаты работы кого-то с более низким рангом. Возможно, вы будете общаться с заказчиком для того, чтобы разрешить его проблемы. Эта категория очень широка, так что кто знает?
Кроме того, категория «примерно понимает, что делает» — это ещё и этап отделения зёрен от плевел. Начальники всегда находятся в поиске того, кто сможет взять на себя их обязанности. Теперь, когда вы уже множество раз доказали свои навыки, для них настало время подумать о будущем и «вырасти» до более ответственной должности. Как вы смотрите на то, чтобы руководить чуть более объёмной фичей, имея под своим начальством всех этих «молодых и зелёных» программистов?
В конце концов, это вполне очевидный шаг для вас. Когда компания растёт и пополняет свои ряды новыми сотрудниками, кто будет ими руководить? Очевидно, что не новые и неопытные люди и очевидно, что не ворчливые ветераны организации, которые уже отвергли предложение о подобной должности в прошлом.
Если вы решите пойти по этому пути, то можете подумать, что ничего не изменится: вы по-прежнему будете выполнять свою обычную работу, за исключением того, что придётся тратить часть времени на координирование других людей. Иногда эта небольшая часть времени, посвящённая координированию, расширяется до полномасштабного координирования и вы полностью перестаёте заниматься той работой, которую вы раньше выполняли хорошо.
Следовательно, ваши собственные знания тоже останавливаются на уровне «примерно знает, что делает», потому что нельзя совершенствоваться в задачах, которые не выполняете ежедневно. Похоже, художники полностью осознают эту проблему: они знают, что нужно изучать мастеров прошлого и тратить многие часы, чтобы самому стать мастером. С другой стороны, разработчики ПО часто приравнивают годы работы к некому свидетельству об уровне знаний. Десятилетнее сидение в офисе и перекладывание бумажек не сделают вас мастером программирования. На это способно только написание программ.
Обречён ли я вечно оставаться на уровне «примерно знает, что делает», если выберу путь руководителя? Нет, некоторые люди достаточно упорны, чтобы добраться до категории «опытных» программистов, но очень немногие готовы вкладывать такие усилия сверх своей работы по координированию.
Как показано выше на придуманном графике, чем выше вы взбираетесь, тем сильнее становится одиночество. На самом деле никто не знает, как выглядит истинное соотношение категорий, но можно его прикинуть, понаблюдав за окружающими. Особенно в курсе ситуации на рынке те, кто проводит собеседования (хотя это зависит и от «гламурности» вашей компании. Знаменитые компании привлекают более качественных специалистов). Кто-то говорит, что большинство профессиональных программистов имеет опыт меньше пяти лет работы, но проверить это утверждение невозможно.
Наконец, вы достигаете категории «опытный», в которой ваши обязанности и политическая власть снова возрастают. Обычно от вас ждут, что вы будете выдавать готовые проектные решения и прогнозы выполнения задач, устранять сложные баги, выполнять ревизию кода, проводить собеседования с кандидатами, совершенствовать внутренние процессы, заниматься менторством и играть в офисную политику.
Так как вам приходится заниматься всеми этими дополнительными задачами, вы уже не можете тратить столько же времени на программирование, как на более низких уровнях; теперь вы вынуждены делегировать написание кода остальной части команды. В конце концов, один человек, как бы велик он ни был, не способен всё успеть.
Так кто же тогда разрабатывает все фичи?
Из-за того, как работает система ранжирования программистов, в среднестатистической компании будет большая толпа неопытных работников и горстка тех, кто способен решать сложные задачи. Поэтому подавляющее большинство ПО написано теми, кто всё ещё осваивает ремесло.
Сколько на самом деле знают программисты «молодо-зелено»? Не очень много, и это сказывается на качестве программ. Да, опытные программисты берут на себя задачи по проектированию, но это не спасёт вас, если реализация великолепной архитектуры будет ужасной.
Если вы хотите производить высококачественное ПО, вам нужны и опытные люди «за станком», которые не просто делегируют поступающие сверху приказы. Как часто вы встречали огромный кусок переусложнённого кода, который можно было значительно упростить, если бы разработчики лучше знали свою среду разработки? Обычно существует множество различных подходов, однако некоторые решения лучше других.
Но постойте! Как узнать, что сработает, а что нет? Вам нужно наработать интуитивное понимание, и единственный способ сделать это — много программировать. Нельзя научиться, читая случайно найденные статьи, необходимо практиковаться, чтобы усвоить уроки, о которых вы читали.
