«Программирование без эго» — перевод понятия egoless programming. Смысл в том, что разработчик осознанно отодвигает эго на второй план ради эффективности в работе. При разработке Web-payment.ru — сайта о платежных системах с каталогами и мониторингом обменников — мы стараемся руководствоваться этими принципами. Если кто-то благодаря этому посту тоже начнет применять их в своем проекте, мы будем очень рады, ведь они помогают избежать конфликтов и несут в себе добро. Перевод и редактура moigagoo.О программировании Стивен начал говорить с отцом за 2 недели до его смерти. Стивену было 22, он изучал графдизайн в колледже и почти получил степень бакалавра. Его отцу было 62 — больше, чем большинству отцов. Когда он только начинал программировать в Теннессийском техническом университете в 60-е, то писал код на Фортране на перфокартах. Знал он очень много.
Как раз в том семестре Стивен впервые столкнулся с программированием, и оно уже увлекало его. Стивену оно казалось волшебным и могущественным занятием, во многих смыслах более творческим, чем визуальный дизайн.
Когда Стивен приехал домой на каникулы, отец рассказал ему про 10 заповедей программирования без эго. Он распечатал их, и вдвоем со Стивеном они обсудили каждый пункт. Из-за внезапной смерти отца Заповеди стали одной из немногих программистских тем, которые Стивен успел обсудить вместе с ним. Возможно, именно поэтому они ему так запомнились.
Итак, вот 10 заповедей программирования без эго, из книги 1971 года «Психология программирования»:
- Поймите и примите как факт, что наделаете ошибок. Задача в том, чтобы найти их рано, пока они не попали в продакшн. Слава богу, в нашей индустрии, за исключением ребят из Лаборатории реактивного движения НАСА, которые делают софт для управления ракетами, ошибки обычно несмертельны. Мы можем и должны учиться, смеяться и продолжать работу.
- Ваш код — не вы. Помните, что вся суть проверки кода в том, чтобы найти ошибки, и они обязательно найдутся. Не воспринимайте как личное оскорбление, когда это случится.
- Не важно, насколько вы прокачанный спец. Кто-нибудь всегда знает больше, и у него можно поучиться. Стоит только попросить. Ищите и принимайте то, что говорят другие, особенно когда кажется, что это вам не нужно.
- Не переписывайте код без консультации. Есть тонкая грань между «поправить код» и «переписать код». Почувствуйте разницу и преследуйте изменения стиля в рамках штатной проверки кода, а не как одинокий рейнджер.
- Относитесь к людям, которые знают меньше вас, с уважением, почтением и терпением. Люди, напрямую не связанные с IT, но которым часто приходится иметь дело с разработчиками, считают нас в лучшем случае зазнайками, а в худшем — нытиками. Не кормите стереотипы гневом и нетерпеливостью.
- Единственное, что в мире постоянно — это перемены. Будьте готовы к переменам и принимайте их с улыбкой. Взгляните на изменения в требованиях, платформе или инструменте как на вызов, а не как на неудобство, которое надо побороть.
- Единственный истинный авторитет дают знания, а не положение. Знание порождает авторитет, а авторитет порождает уважение. Хотите уважения в среде, где нет места эго — культивируйте знания.
- Боритесь за то, во что верите, но непринужденно признавайте поражение. Поймите, что иногда ваши идеи будут отклонять. Даже если вы и правы, не надо мстить и говорить «А я предупреждал, что так будет». Никогда не превращайте отвергнутые идеи в мученический стон или боевой клич.
- Не становитесь «тем кодером в углу». Не будьте человеком в темном кабинете, который выходит только за колой. Кодера в углу не видно, с ним сложно связаться, его сложно контролировать. У такого человека нет голоса в открытой, кооперативной среде. Включайтесь в беседы и будьте частью сообщества своего офиса.
- Критикуйте код, а не людей. Будьте добры к людям, но не к коду. Насколько возможно, пишите позитивные комментарии, направленные на улучшение кода. Свяжите комментарии с принятым в команде стандартом кода, техзаданием, повышением производительности и т.д.
Стивен и сегодня всегда держит этот список поблизости. Он уже помог Стивену стать более хорошим программистом. Иногда Стивен представляет, что еще мог бы посоветовать ему отец, будь он рядом. Хоть он и не знает наверняка, но уверен, что папа гордился бы им, пока он помнит о Заповедях.
Чтобы узнать больше об отце Стивена, читайте книгу Вклад Фрэнка Буша в IT-профессию, составленную его коллегами по ТТУ.
Комментарии (37)
fralik
09.04.2015 16:05-20Стивен стал «более хорошим программистом», а его подруга Света — более лучше одеваться.
CosmoMegaSuperBlaster
09.04.2015 16:49+12Если на то пошло, то «хороший» — это не сравнительная форма, поэтому «более хороший» — вполне легальная конструкция. «Лучше» — это сравнительная форма от «Хорошо» и это, вообще-то, наречие, так что здесь двойной промах.
fralik
09.04.2015 17:20+5Да-да, я еще подумал об этой фразе и понял, что не прав. Но все это предложение с более хорошим как-то режет слух. Похоже, что только мне.
В оригинале там It has already helped me be a better programmer. Он уже помог Стивену стать лучше в программировании, как вариант.
webkumo
10.04.2015 00:58+9Я не понимаю… ЗАЧЕМ пытаться сохранить конструкцию максимально близко к оригиналу? Можно же перефразировать:
Благодаря этому списку Стивен достиг новых высот в программировании.
или
С помощью этого списка Стивен улучшил свой навык программирования.
leventov
10.04.2015 11:071. Ненужная «художественность» 2. Опять кривое калькирование
Единственный нормальный вариант «Стивен стал лучше программировать/писать код». «Лучше в программировании» — кривость по типу «сумки от Армани»webkumo
10.04.2015 12:14Ваш вариант тоже плох — на причину ничто не указывает… А с причиной — всё будет калькированием…
leventov
10.04.2015 12:19Я просто опустил эту часть, потому что она неизменна: «Благодаря этому списку Стивен стал лучше программировать/писать код». Однако это привело к написанию двух лишних комментариев, значит зря опустил.
webkumo
10.04.2015 13:50Именно поэтому перевод — это весьма не просто… И после технического перевода лучше проходиться и слегка «охудожествлять».
jcmvbkbc
09.04.2015 17:27К.О. говорит, что это дословная цитата из одного видео.
Mithgol
10.04.2015 13:36![[спасибо, Капитан Очевидность]](http://habrastorage.org/getpro/habr/comment_images/a24/d62/a70/a24d62a700d1c9476c531ff46c0d9d6d.png)
jcmvbkbc
10.04.2015 13:52О, вот ещё одному человеку нечего делать, как было мне.После прочтения комментария на который я отвечал, мне показалось, что его автор протестует против использования «более лучше одеваться». Спустя некоторое время я конечно понял, что протест был против сравнения «стал более хорошим программистом» с «более лучше одеваться», но комментарий менять было уже поздно. На вашей картинке КО можно заменить на Слоупока.
Areso
09.04.2015 16:16+6Наш препод на 1м курсе любил говорить примерно так: «когда пишете код, пишите его так, чтобы ваш сосед мог не только сдуть его у вас, но понять и объяснить каждую строчку, каждую функцию и процедуру...».
При этом, в универе я делал (из эгоистичности) делал ровно обратное…
vayho
09.04.2015 16:34+3… а еще позже я понял что чтение кода это такой же навык как и написание, поэтому учитесь не только писать код но и читать любой даже самый самый плохой…
AndrewNikolaevich
09.04.2015 16:38+2Часто чтение чужого кода, да и перечитывание своего занимает достаточно много времени. Поэтому понятно написанный код и умение читать код могут значительно увеличить производительность труда. (Капитан Очевидность гордился бы мной )
saboteur_kiev
10.04.2015 13:28+2Черт, это же неизведанная область!
Сейчас столько всего написано о том, как правильно писать хороший код, и практически ничего о том, как читать плохой. Срочно организовать курсы по чтению плохого кода и срубить денег.
zorba_buddha
09.04.2015 16:18+7Периодически встречаю подобные вещи и удивляюсь — зачем об этом говорить, если оно и так понятно?
Ан нет, всё время забываю, что люди не такие, как я, что все разные и думают по разному.
Согласен с правилами, спасибо за статью.
MichaelBorisov
09.04.2015 19:14+3Аналогично. Я думал, что заповеди будут гораздо более жесткими. А так, если кто-то нарушает даже это — то ему следует задуматься, подходит ли его характер к выбранной профессии вообще.
Тем не менее сама идея верная. Думаю, что заповеди надо ужесточать и добавить к ним следующее:
1) Если вам нужна библиотека, и вы решаете, что лучше: взять готовую или написать свою — берите готовую. Даже если она хуже, чем та своя, которую вы бы написали. Вы на этом сэкономите драгоценное время, которое может стать решающим в конкурентной борьбе вашего бизнеса или бизнеса вашего работодателя;
2) Действие п.1 сохраняется даже в случае, если готовая библиотека стоит серьезных денег. Решение должно приниматься ответственным руководителем предприятия. Если вы простой разработчик — оставьте решение директору. Если вы одиночка и сам себе директор — считайте выгоду по деньгам и рискам, умножая в 2-3 раза оцениваемые временные затраты, а не исходя из тщеславия.
3) Соблюдайте стандарты. Не изобретайте велосипед в виде форматов файлов, интерфейсов компонентов, протоколов обмена и т.п., если есть стандартные решения.
eaa
09.04.2015 23:21+4Программирование — не всегда бизнес. Ваши «заповеди» касаются чисто бизнеса и мало имеют отношения к программированию как таковому.
MichaelBorisov
09.04.2015 23:51Профессиональные программисты, по определению, зарабатывают этой деятельностью себе на жизнь. Они прямо или косвенно продают результаты своего труда другим людям, а не только пользуются ими сами. А где есть продажа — там есть рынок. И там есть бизнес. Игнорировать его законы — это путь к неприятностям либо для себя, либо для работодателя.
Даже если вы пишете программу исключительно для собственного использования — то приведенные в статье и добавленные мной принципы тоже верны. Они позволят вам быстрее получить результат с минимальными затратами и получить ценный опыт, применимый в будущем.
Ну, а если вы занимаетесь любительским программированием ради самого процесса — то там, конечно, никаких ограничений нет. Ваяйте в свое удовольствие что угодно и как угодно. Но я бы не сказал, что любительское программирование в настоящее время преобладает над профессиональным. Все-таки больше программ (и количественно, и качественно) разрабатывается профессионалами. Поэтому ваша фраза: «мало имеют отношения к программированию как таковому» не верна.VolCh
13.04.2015 21:43Создавать продукт и продавать его — две разные профессии. Обычно программист продает не результат труда, а труд.
MichaelBorisov
13.04.2015 22:51Труд, который не приносит результатов, никому не нужен. Поэтому продается только тот труд, который их приносит — это раз. Во-вторых, некоторые программисты продают именно результаты труда (готовые продукты). В-третьих, если фирма, нанимающая программиста, получает прибыль за счет продажи его разработок — то речь идет о косвенной продаже результатов, о которой я в комментарии упомянул. Это справедливо и для случаев, когда программист разрабатывает продукты сугубо для внутреннего использования работодателя, если эти продукты как-то влияют на получение работодателем прибыли или грантов.
saboteur_kiev
10.04.2015 13:33Цель чего-либо — конечный продукт, а программирование просто инструмент.
И если слишком долго думать над эстетикой того, как молотком стукнуть по гвоздю, а может молоток стоит предварительно покрасить в желтый а гвоздь в красный, чтобы лучше видеть, или сперва просверлить тонкую дырочку, чтобы забить с одного удара, то конечная цель уже не видна за процессом. Из-за чего мы видим множество отличных, но но незавершенных или не взлетевших проектов, которых обошли менее щепетильные в выборе инструмента конкуренты.
В конечном счете, вся цель хорошего кода в в 90% заключается в том, чтобы сделать его дешевле в долгой перспективе.
mmMike
10.04.2015 05:11+3П1. весьма спорный (если код не opensource или не крупной фирмы типа Oracle). На эти грабли неужели не наступали? Нужно сделать мелкое изменение или найден критичный баг, а производителя уже нет или он вас игнорирует или запрашивает безумные деньги за изменение/исправление бага… и т.д. и т.п.
А соотношение кода, например, 1/10 (1- стронняя библиотека, 10 — ваш код.)
Во многих случая, для критичный сервисов, которые будут развиваться, лучше сделать свою реализацию и изобрести свой велосипед.
А для не критичных или законченных продуктов… ну зачастую дешевле и проще взять готовое.
Так что не стоит из этого делать догму.
nekt
10.04.2015 16:21Если в проекте используется десятка два сторонних библиотек, то в 2-3 из них обязательно найдутся баги. Обычно просто неприятные, реже — критичные. Но про остальные библиотеки вы даже не вспомните — все время существования проекта они будут просто работать. Но в памяти останутся только библиотеки с багами.
nekt
10.04.2015 16:18Стороннюю библиотеку нужно брать всего лишь в двух случаях:
1. Если вы можете сами написать ее — значит у вас займет меньше времени исправить готовую библиотеку, чем написать полностью свою.
2. Если вы не можете сами написать ее — значит в написанной с нуля библиотеке будет больше ошибок, чем в уже готовой.
AndrewNikolaevich
Правило №13пишите код так, будто бы его будет читать крайне неуравновешенный и жестокий человек, который знает где вы живёте, знает код от домофона и умеет открывать замки.7voprosov
Ну а так так многие люди сочли бы разумной стратегией работы с «крайне неуравновешенным и жестоким человеком, который знает код от домофона и умеет открывать замки» отказ от такой работы, то это правило преобразуется до еще более простого — не пишите код.
eaa
тогда уж еще проще: "не пишите"
AndrewNikolaevich
Нет, писать надо. Писать хорошо, а хорошо писать ещё лучше. ©
Sykoku
Ударение на каком слоге?
stardust_kid
Не делайте
velvetcat
Если вдуматься, то ничего хорошего в этом совете нет.
leventov
Всегда бесил этот «перл» своей бессмысленностью. Псевдоостроумная версия фразы «Пишите код хорошо», которая не дает ровным счетом никакого совета, как именно надо писать.