- PVSM.RU - https://www.pvsm.ru -
Каждый знает, что бывают «десятикратные» программисты, которые в 10 раз более производительны, чем программист обыкновенный. Мы не можем измерить производительность, поэтому и не знаем, правда ли это. Но на самом деле людей необыкновенно производительных существует немало, достаточно, чтобы доказать существование «десятикратного программиста».
Как же они этого добиваются?
Часто считают, что десятикратная производительность вытекает из десятикратных способностей или десятикратных знаний. Я так не думаю. Не хочу сказать, что способности или знания бесполезны. Но за много лет я заметил, что самое главное тут — десятикратная разборчивость. Фокус в том, чтобы постоянно уклоняться от паршивой работенки.
А под ней я имею в виду совсем не «интеллектуально неудовлетворительную». Определение паршивой работы — в том, что ее результат идет прямо в унитаз.
Я сам переделал немало паршивой работы, особенно когда был неопытным и наивным. (Одно из больших преимуществ опыта в том, что человек становится менее доверчивым — а это более, чем компенсирует испарение из памяти школьных знаний).
Я приведу вам просто показательный пример работы тяжелой, развивающей и отправляющейся прямо в унитаз: мои приключения десятилетней давности с фиксированной точкой.
Вы знаете, что такое «арифметика с фиксированной точкой»? Я вам расскажу. Это когда вы работаете с целыми, но делаете вид, что это дроби, неявно предполагая, что целое x на самом деле представляет собой x/2^N для какого-то значения N.
Чтобы сложить два числа, вы просто вычисляете x+y. Для умножения вам нужно x*y>>N, потому что просто x*y — это будет x*y/2^2N, правильно? Еще необходимо быть осторожным, чтобы эта дрянь не переполнилась, как-то разбираться с разными N в одном выражении и так далее.
Тогда, в начале 90-х, я портировал программы на процессор, который разрабатывали в нашей фирме. Аппаратный блок для плавающей точки ему не запланировали — «мы будем все делать с фиксированной точкой».
Вот часть моих тогдашних дел:
Месяцы и месяцы я работал в полную силу, выдавая сложный и отлаженный код — все, как обычно.
А вот что мне на самом деле нужно было сделать:
Почему вся эта эпопея выродилась во многие месяцы паршивой работы, за которые можно было сделать что-то полезное? Потому что я не знал, что к чему; потому что я не догадывался, что можно спорить с начальником; и потому что работа была творческая и интересная. Которая очень быстро отправилась в унитаз.
Самое сложная вещь в «управлении» этими десятикратными людьми — теми, о которых все знают, что они очень производительны — убедить их заняться задачей. (все остальное уже гораздо легче — они сами знают, что почем; если они взялись что-то делать, то оно будет сделано).
Вы ждали совсем другого, признайтесь? Я имею в виду, что если вы такой продуктивный, то о чём вообще переживать? Вы работаете быстро; худшее, что вас ждёт, — что в результате ничего не получится — и тогда вы быстро займётесь чем-нибудь другим, ведь так? Я имею в виду, что это медлительным и не очень производительным людям надо быть переборчивыми — они же более медленные и у них меньше возможностей переключиться на что-то новое — ведь так?
Но это всего лишь оптическая иллюзия: более производительные люди не настолько быстро работают — не в десять раз быстрее. Причина, по которой они кажутся в 10 раз более быстрыми — в том, что почти ничего из ими сделанного не выбрасывается — в отличие от кучи работы, которой занимаются другие.
А выкинутые дела в производительности не учитываются. Вы расцениваете человека как «парня, который сделал Х», где полезность Х известна всем — и забываете о всех тех Y, которые не были особенно полезны, несмотря на усилия и талант, пошедший в их изготовление. Даже если в этом было что-то виновато — менеджер, или недостаток времени, или что там еще.
Если брать известные примеры — вы знаете Кена Томпсона по Си и Юниксу — но не по Плану 9, в самом-то деле, и не по языку Go. Пока что наоборот — Go привлек ваше внимание только потому, что это детище тех парней, которые сделали Юникс. Вы знаете Линуса Торвальдса, хотя Линукс — это клон Юникса, а Гит — клон Биткипера — собственно, потому что это клоны успешных продуктов, которые имели прекрасные шансы преуспеть, если бы появились вовремя.
Первое, на что вы смотрите — не на оригинальность и не на то, как сложно было писать, или как хороша эта вещь по какому-нибудь конкретному критерию: вы смотрите, как ее можно использовать.
Десятикратный программист, как правило, устраивает настоящую войну, только чтобы не заниматься тем, что никогда не будет использоваться.
Один из этих умных людей спросил меня как-то о checkedthreads [1], которые я только что закончил: «Кто-нибудь это использует?» с той самой фирменной иронией. Я сказал, что не знаю; на «Hacker News» кто-то написал в комментариях, что, может, попробует.
Я знаю, что это замечательная штука; с ее помощью можно найти все ваши ошибки в многопоточных программах. Но это не замена pthreads, вам придется писать код, используя новые интерфейсы — хорошие, простые интерфейсы, но не те, которые вы уже применяете. Так что вполне вероятно, что заинтересует моя библиотека немногих; хотя Helgrind [2] и thread sanitizer [3] имеют кучу ложных срабатываний, они по крайней мере работают с теми интерфейсами, которые люди широко используют.
Зачем мне тогда вообще было этим заниматься? Потому что для написания первой версии понадобился всего один день (я еще не решил тогда завести параллельные вложенные циклы и всё такое), и я посчитал, что какой-то шанс будет, если я напишу о моей программе в блоге (что я делаю прямо сейчас). Если бы я написал несколько постов, в которых объяснил, как практически можно отследить ошибки [4] в старомодным параллельном, разделяющем общую память, коде на С даже легче, чем на Rust, или Go, или Erlang, тогда, может быть, люди обратили бы внимание.
Но и так слишком много шансов на провал среди той десятикратной толпы, которую я знаю лично — не стоит и пытаться. Даже если мы используем что-то типа checkedthreads у себя и очень даже успешно. Собственно, иронический вопрос я услышал от того парня, который вложил немало труда в эту самую внутреннюю версию — потому что очень вероятно, что у нас программа будет использоваться.
Видите? Не заниматься тем, что скорее всего провалится — вот где производительность.
Как выбрать то, над чем стоит работать? Есть множество вещей, которые следует учесть:
Вы можете легко продолжить этот список; основная его идея — какова вероятность, что я закончу эту штуку и ее потом будут действительно использовать? Эта же идея рекурсивно применима к каждой функции, подфункции и строчке кода: целое благодаря им будет полезным? И не потратить ли мне время на что-то другое, что принесет больше пользы?
Конечно, все еще сложнее; некоторые полезные вещи по разным причинам ценятся выше других. Вот где появляется Ричард Столман и требует, чтобы мы называли Линукс «GNU/Линуксом», потому что GNU написала большую часть пользовательских программ. И хотя я не собираюсь называть систему «Гну-Линукс», в его претензиях, к сожалению, есть своя правда, в том смысле, что да, к сожалению, некоторая тяжелая и важная работа не так заметна, как другая тяжелая и важная работа.
Но справедливость — это уже другая тема. В конце концов, вряд ли десятикратная производительность даст вам десятикратную компенсацию.
Поэтому не так-то много поводов «жульничать» и казаться более производительным, чем вы есть. Главная причина, по которой люди производительны — это шило в заднице, не дающее покоя, а не какие-то осязаемые выгоды.
Вот что я хочу сказать: чтобы сделать больше, вам надо не столько добиваться успеха быстрее (хотя и это не повредит), сколько пореже испытывать неудачу. И не все неудачи вызваны недостатком знаний или опыта; большинство их бывает, когда программу бросают в той стадии, когда ее еще невозможно использовать — или потому, что ее с самого начала никто использовать не собирался.
Поэтому я, как человек, написавший немало кода для унитаза, считаю, что добиваться производительности надо не столько работой, сколько отсутствием работы — не заниматься тем, что в конце концов будет выкинуто на помойку.
Автор: Иосиф Крейнин
Оригинал: www.yosefk.com/blog/10x-more-selective.html [5]
Автор: gatoazul
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/33452
Ссылки в тексте:
[1] checkedthreads: https://github.com/yosefk/checkedthreads
[2] Helgrind: http://valgrind.org/docs/manual/hg-manual.html
[3] thread sanitizer: https://code.google.com/p/data-race-test/wiki/ThreadSanitizerAlgorithm
[4] отследить ошибки: http://www.yosefk.com/blog/checkedthreads-bug-free-shared-memory-parallelism.html
[5] www.yosefk.com/blog/10x-more-selective.html: http://www.yosefk.com/blog/10x-more-selective.html
[6] Источник: http://habrahabr.ru/post/178553/
Нажмите здесь для печати.