Недавно я прочитал книгу Роберта Мартина «Идеальный программист». Книга, несмотря на свою популярность, оставила у меня много вопросов, касающихся того, насколько её советы применимы в реальной жизни разработчиков.
1. Обеденный перерыв для учебы — серьёзно?
Один из моментов, который вызывает недоумение, — это рекомендация использовать обеденный перерыв для учёбы. Автор, похоже, считает, что обучение должно занимать всё свободное время программиста, включая обед. Звучит так, будто отдых и перезагрузка для продуктивности не имеют значения.
2. 12-часовой рабочий день как норма
Мартин настаивает, что профессионал должен работать 8 часов в день, а потом еще 4 часа тратить на обучение. Проблема в том, что это оставляет очень мало времени на семью, друзей или увлечения. Как такой подход может быть реалистичным для человека, у которого есть обязательства вне работы? При этом автор сам неоднократно упоминает, что в своё время работал по 60–80 часов в неделю, что приводит к вопросу: это хвастовство или жалоба?
Если вы не укладываетесь в 40 часов, то, возможно, проблемы кроются в вашем планировании или менеджменте компании, а не в том, что вы недостаточно профессиональны.
3. Алгоритмы — обязательны, но не для всех
Мартин утверждает, что каждому разработчику важно уметь писать алгоритмы, и с этим трудно не согласиться, ведь знание основ алгоритмов помогает решать задачи эффективно. Однако далеко не каждому программисту приходится ежедневно сталкиваться с задачами, где эти знания жизненно необходимы. В современном мире многие алгоритмические задачи уже решены, и есть готовые библиотеки и инструменты, которые можно использовать. Если вам всё-таки понадобятся эти знания, их легко освежить при необходимости.
4. Сети Петри и диаграммы Насси-Шнейдермана — полезные, но нечастые инструменты
Сети Петри, диаграммы Насси-Шнейдермана и автоматы Мура и Мили — это классические инструменты, которые можно однажды изучить и использовать при редкой необходимости. В повседневной практике они встречаются не часто, но их знание может стать полезным в специфических ситуациях. Они не устарели, но, как и с алгоритмами, это те вещи, которые можно временно отложить и вернуться к ним, когда потребуется.
5. Ката каждое утро
Одно из самых спорных утверждений — необходимость выполнять программные упражнения (ката) каждое утро перед работой. Звучит как обязательный ритуал, который не обязательно способствует реальному профессиональному росту.
6. Профессионализм или антисоциальное поведение?
Основная мысль книги заключается в том, что разработчик должен быть предельно погружён в работу, даже в ущерб личной жизни. Это создаёт образ программиста как человека, который живёт ради работы, что, мягко говоря, далеко от реальности. Программирование — это не «личностная черта», а профессия, и важно иметь баланс между работой и жизнью.
7. Идеальные программисты и другие профессии
Многие принципы, которые Мартин описывает как применимые исключительно к разработке, на самом деле универсальны для любой профессии. Ответственность, честность, соблюдение сроков — всё это важно не только для программистов, но и для врачей, инженеров или юристов. Автор, похоже, забывает, что многие его советы не уникальны для программирования.
8. Программирование — это не искусство
Автор сравнивает программирование с музыкой, искусством или боевыми искусствами, что для меня кажется совершенно неверным. Программирование — это прежде всего решение задач, и оно больше связано с логикой, чем с творчеством. В реальной жизни большинство разработчиков не занимаются «тренировками» своего кода — они просто эффективно решают задачи с помощью инструментов и справочных материалов.
9. Работодатель обязан заботиться о квалификации сотрудников
Мартин утверждает, что работодатель не обязан заботиться о повышении квалификации программиста. Но это идёт вразрез с реальной практикой — работодатели, заинтересованные в квалифицированных сотрудниках, должны способствовать их развитию. Никто не обязан учиться за свой счёт, если этого требует работа.
10. Структура книги: хорошие идеи, но слишком много воды
Нельзя отрицать, что Роберт Мартин — отличный разработчик с огромным опытом. Однако как автор книги он, мягко говоря, оставляет желать лучшего. Большинство его советов можно легко суммировать в несколько предложений, но вместо этого они растянуты на десятки страниц, создавая впечатление, что книга могла быть в два-три раза короче.
Проблема с «Идеальным программистом» в том, что книга перегружена ненужными подзаголовками и разрозненными мыслями, которые не всегда связаны друг с другом. Некоторые идеи повторяются на протяжении всей книги, что создаёт ощущение дежавю. Это мешает целостности повествования и заставляет задаваться вопросом, действительно ли автор знает, что хочет донести, или просто заполняет страницы.
Заключение
«Идеальный программист» Роберта Мартина — это книга, которая отражает крайние взгляды автора на профессию разработчика. Многие из предложенных им методов могут оказаться полезными для некоторых, но для большинства современных разработчиков они могут показаться устаревшими и нереалистичными. Книга, очевидно, написана не для джунов, но, с другой стороны, состоявшиеся специалисты вряд ли нуждаются в информации, которой делится автор.
Настоящий профессионал — это не тот, кто жертвует всем ради работы, а тот, кто умеет балансировать между профессиональной и личной жизнью.
Комментарии (45)
Tzimie
24.09.2024 14:33+6Погуглил его personal life. Ее нет
sergey-gornostaev
24.09.2024 14:33+2Семья с четырьмя детьми - это нет personal life?
killyself
24.09.2024 14:33+2Да ладно вам, 4 ребенка можно уложить в 8 минут. А вот если бы он действительно уделял им должное время, то и не писал бы про переработки и обучение 4 часа вне работы
askharitonov
24.09.2024 14:33Да ладно вам, 4 ребенка можно уложить в 8 минут.
Это если делать последовательно. Возможно процедуру можно оптимизировать, если использовать рекурсивный алгоритм: даётся команда старшему: уложить спать остальных и сообщить об этом, а потом остаётся уложить старшего, а он, в процессе, даёт аналогичные указания следующему ребёнку и т.д., в итоге 4-го ребёнка укладывает 3-й, того - 2-й, того - 1-й, ну и 1-го укладывает отец.
ZetaTetra
24.09.2024 14:33+10Программирование — это прежде всего решение задач, и оно больше связано с логикой, чем с творчеством.
Мне кажется это больше зависит от задачи.
Если задача: - Подвинь кнопку Submit на 20 пикселей вправо, то тут всё просто и понятно, никакого креатива.А если задача связана с придумыванием новой логики на осоновании какйо-то старой, то тут уже будет креатив. (Можно-ли соединить этот сервис с этим? А тот сервис вместе с этим сервисом решит нашу проблему или не решит? и т.д. и т.п.)
Тоже самое касается и музыки, картин и пр.:
Если музыканта попросят набросать что-то из Drum and Bass, то реализация в IDM заказчика не вдохновит. Как и написанная в абстракционизме картина, при заказе картины в ренессансе.Ukrainskiy
24.09.2024 14:33+2Думаю, в профессиональной разработке для креатива остаётся очень мало места. Задача разработчика — не придумывать что-то в стиле "А что если сделать вот так или вот так, а добавлю-ка я ещё вот это". В серьёзном проекте такое непозволительно: задачи нужно решать наиболее эффективным способом, с соблюдением установленных стандартов и паттернов. Для изобретения чего-то нового лучше применять инженерный подход: выдвигать обоснованные гипотезы, проверять их, заниматься R&D и т.д. Потом еще вероятно защищать свое решение придется перед кем-то. Не думаю, что здесь есть место креативу, до какого-то уровня да, в пет проектах или небольших компаниях это может встречаться.
19Zb84
24.09.2024 14:33+2Автор сравнивает программирование с музыкой
Попробуйте написать полифоническое произведение в строгом стиле.
Это не придумывать что-то в стиле "А что если сделать вот так или вот так, а добавлю-ка я ещё вот это". В серьёзной музыке такое непозволительно: музыку нужно писать наиболее эффективным способом, с соблюдением установленных стандартов и паттернов.
shushara4241
нет