7 привычек высокоэффективных программистов

Автор оригинала: SeattleDataGuy
  • Перевод
Начинающие программисты тратят много времени, набирая знания, необходимые для прохождения интервью. Они решают задачи и улучшают свои резюме. Но самое интересное начинается после того, как программист получает вожделенную должность — в каком-нибудь стартапе, в Google, в Amazon или где-нибудь ещё. Нередко оказывается так, что те знания и навыки, которые помогли человеку найти работу, не соответствуют тому, что надо знать и уметь для выполнения его повседневных задач.



Автор статьи, перевод которой мы сегодня публикуем, говорит, что команда, в которой он трудится, воодушевилась рассказом TechLead’a о 7 привычках высокоэффективных программистов. Члены команды решили высказать собственные мысли по этому вопросу. Здесь, в форме советов, приведён разбор 7 навыков эффективных программистов.

1. Учитесь читать чужой код



Все кроме вас пишут ужасный код. Именно поэтому способность программиста работать с чужим кодом — это ценный навык. Этот навык даёт тому, кто им обладает, много хорошего.

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

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

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

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

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

Способность понимать некачественный код, кроме прочего, помогает во внесении изменений в подобный код. Иногда это означает редактирование кода, в котором некто разбирается не очень хорошо. Например, однажды нам попался скрипт, в ходе работы которого были задействованы такие технологии, как PowerShell, Python и Perl. В Perl мы разбирались не очень хорошо. Однако нам удалось достаточно глубоко разобраться в проекте, удалось понять сущность происходящего и внести в код необходимые изменения. Это стало возможным благодаря тому, что мы поняли тот код, который нам нужно было изменить, включая и код Perl-скриптов.

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

2. Развивайте в себе чутьё на неудачные проекты


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

В больших компаниях всегда имеется множество проектов, над которыми трудятся программисты. Но далеко не все эти проекты будут завершены. Далеко не все из них принесут пользу. Среди них могут быть и такие, которые не имеют коммерческого смысла (по крайней мере — для программиста). Некоторые проекты, в целом — перспективные, могут страдать от недостатков управленческого характера. Это не значит, что вы должны отказываться от неких идей сразу же после того, как поняли, что вы не согласны с теми, кто их предлагает. Однако если автор идеи не может внятно объяснить то, какую пользу компании может принести проект после его завершения, тогда, возможно, такой проект не стоит и начинать.

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

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

3. Избегайте совещаний



Кем бы вы ни работали, без совещаний вам не обойтись. Это касается абсолютно всех. Дело в том, что вам нужно находить общий язык с менеджерами проектов, пользователями, клиентами. Однако у совещаний есть одна неприятная особенность: иногда они внезапно занимают едва ли не весь рабочий день. Именно поэтому очень важно научиться избегать ненужных совещаний. Пожалуй, лучше будет не «избегать совещаний», а стремиться к тому, чтобы «контролировать время, которое уходит на совещания». Цель этого заключается в том, чтобы тратить время только на те совещания, которые действительно необходимы, на такие, которые способствуют развитию проектов.

Самый распространённый метод управления временем, которое уходит на совещания, заключается в том, что ежедневно выделяется двухчасовой блок, который превращается в непрерывное совещание. Многие назначают повторяющиеся совещания на время, которое они считают наиболее подходящим. Эти совещания используются для обсуждения рабочих вопросов.

Ещё один способ управления временем — приходить на работу раньше других для того, чтобы успеть справиться со своими делами. Мы, например, предпочитаем поступать именно так. И, кстати, если в офис прийти пораньше — работать там будет гораздо спокойнее чем обычно. Большинство людей, приходящих пораньше, похожи друг на друга. Они это делают для того, чтобы успеть справиться со своей работой. Поэтому они не мешают работать другим.

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

4. Освойте GitHub



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

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

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

Если вам нужна «шпаргалка» по GitHub — сделайте её.

Научитесь продуктивно работать с GitHub. При этом неважно то, как именно вы этого добьётесь.

5. Пишите простой код, который легко поддерживать



Некоторые начинающие программисты имеют следующую черту: они пытаются, в одном проекте, реализовать всё, что знают. Дело тут в том, что они стремятся использовать в каждом фрагменте создаваемого ими кода свои знания об объектно-ориентированном программировании, о структурах данных, о паттернах проектирования и о новых технологиях. Это неоправданно усложняет код из-за того, что при таком подходе на решаемую программистом задачу легко могут повлиять, например, те паттерны проектирования, которые он уже реализовывал на практике.

Существует баланс между слишком сложными структурами проектов и простым кодом. Паттерны проектирования и объектно-ориентированное программирование нацелены на то, чтобы упрощать код в крупномасштабных проектах. Однако чем больше мы прибегаем к абстрагированию и инкапсуляции, чем больше в наших решениях «чёрных ящиков» — тем сложнее отлаживать код таких решений.

6. Научитесь говорить «нет» и расставлять приоритеты


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

Надо отметить, что способность расставлять приоритеты и умение говорить «нет», на самом деле, может представлять собой два отдельных навыка. Однако эти навыки очень близко друг с другом связаны. Там, где возникает необходимость в одном из них, обычно нужен и второй. Расстановка приоритетов — это когда время тратят только на то, что оказывает серьёзное влияние на компанию. А умение говорить «нет» — это отказ от выполнения работы, которую должен выполнять кто-то другой.

Научиться тому, о чём мы говорим, может быть непросто, так как люди часто стремятся к тому, чтобы решить каждую задачу, которую перед ними ставят. Особенно это характерно для тех, кто только что отучился и получил свою первую работу. Раньше, на учёбе, им давали задания, с которыми они вполне справлялись. Теперь же, на работе, они ожидают того же и стремятся к тому, чтобы никого не разочаровать.

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

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

7. Научитесь думать о том, как именно будет использоваться ваша разработка



Есть один навык, на владение которым сложно организовать проверку в ходе собеседования. Ситуации, в которых он нужен, тяжело воспроизвести во время учёбы. Речь идёт об умении видеть ошибки, которые может совершить конечный пользователь программной системы. Мы обычно называем это «продумыванием сценариев использования программы».

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

Например, так как большая часть работы программиста заключается в поддержке кода, ему часто приходится менять код, который тесно связан с чем-то другим. Даже простое изменение чего-либо требует поиска всех тех мест, где это используется. Например, меняться может объект, метод, API некоей системы. Если внести в систему непродуманное изменение — это может «поломать» работу совершенно неожиданных частей программы. Причём, речь идёт об изменениях любого масштаба — даже о чём-то вроде смены типа в базе данных.

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

Это относится и к разработке более крупных частей систем, таких, как модули или микросервисы. Приступая к решению подобных задач нужно подумать о том, как именно будут использоваться сущности, которые планируется создать. Нужно поразмыслить о сценариях их неправильного использования, о различных вариантах их использования, и о том, что тем, что вы создаёте, возможно, будут пользоваться совершенно неочевидными на первый взгляд способами.

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

Итоги


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

Уважаемые читатели! Что вы посоветовали бы освоить тому, кто стремится к профессионализму в программировании?

RUVDS.com
916,11
RUVDS – хостинг VDS/VPS серверов
Поделиться публикацией

Комментарии 80

    +8
    Уважаемые читатели! Что вы посоветовали бы освоить тому, кто стремится к профессионализму в программировании?
    Идти своим путем. Выработать те практики и навыки, которые будут максимально эффективны именно для него.
      +9
      И поменьше впечатляться статьями, подобной этой.
      +14
      Если вы читаете чужой код и встречаете в нём что-то такое, что вам не нравится, постарайтесь не молчать об этом. Это поднимет ваш авторитет в глазах сослуживцев.

      — Вы все говно! (с)

      Всегда думал, что сначала стоит узнать — почему выбрано такое решение. Предложить своё, обсудить возможные вариант.
        +5
        Думаю «не молчать» как раз об этом.
          +8
          Авторитет зависит не только от факта обсуждения чужого кода, но и от тона, с которыми это делалось и ещё от множества не технических факторов.
            +9
            Мне вот следующий абзац ещё больше понравился.

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

            Оно вроде как бы и не враньё — статус оно таки упрочит. Вот только вам этот статус не понравится, скорее всего.
            Самое мягкое, что вы услышите от программиста в ответ на претензии к недостатку хороших комментариев в его коде — «ну так возьми и напиши».

            То же самое про поддержку — чаще всего есть причины, по которым некоторый код тяжело поддерживать. Например, потому что система мгновенных транзакций делалась из системы заявок, которая делалась на основе чата, который делался на основе форума (которым проект был N лет назад). И автор этих переделок вас, конечно, выслушает, но вряд ли согласится с предположением о том, что все проблемы от недостатка планирования наперёд.
              0
              «Красота в глазах смотрящего.» © Оскар Уайльд
              +80
              Когда уже все эти советчики научатся отличать GitHub от git.
                +2
                Как только выполнят пункт 4
                  +1
                  Bitbucket? Не, не слышали. А там что-то свое?
                    +5
                    И частную программу Git от систем контроля версий.
                      –2
                      git-scm.com
                      Git is a free and open source distributed version control system

                      Я чего то не понимаю?
                        +2
                        Да. Вы не понимаете отличия конкретной реализации системы контроля версий, от целой категории такого софта.

                        Учить надо не столько гит, сколько в целом системы контроля версий. Чтобы небыло попаболи когда приходите в новую контору, а там вместо гита пластик или меркуриал.
                          –1
                          Тогда будьте добры — напишите название для
                          системы контроля версий
                          используемой Git, если Git — это только название конкретного приложения.
                          Я вот читаю(https://en.wikipedia.org/wiki/Git#cite_note-linusGoogleTalk-11):
                          These criteria eliminated every then-extant version-control system, so immediately after the 2.6.12-rc2 Linux kernel development release, Torvalds set out to write his own
                            +2
                            Где вы в моем ответе увидели слово «приложение»?

                            Разжую чутка. Есть такое понятие — «система контроля версий». Их есть много реализаций — svn, git, mercurial, plastic, TFS. Git — конкретная реализация этого понятия. Которая имеет общие черты с другими реализациями — так же как и автомобили имеют общие черты, несмотря на конкретные реализации.

                            Так вот. Лучше всего учить и понимать как работает абстрактная система контроля версий. А потом уже спроецировать эти знания на конкретную реализацию. Грубо говоря — вы учитесь ездить на автомобиле, а не на конкретной модели. И еще грубо говоря — в резюме вы сможете написать «умею работать с системами контроля версий», а не конкретно с гитом. Который вообще не панацея.
                              –7
                              Да вы, мсье, хамло. И, видимо, ответить не сможете.

                              А чтобы не быть голословным по поводу хамства:
                              1) В компьютерном сленге часто используется слово софт, произошедшее от английского слова «software», которое в этом смысле впервые применил в статье журнала American Mathematical Monthly математик из Принстонского университета Джон Тьюки в 1958 году.
                              Wiki
                              2) «software» переводится как «программное обеспечение»
                              3) Прикладное ПО — программа, предназначенная для выполнения определённых задач и рассчитанная на непосредственное взаимодействие с пользователем. В большинстве операционных систем прикладные программы не могут обращаться к ресурсам компьютера напрямую, а взаимодействуют с оборудованием и другими программами посредством операционной системы.

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

                              так что ваше добавленное оправдание по примеру автомобилей — совсем не оправдание.

                              0
                              Шутка была в том, что github это не только Git, а целая инфраструктура.
                              Кстати checkout оттуда можно сделать и при помощи SVN, хотя это другая система контроля версий.

                              В частности git это лишь одна из систем контроля версий.

                              P.S. А ещё git это контент-адресуемое по SHA-1 хранилище объектов
                                0
                                Так я ничего и не говорил про github. Меня, как человека пару месяцев занимающегося изучением вопросов CI/CD очень заинтересовало отличие «частной программы» от «системы контроля версий».
                                0
                                напишите название

                                DVCS ?

                                  0
                                  DVCS — распределенная система контроля, только одно из свойств контроля версий.
                                  Да и к тому же говорилось именно про Git, а не весь спект возможны приложений и систем:
                                  отличия конкретной реализации системы
                                +1
                                Вы не в тренде :)
                                Сейчас модно тупо лоббировать переход на Git вместо изучения других систем контроля версий, даже если они уже вполне успешно используются.

                                P.S. Оригинальной статье сарказм не чужд
                                +1

                                Mercurial, SVN...

                                  –2
                                  Картошка, ракеты…
                              0
                              Понятно что они путают теплое с мягким, но в защиту хочу сказать что в плане Git Гитхабу альтернативы по сути нет, ибо Гуглокод уже ридонли официально, остальные проекты полумертвые, а с тем же Гитлабом лично у меня как-то не сложилось, не знаю, какой-то он не такой, я хотел на него пересесть, ибо люблю альтернативы, но как-то не зашло, поэтому в мире Git это уже стало нарицательным по сути, как ксерокс или джип, уже же никто не говорит, мол, да когда уже эти обыватели научатся отличать копир от ксерокса?)
                                0
                                Bitbucket?
                                  0
                                  Ни одного проекта на нем не встречал, каким бы крутым бы он ни был. Возможно изначально Гитхаб был популярнее, и разрабы не видят смысла поддерживать несколько проектов в разных системах одновременно. Я просто констатирую факт, что есть — то есть.
                                    0
                                    Вы измеряете ценность инструмента крутизной проектов, его использующих?
                                      0
                                      Слово «крутизна» относилась к Bitbucket.
                                      0
                                      По проектам — Unity держит всякое-разное на битбакете.
                                      По популярности — да, гитхаб более раскручен.
                                      Про поддержку проектов — ерунда. Сделать пуш не в один remote а в два требует ровным счетом ничего.

                                      По факту — битбакет и гитлаб круты тем, что их можно поставить на локальные сервера. В первую очередь.

                                      Ну а так да, сравнение с ксероксом — прям в точку.
                                        0
                                        Сделать пуш не в один remote а в два требует ровным счетом ничего.

                                        Возможно, просто та же IDEA вроде как может только в одну SVC коммитить за раз. Во всяком случае насколько я знаю. У меня только GitHub, поэтому его подключил и лью все на него, может и в несколько можно…

                                        По факту — битбакет и гитлаб круты тем, что их можно поставить на локальные сервера.

                                        Это да, это да, тут спорить не буду, самому очень не хватает своего Гитхаба, люблю все хранить у себя. Пока в виде компромисса храню все в приватных репозиториях, надеясь что однажды они не станут публичными :/ Утешаю себя что для Гитхаба это могут быть многомиллиардные потери, ибо в Штатах очень любят получать компенсации за моральный ущерб, поэтому всяко думаю у них все в порядке с этим, а взломать можно все, было бы желание.
                                          0
                                          Возможно, просто та же IDEA вроде как может только в одну SVC коммитить за раз.

                                          В VSCode это 3 дополнительных нажатия правой кнопкой мыши.
                                            0
                                            IDEA вроде как может только в одну SVC коммитить за раз. Во всяком случае насколько я знаю.

                                            Да, я тоже за одну оправку могу запушить в один из репозиториев. Но повторить дело для другого репозитория — дел меньше чем на минуту.
                                            Занудство QA
                                            только в одну SVC коммитить за раз

                                            VCS
                                              0
                                              VCS

                                              Ой, ну конечно, господи, как неловко-то, 10 лет разработки и такая ошибка) Редко просто эту аббревиатуру использую…
                                          +1
                                          Все наши проекты (фирмы, где я работаю) на битбакете. Другое дело, что проекты «закрытые». Но они есть, кода очень много.

                                          *сугубо свои «домашние, R&D» держу сразу и на гитхабе, и на битбакете. Но опять же, репозитории закрытый характер носят.

                                          *да, локальный битбакет был одним из плюсов
                                    0
                                    Похоже на краткий пересказ книги Clean Coder
                                      +6
                                      Как стать высокоэффективным программистом (если верить статье) — приходи пораньше, хреначь, не отвлекаясь, и не забывай пушить :)
                                        +3
                                        Сам процесс написания кода — это лишь часть работы по решению некоей задачи. Нетрудно создать программу, которая хорошо работает на вашем компьютере. Но код, с которым работает кто-то другой, легко может вести себя совсем не так, как изначально ожидалось. Как код, который вы пишете, будет использоваться в продакшне? С какими системами ему придётся взаимодействовать? Частью каких процессов он может стать? Не покажется ли он слишком примитивным и ограниченным программисту, которому придётся поддерживать его через несколько лет? Это — очень непростые вопросы.

                                        Вопрос откуда взялись вопросы, если в оригинале их не было :)
                                        Simply coding and programming is only part of the problem. It’s easy to create software that works well on your computer. But there are a lot of ways deploying code can go wrong. Once in production, it’s hard to say how code will be used and what other code will be attached to your original code. Five years from now, a future programmer might get frustrated at the limitations of your code.
                                          +3
                                          Пишите простой код, который легко поддерживать

                                          Или как шутил наш техлид: «Подходит ко мне заказчик, смотрит мне в глаза и спрашивает: Ребята, просто скажите — сколько? (драматическая пауза) я все пойму, просто скажите — сколько? (еще одна драматическая пауза с заглядыванием в глаза) сколько стоит, чтобы вы писали код без багов ?»
                                            +2
                                            без багов не бывает.
                                              +3

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

                                              +11
                                              «У вас столько нет»(с)
                                                +1
                                                Помнится в ВУЗ-е самую первую лекцию по АиЯП лектор начал с фразы: Программирование без ошибок есть теоретическая абстракция. -)
                                                  0
                                                  Мы не знаем.
                                                  Это не к нам.
                                                  Мы не знаем к кому это.
                                                    0
                                                    Вопрос «сколько?» напомнил мне вопросы типа «когда?». Типа сколько времени на разработку? Когда программа будет готова? Вопросы начальства/заказчика вроде бы справедливые, но точно ответить бывает не всегда легко. Вот вопрос «за сколько секунд поднимешь мешок цемента на 3-й этаж» — всегда простой — ответ на него легко вычислить, а если даже не вычислить, то уж засечь время на примере. А «кагда завершишь программу?» — не для каждой программы ответ однозначен и точен.
                                                      0
                                                      coub.com/view/1s775f

                                                      Кстати полная лекция очень даже ничего. Анекдот про обезьяну и бильярдный шар можно цитировать при каждом старте нового проекта.
                                                      0
                                                      Без багов — это ему в NASA надо.
                                                        0
                                                        Ну-ну…
                                                        Заголовок спойлера
                                                        image
                                                        image
                                                        image
                                                        image
                                                        image
                                                        0

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

                                                        +15
                                                        5. Пишите простой код, который легко поддерживать

                                                        Уважаемый филин, а есть у вас тактические рекомендации, как мышкам стать ёжиками?
                                                          +3
                                                          В оригинальной статье тэг «Юмор» — это дело привычки :)
                                                          Высокоэффективные программисты так привыкли.
                                                          Можно ещё написать что высокоэффективные программисты имеют привычку высокоэффективно программировать o_O
                                                          +4

                                                          Ужасный перевод — давайте читать в оригинале, и его обсуждать.

                                                            +7
                                                            Можно тогда уж и на оригинале обсуждать.
                                                            Причём даже комментарии аналогичны:
                                                            GitHub is not Git.

                                                            Not including any documentation is horrible advice.

                                                            This article is a joke, right?!

                                                            Причём с ответом автора что да — это статья-шутка

                                                            Вообще это мысль — к переводу статьи вставлять переводы комментариев :)
                                                            –1
                                                            Ваш собственный код должен быть спроектирован настолько качественно, чтобы он был бы понятным и без документации. На самом деле, у хороших программистов не возникает нужды в документировании кода. Это — пустая трата времени, того времени, которое лучше было бы потратить на программирование и на проведение совещаний.


                                                            Сколько еще будут писать вот эту глупость, это я как имеющий большой стаж по SQL(PL/SQL) спрашиваю. В одной компании где это же обсуждали (писать или не писать комменты) я выдал код на 4 строчки в SQL который решал очень стандартную задачу, которая часто встречалась всем, но никто так и не догадался что он делает. По факту если у вас не какой нибудь декларативный язык, сам код отвечает на вопрос КАК (это видно), а не на вопрос ЧТО (это ниразу не очевидно).
                                                              +3
                                                              Это был «юмор», в оригинале сарказм был выделен зелёным, но при переводе выделение потеряли, как и это:
                                                              Everyone but you writes terrible code.

                                                              Все кроме вас пишут ужасный код.
                                                                +1
                                                                По факту если у вас не какой нибудь декларативный язык

                                                                SQL — декларативный язык программирования
                                                                  –1
                                                                  SQL — декларативный язык программирования


                                                                  ммм не совсем… лично мне он напоминает цикл for/foreach вывернутый на изнанку… как тесто в сосиске:) Просто те кто привык работать с модельками ООП не совсем понимают что кроме извлечения данных у SQL есть куча возможностей их обработки, запросы на пяток страниц (с рекурсивом и аналитическими функциями:)) для ораклистов это норма.
                                                                    0
                                                                    Декларативный — декларативный. Другой вопрос в том, чтобы с ним хорошо работать, надо еще иметь хотя бы среднее понимание того, что творится под капотом. Например, те же рекурсивные и аналитические функции мы в нем все-таки декларируем, а вот как их база внутри реализовывает — это лучше знать, чтобы не понаписать тормознутого говна.
                                                                +2

                                                                оригинал пропитан сарказмом, который, к сожалению, не так явно виден в переводе.

                                                                  +1
                                                                  1. Избегайте совещаний


                                                                  • в чат входит Agile
                                                                    Agile: Ха. Хаха. Хахаха. ААААаааааааххахааахахахахахаха....
                                                                    +1
                                                                    и попадает на ретро после прочтения статьи ;)
                                                                    0
                                                                    «чутьё на неудачные проекты» — это типа чтобы боссу сказать, что «мне проект не нравится, и я над ним работать не буду»? Ну-ну. Гораздо полезнее тогда чутье на неудачные команды или компании.

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

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

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

                                                                          0
                                                                          Только начальники обычно это не сильно любят. А уж менеджеры объяснять клиентам и подавно.
                                                                            0
                                                                            Получать по голове от своего начальника начальники тоже не любят, поэтому адекватные начальники все таки прислушиваются к мнению специалистов
                                                                          0
                                                                          не имеют возможности эффективно работать в стандартные часы

                                                                          Ну, ради объективности, не всегда есть какая-то в этом проблема. Даже на примере самого себя могу сказать, что иногда есть банальное желание прийти «с зарей», пройдясь по пустым улицам и обдумать в такой «романтичной» прогулке план работ на день. А бывает хочется банально выспаться.

                                                                          По мне так максимально гибкое расписание — ощутимый плюс работ\команды.
                                                                          P.S. Всегда на связи — если есть необходимость, со своей стороны так же готов проявить гибкость :)
                                                                          0
                                                                          Неплохие советы, но, как известно, проэкты не проваливаются из-за программистов, а из-за плохого руководства проектами. Вот из-за плохого руководства пишется говнокод, который потом не то чтоб понять, прочесть невозможно. Переписать его тоже практически невозможно, т.к. все переплетено и находится в продакшене. Тестов естественно нет никаких. Поэтому надо хорошо продумывать архитектуру перед написанием кода и не давать никому из «талантов» ее нарушать. Для этого можно использовать code-review подход чтобы изменения контролировались и следовали задуманной архитектуре.
                                                                            +1
                                                                            Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии

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

                                                                            Избегайте совещаний
                                                                              0
                                                                              Такое ощущение, что статью писал тролль ради флейма: ошибки + взаимоисключающие параграфы
                                                                                0
                                                                                Так автор же говорит, что комментарии должны писать другие, а он — Д'Артаньян
                                                                                0
                                                                                Мне очень помогает написание документации к своей программе, UserGuide.
                                                                                  0
                                                                                  «3. Избегайте совещаний» — очень сомнительный пункт. Он может работать только тогда, когда команда очень маленькая. Когда команда состоит и более чем 5-ти человек, есть необходимость регулярного обмена состояниями (например: чтобы не искать решения уже решенных проблем, чтобы код у команды имел единую архитектуру, чтобы быть в курсе изменения требований и т. д.).
                                                                                  «4. Освойте GitHub» — реклама GitHub'а? Я слышал что на этом ресурсе банят за прямую рекламу! Но если имеется в виду любая система контроля версий (о чем говорится в описании пункта), то совет не плохой (но в этом случае пункт должен называтья «4. Освойте систему контроля версий»).
                                                                                  «6. Научитесь говорить «нет»» — такой совет многие начинающие разработчики могу понять неправильно и в дальшейм сильно недоумевать почему у них проблемы на работе (или уже на бывшей работе). Возможность сказать «нет» есть далеко не всегде, не везде и не у всех. А если ты начинающий разработчик, то лучше всего научится всегда говорить «да».
                                                                                    0
                                                                                    1. Совещание это не про обмен опыта, а обмен состояния это дейлики по 15-20 минут, они много времени не жрут. А вот когда кучу дней подряд идут совещания по три часа, где из 5 человек только двое в теме, а остальные слушают и пытаются ухватить контекст это не обмен опыта а трата времени и сил. Особенно весело в какой-то момент вначале потерять контекст а потом еще 2 часа с умным видом хлопать глазами.
                                                                                    2. Насчет сказать нет ведь не имеется в виду послать начальство, а высказать свое мнение, почему так нельзя.
                                                                                    0
                                                                                    Статью писал точно не программист. Ставлю, что это ПМ, который таким нехитрым образом поднимает эффективность своей команды, заставляя гребцов работать с раннего утра. В топку.
                                                                                      0
                                                                                      ~~~ T.D.D. ~~~
                                                                                      Просто надо понять, что написание программы в любом достаточно большом и долгом проекте (практически все, которые существуют в объективной реальности) или делается через TDD или покрывается мерзкими и неожиданными багами и медленно в муках умирает на руках обессиливших и потерявших всякую надежду вдохнуть жизнь в эту кучу сочащейся всеми жидкостями плоти программистов. Третьего варианта нет.

                                                                                      Это как строить дом вслепую, просто завязываем глаза и начинаем класть кирпичи, всё же просто. Даже какие-то приемы у людей появляются, как ловчее кирпичи эти класть, паттерны там всякие, бросаются всё это изучать, применять, называют себя программистами строителями. А надо в первую очередь контролировать получающийся результат, контролировать отсутствие его деградации от разных возмущений, обратная связь нужна, как для любой системы, от которой нам надо получить некое устойчивое состояние.
                                                                                        0
                                                                                        Не любая система с тестами (что вы описали, по-моему) построена по TDD. Система, построенная по TDD, может быть в итоге недотестирована (особенно это касается уровня интеграции компонентов).
                                                                                          0
                                                                                          Я к тому, что любая система без тестов обречена на неудачу. А все руководства по программированию делают упор на то, как половчее извернуть код, не акцентируя внимание на том, что код без тестов == половина кода. Инь без янь, белка без стрелки, и т.п. В итоге имеем, что имеем, а насмотрелся я уже на всякое. Мы программисты, мы пишем код, а вон там где-то в подвале у нас вроде тестировщики должны сидеть, пусть тестируют наши творения, вообще не наша забота уже, мы своё дело сделали, дайте нам много денег, посмотрите как хитро извёрнут и отформатирован наш прекрасный код.
                                                                                        +3
                                                                                        Однажды я попросил очень опытного водителя научить меня правильно водить машину. А он говорит:
                                                                                        — Едь как в автошколе учили, не нарушай правила.
                                                                                        — Ну это понятно. А как быстро разгоняться и проходить повороты, как выходить из заноса?
                                                                                        — Если будешь ехать по правилам, то не будет разгонов и заносов. И с машиной меньше хлопот.
                                                                                        — А если…
                                                                                        — Если скучно нормально ездить — иди с парашютом прыгай.

                                                                                        Ну, вот я отмотал мильон километров и написал мильон строк кода. Да, все так. Чем спокойнее едешь, тем меньше износ (машины и организма), тем больше можешь проехать. Больше внимания уделяется маршруту, цели поездки. Чем аккуратнее пишешь код (с говорящими именами, соблюдением стиля и правил безопасности), тем легче его читать и дорабатывать, тем больше кода и крупнее проекты можно поддерживать. То есть, код сам по себе перестает быть проблемой, можно сосредоточиться на решаемых задачах, взаимосвязях, архитектуре.

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

                                                                                        Самое читаемое