×

Всему, что нужно знать, чтобы быть хорошим программистом, я научился в детском саду

(перевод, оригинал: thecodist.com — All I Need To Know To Be A Better Programmer I Learned In Kindergarten).

Программирование — сложная штука, но многие из принципов, которые делают программиста лучше, не слишком отличаются от того, чему нас учили тети-воспитательницы.

Вдохновением для списка ниже послужило эссе «Все что мне действительно нужно знать, я узнал в детском саду», автор Robert Fulghum (www.robertfulghum.com).

1. Делись со всеми

Используйте Open Source насколько это возможно, и по мере сил старайтесь вносить свою лепту. Совместная мудрость большого сообщества лучше ограниченной позиции нескольких больших корпораций.

2. Играй честно

Дайте другим технологиям, фреймворкам, методологиям и мнениям шанс. Не считайте свое мнение единственно верным. Другие подходы к проблеме вполне могут оказаться лучше Ваших; взглянуть на них непредвзято делу не повредит.

3. Не дерись

Не стоит атаковать людей только потому, что они используют. Net, Java или PHP. Иногда технологии могут оказаться гораздо более полезными и удобными чем представляется. У человека можно научиться гораздо большему, если при этом не стараться растереть его в порошок.

4. Убирай за собой

Старайтесь выдавать на-гора код, который работает. Не стоит ожидать, что QA найдет все ошибки за Вас. Тестируйте свой код интенсивно, и вглубь (юнит-тесты) и вширь (функциональные тесты).

5. Не бери чужое

Придерживайтесь лицензий на код, библиотеки или инструменты, которые Вы используете, не надо воровать, а затем говорить что невиновен.

6. Извинись, если кого-то обидел

Просмотр кода (Code Review) — хорошая, но редко применяемая идея. Обучение менее опытных программистов идет на пользу команде. Но не нужно открыто критиковать, если что-то не так — обучать людей не значит принижать их. Иногда Вас будут слушать, иногда нет. Иногда можно многому научиться у людей, которых Вы считали ниже себя по уровню.

7. Мой руки перед едой

Старайтесь разобраться в поставленной задаче прежде чем писать код. Напишите небольшой прототип, поищите аналоги в сети, пообщайтесь с людьми, которые с этим уже сталкивались. Создать с нуля что-то, с чем не приходилось работать или иметь дело раньше — непростая задача. Конечный результат будет намного лучше, если начинать работу с пониманием проблемы.

8. Смывай

Не нужно бояться заменить, переписать, реструктурировать или вообще выбросить кусок плохого кода или неудачный проект. Иногда «если не знаешь что делать — выбрось и забудь» — лучший подход. Никогда не надо слишком любить свой код.

9. Теплое печенько и холодное молоко полезны для тебя

Да, у программиста должна быть удобная и комфортная рабочая обстановка. Хорошее кресло, тихое рабочее место, пристойный компьютер и инструменты, делающие разработку лучше и проще — все это очень важно. Менеджеры должны осуществлять функцию зонтика, оберегающего разработчиков от всего того нехорошего, что стекает сверху. Как программист, Вы должны ожидать достойного к себе отношения. Если же наниматель не может этого обеспечить, стоит задуматься о поиске более адекватного места работы.

10. Живи полной жизнью — учись и думай, рисуй и крась, пой и танцуй, играй и работай

Мне нравится организация труда в Google, где 20% своего времени ты можешь посвятить работе над тем, что, как тебе кажется, этого заслуживает. Неплохо было бы также предоставлять комнаты для отдыха или игр — программирование это тяжелый умственный труд, иногда просто необходимо дать голове отдохнуть. Избегайте постоянных переработок — упавшее качество работы сведет на нет прирост в производительности, достигнутый ценой ночных бдений.

11. Отдыхай после обеда

Работа 24 часа в сутки не делает вас более продуктивным. Делайте перерывы, уйдите домой, поспите немного. Часто мне удавалось решать запутанные задачи просто уходя домой, и решение приходило в голову по дороге с работы или на следующее утро.

12. Выходя на улицу, смотри по сторонам, держись за руки и не убегай далеко

Общество полезно для души — читайте блоги, изучайте новые языки и фреймворки, участвуйте в дискуссиях и смотрите что делают другие. Только делая свою работу, не стать лучшим программистом. Зарывшись в работу с головой, вы рискуете в один прекрасный день обнаружить что все переменилось и ваши знания устарели.

13. Помни о чудесном. Это как маленькое зернышко в горшке с землей — корни растут вниз, а росток поднимается вверх, и никто на самом деле не знает, как и почему, но это так.

Каждый день что-то новое и удивительное происходит в мире программирования и технологий. Узнайте об этом. Удивитесь. Узнавайте что-то новое каждый день. Это помогает поддерживать свежесть мышления и актуальность навыков и расширяет кругозор.

14. Рыбки и хомячки и мыши и даже маленькое зернышко в горшке — все они умирают. И мы тоже.

Код становится старым и умирает. Временами лучше просто смириться с этим и сделать все заново. Незачем держаться за ужасный код только для того, чтобы сохранить вложенные деньги.

15. А теперь вспомни книжки про Дика и Джейн [1] и первое слово которое ты выучил — самое главное слово — СМОТРИ.

Вы не узнаете ничего, если не попробуете это сделать. Все, чему я научился в программировании, было результатом ни к чему не обязывающей возни с новыми интересными вещами. Каждое утро я читаю кучу сайтов и узнаю что происходит в индустрии; я делаю так с самой начала моей профессиональной карьеры в начале 80-х (тогда это означало чтение каталогов и журналов)

Видите, программирование — это просто, если посмотреть глазами пятилетнего ребенка.

[1] — Дик и Джейн — герои популярных в свое время в США книг для
обучения чтению, см. en.wikipedia.org/wiki/Dick_and_Jane

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




31 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Коментар порушує правила спільноти і видалений модераторами.

Все сравнения хороши.

Работа 24 часа в сутки не делает более продуктивным.

Все татары кроме я.

Ну да в том что я еще не поменял работу.

ну это было бы слишком просто, не находите? просто поговорите со знакомыми программистами — я думаю и процента не наберётся таких, которые бы испытали хотя бы половину из описанных ужасов.

А потом менеджеры типа СОТОНы будут говорить какого хрена заявление об уходе на столе

менеджеры типа СОТОНы давно не удивляются действиям программистов типа Dima:) (для справки: если бы у меня был программист, которого я бы вынужден был регулярно заставлять работать по 12 часов вместо 8 ми, то его бы у меня просто не стало)

2 COTOHAА в чем же проблема? Ну да в том что я еще не поменял работу.А потом менеджеры типа СОТОНы будут говорить какого хрена заявление об уходе на столе:)

2 Dimaкакой огромный список ужосов. самое страшное то, что к статье все эти ужасы не имеют никакого отношения.это я к тому, что в вашем случае скорее всего не в менеджерах дело...

Очень правильная статья. Программист это как тврчество, всегда хочется знать больше, читать статьи и применять свои знания на практике. Вот только менеджеры этого понять не могут. По их представлению программист это такая приставка к компютеру которой должно нравится работать по 12 часов в сутки, делать нудную однотипную работу. Я вот не могу понять почему если ты программист, то менеджеры так удевляются что они хотят работать и получать за это деньги. Хотят как и все нормальные люди отдыхать, раюотать не по 12 часов, а по 9 как и все. Не бежать на работу в очередной испорченный выходной чтобы решить очередную проблему кастомеров за решение которой они не платят сверхурочно так как «надо чувствовать ответственность за свой код». Почему считают что дни отпуска это всего лишь цыфры, а когда попросишь отпуск то его можно взять раскидав по году по 3−4 дня. Что такое 3−4 дня? Даже съездить отдохнуть не успеешь. В худшем случае отпуск дается деньгами. И потом когда человек устает до такой степени что для него деньги это всего лишь цыфры так как всеравно нету времени их потратить, менеджеры удевляется почему он не доволен и начинают считать что человек не любит свою работу. Не любит работать по 12 часов при оплате за 8, не любит выходить по выходнным при появлении очередной частой проблемы и т п. Менеджеры практикуют «работу на износ», при этом если человек устал и не может сделать какую-то простую задачу его постоянно начинают тыкать носом. А потом начинается смена работы только для того чтобы просто банально отдохнуть, взять свой законный отпуск не маленькими кусочками, а как белый человек.

ну и зануды вы =) классная статья.

Непогана стаття. Як мнемонічне правило дуже навіть нічого.Тільки я сумніваюся шо початківці оцінять їх... поки не станешсвоїм досвідом на кілька сотен граблів, над такими вічними іправильними мудростями рідко задумуєшся:)

Статья просто Библия для Программиста распечатать и под стекло.

Статья понравилась.

Общество полезно для души — читайте блоги, изучайте новые языки и фреймворки, участвуйте в дискуссиях и смотрите что делают другие. Только делая свою работу, не стать лучшим программистом. Зарывшись в работу с головой, вы рискуете в один прекрасный день обнаружить что все переменилось и ваши знания устарели.

Каждое утро я читаю кучу сайтов и узнаю что происходит в индустрии;

Посоветуйте как кто это делает на практике? Какие сайты, методы получения и отбора информации и т.п.А время и способы ИЗУЧЕНИЯ новых языков/технологий?

2 eugene_nСмотрит. Но вопервых всем всего не продиктуешь. А если продиктуешь — то не обязательно уследишь. Юниформенность тяжело прививать. Но при этом ее важность тяжело переоценить. Если будет чуть чуть времени может статью сюда о юниформенности напишу. А во вторых работодатели часто и сами исповедуют такие взгляды. Или не хотят лезть в технологические решения. Вот и получаются потом продукты которые целый технологический зоопарк.

Не заботься о юниформенности, пусть каждый пишет на том языке котором хочет. А то что продукт написаный на нескольких технологиях выходит намного дороже и сложнее в поддержании — проблема работодателя.

Я не понял. А что «работодатель» не смотрит на проектную документацию, прежде чем дать отмашку на старт проекта? И каждый джун пишет, как он хочет?

Проблема с переписыванием кода в том что часто переписав «грязный и некрасивый», но отлаженный и провереный кровью пользователей код програмист получит красивый, но совершенно сырой продукт. На который уйдет еще много крови внедренцев. А в случае если переписка идет от лени понять и разобраться — то в этом новом продукте будет недоставать 70% всяких побочных сценариев. Поддержка которых и является качеством продукта. И после добавления всех этих сценариев код опять перестанет быть «чистым и красивым» так как обычно они противоречат архитектуре. Хорошо переписать продукт может только тот кто его хорошо понял. А то действительно, как в детском саду — увидел некрасивый код — не разбирайся, перепиши все заново. Только часть предложений о переписке исчезает сама собой когда человек не поленился разобраться. А часть решается небольшим рефакторингом походу работы. Не напрягайся, не перерабатывай. Заботься исключительно о своей личной продуктивности, выучи сто новых технологий (их которых только две-три доведут до ума и до коммерческого использования, так это на самом деле происходит). Не заботься о юниформенности, пусть каждый пишет на том языке котором хочет. А то что продукт написаный на нескольких технологиях выходит намного дороже и сложнее в поддержании — проблема работодателя. Тем более что другой програмист получив потом твой код не будет долго страдать обучаясь твоим любимым языкам и фреймворкам — он исходя из советов этой статьи просто возьмет все выкинет и перепишет на своих. Embrace the diversity. А твоя продуктивность — проблема работодателя, который должен тебя обеспечить терпеливыми и денежными инвесторами. Причем желательно инвесторами, а не клиентами, ибо от клиентов «стекает слишком много нехорошего», менеджеры могут не успеть уберечь. Хотя со многими вещами написанными здесь полностью согласен. Но без ответственности за свою работу и за ее результат (не код, а результат) не стать хорошим програмистом. Хотя не скрою что ответственность «не полезна для души» и выводит из зоны комфорта и иногда даже лишает хорошего настроения: -) Но сомневаюсь что хорош тот програмист за результат работы которого страшно отвечать. Даже если с ним очень интересно попить пиво и поговорить о технологиях: -)

Спасибо, это замечательный перевод хорошей статьи

2 Дмитрий

В программировании плохо то, что очень многие программисты относятся к программированию как к чистому творчеству, забывая, что программирование — это, все-таки, бизнес, и что они делают продукт, который будет продаваться пользователям, и это главное, а не создание идеального кода.

Есть такое:)

Представьте себе картину: производство телевизоров...

А зачем представлять? Я очень долго проработал на разраработке электроники. И до сих пор в шоке от некоторых подходов к разработке софта. Точнее, к стадии проектирования, прототипирования и документирования. Тем не менее, не раз был свидетелем того, как полугодовой труд инженеров, монтажников, настройщиков и слесарей вывозился на свалку.

eugene_n, если не сделали хорошо с первого раза, где гарантия, что сделают хорошо со второго? Я же не говорю, что не надо никогда, ни при каких условиях переписывать код.Просто я много раз был свидетелем того, как вполне работоспособный код, требующий небольшой модификации, может быть, не очень хорошо написанный, перепроектировался и переписывался начисто только потому, что программисту он казался плохим, или программист считал ниже своего достоинства разбираться в чужом «плохом» коде. Решение о переписывании кода должно приниматься с учетом возможных финансовых затрат и рисков. Это и есть профессиональный подход к делу.В программировании плохо то, что очень многие программисты относятся к программированию как к чистому творчеству, забывая, что программирование — это, все-таки, бизнес, и что они делают продукт, который будет продаваться пользователям, и это главное, а не создание идеального кода.Представьте себе картину: производство телевизоров. Вот, инженеры спроектировали новую модель телевизора, разработка завершена, модель готовится к производству. Хочу заметить: телевизор полностью готов и прекрасно работает. И тут в кабинет руководителя вбегает взъерошенный инженер и говорит, что схема телевизора ни к черту не годится, она нерациональна, некрасива, все нужно переделать, и предлагает руководителю отменить запуск производства и начать разработку сначала. О том, сколько денег уже потрачено на разработку, инженер, конечно, как-то не думал — он же занимается творчеством. Представляете себе реакцию руководителя?

2 ДмитрийА что делать, если код действительно неудачный? Ждать, пока проблемы не начнут нарастать в геометрической прогрессии? Или все-таки списать потери и сделать хорошо заново? Умение признать ошибки, списать потери и начать все заново — очень важная вещь, и не только в программировании.

По поводу готовности к выбрасыванию и переписыванию кода — вообще сомнительный совет. Практика показывает совершенно обратное.Наоборот, многим программистам не хватает понимания того, что программный код, какой бы он ни был «некрасивый», «корявый» или «несовершенный», прежде всего предназначен для того, чтобы решать поставленную задачу, а не радовать программистов своей гениальностью.И любой код стоит денег.Больше того — код среднестатистической программы прямо таки «золотой». За те деньги, которые были потрачены на его разработку, его можно было бы высечь в каррарском мраморе золотыми литерами. Так что любителю рефакторинга можно посоветовать перед тем как отважно «выкидывать» код, сначала посчитать, сколько денег было потрачено на его разработку, отладку и тестирование.В свете вышесказанного этот совет: «не нужно бояться заменить, переписать, реструктурировать или вообще выбросить кусок плохого кода или неудачный проект» звучит как «не бойтесь выкинуть очередные 10 000 $, потраченные вашим инвестором, если вы решили, что код неудачен».

Зернышко в горшочке не умирает. Если там есть земля (условия), оно становится полноценным растением.Если условий нет, оно засыхает и в зависимости от растения, оно может ожить вновь набрать соки.Так и в любой области, старая идея, никому не нужная и не верно понятая, в другое время может оказаться бесценной.+если уж проводить аннологию с родительскими наставлениями, надо вспомнить, что подрастая все дети рано или поздно понимают, что далеко не все, что говорили им родители — это верно.Родители не всегда самые умные на свете люди. Они умны в определенных ограниченных условиях.Изменяются условия — изменяется подход.Так и с правилами. Любая схемка поведения всегда хуже своего развитого чувства такта, меры и проч.Ну и креатив, конечно, он ведь и в кодинге есть...

Аналогия с детским садом мне кажется надуманной и пошловатой.К тому же, соблюдение упомянутых правил само по себе вряд ли сильно может повлиять на эффективность труда. Существует множество других, гораздо более существенных, факторов.По поводу способности расслабиться — это сугубо индивидуально. Некоторые только и делают, что расслабляются на работе — им можно было бы посоветовать, наоборот, собраться. Другие — работают сверхурочно, только потому, что им интересна их работа.

Согласен со всем, кроме высказывания: «Иногда „если не знаешь что делать — выбрось и забудь“ — лучший подход». Если бы тот, кто написал статью прочел бы книгу Спольского «Джоэл о программировании», то он наврятли бы остался при этом же мнении

Правильно, Аня. И если провести аналогию с детским садом, то нужно утраивать занятия в актовом зале, шаги и приседания под музыку и танцы попарно:)

Программистам, мне кажется, иногда не хватает элементарной способности расслабиться. Многие не умеют перестроиться, разгрузить мозг.

Стараюсь придерживаться правил как работодатель: устал, выдохся, чересчур успокоился, потушил огонь — иди погуляй, хоть на 2 дня. Эффективность работы моих любимых программистов невероятно высокая.

Макс, убери autorefresh страниц. Я писал очень длинный пост, после чего браузер решил, что пора обновить страничку и всё, что я писал — исчезло.

кстати, у меня наверное был не правильный садик:) как-то так половина пунктов в садике мне озвучена не была...

2 сергейэто потому что «а на следующий день постараться наверстать упущенное» почти никогда не работает.а память штука избирательная — я вот например совершенно точно помню, что как минимум 2 алгоритмически сложных задачи я решил во сне. и как-бы если начать про это рассказывать, как автор текста «мне удавалось решать запутанные задачи просто уходя домой, и решение приходило в голову по дороге с работы или на следующее утро», то получается, что спать на работе полезно. только никто не считает разы, когда с работы ушёл, а ничего в голову не пришло. так что работодателя понять можно:)

2Сергей: наверное этот пункт более подходит фрилансерам:)

11. Отдыхай после обедаРабота 24 часа в сутки не делает более продуктивным. Делайте перерывы, уйдите домой, поспите немного. Часто мне удавалось решать запутанные задачи просто уходя домой, и решение приходило в голову по дороге с работы или на следующее утро.

ха, если бы действительно можно было бы так... допустим, если башка сегодня мутная, и программирование ну никак не идёт, то просто уйти после обеда домой, а на следующий день постараться наверстать упущенное... так нет, почти все работодатели не понимают этого и им нужно, чтобы сотрудник сидел на рабочем месте чётко от 9 до 18...

Из предложенных тегов «дети» и «юмор» наиболее полно подходят к тексту.

согласен с предыдущем оратором, мне понравилось

Спасибо, действительно интересно.

Підписатись на коментарі