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

1. Обеденный перерыв для учебы — серьёзно?

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

2. 12-часовой рабочий день как норма

Мартин настаивает, что профессионал должен работать 8 часов в день, а потом еще 4 часа тратить на обучение. Проблема в том, что это оставляет очень мало времени на семью, друзей или увлечения. Как такой подход может быть реалистичным для человека, у которого есть обязательства вне работы? При этом автор сам неоднократно упоминает, что в своё время работал по 60–80 часов в неделю, что приводит к вопросу: это хвастовство или жалоба?

Если вы не укладываетесь в 40 часов, то, возможно, проблемы кроются в вашем планировании или менеджменте компании, а не в том, что вы недостаточно профессиональны.

3. Алгоритмы — обязательны, но не для всех

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

4. Сети Петри и диаграммы Насси-Шнейдермана — полезные, но нечастые инструменты

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

5. Ката каждое утро

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

6. Профессионализм или антисоциальное поведение?

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

7. Идеальные программисты и другие профессии

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

8. Программирование — это не искусство

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

9. Работодатель обязан заботиться о квалификации сотрудников

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

10. Структура книги: хорошие идеи, но слишком много воды

Нельзя отрицать, что Роберт Мартин — отличный разработчик с огромным опытом. Однако как автор книги он, мягко говоря, оставляет желать лучшего. Большинство его советов можно легко суммировать в несколько предложений, но вместо этого они растянуты на десятки страниц, создавая впечатление, что книга могла быть в два-три раза короче.

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

Заключение

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

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

Комментарии (44)


  1. shushara4241
    24.09.2024 14:33
    +3

    нет


  1. Tzimie
    24.09.2024 14:33
    +6

    Погуглил его personal life. Ее нет


    1. sergey-gornostaev
      24.09.2024 14:33
      +2

      Семья с четырьмя детьми - это нет personal life?


      1. killyself
        24.09.2024 14:33
        +2

        Да ладно вам, 4 ребенка можно уложить в 8 минут. А вот если бы он действительно уделял им должное время, то и не писал бы про переработки и обучение 4 часа вне работы


        1. askharitonov
          24.09.2024 14:33

          Да ладно вам, 4 ребенка можно уложить в 8 минут.

          Это если делать последовательно. Возможно процедуру можно оптимизировать, если использовать рекурсивный алгоритм: даётся команда старшему: уложить спать остальных и сообщить об этом, а потом остаётся уложить старшего, а он, в процессе, даёт аналогичные указания следующему ребёнку и т.д., в итоге 4-го ребёнка укладывает 3-й, того - 2-й, того - 1-й, ну и 1-го укладывает отец.


          1. killyself
            24.09.2024 14:33

            Sweet home, Alabama..


  1. ZetaTetra
    24.09.2024 14:33
    +10

    Программирование — это прежде всего решение задач, и оно больше связано с логикой, чем с творчеством.

    Мне кажется это больше зависит от задачи.
    Если задача: - Подвинь кнопку Submit на 20 пикселей вправо, то тут всё просто и понятно, никакого креатива.

    А если задача связана с придумыванием новой логики на осоновании какйо-то старой, то тут уже будет креатив. (Можно-ли соединить этот сервис с этим? А тот сервис вместе с этим сервисом решит нашу проблему или не решит? и т.д. и т.п.)

    Тоже самое касается и музыки, картин и пр.:
    Если музыканта попросят набросать что-то из Drum and Bass, то реализация в IDM заказчика не вдохновит. Как и написанная в абстракционизме картина, при заказе картины в ренессансе.


    1. Ukrainskiy
      24.09.2024 14:33
      +2

      Думаю, в профессиональной разработке для креатива остаётся очень мало места. Задача разработчика — не придумывать что-то в стиле "А что если сделать вот так или вот так, а добавлю-ка я ещё вот это". В серьёзном проекте такое непозволительно: задачи нужно решать наиболее эффективным способом, с соблюдением установленных стандартов и паттернов. Для изобретения чего-то нового лучше применять инженерный подход: выдвигать обоснованные гипотезы, проверять их, заниматься R&D и т.д. Потом еще вероятно защищать свое решение придется перед кем-то. Не думаю, что здесь есть место креативу, до какого-то уровня да, в пет проектах или небольших компаниях это может встречаться.


      1. 19Zb84
        24.09.2024 14:33
        +2

        Автор сравнивает программирование с музыкой

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


        1. killyself
          24.09.2024 14:33
          +3

          Буквально описали всю попсу


          1. 19Zb84
            24.09.2024 14:33

            Буквально описали всю попсу

            )) Я бы сказал это канон. Если мы об одном и том же