Десятилетнее сидение в офисе и перекладывание бумажек не сделают вас мастером программирования. На это способно только написание программ.
В свете недавних событий, связанных с производительностью терминала Windows [см. https://github.com/microsoft/terminal/issues/10362], я решил, что стоит немного порассуждать на эту тему, поскольку она раскрывает некоторые проблемы, мучающие отрасль разработки ПО.
Ситуация представляет собой стандартную мыльную интернет-оперу, запечатлённую на Github. Опытный программист опубликовал баг-репорт о медленном рендеринге текста в терминале и после долгого общения с мейнтейнерами один из них выдал следующее заявление:
Я считаю то, что вы называете целый исследовательский проект на соискание докторской степени в эмуляции высокопроизводительного терминала «чрезвычайно простой» работой, выглядит довольно агрессивно...
Несколько часов спустя ещё один программист опубликовал прототип гораздо более быстрого рендерера терминала, доказав тем самым, что для опытного программиста рендерер терминала — это просто забавный проект на выходные, совсем не требующий многолетних долгих исследований. Как бы ни унизительно это было для Microsoft, которая, несмотря на владение платформой и API, по-прежнему испытывает трудности в создании ПО с удовлетворительной скоростью, мне кажется, что частично эта проблема вызвана корпоративной системой стимулов.
На основании моих ограниченных знаний, сложившихся из услышанных историй, я считаю, что отрасль разработки ПО не так сильно ценит совершенство навыков, как она ценит количество рабочей силы. Это, в свою очередь, ограничивает объём опыта, который может получать среднестатистический программист при работе с большими проектами, просто потому, что у него есть стимул как можно скорее уйти с должности создателя реализаций на какую-нибудь руководящую должность.
Тем не менее, крупные корпоративные проекты расширяются быстрее, чем наша Вселенная, и кому-то всё равно приходится программировать все новые фичи. Но кто же будет выполнять всю эту работу?
Цикл жизни программиста
Чтобы ответить на предыдущий вопрос, нам нужно понять цикл жизни профессионального программиста. Мне кажется, программистов можно грубо разделить на три категории:
Молодо-зелено: те, кто только что начали работать профессиональными программистами; над ними требуется сильный надсмотр.
Примерно понимающие, что они делают: профессиональные программисты, вроде бы разобравшиеся с тем, что они делают, и чаще всего способные выполнять собственные задачи.
Опытные: те, кто уже давно в строю и, скорее всего, влияют на все серьёзные решения в крупном проекте по разработке ПО. Коллеги обычно обращаются к ним, когда требуется совет по сложной технической проблеме. Некоторые программисты никогда не достигнут этого уровня, несмотря на официальное название их должности (подробнее об этом ниже).
Очевидно, что такая разбивка очень приблизительна, и о признаках категорий можно спорить бесконечно, но для нашего небольшого обсуждения этой условности вполне достаточно. Я специально решил не добавлять в эти категории упоминание длительности опыта работы, потому что считаю, что интерес и любопытство важнее, чем годы, потраченные на написание геттеров и сеттеров в соответствии с каким-нибудь корпоративным руководством по стилю.
Когда вы входите в мир работы профессиональным программистом, то скорее всего получаете самый нижний ранг — так называемую категорию «молодо-зелено». Вероятно, вам назначат ментора, который будет контролировать вашу работу и обеспечивать её соответствие стандартам и нормам компании. У вас не будет особого выбора в том, что вы делаете, и вам придётся выполнять всевозможные задачи; и интересные, и довольно скучные, к которым никто не хочет прикасаться.
Спустя несколько лет протирания полов на уровне «молодо-зелено» ваш начальник наконец понимает, что вы уже много раз подтвердили свои способности и готовы к большему. Вы получаете почётный титул «примерно понимает, что делает».
С великой зарплатой приходит и великая ответственность. На этом этапе от вас ожидают более-менее независимой работы, без необходимости стороннего контроля каждого принятого вами решения. Возможно, вам доверят проектирование небольшой части проекта. Возможно, вы возьмёте на себя задачи более опытного разработчика, пока он находится в заслуженном отпуске. Возможно, вам поручат проверять результаты работы кого-то с более низким рангом. Возможно, вы будете общаться с заказчиком для того, чтобы разрешить его проблемы. Эта категория очень широка, так что кто знает?
Кроме того, категория «примерно понимает, что делает» — это ещё и этап отделения зёрен от плевел. Начальники всегда находятся в поиске того, кто сможет взять на себя их обязанности. Теперь, когда вы уже множество раз доказали свои навыки, для них настало время подумать о будущем и «вырасти» до более ответственной должности. Как вы смотрите на то, чтобы руководить чуть более объёмной фичей, имея под своим начальством всех этих «молодых и зелёных» программистов?
В конце концов, это вполне очевидный шаг для вас. Когда компания растёт и пополняет свои ряды новыми сотрудниками, кто будет ими руководить? Очевидно, что не новые и неопытные люди и очевидно, что не ворчливые ветераны организации, которые уже отвергли предложение о подобной должности в прошлом.
Если вы решите пойти по этому пути, то можете подумать, что ничего не изменится: вы по-прежнему будете выполнять свою обычную работу, за исключением того, что придётся тратить часть времени на координирование других людей. Иногда эта небольшая часть времени, посвящённая координированию, расширяется до полномасштабного координирования и вы полностью перестаёте заниматься той работой, которую вы раньше выполняли хорошо.
Следовательно, ваши собственные знания тоже останавливаются на уровне «примерно знает, что делает», потому что нельзя совершенствоваться в задачах, которые не выполняете ежедневно. Похоже, художники полностью осознают эту проблему: они знают, что нужно изучать мастеров прошлого и тратить многие часы, чтобы самому стать мастером. С другой стороны, разработчики ПО часто приравнивают годы работы к некому свидетельству об уровне знаний. Десятилетнее сидение в офисе и перекладывание бумажек не сделают вас мастером программирования. На это способно только написание программ.
Обречён ли я вечно оставаться на уровне «примерно знает, что делает», если выберу путь руководителя? Нет, некоторые люди достаточно упорны, чтобы добраться до категории «опытных» программистов, но очень немногие готовы вкладывать такие усилия сверх своей работы по координированию.
Как показано выше на придуманном графике, чем выше вы взбираетесь, тем сильнее становится одиночество. На самом деле никто не знает, как выглядит истинное соотношение категорий, но можно его прикинуть, понаблюдав за окружающими. Особенно в курсе ситуации на рынке те, кто проводит собеседования (хотя это зависит и от «гламурности» вашей компании. Знаменитые компании привлекают более качественных специалистов). Кто-то говорит, что большинство профессиональных программистов имеет опыт меньше пяти лет работы, но проверить это утверждение невозможно.
Наконец, вы достигаете категории «опытный», в которой ваши обязанности и политическая власть снова возрастают. Обычно от вас ждут, что вы будете выдавать готовые проектные решения и прогнозы выполнения задач, устранять сложные баги, выполнять ревизию кода, проводить собеседования с кандидатами, совершенствовать внутренние процессы, заниматься менторством и играть в офисную политику.
Так как вам приходится заниматься всеми этими дополнительными задачами, вы уже не можете тратить столько же времени на программирование, как на более низких уровнях; теперь вы вынуждены делегировать написание кода остальной части команды. В конце концов, один человек, как бы велик он ни был, не способен всё успеть.
Так кто же тогда разрабатывает все фичи?
Из-за того, как работает система ранжирования программистов, в среднестатистической компании будет большая толпа неопытных работников и горстка тех, кто способен решать сложные задачи. Поэтому подавляющее большинство ПО написано теми, кто всё ещё осваивает ремесло.
Сколько на самом деле знают программисты «молодо-зелено»? Не очень много, и это сказывается на качестве программ. Да, опытные программисты берут на себя задачи по проектированию, но это не спасёт вас, если реализация великолепной архитектуры будет ужасной.
Если вы хотите производить высококачественное ПО, вам нужны и опытные люди «за станком», которые не просто делегируют поступающие сверху приказы. Как часто вы встречали огромный кусок переусложнённого кода, который можно было значительно упростить, если бы разработчики лучше знали свою среду разработки? Обычно существует множество различных подходов, однако некоторые решения лучше других.
Но постойте! Как узнать, что сработает, а что нет? Вам нужно наработать интуитивное понимание, и единственный способ сделать это — много программировать. Нельзя научиться, читая случайно найденные статьи, необходимо практиковаться, чтобы усвоить уроки, о которых вы читали.
Комментарии (20)
OlegZH
07.12.2021 13:33+2Если вы хотите производить высококачественное ПО, вам нужны и опытные люди «за станком», которые не просто делегируют поступающие сверху приказы.
Значит, и программировать должны уже сложившиеся программисты. А начинающие программисты просто должны быть рядом и, тщательно наблюдая за происходящим, высказывать собственные (надеюсь, что свежие) идеи и параллельно (!!) разрабатывать свои собственные решения, которые никто не будет включать в реальный проект. Когда собственные решения по качеству перейдут определённую черту, программиста можно уже включить в группу разработчиков.
Если сравнивать работу программиста с работой художника, то программисту, как и художнику, нужно много раз повторять решения одних и тех же рутинных задач (поиск, сортировка, генерация, кеширование, хеширование, файлы, графика, работа с устройствами, с базами данных). В этом смысле, все профессии одинаковы. И в один прекрасный момент такого специалиста пригласят для реальной работы. Ведь, и хирурги когда-то начинают. Страшно и подумать, если бы...
Alexey2005
07.12.2021 13:49+1мне кажется, что частично эта проблема вызвана корпоративной системой стимулов.
А в мире Linux аналогичная проблема с чем связана? Там на оптимизацию забивают так, как никакой Microsoft даже не снилось.
Ставим KUbuntu и видим, что Windows 10 грузится 12 секунд, а KDE — сорок.
А потом доставляем пакеты, и когда в терминале появляется надпись «processing triggers for man-db» и процесс установки подвисает в таком состоянии минут на пять, становится окончательно понятно, что корпоративная культура тут ни при чём.
elisoff
07.12.2021 14:16В windows не всегда так хорошо все было с загрузкой. Если я не ошибаюсь,то МС в качестве производительность mssql сервера приводит TPS на SUSE.
tzlom
07.12.2021 16:54+1Ставим KUbuntu и видим, что Windows 10 грузится 12 секунд, а KDE — сорок.
Ну а у меня наоборот линукс быстрее грузится, казалось бы почему?
Ну например какова отзывчивость дексктопа через 12 секунд на винде? Мак вон вообще подгружает изображения окон как они были до выключения и рисует их как будто всё уже загружено пока в фоне приложения запускаются.
Когда я втыкаю USB наушники в Windows я жду пока они подхватятся системой, а в линуксе звук появляется пока ещё пальцы за свисток держатся. Как вы думаете, будут ли они вообще когда нибудь рассматривать это как недоработку, если речь идёт о переделке всего PnP ?
PocketM
07.12.2021 17:23+2Windows 10 грузится 12 секунд
У windows есть прикольный чит — fast startup. Винда при выключении делает что-то типа гибернации для всего, кроме юзерских приложений. Образ включенной винды хранится на диске и при включении просто считывается в память.KDE — сорок
Отнесите Ваш компьютер в ремонт, он сломался… А если серьезно, то ситауция странная. Возможно у Вас медленный HDD, но и винда на таких диска еле шевелится…
Я на линуксе очень давно и еще помню шестую убунту на своем компе. У меня никогда небыло ситуации, что линукс грузился медленнее винды. Чаще бывало наоборот.
И Вы наверное забыли многочасовые установки обновлений у windows…
Edit: 15 секунд с учетом ввода пароля грузится федора. После этого ОС полностю загружена и больше никакой активности HDD и CPU нет
DistortNeo
07.12.2021 17:37У windows есть прикольный чит — fast startup. Винда при выключении делает что-то типа гибернации для всего, кроме юзерских приложений. Образ включенной винды хранится на диске и при включении просто считывается в память.
Да. Если вы посмотрите в аптайм системы, то увидите, что выключение компьютера его не прерывает.
Побочный эффект этого чита: dual boot будет его ломать.
elisoff
07.12.2021 13:50+2Статья прекрамно начал про проблемы конкретной компании, у которой со скоростью работы софта проблемы. А потом странным образом разговор пошел про опыт программистов и -"Да, опытные программисты берут на себя задачи по проектированию".
Программисты не берут задачи , им их поручают или дают. Компания по своему менеджменту не продуктовая ,а коммарческая ,нацеленная на продажи. При чем продажи лицензий ,а не продукта, с полным отказом от ответствонности. Компания прилагает все усилия для продажи лицензий и экономии(как и любая другая) на ФОТ "опытных программистов". Вполне закономерный результат если стоимость техподдежки, пищущей какие либо отписки, обходится дешевле дополнительных отделов "опытных программистов".
Cheater
07.12.2021 14:12+5для опытного программиста рендерер терминала — это просто забавный проект на выходные, совсем не требующий многолетних долгих исследований.
Это ложь. Абсолютно согласен с мейнтейнером майков. Отрендерить даже просто текст (не то что окно терминала) - это задача запредельной сложности, которая будет "забавным проектом" только для того, кто профессионально занимается рендерингом текста, а таких разработчиков не думаю что много. Классический ликбез по тому, насколько сложен на самом деле рендеринг юникода: Text Rendering Hates You.
Если же принять, что у нас уже готовый рендерер текста и не надо реализовывать POSIX terminal а требуется просто тупо динамически выводить текст в окно с прокруткой как можно быстрее, то в этой задаче всё равно куча нудной и не всегда тривиальной работы по подготовке "сцены действия" (общение с glyph cache, вычисление размеров, вызов рендера). Плюс оптимизация рендеринга, там тоже rocket science, разработчики alacritty вон с kitty и прочими за миллисекунды рубятся. В alacritty например файл src/display/mod.rs, занимающийся рендером, содержит ~800 строк, и это при том что alacritty опирается на кучу мощных готовых библиотек, таких как glutin. Плюс "рендерить как можно быстрее" не катит, тк ещё необходимо соблюдать плавность рендеринга, и более быстрый рендерер часто бывает и более рваным, так что я бы ещё глянул как выглядит терминал после того пулл-реквеста.
cepera_ang
07.12.2021 16:01+7Блин, я думал тут будет более детальный рассказ про ситуацию, потому что она была реально эпичная и там Casey Muratori психанул от того, что для всего гигантского Майкрософта оказалось слишком сложным сделать быстрый терминал (в стиле: "куку! Компьютерные игрушки рендерят терминал со скоростью 500 кадров в секунду, поверх целого 3д мира вместе со всей его графикой и физикой, а вы говорите, что напечатать моноширинный текст в прямоугольную сетку — это повод для диссертации?!") и за выходные накатал прототип терминала, который держит на встройке 7000фпс и дампит текст со скоростью в несколько гигов в секунду и заодно поддерживает всякие юникоды/смайлики/расцветку символов лучше чем родной терминал, о котором шла исходная речь (и что ему приводили как пример невероятной сложности, из-за чего всё тормозит). А потом ещё и запилил серию видео лекций с объяснениями почему эта задача реально простая, чтобы не говорили корпоративные любители всё усложнять.
Вместо этого простыня воды, совершенно неинтересная без контекста.
svr_91
07.12.2021 16:43+3Компьютерные игрушки рендерят терминал со скоростью 500 кадров в секунду, поверх целого 3д мира
Вродебы все не так просто (хотя я многого не знаю), и задача вывода текста в тойже игре гораздо сложнее чем кажется. Можно заметить в каком-нибудь 3-м ведьмаке, когда во время диалогов дальность прорисовки прям сильно снижается. Хотя казалось бы, просто буковки на экран вывести
cepera_ang
07.12.2021 18:07Речь о выводе текста в консоль, это проще, чем полный рендер произвольного форматированного текста, о котором пишут комментарием выше моего. Впрочем в игре дальность прорисовки вполне может снижаться из тех соображений, чтобы не гонять почем зря полигоны в тот момент, когда пользователь гарантированно будет сосредоточен на чтении.
deinlandel
08.12.2021 10:36+3Дальность прорисовки в Ведьмаке снижается не из-за буковок, а из-за того, что используется другое, более «кинематографичное» (и более нагружающее видеокарту) освещение, модели с максимально качественными LOD-ами и так далее. А на фон там, как правило, накладывается достаточно сильный DoF, так что разработчики экономят на рендеринге и так «замыленного» задника.
antirek
08.12.2021 06:57поэтому и есть open source, и возможность запускать приложения на ОС от других разработчиков
nuald
08.12.2021 09:40Во многих серьёзных компаниях есть два пути развития: people manager & individual contributor. Где-то начиная с senior developer можно выбирать и вполне можно оставаться программистом (individual contributor). Например technical leader (моя текущая позиция) эквивалентна director (позиция для менеджера). Естественно, есть дополнительные роли и все-равно не будет много времени на программирование, но с другой стороны, можно продолжать заниматься любимой работой, а не разбираться кто кого обидел.
Единственное исключение я знаю Facebook, они там требуют от всех программировать и у них "горизонтальные" отношения. Деталей дальше не знаю, так как не успел написать решения для их задачек (подсказка всем кто почему-то хочет у них работать - не используйте C++ или что-то другое сильно типизированное, потому что они не принимают псевдокод и надо чтобы программа корректно компилировалась и работала. Естественно, никаких IDE, все в онлайн блокноте с компилятором + несколько предустановленных библиотек).
nuald
08.12.2021 18:41-1auto не поможет, когда надо написать алгоритм числодробилку, в которой миллиарды надо умножать на миллионы (какой тип будет у "auto c = a * b;", если a и b int?). В этом плане Python с его прозрачным bignum намного удобнее. Другой пример - сложные коллекции (например, словарь со составным ключом и другой коллекцией для значений). В любом случае, это просто был совет, и это ваше полное право его игнорировать.
Earthsea
Да ничего подобного она не испытывает. Если проблема не влияет на количество продаж, то на нее закрывают глаза, вот и все. Windows покупают не ради быстрого терминала.
В проекте уровня Windows во-первых сеньора нельзя напрячь в выходные, его нужно снять с другой задачи (более важной по мнению Microsoft) и дать ему эту. Во-вторых, демо-прототип за 2 дня это еще не рабочее решение, которое будут делать далеко не 2 дня. Потом решение еще нужно будет протестировать, внести изменения.
Это ляпнул дешевый сотрудник, которого посадили отвечать на комментарии за мелкий прайс. Скорее всего вообще не разработчик, даже не джуниор.
sshmakov
Скорее всего сеньор в Микрософт не программирует. У него есть более важная задача - сидеть на совещаниях. По крайней мере так говорится в статье.
v1vendi
Это ляпнул разработчик, у которого на гитхабе 1000+ подписчиков, в 6 раз больше, чем у вас на хабре комментариев.
densmoke
По опыту общения с разработчиками МС там большинство такие выскочки, которые в РФ были бы максимум джунами. Искренне не понимаю, как они добрались до должности сеньора в МС